👨🏾‍🎓 👼🏾 🙍🏿 Qu'est-ce que GitOps? 😩 🙋🏾 🧜🏿

Remarque perev. : Après la publication récente de matériel sur les méthodes pull and push dans GitOps, nous avons constaté un intérêt pour ce modèle dans son ensemble, cependant, il y avait très peu de publications en russe sur ce sujet (elles ne sont tout simplement pas sur le hub). Par conséquent, nous sommes heureux de porter à votre attention une traduction d'un autre article - bien qu'il y ait presque un an! - de la société Weaveworks, dont le chef a inventé le terme "GitOps". Le texte explique l'essence de l'approche et les principales différences par rapport aux approches existantes.

Il y a un an, nous avons publié une introduction à GitOps . Ensuite, nous avons expliqué comment l'équipe Weaveworks a lancé le SaaS basé sur Kubernetes et développé un ensemble de meilleures pratiques normatives pour le déploiement, la gestion et la surveillance dans un environnement natif cloud.

L'article s'est avéré être populaire. D'autres personnes ont commencé à parler de GitOps, ont commencé à publier de nouveaux outils pour git push , développement , secrets , fonctions , intégration continue , etc. Un grand nombre de publications et de cas d'utilisation de GitOps sont apparus sur notre site. Mais certaines personnes ont encore des questions. En quoi le modèle diffère-t-il de l' infrastructure traditionnelle en tant que code et livraison continue? Est-il obligatoire d'utiliser Kubernetes?

Bientôt, nous avons réalisé qu'une nouvelle description était nécessaire, offrant:

Un grand nombre d'exemples et d'histoires;
La définition spécifique de GitOps;
Comparaison avec la livraison continue traditionnelle.

Dans cet article, nous avons essayé de couvrir tous ces sujets. Vous y trouverez une introduction mise à jour de GitOps et un regard du côté des développeurs et CI / CD. Nous nous concentrons principalement sur Kubernetes, bien que le modèle puisse être généralisé.

Rencontrez GitOps

Imaginez Alice. Elle dirige Family Insurance, une entreprise qui propose des polices d'assurance maladie, automobile, immobilier et voyage aux personnes trop occupées pour comprendre par elles-mêmes les nuances de leurs contrats. Son entreprise a commencé comme un projet parallèle quand Alice a travaillé à la banque en tant que data scientist. Une fois qu'elle a réalisé qu'elle pouvait utiliser des algorithmes informatiques avancés pour analyser plus efficacement les données et former des packages d'assurance. Les investisseurs ont financé le projet, et maintenant son entreprise rapporte plus de 20 millions de dollars par an et connaît une croissance rapide. Actuellement, 180 personnes y occupent différents postes. Parmi eux, une équipe technologique qui développe, maintient un site, une base de données et analyse la clientèle. Une équipe de 60 personnes est dirigée par Bob, directeur technique de l'entreprise.

L'équipe de Bob déploie des systèmes de production dans le cloud. Leurs principales applications fonctionnent sur GKE, profitant de Kubernetes sur Google Cloud. De plus, ils utilisent divers outils pour travailler avec des données et des analyses dans leur travail.

L'assurance familiale n'allait pas utiliser de conteneurs, mais était enthousiasmée par Docker. Bientôt, les experts de l'entreprise ont découvert que GKE facilite et déploie facilement les clusters pour tester de nouvelles fonctionnalités. Jenkins pour CI et Quay ont été ajoutés pour organiser le registre des conteneurs, des scripts pour Jenkins ont été écrits pour pousser ou créer de nouveaux conteneurs et configurations dans GKE.

Un certain temps s'est écoulé. Alice et Bob ont été déçus par la performance de l'approche choisie et son impact sur l'entreprise. L'introduction de conteneurs n'a pas augmenté la productivité autant que l'espérait l'équipe. Parfois, les déploiements se cassaient et il n'était pas clair si les modifications du code étaient à blâmer. Il s'est également avéré difficile de suivre les changements dans les configurations. Il était souvent nécessaire de créer un nouveau cluster et d'y déplacer des applications, car c'était le moyen le plus simple d'éliminer le gâchis dans lequel le système se transformait. Alice craignait que la situation ne s'aggrave au fur et à mesure du développement de l'application (en outre, un nouveau projet basé sur l'apprentissage automatique se préparait). Bob a automatisé la plupart des travaux et n'a pas compris pourquoi le pipeline est toujours instable, ne s'adapte pas bien et nécessite une intervention manuelle de temps en temps?

Ils ont ensuite découvert GitOps. Cette décision s'est avérée être exactement ce dont ils avaient besoin pour avancer en toute confiance.

Alice et Bob ont entendu parler des workflows basés sur Git, DevOps et l'infrastructure comme code pendant des années. Le caractère unique de GitOps est qu'il apporte un certain nombre de meilleures pratiques - catégoriques et normatives - pour mettre en œuvre ces idées dans le contexte de Kubernetes. Ce sujet a été soulevé à plusieurs reprises , notamment sur le blog Weaveworks .

L'assurance familiale décide de mettre en œuvre GitOps. La société dispose désormais d'un modèle d'exploitation automatisé compatible avec Kubernetes qui allie vitesse et stabilité , car ils:

a constaté que l'équipe a doublé sa productivité et que personne ne devient fou;
arrêté de réparer les scripts. Au lieu de cela, ils peuvent désormais se concentrer sur de nouvelles fonctionnalités et améliorer les méthodes d'ingénierie - par exemple, introduire des déploiements de canaris et améliorer les tests;
processus de déploiement amélioré - maintenant il se casse rarement;
obtenu la possibilité de récupérer des déploiements après des échecs partiels sans intervention manuelle;
acquis une plus grande confiance dans les systèmes d'approvisionnement. Alice et Bob ont constaté que l'équipe peut être divisée en groupes qui travaillent en microservices et travaillent en parallèle;
peut apporter 30 à 50 changements au projet chaque jour grâce aux efforts de chaque groupe et essayer de nouvelles techniques;
ils sont facilement attirés par le projet par de nouveaux développeurs qui ont la possibilité de lancer des mises à jour sur la production en utilisant des requêtes pull en quelques heures;
facilement audité dans SOC2 (pour la conformité des fournisseurs de services avec les exigences de gestion sécurisée des données; en savoir plus, par exemple, ici - traduction approximative) .

Qu'est-il arrivé?

Les GitOps sont deux choses:

Modèle de fonctionnement pour Kubernetes et cloud native. Il fournit un ensemble de meilleures pratiques pour le déploiement, la gestion et la surveillance des clusters et applications conteneurisés. Définition élégante dans une seule diapositive de Luis Faceira :
Chemin vers la création d'un environnement orienté développeur pour la gestion des applications. Nous appliquons le workflow Git à l'exploitation et au développement. Veuillez noter qu'il ne s'agit pas seulement de Git push, mais de l'organisation de l'ensemble des outils CI / CD et UI / UX.

Quelques mots sur Git

Si vous n'êtes pas familier avec les systèmes de contrôle de version et le workflow basé sur Git, nous vous recommandons fortement de les étudier. Au début, travailler avec des branches et des demandes de tirage peut sembler de la magie noire, mais les pros en valent la peine. Voici un bon article pour commencer.

Comment fonctionne Kubernetes

Dans notre histoire, Alice et Bob se sont tournés vers GitOps après avoir travaillé avec Kubernetes pendant un certain temps. En effet, GitOps est étroitement lié à Kubernetes - c'est un modèle opérationnel pour l'infrastructure et les applications basées sur Kubernetes.

Que propose Kubernetes aux utilisateurs?

Voici quelques fonctionnalités clés:

Dans le modèle Kubernetes, tout peut être décrit sous une forme déclarative.
Le serveur API Kubernetes accepte une telle déclaration en entrée, puis essaie constamment d'amener le cluster à l'état décrit dans la déclaration.
Les déclarations sont suffisantes pour décrire et gérer une grande variété de charges de travail - «applications».
Par conséquent, les modifications apportées à l'application et au cluster sont dues à:
- modifications des images de conteneurs;
- modifications de la spécification déclarative;
- des erreurs dans l'environnement - par exemple, un conteneur se bloque.

Les grandes capacités de convergence de Kubernetes

Lorsqu'un administrateur apporte des modifications de configuration, l'orchestrateur Kubernetes les applique au cluster jusqu'à ce que son état approche de la nouvelle configuration . Ce modèle fonctionne pour toutes les ressources Kubernetes et s'étend aux définitions de ressources personnalisées (CRD). Par conséquent, les déploiements Kubernetes ont les merveilleuses propriétés suivantes:

Automatisation : les mises à jour de Kubernetes fournissent un mécanisme pour automatiser le processus d'application des modifications correctement et en temps opportun.
Convergence : Kubernetes continuera de tenter des mises à jour jusqu'à ce qu'il réussisse.
Idempotence : des applications répétées de convergence produisent le même résultat.
Déterminisme : avec des ressources suffisantes, l'état du cluster mis à jour ne dépend que de l'état souhaité.

Comment fonctionne GitOps

Nous en avons assez appris sur Kubernetes pour expliquer le fonctionnement de GitOps.

Revenons aux équipes d'assurance familiale liées aux microservices. Que doivent-ils généralement faire? Regardez la liste ci-dessous (si certains points semblent étranges ou inconnus - veuillez reporter les critiques et rester avec nous). Ce ne sont que des exemples de workflows basés sur Jenkins. Il existe de nombreux autres processus lorsque vous travaillez avec d'autres outils.

L'essentiel est que nous voyons que chaque mise à jour se termine par des modifications des fichiers de configuration et des référentiels Git. Ces modifications dans Git entraînent la mise à jour de la «déclaration GitOps» du cluster:

1. Workflow: « Jenkins Build - branche principale ».
La liste des tâches:

Jenkins envoie des images balisées à Quay;
Jenkins push'it config et Helm charts vers le compartiment de stockage principal;
La fonction cloud copie la configuration et les graphiques du compartiment de stockage principal dans le référentiel git principal;
L'instruction GitOps met à jour le cluster.

2. Jenkins build - branche release ou hotfix :

Jenkins pousse des images non marquées à Quay;
Jenkins pousse les graphiques de configuration et de barre dans le compartiment de stockage intermédiaire;
La fonction cloud copie la configuration et les graphiques du compartiment du stockage intermédiaire au stockage intermédiaire du référentiel Git;
L'instruction GitOps met à jour le cluster.

3. Jenkins build - développer ou développer une branche :

Jenkins pousse des images non marquées à Quay;
Jenkins pousse les graphiques de configuration et de barre dans le compartiment de stockage de développement;
La fonction cloud copie la configuration et les graphiques du compartiment de stockage de développement vers le référentiel de développement git;
L'instruction GitOps met à jour le cluster.

4. Ajout d'un nouveau client :

Un gestionnaire ou un administrateur (LCM / ops) appelle Gradle pour déployer et configurer initialement les équilibreurs de charge réseau (NLB);
LCM / ops commet une nouvelle configuration pour préparer le déploiement pour les mises à jour;
L'instruction GitOps met à jour le cluster.

Brève description de GitOps

Décrivez l'état souhaité de l'ensemble du système à l'aide de spécifications déclaratives pour chaque environnement (dans notre histoire, l'équipe Bob définit la configuration complète du système dans Git).
- Le référentiel git est la seule source de vérité concernant l'état souhaité de l'ensemble du système.
- Toutes les modifications de l'état souhaité sont effectuées via des validations dans Git.
- Tous les paramètres de cluster souhaités sont également observables dans le cluster lui-même. Ainsi, nous pouvons déterminer si les états souhaités et observés coïncident (convergent, convergent ) ou diffèrent ( divergent , divergent ).
Si les états souhaités et observés sont différents, alors:
- Il existe un mécanisme de convergence qui synchronise tôt ou tard automatiquement les états cible et observé. À l'intérieur du cluster, Kubernetes fait cela.
- Le processus démarre immédiatement avec une notification de «modification validée».
- Après une période de temps configurable, une alerte diff peut être envoyée si les états sont différents.
Ainsi, toutes les validations dans Git déclenchent des mises à jour vérifiables et idempotentes dans le cluster.
- La restauration est une convergence vers un état précédemment souhaité.
La convergence est définitive. À propos de son apparition témoignent:
- Absence d'alertes "diff" pendant un certain temps.
- Une alerte convergente (par exemple, webhook, événement d'écriture différée Git).

Qu'est-ce que la divergence?

Nous répétons encore une fois: toutes les propriétés souhaitées du cluster doivent être observables dans le cluster lui-même .

Quelques exemples de divergence:

Changement dans le fichier de configuration en raison de la fusion des branches dans Git.
Un changement dans le fichier de configuration en raison d'une validation dans Git effectuée par le client GUI.
Plusieurs changements dans l'état souhaité en raison de PR dans Git avec l'assemblage ultérieur de l'image du conteneur et des modifications de la configuration.
Changement d'état du cluster en raison d'une erreur, d'un conflit de ressources entraînant un «mauvais comportement» ou simplement d'une déviation accidentelle par rapport à l'état d'origine.

Qu'est-ce qu'un mécanisme de convergence?

Quelques exemples:

Pour les conteneurs et les clusters, le mécanisme de convergence fournit Kubernetes.
Le même mécanisme peut être utilisé pour gérer les applications et les conceptions basées sur Kubernetes (par exemple, Istio et Kubeflow).
Le mécanisme de gestion de l'interaction de travail entre Kubernetes, les référentiels d'images et Git est fourni par l'opérateur Weave Flux GitOps , qui fait partie du Weave Cloud .
Pour les machines de base, le mécanisme de convergence doit être déclaratif et autonome. D'après notre propre expérience, nous pouvons dire que Terraform est le plus proche de cette définition, mais nécessite toujours un contrôle humain. En ce sens, GitOps étend la tradition de l'infrastructure en tant que code.

GitOps combine Git avec l'excellent moteur de convergence de Kubernetes, offrant un modèle de fonctionnement.

GitOps nous permet de déclarer que seuls les systèmes qui peuvent être décrits et observés peuvent être automatisés et contrôlés .

GitOps concerne l'ensemble de la pile native du cloud (par exemple Terraform, etc.)

GitOps n'est pas seulement Kubernetes. Nous voulons que l'ensemble du système soit géré de manière déclarative et utilise la convergence. Par un système entier, nous entendons un ensemble d'environnements qui fonctionnent avec Kubernetes - par exemple, «cluster de développement 1», «production», etc. Chaque environnement comprend des machines, des clusters, des applications, ainsi que des interfaces pour les services externes qui fournissent des données, la surveillance et etc.

Remarquez à quel point Terraform est important dans ce cas pour le problème d'amorçage. Kubernetes doit être déployé quelque part, et l'utilisation de Terraform signifie que nous pouvons utiliser les mêmes flux de travail GitOps pour créer la couche de contrôle qui sous-tend Kubernetes et les applications. Il s'agit d'une bonne pratique exemplaire.

Une grande attention est accordée à l'application des concepts GitOps aux couches sur Kubernetes. Il existe actuellement des solutions de type GitOps pour Istio, Helm, Ksonnet, OpenFaaS et Kubeflow, ainsi que, par exemple, pour Pulumi, qui créent une couche pour développer des applications natives du cloud.

Kubernetes CI / CD: comparer GitOps avec d'autres approches

Comme indiqué, les GitOps sont deux choses:

Le modèle opérationnel pour Kubernetes et cloud native décrit ci-dessus.
Le chemin vers l'organisation d'un environnement de gestion des applications centré sur les développeurs.

Pour beaucoup, GitOps est principalement un workflow basé sur Git push. Nous l'aimons aussi. Mais ce n'est pas tout: regardons maintenant les pipelines CI / CD.

GitOps fournit un déploiement continu (CD) pour Kubernetes

GitOps offre un mécanisme de déploiement continu qui élimine le besoin de «systèmes de gestion de déploiement» distincts. Kubernetes fait tout le travail pour vous.

La mise à jour de l'application nécessite une mise à jour dans Git. Il s'agit d'une mise à niveau transactionnelle vers l'état souhaité. Le «déploiement» est ensuite effectué au sein du cluster par Kubernetes lui-même sur la base d'une description mise à jour.
En raison des spécificités de Kubernetes, ces mises à jour sont convergentes. Cela fournit un mécanisme de déploiement continu dans lequel toutes les mises à jour sont atomiques.
Remarque: Weave Cloud propose un opérateur GitOps qui intègre Git et Kubernetes et vous permet d'exécuter un CD en faisant correspondre l'état souhaité et actuel du cluster.

Sans kubectl et scripts

Évitez d'utiliser Kubectl pour mettre à niveau le cluster, et en particulier les scripts pour regrouper les commandes kubectl. Au lieu de cela, avec un pipeline GitOps, un utilisateur peut mettre à niveau son cluster Kubernetes via Git.

Les avantages comprennent:

Exactitude . Un groupe de mises à jour peut être appliqué, convergé et finalement validé, ce qui nous rapproche de l'objectif du déploiement atomique. Au contraire, l'utilisation de scripts ne donne aucune garantie de convergence (voir ci-dessous).
La sécurité Citant Kelsey Hightower: «Limitez l'accès au cluster Kubernetes aux outils d'automatisation et aux administrateurs chargés de le déboguer ou de le maintenir.» Voir aussi ma publication sur la sécurité et la conformité, ainsi qu'un article sur le piratage de Homebrew en volant des informations d'identification d'un script Jenkins imprudemment écrit.
Expérience utilisateur . Kubectl expose la mécanique du modèle objet Kubernetes, qui est assez complexe. Idéalement, les utilisateurs devraient interagir avec le système à un niveau d'abstraction plus élevé. Ici, je vais à nouveau faire référence à Kelsey et recommander de consulter un tel curriculum vitae .

La différence entre CI et CD

GitOps améliore les modèles CI / CD existants.

Le serveur CI moderne est un instrument d'orchestration. En particulier, c'est un instrument pour orchestrer les pipelines CI. Ils incluent la génération, le test, la fusion vers le tronc, etc. Les serveurs CI automatisent la gestion des pipelines complexes en plusieurs étapes. Une tentation courante consiste à créer un script pour l'ensemble de mises à jour Kubernetes et à l'exécuter en tant qu'élément de pipeline pour pousser les modifications dans le cluster. En effet, c'est ce que font de nombreux experts. Cependant, ce n'est pas optimal, et voici pourquoi.

CI doit être utilisé pour effectuer des mises à jour du tronc, et le cluster Kubernetes doit se changer en fonction de ces mises à jour afin de gérer le CD «en interne». Nous appelons cela le modèle pull pour le CD , contrairement au modèle push CI. Le CD fait partie d'une orchestration d'exécution .

Pourquoi les serveurs CI ne devraient pas créer de CD via des mises à jour directes dans Kubernetes

N'utilisez pas le serveur CI pour orchestrer les mises à jour directes dans Kubernetes en tant qu'ensemble de tâches CI. C'est l'anti-pattern dont nous avons déjà parlé sur notre blog.

Revenons à Alice et Bob.

Quels problèmes ont-ils rencontrés? Le serveur CI de Bob applique les modifications au cluster, mais s'il se bloque au cours du processus, Bob ne saura pas dans quel état le cluster est (ou devrait être) et comment le corriger. La même chose est vraie en cas de succès.

Supposons que l'équipe de Bob ait assemblé une nouvelle image, puis corrigé ses déploiements pour déployer l'image (le tout à partir du pipeline CI).

Si l'image se construit normalement, mais que le pipeline tombe, l'équipe devra découvrir:

La mise à jour a-t-elle été déployée?
Commençons-nous une nouvelle construction? — ?
, ?
? ( )?

Git' , . - push' , - ; --.

, CI- CD:

; .
CI- .
. .
.

Helm'e: Helm, GitOps-, Flux-Helm . . Helm , .

GitOps Continuous Delivery Kubernetes

GitOps , , . , , . , , GitOps .

Kubernetes

. Git :

, Git .
Runtime GitOps, . Git .

?

: , , Git . , CI runtime-. « » (immutability firewall) , . 72-87 .
CI- Git- : GitOps . CI- Git-, . Continuous Delivery CI-/Git- . cloud native. GitOps .
: Git , Weave Flux ( Weave Cloud) runtime. , Kubernetes , Git . GitOps, .

Conclusion

GitOps , CI/CD:

;
;
;
.

, cloud native.

, runbook' ( — . .) , deployment'.
cloud native- , .

, . GitOps - .

PS du traducteur

Lisez aussi dans notre blog:

Qu'est-ce que GitOps?