Comment tirer le meilleur parti de GitOps dès maintenant

GitOps est un excellent point de départ pour comprendre ce qui s'exécute en production, mais il faudra peut-être un peu plus d'amélioration pour qu'il fonctionne parfaitement pour votre équipe d'ingénierie.

Vous avez peut-être rencontré cette brève introduction à GitOps partagée par Kelsey Hightower, ingénieur logiciel cloud répandu :

GitOps : CI/CD versionné au-dessus de l'infrastructure déclarative. Arrêtez les scripts et commencez à expédier. https://t.co/SgUlHgNrnY

– Kelsey Hightower (@kelseyhightower) 17 janvier 2018

Dans le monde de l'infrastructure en tant que code, GitOps est un moyen populaire de gérer les déploiements automatisés via l'intégration continue/le développement continu (CI/CD) et l'architecture de microservices en général, car la plupart de notre infrastructure est aujourd'hui essentiellement définie dans des fichiers de configuration (par exemple, YAML). , JSON, HCL). Cela ne se limite pas à Kubernetes (K8), mais est souvent fortement associé aux clusters K8. (J'expliquerai pourquoi dans une seconde.) Cela signifie essentiellement que changer quoi que ce soit dans votre infrastructure de production est aussi simple que changer une ligne de code.

La raison pour laquelle GitOps est si étroitement identifié avec K8 est que K8 est entièrement configuré en YAML déclaratif et, par conséquent, vous pouvez rapidement bénéficier des avantages de l'utilisation de GitOps car il ne s'agit en réalité que d'une infrastructure définie par logiciel. Lorsqu'il s'agit d'appliquer correctement GitOps dans votre organisation d'ingénierie, la principale chose à laquelle vous devez prêter attention est la manière dont vous appliquez les modifications à votre cluster ou à votre infrastructure.

Lorsque vous choisissez la voie GitOps, vous ne pouvez le faire qu'à travers une seule source de vérité : votre référentiel de gestion du code source (SCM) (par exemple, GitLab, GitHub, Bitbucket ou votre propre solution d'hébergement) qui applique la politique de contrôle de version. pour l'ensemble de votre organisation. Cela signifie que la seule façon d’apporter des modifications à votre infrastructure consiste à effectuer une pull request dans votre référentiel. C'est ainsi que le contrôle de version est maintenu à grande échelle dans les grandes organisations d'ingénierie utilisant GitOps.

L'état des déploiements dans le monde réel

La doctrine GitOps prétend être le moyen nouveau et plus simple de réaliser le CI/CD, sauf que la partie CD du CI/CD est une bête beaucoup plus complexe que les pratiques GitOps ne voudraient vous le faire croire. Avec GitOps, la partie CD se résume à une approche très binaire des environnements d'ingénierie. Vous êtes soit en préparation, soit en production, où il vous suffit d'appuyer sur le commutateur et votre code est en production. Au cours de mes années d'expérience en tant qu'ingénieur, je n'ai pas encore participé à un changement de code important, à un déploiement de fonctionnalités ou à un autre déploiement majeur aussi simple.

Il y a beaucoup plus de travail encapsulé dans la mise en scène ou la gestion des versions de production complètement abstraite du processus de CD avec GitOps. Cela signifie que tout processus d'ingénierie qui prend la qualité au sérieux comportera quelques étapes entre les phases CI et CD d'un déploiement majeur. Ceux-ci incluent des tests, la validation des résultats, la vérification de la propagation des modifications, de nouveaux tests et souvent des déploiements partiels (Canary et autres). Ce ne sont là que quelques exemples de la manière dont le CD est géré dans les organisations d'ingénierie.

Conseils GitOps pour mieux effectuer les déploiements

Lorsqu'il s'agit de GitOps, il n'est pas nécessaire de réinventer la roue CI/CD (et en particulier la roue CD). Si vous êtes comme la plupart des gens et que vous réalisez le CI/CD en scotchant votre processus de CD avec des scripts personnalisés avant et après le déploiement pour franchir la ligne d'arrivée, sachez qu'il existe de meilleures façons de le faire avec les facilitateurs GitOps. À l'aide de facilitateurs GitOps tels que l'open source, le CD Argo hébergé par la Cloud Native Computing Foundation (CNCF) permet aux utilisateurs de prendre tous ces scripts personnalisés et de les gérer à grande échelle en un seul endroit. Cela garantit les meilleures pratiques lors de l'utilisation de scripts dans votre processus CI/CD, les rendant canoniques et reproductibles à chaque exécution.

De plus, puisqu'il existe un agent qui synchronise en permanence l'état, il réduit les erreurs humaines en appliquant l'état validé.

Gérez le chaos dans les référentiels avec GitOps

Avec des architectures de déploiement complexes telles que les K8 ou même de simples microservices anciens, même de petites modifications apportées au code affectent souvent d'autres services interdépendants. Cartographier ces dépendances avec GitOps a tendance à devenir un paysage infernal. Souvent, avec les dépôts et les fichiers partagés, vous devez synchroniser l'état. Cependant, ce que vous constaterez aussi souvent, c'est que des erreurs, des erreurs de configuration ou même simplement des bugs peuvent créer un effet papillon qui déclenche une cascade d'échecs qui devient extrêmement difficile à suivre et à comprendre dans GitOps.

Une méthode courante pour résoudre ce problème avec GitOps consiste à créer un « super dépôt », qui est essentiellement un monorepo centralisé contenant des pointeurs vers toutes les dépendances, fichiers, ressources, etc. Cependant, cela devient rapidement un « fourre-tout » désordonné d'un référentiel, où il est extrêmement difficile de comprendre, suivre et enregistrer les modifications.

Lorsque vous avez de nombreuses dépendances, pour que cela fonctionne dans GitOps, ces dépendances doivent être représentées dans Git. Cela nécessite que votre organisation soit « native de Git ». Cela signifie que vous devrez effectuer de nombreux travaux d'automatisation pour créer des modules et des sous-modules permettant de connecter et d'établir une corrélation entre votre super repo et les sous-dépôts concernés. Souvent, cela s’accompagne de nombreux frais de maintenance qui deviennent extrêmement difficiles à maintenir au fil du temps.

Si vous ne le faites pas, vous ne bénéficierez pas des avantages de GitOps et vous vous retrouverez principalement avec les inconvénients. Vous pouvez obtenir des fonctionnalités similaires grâce à un fichier YAML qui encapsule toutes les versions et dépendances, à la manière d'un graphique parapluie Helm. Sans devenir entièrement natif de Git, vous pourriez essentiellement être autre chose, et non GitOps.

Alors que dans le monde GitOps, les dépôts représentent la source unique de vérité pour les environnements, en pratique, il existe de nombreuses intégrations tierces dans un déploiement donné. Ces intégrations peuvent aller de votre authentification et autorisation (par exemple, Auth0) à votre base de données, qui sont, pour la plupart, mises à jour en externe à votre dépôt. Ces modifications apportées aux ressources externes, qui pourraient avoir un impact significatif sur votre production et vos déploiements, n'ont aucune représentation dans votre dépôt à source unique de vérité. Cela pourrait constituer un sérieux angle mort dans l’ensemble de votre déploiement.

Conseils GitOps pour mieux gérer le chaos

Lorsque vous utilisez GitOps, traitez vos configurations de la même manière que vous traiteriez votre code. Ne lésinez pas sur les pipelines de validation, assurez une bonne hygiène des demandes d'extraction et maintenez toutes les autres pratiques que vous appliquez lors de la gestion du code à grande échelle pour éviter ce chaos. Ne pas paniquer! Si quelque chose d'incorrect est poussé et que vous craignez qu'il se propage à tous les serveurs, clusters et dépôts, tout ce que vous avez à faire est d'exécuter git revert et vous pourrez annuler votre dernier commit.

De plus, comme ma recommandation concernant l'état de synchronisation, l'utilisation de facilitateurs GitOps peut aider à gérer les pratiques Git, à être natif de Git et à gérer les déploiements Kubernetes (tout en étant natif de Kubernetes).

Enfin, pour éviter tout désordre ou complexité, assurez-vous que l'état de votre dépôt Git est le plus proche possible de vos environnements de production pour éviter toute dérive de vos environnements par rapport à votre fonctionnement GitOps.

3 conseils pour utiliser GitOps

Voici mes conseils pour tirer le meilleur parti de GitOps :

1. Assurez-vous de renforcer la visibilité de votre automatisation GitOps dès le début, afin de ne pas être aveugle sur vos nombreux dépôts. Lorsqu'il s'agit de faire fonctionner GitOps de manière optimale, vous devez travailler avec un seul dépôt par application. Lorsque ces éléments commencent à s’additionner, la visibilité peut devenir un véritable problème. Pensez aux dépendances et à la manière de garantir une visibilité suffisante sur le système. Ainsi, si quelque chose ne va pas, vous saurez comment le retrouver jusqu'à sa source et le réparer.
2. Une façon d’y parvenir est de planifier chaque type de scénario d’échec. Que se passe-t-il lorsque les dépendances tombent en panne ? Lorsqu'il s'agit de GitOps, les conflits de fusion sont un mode de vie. Comment gérer les déploiements à grande vitesse et les promotions en production qui peuvent submerger un système GitOps ? Pensez aux nombreux défis, échecs et conflits potentiels et préparez un manuel pour chacun. Aussi, dans le prolongement du premier point, assurez-vous d'avoir une visibilité suffisante pour que chacun puisse dépanner rapidement. Et bien sûr, n'oubliez pas la commande git revert en cas d'échec.
3. Utilisez un monorepo. Là, je l'ai dit. Le débat séculaire entre mono et multi-repo. Lorsqu'il s'agit de GitOps, il ne fait aucun doute quel est le meilleur choix. Bien qu'un monorepo centralisé présente des inconvénients (par exemple, il peut devenir compliqué, devenir un cauchemar pour comprendre les processus de construction, etc.), il peut également aider à résoudre une grande majorité des problèmes liés aux dépendances entre dépôts.

En tant qu'ingénieur, j'ai ressenti cette douleur directement. J'ai réalisé qu'il y avait un besoin urgent de quelque chose pour corréler ces dépendances et les défis de visibilité que j'ai ressentis chaque jour de ma vie GitOps.

Je voulais une meilleure solution pour suivre et relier les pannes dans une configuration de microservices complexe à une cause première ou à un changement de code. Tout ce que j'avais essayé jusqu'à présent, y compris GitOps, ne fournissait que des informations partielles, très peu de corrélation et presque aucune causalité.

Les outils GitOps (comme Argo CD) aident à résoudre de nombreux problèmes qui surviennent avec DIY GitOps. L'utilisation de tels outils peut être une bonne chose à considérer lorsque vous empruntez la voie GitOps, car ils :

• Sont conçus nativement pour Kubernetes
• Sont adaptés aux petites équipes utilisant un extracteur d'images
• Avoir un fort soutien de la communauté (par exemple, le CD Argo via la CNCF, qui est également facile à utiliser avec d'autres outils Argo)
• Fournir une expérience de développement améliorée avec une bonne interface utilisateur pour les applications
• Intégration native à Git, ce qui permet de minimiser le chaos et la complexité

L'essentiel

Les processus de déploiement, en particulier avec les nouvelles versions, constituent une prouesse d'ingénierie complexe. Pour y parvenir, vous devez investir des efforts à la fois dans la technologie et dans la conception du processus. Par exemple, quelle est la meilleure façon de déployer et de valider mon application en production ?

GitOps est un très bon point de départ pour comprendre ce qui se passe en production. Gardez simplement à l’esprit qu’il faudra peut-être également un peu plus d’amélioration avec des outils supplémentaires et une automatisation de bricolage pour qu’il fonctionne parfaitement pour votre équipe d’ingénierie. De cette façon, l'éclat de GitOps est 24K plutôt que de l'or des fous pour votre organisation.