GitOps : tour d’horizon des pratiques et des outils

Cet article est une introduction aux principes GitOps. Nous nous servirons de Kubernetes comme exemple.

Par Arthur Outhenin-Chalandre, chargé d’études @ Objectif Libre

Public visé : Administrateurs Kubernetes

Introduction au GitOps

Le GitOps est un concept introduit en 2017 par « Weave ». Vous pouvez retrouver différentes ressources, notamment leur article de blog originel ou bien leur guide Gitops.

Infrastructure As Code et GitOps

Le principe rejoint celui de l’infrastructure as code avec des contraintes clairement définies assurant de bonnes pratiques.

L’infrastructure as code et de ce fait le Gitops reposent en grande partie sur la formalisation déclarative de notre infrastructure. Cela se traduit notamment par l’usage d’outils tels qu’Ansible, Chef/Puppet, Terraform, Salt, et bien sûr Kubernetes.

De ce fait les opérations manuelles via ssh ou même kubectl (kubectl est le nouveau ssh !) sont proscrites. Tout changement doit être décrit de manière déclarative via un outil de provisionnement ou de déploiement. Ce point est décrit sur le 10e point des 12factor.

Puisque l’on ne fait aucun changement manuel, on peut facilement répliquer nos déploiements. On peut parler de « déploiement immutable ».

Les spécificités GitOps

Comme son nom peut le laisser penser, GitOps se base sur Git. Malgré tout, il est possible de faire le parallèle avec tout autre outil de versionning et l’utilisation de Git n’est pas obligatoire pour avoir un résultat similaire.

L’aspect central du GitOps repose sur le fait de considérer que notre dépôt Git est notre unique source de vérité : cela proscrit les opérations manuelles décrites précédemment. Et plus encore, cela incite à se servir uniquement de git pour effectuer nos déploiements habituels via du « Continuous Deployment ».

La notion de convergence est également un point important du GitOps. Étant donné que notre dépôt git est notre source de vérité absolue, nous allons chercher à faire converger l’état de nos déploiements avec l’état décrit dans git. Cela passe notamment via de la supervision active de notre infrastructure et du reporting des divergences constatées.

Les bonnes pratiques Git

Tous nos environnements doivent être décrits dans git de manière déclarative. Cela apporte les avantages d’un VCS (Version Control System) classique, notamment la possibilité de rollback et d’avoir un historique clair de nos modifications.

On peut ajouter à cela le 1er point des 12 factor interdisant de démultiplier les branches ou les dépôts décrivant plusieurs environnement d’un même déploiement. Par exemple, il est inconcevable de maintenir une branche « pré-prod » avec les spécificités de votre environnement de pré-production à l’intérieur.

Les bonnes pratiques conseillent plutôt de décrire tous les environnements dans votre branche principale. Ainsi, vous devrez modifier tous vos environnements en même temps et vous n’aurez plus à maintenir les spécificités de votre environnement à part.

Attention cela n’interdit absolument pas de créer d’autres branches pour vos nouvelles fonctionnalités. Vous pouvez bien entendu appliquer des workflows telles que le Git Flow, le Github Flow, le GitLab Flow ou bien tout autre dérivé collant plus à votre utilisation et votre équipe.

Sur Kubernetes, il est possible d’utiliser l’outil « Kustomize » pour faire ça. Il est natif à « kubectl » et propose un système d’overlay. Pour faire court : on décrit notre base et on vient appliquer des patchs. Souvent, on décrit un overlay décrivant différents patch pour passer de notre base commune aux spécificités de notre environnement.

Les différentes stratégies de Continuous Deployment

Pour l’étape de « Continuous Deployment », il faut distinguer deux stratégies différentes :

  • la stratégie « push« , plus traditionnelle, consiste à se servir de sa forge pour « pousser » les modifications qu’on vient d’effectuer dans git.
  • la stratégie « pull » consiste à laisser l’infrastructure s’auto-gérer et à tout seul « pull » le dépôt git et se l’auto-appliquer. Cela permet notamment de s’abstraire de la forge pour la partie CD ce qui implique moins de vendors lock-in. Certaines solutions imposent néanmoins la plateforme sur laquelle notre dépôt git doit être hébergé, GitHub par exemple.

Les différents outils sur Kubernetes

GitLab CI

GitLab CI permet de faire de la « CD » dans le cadre de la stratégie « push ». C’est un outil intéressant, surtout si c’est déjà votre forge actuelle. GitLab propose une intégration avec des clusters Kubernetes. Il suffit d’ajouter au projet GitLab les credentials requis pour se connecter au cluster Kubernetes en question. A noter également, gitlab apporte un environnement de CI/CD pré-fait qui peut vous être suffisant ; vous pourrez trouver plus d’information ici.

Jenkins

Jenkins, dans le même esprit que GitLab CI est un outil intéressant si vous l’utilisez déjà en tant que forge. Il s’intègre lui aussi dans la stratégie « push ».

JenkinsX

JenkinsX est basé lui aussi sur la stratégie push, mais offre une intégration native dans Kubernetes. Il propose des environnement de quickstart avec des « preview » environnements, mais également de nombreuses fonctionnalités très pratiques comme les dev pods, offrant via « Skaffold » et « ksync » un pod se synchronisant avec votre code sur votre filesystem local directement dans votre cluster Kubernetes. Ce qui permet de réduire considérablement les différences entre du dev et de la prod.

Malgré ces features extrêmement intéressantes, JenkinsX est pourtant encore trop lié à GitHub ce qui nous pose problème chez Objectif Libre puisque nous sommes plutôt pro-Gitlab. Ils travaillent néanmoins activement sur l’émancipation de Github, c’est donc un projet à surveiller de près.

Flux

Flux est l’outil de CD de Weave (qui est sous la gouvernance la CNCF en tant que « Sandbox Project »).

C’est un opérateur Kubernetes permettant de synchroniser les manifests Kubernetes contenus dans un dépôt Git et de les déployer. Il s’inscrit donc dans la stratégie « pull ».

Flux est extensible et peut facilement être complété par de nombreux outils de templating de manifests comme kustomize ou jsonnet. Flux peut également pull et watch des registries docker. En cas de modifications sur un registry, il peut commit sur le dépôt git pour mettre à jour le tag de l’image docker utilisé dans un manifest. Il peut également alerter, par exemple via Slack, lors d’une divergence constatée entre les manifests stockés sur Git et les ressources déployées sur le cluster Kubernetes.

Flux supporte un unique dépôt Git par instance. Il existe un opérateur pour déployer plusieurs instances de Flux, mais il n’est plus activement maintenu. Fluxcloud, un outil développé par la communauté, offre la possibilité d’envoyer les événements Flux sur Slack.

Étant donné qu’il est conseillé de séparer les manifests Kubernetes du code applicatif, tous vos manifests devront être rassemblés sur un unique dépôt Git. Si cela ne convient pas à votre cas d’utilisation, une solution comme Argo CD sera très probablement un meilleur choix.

Argo CD

Argo CD est, tout comme Flux, un opérateur Kubernetes synchronisant des manifests Kubernetes stockés sur un dépôt Git. Il s’inscrit lui aussi dans la stratégie « pull ». Weave est lui aussi extensible et supporte de base Helm, Kustomize et Ksonnet.

Argo CD a également une web UI et un utilitaire en CLI sur lesquels vous pouvez créer et suivre les ressources d’Argo CD. Argo CD supporte plusieurs « Applications » qui sont en fait un regroupement de manifests stockés dans un dépôt git. Il n’est donc pas soumis aux mêmes limitations que Flux. Il supporte lui aussi les alertes via des « Jobs » créés par Argo CD lors de certains événements. Par exemple, il existe un événement en cas d’échec de synchronisation (SyncFail) et en cas de réussite de synchronisation (PostSync).

Argo CD stocke les déploiements d’applications via des CRDs. Il est donc possible d’intégrer les manifests d’Argo dans le processus GitOps.

Argo Flux

Argo Flux est un projet très récent annoncé peu avant la KubeCon US 2019 (novembre 2019). Il a pour ambition d’être la fusion des projets Argo CD et Flux. Le développement et les releases régulières sur les projets Flux et Argo CD sont pour l’instant toujours d’actualité.

Weave, Intuit et AWS ont annoncé conjointement le projet et vont participer à son développement.

Le projet est encore à un stade très précoce et n’a, à ce jour, aucune release. Vous pouvez retrouver les avancements du projet sur le dépôt du Gitops Engine.

Conclusion

L’outil qui ressort pour les déploiements GitOps sur Kubernetes est Argo CD, notamment parce qu’il est déployable et configurable lui-même dans un processus GitOps, c’est-à-dire de façon déclarative avec des CRDs. Il est également plutôt simple d’utilisation et propose des features indispensables comme du SSO via de l’OIDC par exemple.

Il faudra tout de même suivre de près les évolutions d’outils comme Argo Flux et Jenkins X.