Gestion du code source pour GitOps et CI/CD

Ceci est un article du rapport sur les tendances DevOps 2023 de Développeurweb.com.

Pour plus:

Lire le rapport

GitOps a pris d’assaut le monde DevOps depuis que Weaveworks a introduit le concept en 2017. L’idée est simple : utilisez Git comme source unique de vérité pour stocker et gérer de manière déclarative chaque composant pour un déploiement d’application réussi. Cela peut inclure l’infrastructure en tant que code (par exemple, Terraform, etc.), les documents de politique (par exemple, Open Policy Agent, Kyverno), les fichiers de configuration, etc. Les modifications apportées à ces composants sont capturées par les commits Git et déclenchent des déploiements via des outils CI/CD pour refléter l’état souhaité dans Git.

GitOps s’appuie sur les récentes évolutions vers une infrastructure immuable via une configuration déclarative et une automatisation. En gérant de manière centralisée les composants d’infrastructure déclaratifs dans Git, l’état du système est effectivement lié à un commit Git, produisant un instantané versionné et immuable. Cela rend les déploiements plus fiables et les restaurations triviales. Comme avantage supplémentaire, Git fournit une piste d’audit complète pour les modifications et met en place des garde-corps plus solides pour éviter les dérives dans le système.

Enfin, il favorise une expérience CI/CD plus cohérente, car toutes les tâches opérationnelles sont désormais entièrement capturées via les actions Git. Une fois le pipeline configuré, les développeurs peuvent s’attendre à ce qu’un flux de travail Git standard promeuve leurs modifications dans différents environnements.

Même si les avantages de GitOps sont bien documentés, les meilleures pratiques pour la mise en œuvre de GitOps sont encore en cours de formation. Après tout, les détails de la mise en œuvre dépendront de la nature des référentiels de code existants, de la taille et de la composition des équipes d’ingénierie, ainsi que des besoins pratiques en matière de changements impératifs (par exemple, restauration d’urgence ou procédures de bris de glace).

Dans cet article, nous verrons comment choisir la meilleure stratégie pour adopter GitOps en gardant à l’esprit les considérations susmentionnées.

Gestion des codes sources

La première considération pour adopter GitOps est de décider quels artefacts stocker dans quel référentiel Git. Certaines entreprises technologiques, telles que Google et Facebook, sont de fervents partisans des monorepos, utilisant des outils sophistiqués pour créer et déployer du code. D’autres adoptent l’approche inverse, en utilisant plusieurs référentiels pour séparer les applications ou les produits afin de les gérer séparément.

Heureusement, GitOps n’est pas lié à un cadre particulier, mais à moins que votre organisation ne dispose déjà d’outils robustes pour gérer les versions monorepo, telles que Bazel, la recommandation générale est de séparer au moins le code source de l’application des artefacts de déploiement.

Figure 1 : Flux GitOps typique

Les avantages de séparer les deux référentiels sont multiples :

La cadence de déploiement des changements d’application et d’infrastructure peut être plus facilement séparée et contrôlée. Par exemple, les équipes d’application peuvent souhaiter que chaque validation déclenche un déploiement dans des environnements inférieurs, tandis que les équipes d’infrastructure peuvent souhaiter regrouper plusieurs modifications de configuration avant de déclencher un déploiement (ou vice-versa).
Il peut y avoir des exigences de conformité ou réglementaires pour séparer qui a accès au déploiement de certains aspects de la pile d’applications dans son ensemble. Certaines organisations peuvent autoriser uniquement une équipe d’ingénierie de production ou SRE à déclencher des déploiements de production. Le fait d’avoir des référentiels séparés facilite la configuration de l’accès et des pistes d’audit.
Pour les applications avec des composants dépendants qui nécessitent un déploiement en tant qu’unité unique, un référentiel de configuration séparé permet à plusieurs référentiels d’applications ou de dépendances externes de pousser les modifications indépendamment. Ensuite, l’outil CD peut surveiller un référentiel de configuration unique et déployer tous les composants en même temps.

Cela dit, le point de séparation exact entre ce qui appartient au référentiel d’application et le référentiel d’artefacts de déploiement dépend de la composition de votre équipe. Les petites startups peuvent s’attendre à ce que les développeurs d’applications soient responsables du code d’application et d’autres artefacts de déploiement (par exemple, Dockerfile, Helm charts, etc.). Dans ce cas, il peut être judicieux de conserver ces manifestes dans le même référentiel et de conserver simplement les configurations Terraform dans un autre référentiel.

Comme pour les grandes organisations avec des équipes DevOps/infrastructure dédiées, ces équipes dédiées peuvent posséder exclusivement des composants Kubernetes et les maintenir séparément du code d’application.

Configuration du référentiel de déploiement

La prochaine question logique est de savoir combien de référentiels doivent contenir des configurations de déploiement ? La réponse à cette question est motivée par des considérations similaires à celles ci-dessus, mais avec l’influence de la topologie de l’infrastructure.

Pour petites équipes avec un petit nombre de comptes/projets cloud, il sera plus facile d’avoir un référentiel unique pour héberger toutes les configurations de déploiement afin de déclencher des déploiements sur un petit nombre d’environnements. Au fur et à mesure que l’infrastructure évolue, les artefacts non prod peuvent être séparés des dépôts prod.
Pour équipes de taille moyenne avec des outils légèrement plus sophistiqués et une infrastructure cloud complexe (par exemple, plusieurs projets imbriqués dans des organisations, hybride/multi-cloud), un référentiel par équipe peut bien fonctionner. De cette façon, différents contrôles peuvent être mis en œuvre en fonction des besoins de sécurité ou de conformité.
À l’autre extrémité du spectre, un référentiel par service et environnement offre le plus de flexibilité en termes de contrôles pour grandes équipes avec un outillage robuste.

Autres considérations CI/CD

L’objectif principal de GitOps est de tirer parti de la puissance de Git pour stocker la source unique de vérité en termes d’état déployé. En pratique, cependant, ce qui constitue l’artefact versionné et immuable sera déterminé par l’état des outils CI/CD pour chaque équipe. Pour les équipes avec des pipelines lents, il peut être indésirable de déclencher des mises à jour fréquentes. De même, pour les équipes de produits qui doivent s’interfacer avec des composants externes, les versions versionnées peuvent devoir être coordonnées avec les partenaires commerciaux. Dans de tels cas, la conception du pipeline CI pour mettre à jour le référentiel de configuration sur les versions marquées peut être bénéfique. D’un autre côté, pour les équipes agiles disposant d’outils CD robustes pour les versions Canary, des déploiements fréquents peuvent être privilégiés pour recueillir les commentaires des utilisateurs en temps réel.

Un autre composant essentiel à appeler avec GitOps est la gestion des secrets. Étant donné que les secrets ne peuvent pas être archivés dans Git en tant que texte brut, un cadre distinct est nécessaire pour traiter les secrets. Certains frameworks comme Bitnami Sealed Secrets vérifient les données chiffrées dans Git et utilisent un contrôleur/opérateur sur l’environnement déployé pour déchiffrer les secrets. D’autres séparent entièrement les secrets et tirent parti des magasins secrets tels que Hashicorp Vault.

Enfin, il est important de signaler que même avec GitOps, une dérive de configuration peut toujours se produire. En fait, pour les petites équipes avec des outils immatures, il peut être essentiel de laisser une certaine marge aux changements impératifs. Pour les pannes urgentes, des correctifs manuels peuvent être nécessaires pour restaurer le service avant de passer par le pipeline officiel pour un correctif à long terme. Avant d’appliquer des politiques strictes, testez les stratégies de restauration et de restauration pour vous assurer que les systèmes GitOps n’entravent pas les correctifs d’urgence.

Conclusion

GitOps est la meilleure chose depuis la configuration en tant que code. Git a changé notre façon de collaborer, mais la configuration déclarative est la clé pour gérer l’infrastructure à grande échelle et ouvre la voie à la prochaine génération d’outils de gestion.
– Kelsey High Tower

GitOps applique les meilleures pratiques que les développeurs d’applications ont apprises au fil des ans en interagissant avec Git pour la configuration et l’infrastructure déclaratives. GitOps produit un état versionné et immuable du système avec une piste d’audit via un système éprouvé avec lequel les développeurs sont déjà familiers. Dans cet article, nous avons passé en revue certaines considérations pour la mise en œuvre de GitOps dans votre organisation en fonction de la taille de l’équipe, de la composition et de l’état de vos outils CI/CD. Pour certains, un monorepo contenant tout au même endroit peut fonctionner mieux, tandis que pour d’autres, des contrôles granulaires appliqués à plusieurs dépôts sont une exigence.

La bonne nouvelle est que GitOps est suffisamment flexible pour s’adapter à l’évolution de vos besoins. Il existe une pléthore d’outils GitOps disponibles sur le marché aujourd’hui. Commencez avec un outil simple pour profiter des avantages de GitOps au fur et à mesure que vous développez votre pile technologique pour augmenter la productivité des développeurs.

Les références: