Dans les premières étapes de la conception ou de la mise en œuvre de GitOps, il peut être décourageant de penser aux différents outils et pratiques dont vous pourriez avoir besoin. Vous voulez être sûr de concevoir un flux de travail robuste et évolutif pour gérer les déploiements d'infrastructures et d'applications. Vous ne voulez pas non plus introduire des éléments qui compliqueraient trop les processus ou qui rendraient plus difficile la publication des modifications de code par votre équipe.
Une façon de réduire votre champ d'action est de rechercher des outils et des pratiques qui soutiendront vos pratiques de déploiement. La principale considération est de savoir si vous utilisez une approche basée sur la poussée ou sur la traction. Les deux ont leurs avantages et leurs inconvénients, et celle que vous utilisez aura un impact sur les outils et les processus que vous inclurez dans votre stratégie GitOps.
Automatisation des flux de travail et de l'infrastructure
Tout d'abord, passons en revue deux pratiques fondamentales de DevOps : L'infrastructure en tant que code (IaC) et l'automatisation avec l'intégration continue et la livraison continue (CI/CD).
L'IaC est une technique de déploiement et de gestion de l'infrastructure par le biais d'un code au lieu d'une série d'étapes manuelles ou d'un processus interactif. Cette approche ne se limite pas aux primitives d'infrastructure ou aux services en nuage gérés - elle s'applique à tous les aspects gérables tels que les fichiers de configuration, les installations de logiciels, les politiques de réseau et de sécurité, etc. Communément appelé "X as Code", ce type de gestion unifiée fournit un état souhaité modélisé et documenté pour votre déploiement.
CI/CD est une méthodologie et un ensemble de pratiques communes permettant aux développeurs de fournir rapidement et de manière fiable des applications codées de qualité et sécurisées. Adopter la CI/CD, c'est adopter une culture dans laquelle les équipes de développement peuvent rester concentrées sur les exigences de l'entreprise et de l'utilisateur final en mettant en œuvre l'automatisation aux bons stades du cycle de vie du développement logiciel.
Dans le développement de logiciels, l'intégration est le processus de validation des modifications apportées au code dans un référentiel. L'intégration continue (IC) est le processus de validation automatique des modifications, en construisant, testant et emballant le code de l'application mise à jour d'une manière fiable et cohérente. Le déclenchement d'un flux de travail d'intégration continue à chaque événement "push" permet un processus de développement plus fluide et plus rapide, puisque les bogues, les vulnérabilités de sécurité et les conflits peuvent être découverts avant que les changements ne soient déployés dans un environnement.
Un flux de travail de livraison continue (CD) prend le relais une fois que le flux de travail de CI a été mené à bien. Il peut s'agir d'un flux de travail qui facilite le déploiement de l'application directement sur des serveurs de stockage ou de production, ou l'expédition d'une nouvelle version vers un registre de conteneurs ou une plateforme de distribution mobile.
Il s'agit de thèmes centraux autour de l'automatisation des flux de travail des développeurs. Une approche GitOps s'appuie sur ces pratiques DevOps fondamentales et les met en œuvre. En exploitant un dépôt git comme source unique de vérité pour les fichiers de définition de l'IaC, et en utilisant des pipelines d'automatisation, vous pouvez contrôler efficacement la version de l'état souhaité de votre infrastructure.
C'est ici que nous revenons à vos pratiques de déploiement : décider si le mode push ou pull est le mieux adapté à votre application et à votre stratégie GitOps.
Comparaison entre l'architecture basée sur la poussée et l'architecture basée sur la traction
L ' approche traditionnelle consiste à pousser les changements vers l'environnement sélectionné par un client CI/CD externe tel que Jenkins ou CircleCI. Cette approche peut être préférable pour les environnements non Kubernetes, ou les environnements avec un mélange de types de charge de travail qui rendraient l'exécution d'agents et de webhooks distincts sur chaque composant encombrante.
Pour :
- Plus simple à mettre en œuvre pour plusieurs types de charges de travail dans un environnement unique.
- Standardisation de la méthodologie de déploiement entre les différents environnements (c'est-à-dire cloud-native et on-premise).
- Flexibilité de l'outil, car la plupart des cadres CI/CD s'appuient sur un modèle basé sur la poussée.
Cons :
- Le client CI/CD n'a pas la possibilité d'observer si les changements ont été déployés avec succès ou si des problèmes sont survenus du côté des serveurs.
- Il peut être nécessaire d'installer des outils supplémentaires (par exemple, kubectl, Helm, Docker, Ansible, Terraform, SSH) pour que le client CI/CD puisse déployer les modifications.
- Nécessité de donner au client CI/CD un accès externe à l'environnement, ce qui augmente le risque de problèmes de sécurité et de conformité.
L'approche basée sur l'extraction ou l'agent fonctionne dans la direction opposée en faisant de l'environnement une partie du pipeline de CD. Un agent ou un opérateur surveille le dépôt git à la recherche de modifications, puis les retire et les applique. Cette tâche est également exécutée chaque fois que l'agent détecte une dérive de la configuration par rapport à la source unique de vérité. Cette approche fonctionne particulièrement bien avec les environnements natifs de Kubernetes.
Pour :
- L'agent/opérateur peut observer l'état actuel de l'environnement et l'état du déploiement.
- Une meilleure sécurité et une conformité simplifiée, car l'environnement n'a besoin que d'une autorisation pour voir la source.
- Détection rapide des dérives de configuration dues à une intervention humaine manuelle ou à d'autres sources.
Cons :
- Plus complexe pour les déploiements non Kubernetes.
- Nécessite un outillage conçu pour fonctionner avec des types d'environnement spécifiques.
Lorsque vous commencez à planifier votre stratégie GitOps, réfléchissez à la manière dont les différentes stratégies de déploiement soutiendront votre application. Les approches basées sur le " push " et le " pull " ont toutes deux leurs avantages et conviennent à différents scénarios. Il existe de nombreux outils et pratiques à considérer, et avec un peu de recul, vous saurez quelle est la bonne solution pour votre équipe et votre pile.
Vous souhaitez plus d'informations ? Téléchargez notre livre électronique gratuit sur la stratégie GitOps ou obtenez une consultation gratuite avec un expert en informatique dans le Cloud d'Akamai.
Commentaires