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 , 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. GitOps Mon article précédent parlait d'une . 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. réussite en matière de réduction des coûts sur la façon dont nous sommes passés d'Elastic Stack à Grafana 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 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 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. 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 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. 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. Cela conduit à une spirale de peur de l'automatisation. 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 . 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. guide "Kubernetes à la dure" À 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. 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. 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. 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. 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 , le gestionnaire de packages HELM était l'application d'emballage la plus populaire, avec une part de plus de 50 %. l'enquête CNCF 2021 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. 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. Ensuite, nous avons un cluster Kubernetes exécutant les contrôleurs de flux. 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. 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. Pour déployer ce YAML dans un cluster, nous décrivons une ressource de personnalisation. Le contrôleur Kustomize le voit, accède au contrôleur source, obtient le YAML et le déploie sur le cluster. 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. Pour que le contrôleur source donne au contrôleur HELM le graphique demandé, nous devons créer un HelmRepository dans le cluster CR. 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. 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. Et, pour terminer notre travail, nous mettons un contrôleur de notification quelque part qui nous informe de ce qui aurait pu mal tourner. 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). 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). 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. 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. 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). 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é 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) Et nous pouvons compliquer encore plus les choses et spécifier la gamme de versions de la charte Helm. 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. À 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. 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). 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. 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 !
