paint-brush
Qu'est-ce que GitOps et pourquoi est-il (presque) inutile ? Partie 1 par@chep
4,883 lectures
4,883 lectures

Qu'est-ce que GitOps et pourquoi est-il (presque) inutile ? Partie 1

par Andrii Chepik
Andrii Chepik HackerNoon profile picture

Andrii Chepik

@chep

Ukrainian Engineer with 3 years of experience

11 min read2023/08/07
Read on Terminal Reader
Read this story in a terminal
Print this story

Trop long; Pour lire

L'article traite de GitOps, un concept de gestion de configuration d'infrastructure, et de ses défis. GitOps est vanté pour ses avantages en matière de cohérence, de sécurité et d'automatisation. Il exploite les référentiels Git pour gérer l'infrastructure et le code d'application. L'article explique les principes de GitOps, l'architecture Flux et l'utilisation de Helm avec Flux. Il met en évidence les lacunes de GitOps dans la gestion des dépendances complexes et le maintien d'une source unique de vérité. La partie suivante couvrira des problèmes tels que les environnements multiples, les secrets, la sécurité, la restauration et son applicabilité.
featured image - Qu'est-ce que GitOps et pourquoi est-il (presque) inutile ? Partie 1
Andrii Chepik HackerNoon profile picture
Andrii Chepik

Andrii Chepik

@chep

Ukrainian Engineer with 3 years of experience

0-item
1-item

STORY’S CREDIBILITY

Opinion piece / Thought Leadership

Opinion piece / Thought Leadership

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Guide

Guide

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.


Sur une nouvelle compagnie aérienne. Une hôtesse entre dans la cabine passagers: "Vous êtes sur notre nouvelle compagnie aérienne. Dans le nez de l'avion, nous avons une salle de cinéma. Dans la partie arrière - une salle de machines à sous. Sur le pont inférieur - une piscine. Sur le pont supérieur - un sauna Maintenant, messieurs, attachez vos ceintures, et avec toutes ces choses inutiles, nous allons essayer de décoller.



Bonjour, je m'appelle Andrii. J'ai travaillé dans l'industrie informatique pendant la majeure partie de ma vie. Je suis très intéressé par l'évolution de l'ingénierie de gestion de la configuration des infrastructures. Depuis 8 ans, je suis impliqué dans le DevOps .


L'une des nouvelles tendances populaires est le concept de GitOps , introduit en 2017 par Alexis Richardson, le PDG de Weaveworks. Weaveworks est une grande entreprise adulte qui, en 2020, a levé plus de 36 millions d'euros d'investissements pour développer ses GitOps.


Mon article précédent parlait d'une réussite en matière de réduction des coûts sur la façon dont nous sommes passés d'Elastic Stack à Grafana . Maintenant, je vais essayer de parler des défis non évidents qui peuvent vous attendre lors de l'adoption de ce concept. Bref, GitOps n'est pas une "Silver Bullet". Vous finirez probablement par réorganiser avec de nombreuses solutions de contournement compliquées. J'ai moi-même suivi cette voie et je souhaite vous montrer les problèmes les plus frustrants que vous ne pouvez pas voir en lisant d'autres articles sur GitOps.


Aperçu du contenu

  • Qu'est-ce que GitOps et pourquoi vous n'en avez (pas) besoin
  • Problème de serveurs Snowflake
  • GitOps - Une panacée pour tous vos problèmes (ou pas)
  • La logique d'utilisation de Flux avec Helm
  • Ressources de flux personnalisées
  • Liste de contrôle pour GitOps
  • Violation du concept de source unique de vérité
  • Petite conclusion


Qu'est-ce que GitOps et pourquoi vous (n'en avez pas) besoin

Plongeons dedans !


Apatride et avec état

image


Le concept le plus prometteur de la construction d'infrastructures aujourd'hui est l'infrastructure immuable. Son idée clé est de diviser l'infrastructure en 2 parties fondamentalement différentes : sans état et avec état.


La partie apatride de l'infrastructure est immuable et idempotente. Il n'accumule pas d'état (ne stocke pas de données) ou ne modifie pas son fonctionnement en fonction de l'état accumulé. Les instances de la partie sans état peuvent contenir des artefacts, des scripts et des assemblys de base. En règle générale, je les crée à partir d'images de base dans des environnements cloud/virtualisés. Elles sont fragiles et éphémères : je livre de nouvelles versions d'applications en recréant des instances à partir de nouvelles images de base.


Les données persistantes sont stockées dans la partie Stateful. Il peut être réalisé par le schéma classique avec des serveurs dédiés ou par certains mécanismes cloud (DBaaS, objet ou stockage par blocs).


Pour rendre ce "zoo" gérable et fonctionner correctement, nous avons besoin d'une collaboration entre les équipes d'ingénierie et DevOps, ainsi que de pipelines de livraison entièrement automatisés.


partie CI

image


La programmation extrême est l'une des méthodologies de développement agile. Il se distingue par de nombreuses boucles de rétroaction, qui permettent de maintenir la synchronisation avec les besoins du client.


Nous mettons en œuvre l'automatisation des pipelines de livraison à l'aide de systèmes CI/CD. Le terme CI (intégration continue) a été proposé par Grady Booch en 1994, et en 1997, Kent Beck et Ron Jeffries l'ont introduit dans la discipline de la programmation extrême. En CI, nous devons intégrer nos changements aussi souvent que possible dans la branche de travail principale de notre projet.


Cela nécessite, tout d'abord, une décomposition plus granulaire des tâches : les petits changements sont plus atomiques et plus faciles à suivre, à comprendre et à intégrer. Deuxièmement, nous ne pouvons pas simplement fusionner du code fraîchement écrit. Avant de fusionner des branches, nous devons nous assurer que rien de ce qui fonctionnait auparavant n'a été cassé. Pour ce faire, l'application doit au moins être construite. C'est aussi une bonne idée de couvrir le code avec des tests.



image


Et c'est la tâche accomplie par les systèmes CI, qui ont parcouru un long chemin dans le développement et, quelque part au milieu de ce chemin, se sont transformés en systèmes CI/CD.


Partie CD

image


Qu'est-ce qu'un CD ? Martin Fowler distingue 2 définitions de CD :


  • Livraison continue. C'est à ce moment-là, avec l'aide des pratiques d'intégration continue et de la culture DevOps, que vous gardez la branche principale de votre projet constamment prête à être déployée en production.


  • Déploiement continu. C'est la livraison continue où tout ce qui entre dans la branche principale est déversé dans votre cluster, dans votre production.


Allons plus loin.


Problème de serveurs Snowflake

Malheureusement, l'infrastructure immuable présente plusieurs problèmes. La part du lion est héritée du concept d'Infrastructure as Code (IaC).


Tout d'abord, c'est la dérive de configuration. Ce terme est né dans les Puppet Labs (auteurs du célèbre Puppet SCM) et indique que toutes les modifications apportées aux systèmes cibles ne sont pas effectuées à l'aide de la gestion de la configuration du système (SCM). Certains sont faits manuellement, en les contournant.



image



Au cours de tels changements multiples, une dérive de configuration apparaît - la différence entre la configuration décrite dans SCM et la situation réelle.




image



Cela conduit à une spirale de peur de l'automatisation.



image



Plus il y a de modifications manuelles, plus il est probable que l'exécution d'un script SCM casse les modifications non enregistrées. Plus il est effrayant de l'exécuter, plus il est probable que de nouvelles modifications manuelles seront apportées.


Finalement, cette rétroaction positive vicieuse conduit à la formation de serveurs de flocons de neige, qui sont devenus si incohérents que personne ne comprend plus ce qu'il y a à l'intérieur. Après des modifications manuelles, le nœud devient aussi unique que chaque flocon de neige lors d'une chute de neige.


Cette dérive laisse les serveurs à des niveaux supérieurs au sein d'une infrastructure immuable : nous pouvons maintenant parler de GCP Project/AWS VPC/Kubernetes-cluster-snowflakes. Cela se produit parce que la mise en œuvre des changements n'est pas réglementée sur une infrastructure immuable. De plus, personne ne sait comment le faire correctement.


GitOps - une panacée pour tous vos problèmes (ou pas)

Et puis Weaveworks arrive et dit : "Les gars, nous avons ce dont vous avez besoin - GitOps". Pour promouvoir GitOps, ils ont fait appel à un poids lourd comme Kelsey Hightower, qui a créé le guide "Kubernetes à la dure" . Au cours de ses relations publiques, il diffuse massivement le message : "Soyez un homme, b ... ! Arrêtez de rédiger des scripts et commencez à expédier." Et il dit une certaine quantité de bingo marketing à la con.


À mon avis, les avantages les plus intéressants étaient :


  • Amélioration de la cohérence et de la standardisation des déploiements
  • Garantie de sécurité améliorée
  • Récupération plus facile et plus rapide des erreurs
  • Gestion simplifiée des accès et des secrets
  • Déploiements auto-documentés
  • Diffusion des connaissances au sein de l'équipe


Et quiconque essaie de comprendre ce qu'est GitOps tombe sur cette diapositive de manuel.


image


Ensuite, on retrouve les principes GitOps, qui ressemblent aux principes IaC légèrement augmentés :


  • GitOps est déclaratif
  • Les applications GitOps sont versionnées et immuables
  • Les applications GitOps sont extraites automatiquement
  • Les applications GitOps sont réconciliées en continu


Néanmoins, il s'agit d'une description sphérique dans le vide, nous poursuivons donc nos recherches. On retrouve le site GitOps.tech et sur celui-ci plusieurs précisions importantes.


Tout d'abord, nous apprenons que GitOps est un code de type infrastructure dans Git avec un outil CD qui l'applique automatiquement à l'infrastructure.



image



Nous devons avoir au moins 2 référentiels au sein de GitOps :


  • Référentiel d'applications. Il décrit le code source de l'application et les manifestes qui décrivent le déploiement de cette application.
  • Référentiel d'infrastructures. Il décrit les manifestes d'infrastructure et l'environnement de déploiement.


De plus, dans l'idéologie GitOps, une approche orientée pull est préférée à une approche orientée push. Ceci est quelque peu contraire à l'évolution des systèmes SCM, des monstres lourds à tirer Puppet et Chef aux modèles légers basés sur la poussée Ansible et Terraform.



image



Et si GitOps est avant tout une histoire de boîte à outils, il est logique de prendre le concept basé sur Flux de Weaveworks lui-même et de le déconstruire. Les auteurs de l'idée doivent avoir fait une implémentation de référence.



image



Flux est maintenant à la version 2 et se compose architecturalement de contrôleurs qui fonctionnent au sein d'un cluster :


  • Contrôleur de sources
  • Personnaliser le contrôleur
  • Contrôleur HELM
  • Contrôleur de notifications
  • Contrôleurs d'automatisation d'image


Ensuite, discutons du travail avec Flux et Helm.

La logique d'utilisation de Flux avec Helm

Je vais décrire plus en détail l'exemple de déploiement d'une application à l'aide du gestionnaire de packages Helm dans Flux 2.


Pourquoi? Selon l'enquête CNCF 2021 , le gestionnaire de packages HELM était l'application d'emballage la plus populaire, avec une part de plus de 50 %.



image



Malheureusement, je n'ai pas pu trouver de données plus à jour, mais je ne pense pas que quelque chose ait beaucoup changé depuis lors.


Passons donc en revue la logique de base du fonctionnement de Flux 2 avec Helm. Nous avons 2 référentiels : application et infrastructure.



image



Nous créons un graphique HELM et une image docker à partir du référentiel de l'application et les ajoutons respectivement au référentiel de graphiques Helm et au registre docker.



image



Ensuite, nous avons un cluster Kubernetes exécutant les contrôleurs de flux.



image



Pour déployer notre application, nous préparons un YAML décrivant la ressource personnalisée (CR) HelmRelease et l'ajoutons au référentiel de l'infrastructure.



image



Pour aider Flux à l'obtenir, nous créons un CR GitRepository dans le cluster Kubernetes. Le contrôleur source le voit, va sur git et le télécharge.



image


Pour déployer ce YAML dans un cluster, nous décrivons une ressource de personnalisation.



image



Le contrôleur Kustomize le voit, accède au contrôleur source, obtient le YAML et le déploie sur le cluster.


image



Le contrôleur Helm voit qu'un CR HelmRelease est apparu dans le cluster et se dirige vers le contrôleur Source pour obtenir le diagramme HELM décrit.



image



Pour que le contrôleur source donne au contrôleur HELM le graphique demandé, nous devons créer un HelmRepository dans le cluster CR.



image



Helm-controller obtient un graphique de Source-controller, crée une version et la déploie sur le cluster. Ensuite, Kubernetes crée les pods nécessaires, accède au registre docker et télécharge les images correspondantes.



image



En conséquence, pour déployer une nouvelle version de notre application, nous devons créer une nouvelle image, un nouveau fichier HelmRelease et éventuellement un nouveau graphique HELM. Ensuite, nous devons les mettre dans les référentiels appropriés et attendre que les contrôleurs de flux répètent le travail dans la chaîne décrite ci-dessus.



image



Et, pour terminer notre travail, nous mettons un contrôleur de notification quelque part qui nous informe de ce qui aurait pu mal tourner.



image


Ressources de flux personnalisées

Parlons maintenant des ressources personnalisées avec lesquelles Flux fonctionne.


Le premier est le référentiel Git. Ici, nous pouvons spécifier l'adresse du dépôt Git (ligne 14) et la branche qu'il regarde (ligne 10).



image



Ainsi, nous ne téléchargeons qu'une seule branche, pas l'ensemble du référentiel. Mais! Comme nous sommes des ingénieurs responsables et essayons d'adhérer au concept Zero Trust, nous verrouillons l'accès au référentiel, créons un secret avec une clé dans le cluster Kubernetes et le donnons à Flux pour qu'il puisse s'y rendre (ligne 12).



image



Vient ensuite la personnalisation. Ici, je veux attirer votre attention sur le fait que le contrôleur Kustomize de Flux et Kustomize des auteurs de Kubernetes sont 2 choses différentes. Je ne sais pas pourquoi une telle dénomination désorientante a été choisie, mais il est important de ne pas les confondre.



image


La kustomisation est un moyen de déployer YAML (n'importe lequel) d'un référentiel Git vers un cluster. Ici, nous devons spécifier la source d'où nous le mettons (ligne 12 - le nom du CR GitRepository décrit ci-dessus), le répertoire d'où nous prenons les YAML (ligne 8), et nous pouvons spécifier l'espace de noms cible où les déposer (ligne 13).


Vient ensuite la version de Helm.



image



Ici, nous pouvons spécifier le nom et la version du graphique (lignes 10,11). Ici, vous spécifiez des valeurs variables afin que Helm puisse personnaliser la version d'un environnement à l'autre (lignes 15 à 19). Il s'agit d'une fonctionnalité extrêmement importante et nécessaire, car vos environnements peuvent différer considérablement. Vous spécifiez également la source pour prendre le graphique Helm (lignes 12, 13, 14). Dans ce cas, il s'agit du référentiel Helm.



Mais! Puisque nous sommes toujours des ingénieurs responsables, nous avons également un accès rapproché au référentiel Helm et donnons à Flux un secret pour y arriver (lignes 7, 8).



image


Liste de contrôle pour GitOps

Alors, faisons une petite liste de contrôle pour capturer ce que nous venons de voir. Pour commencer à faire GitOps, nous devons soudainement écrire un tas de scripts (nous nous souvenons que l'infrastructure Immutable concerne les pipelines de livraison entièrement automatisés). Donc, tout d'abord, nous devons créer:


  • Script pour créer et envoyer des images au registre Docker
  • Référentiel Git d'infrastructure
  • Compte pour l'accès du système CI au référentiel GIT de l'infrastructure
  • Script pour générer et pousser le fichier HelmRelease
  • Référentiel Helm
  • Compte pour l'accès du système CI au référentiel Helm
  • Script pour construire et publier la charte Helm`
  • Compte Flux pour le référentiel d'infrastructure
  • Compte Flux pour le référentiel de chartes Helm


Super, vous avez maintenant une liste de contrôle pour GitOps. Passez.


Violation du concept de source unique de vérité


image


Voyons ce que nous obtenons avec notre version Helm en général. Il est bien évident que Git ne peut pas être la seule source de vérité dans ce cas particulier. Nous avons au moins 2 ressources, 2 artefacts en dehors de git, dont dépend cette version de Helm :


  • Carte Helm (lignes 8-14)
  • Image Docker (ligne 19)


image


Et nous pouvons compliquer encore plus les choses et spécifier la gamme de versions de la charte Helm.


image



Dans ce cas, Flux surveillera et définira de nouveaux graphiques Helm qui apparaissent dans cette plage. De plus, le contrôleur source que nous avons peut utiliser YAML comme source, y compris les bundles S3.



image



À partir de là, nous pouvons conserver les graphiques YAML et Helm.


De plus, nous avons des contrôleurs d'automatisation d'image qui peuvent garder un œil sur les nouvelles images dans le registre Docker et modifier le référentiel d'infrastructure.



image



Mais nous ne voulons pas d'opérations de dépôt HELM Chart ou d'opérations de registre Docker. Nous voulons être aussi GitOps que possible. Nous regardons donc la documentation et corrigeons les processus pour déployer notre charte Helm depuis le référentiel GIT (nous choisissons le référentiel de l'application pour le stocker).



image



Cela nous oblige à créer un autre CR GitRepository pour le référentiel de l'application, un compte permettant à Flux d'y accéder et à créer un secret avec des clés.



image


Dans le même temps, nous ne résolvons en aucune façon le problème d'une dépendance compliquée à l'image Docker.


Petite conclusion

Je pense que ça suffit pour aujourd'hui. Dans la partie 2, je vais vous dire quels problèmes cette bonté a. Je vais discuter:


  • Problème d'environnements multiples
  • Valeurs de
  • Problème secret
  • Ops CI contre GitOps
  • Sécurité
  • Procédure de retour en arrière
  • Problème de cluster multiple
  • Qui a vraiment besoin de GitOps ?


J'espère que cet article vous a été utile !


L O A D I N G
. . . comments & more!

About Author

Andrii Chepik HackerNoon profile picture
Andrii Chepik@chep
Ukrainian Engineer with 3 years of experience

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS...

Read on Terminal Reader
Read this story in a terminal
 Terminal
Read this story w/o Javascript
Read this story w/o Javascript
 Lite
X REMOVE AD