La base de cette liste repose sur plusieurs années d'expérience dans la prise en charge de l'automatisation pour l'équipe d'exécution de conteneurs en amont (podman, buildah, skopeo, etc.). Je ne m'attribuerai pas tout le mérite, car bon nombre de ces conseils sont basés sur un amalgame d'expériences évoluées et de contributions individuelles d'une vaste communauté d'utilisateurs et de développeurs.
La plupart des éléments ci-dessous peuvent se résumer à un seul principe :Éliminer ou réduire la complexité . Ce concept est basé sur une application composée de la loi de Murphy :Plus vous avez de "choses cassables", plus Murphy sera susceptible d'apparaître. Voici huit façons d'éviter ces rencontres fortuites.
[ Les lecteurs ont également aimé : Présentation du nouveau hub d'automatisation Ansible ]
1. Réduire les dépendances réseau
Réduisez les dépendances réseau, en particulier vis-à-vis des services tiers sur lesquels vous n'avez aucun contrôle. En outre, les services réseau de premier et de deuxième partie doivent être considérés comme "à éviter si possible". Il y a en fait deux aspects dans cette recommandation :
- De tous points de vue, la mise en réseau est un système très complexe de composants connexes et de relations en temps réel. D'une manière générale, tout cela doit fonctionner presque parfaitement d'un bout à l'autre, sinon vous risquez de passer une mauvaise journée.
- Encore une fois, d'une manière générale, les pannes de réseau sont souvent transitoires et dépendantes du temps (tout le monde souhaite qu'elles soient corrigées rapidement). Cela peut rendre le débogage après coup incroyablement difficile. Même avec une journalisation intensive, les effets non observés peuvent commencer votre mauvaise journée.
2. Réduire les dépendances logicielles
Dans la mesure du possible, réduisez les dépendances logicielles, en particulier vis-à-vis des bibliothèques tierces. Cela inclut à la fois votre sujet d'automatisation principal et tout code d'automatisation partagé. À moins que vous ne verrouilliez la version de chaque composant de haut en bas de la pile, vous risquez de tomber en panne en raison d'un comportement inattendu ou de changements d'API quelque part. La situation est légèrement meilleure lorsque vous contrôlez le code inclus mais présente toujours un risque.
Remarque :Je reconnais que cette astuce peut être assez controversée et qu'elle n'a certainement pas de sens dans de nombreuses situations. Considérez cela comme un rappel "pensez-y à deux fois", surtout lorsque vous vous retrouvez à vouloir qu'une bibliothèque intègre une fonction simple.
3. Organiser les tâches d'automatisation
Organisez les tâches d'automatisation dans l'ordre décroissant des conséquences de l'échec. En d'autres termes, essayez d'identifier les éléments ayant le plus grand impact négatif le plus tôt possible. L'idée ici est d'économiser des ressources (y compris du temps) pour les "Whoopsies" à fort impact et à faible coût de détection. Quelques exemples de tests d'intégration continue (CI) VCS :
- Vos services réseau tiers sont-ils joignables ? Par exemple, peuvent-ils recevoir un ping et valider leurs certificats SSL ?
- Votre fournisseur ou le code inclus correspond-il réellement à la liste d'exigences documentée et configurée ?
- Quelqu'un a-t-il accidentellement laissé un commentaire "FIXME" dans le code nouvellement validé ?
- Tous les nouveaux commits sont-ils signés ?
- Les modifications correspondent-elles au contexte d'exécution ?
Au fil du temps, l'effet de ce flux de travail est que les contrôles importants recevront le plus d'attention et la maintenance la plus fiable (puisque les pannes ont tendance à bloquer tout le train). À leur tour, les développeurs pourront également cycler plus rapidement. Par exemple, ils n'attendront pas longtemps pour découvrir qu'ils ont mal orthographié leur propre nom.
4. Gardez les emplois courts
Gardez les travaux aussi courts que possible et en "morceaux" facilement reproductibles. Cela dépendra en grande partie du logiciel d'orchestration, mais la plupart des applications permettent plusieurs étapes d'exécution. En utilisant un autre exemple de test CI, si vous avez des tests unitaires, d'intégration et système à exécuter (dans cet ordre), évitez de les exécuter tous ensemble, l'un après l'autre, dans un seul script. De cette façon, si l'étape d'intégration échoue, les utilisateurs ne sont pas obligés de relancer les tests unitaires. Cela améliore la fiabilité en ne réexécutant pas les opérations redondantes, invitant inutilement Murphy à revenir dans le train d'engrenages de l'automatisation.
5. Éviter les opérations non essentielles lors de l'exécution
Évitez les opérations non essentielles (telles que l'installation ou la configuration) lors de l'exécution. Au lieu de cela, préparez vos environnements d'exécution avec tous les éléments nécessaires à l'avance. Cela rend non seulement les choses plus efficaces, mais cela aide également à respecter les autres conseils de cet article. Il permet également d'observer et de tester l'environnement pré-construit au moment de la construction. Si vos environnements sont partagés entre des travaux avec des exigences différentes, envisagez de mettre en cache ces composants/packages dans l'image. L'installation au moment de l'exécution à partir d'un cache local est bien plus sûre et plus fiable que d'accéder à un référentiel distant sur le réseau.
6. Utilisez les bons outils
Utilisez les outils les plus élémentaires disponibles pour la tâche à accomplir. Par exemple, si vous devez vérifier les drapeaux binaires après avoir appliqué un masque binaire, n'essayez pas de le faire dans un script bash. De même, si votre programme C++ exécute simplement une série de commandes, utilisez bash à la place. Cela améliore la fiabilité en n'exposant pas les opérations à des effets secondaires sans rapport avec l'objectif principal de la tâche.
7. Suivre les échecs
Suivez les échecs en fonction de la fréquence de leur signature. La plupart du temps (mais pas toujours), les échecs d'automatisation entraîneront l'enregistrement d'une indication quelque part. Identifiez et classez-les (par exemple, par nom de demande) afin de pouvoir conserver un enregistrement centralisé des occurrences. On peut dire que cela demande beaucoup de travail, ce qui peut vous obliger à apprendre et à vous interfacer avec plusieurs services et API. Cependant, avec les résultats triés par fréquence de signature, vous repérerez rapidement les problèmes qui touchent le plus grand nombre de personnes. Ces éléments devraient recevoir le plus d'attention et auront le plus grand impact sur la fiabilité de l'automatisation.
8. Utilisez les commentaires efficacement
Commentez pourquoi pas comment . Supposons que n'importe quel lecteur de votre code peut déterminer la façon dont il fonctionne. Ils ne peuvent pas déterminer ce que vous (l'auteur) pensiez lorsque vous avez écrit le code. L'automatisation implique de nombreuses pièces mobiles. Certaines des relations peuvent ne pas être évidentes pour un lecteur non initié. Les commentaires sont particulièrement utiles lorsqu'ils informent sur les relations entre les composants.
Par exemple, considérez le commentaire suivant :
# Default variable value comes from CI unless executed manually.
# Detect this (`$CI == false`) to ensure the user did not leave
# the value blank. Vous devriez facilement imaginer le code que cela orne - une forme de définition ou de validation de variable. De plus, il faisait allusion à une source d'informations supplémentaire, "CI" (quoi que cela signifie dans le contexte du script).
Des commentaires utiles comme celui-ci n'ont pas besoin d'orner chaque ligne de votre script; les cibler. Concentrez-vous sur les éléments impactés par des fichiers ou des forces externes (y compris les éruptions solaires). Ces détails rendent l'automatisation plus fiable en garantissant que la "sauce secrète" est transmise en permanence à toute personne chargée des améliorations ou de la maintenance futures.
[ Un guide gratuit de Red Hat :5 étapes pour automatiser votre entreprise. ]
Récapitulez
Dans la plupart des situations, il sera impossible de suivre tous ces conseils. Ils sont destinés à servir de lignes directrices pour un compromis lorsque des implémentations alternatives sont raisonnables. Sinon, pour servir au mieux vos parties prenantes, enfreindre certains de ces principes sera parfois nécessaire. Pourtant, d'autres (comme écrire de bons commentaires) auront tendance à avoir un effet subtil mais constant au fil du temps. Je serai le premier à admettre que faire les choses simplement est souvent beaucoup plus difficile que de taper sur du ruban adhésif. Cependant, avec le temps, la plupart des rubans adhésifs deviennent secs et croustillants, ce qui vous oblige à résoudre à nouveau le problème. Rendez service à votre futur moi, passez du temps à refactoriser vers la simplicité depuis le début.