Le terme GITOPS a commencé à se faire connaître en 2017, parallèlement à la popularisation croissante de nouvelles technologies telles que les conteneurs, Docker, le Cloud, etc.

Ce nouveau concept dérivé du mot GIT (système de contrôle de version) et OPS (opérations) est un ensemble de bonnes pratiques et le concept que tout tourne autour de GIT. Le GITOPS est considéré comme une évolution de l’infrastructure en tant que code (IaC) intégrant les meilleures pratiques DevOps, ce qui entre en conflit avec le modèle traditionnel CI/CD (intégration continue/distribution continue).

Ce modèle CI/CD traditionnel suit une ligne continue depuis le téléchargement du code dans le dépôt, suivi de la complication de l’image et du déploiement au niveau du back-end.

Ce processus linéaire utilisé dans CI/CD est divisé en 2 lorsque nous appliquons les pratiques GitOps :

• D’une part, l’image sera compilée et d’autre part, un dépôt git sera mis à jour, où il sera indiqué que l’image a été mise à niveau pour un déploiement.
• L’outil utilisé dans GitOps veillera à ce que le déploiement dans le cluster corresponde à ce nouvel état souhaité enregistré dans Git.

L’une des règles de base de GITOPS est que « si ce n’est pas dans GIT, cela ne doit pas être déployé ; et si c’est le cas, cela doit être déployé dans le même état que celui indiqué par GIT« . Cela nous permet de disposer d’un mécanisme de versionnement de la création, de la suppression et de la modification de tout objet composant une application.

Nous parlons d’objets car GitOps et Kubernetes vont de pair, comme nous le verrons plus loin.

Principes de GitOps

• L’environnement sera écrit dans un langage déclaratif : cela permet de lire facilement le code du dépôt.
• Git comme source de vérité : toute modification de la configuration doit être stockée dans le référentiel. Git devient la source unique de vérité. Il simplifie le processus de téléchargement, les retours en arrière, le suivi des modifications, la reprise rapide après sinistre (il peut être déployé facilement dans un autre cluster). TOUT est enregistré, quelle que soit la transaction.
• Approbation des modifications : toute modification doit être gérée par Git, à l’aide de demandes d’extraction, de branches protégées, etc. Il s’agit d’un modèle ouvert à la personnalisation par chaque organisation. Il s’agit d’un modèle qui peut être personnalisé par chaque organisation. L’important est le besoin d’approbation et, une fois approuvé, il doit pouvoir être appliqué automatiquement dans le système.
• Utilisation d’agents : un agent sera chargé de vérifier les modifications apportées au référentiel et contrôlera que le système est dans l’état demandé dans GIT. Le système notifiera toute anomalie ou erreur.

Avantages

• Téléchargement de versions.
• Audit.
• Rollback en cas d’échec : tout est dans Git.
• Observabilité : les déploiements sont toujours dans l’état souhaité, la modification ou la suppression d’un objet est possible, mais il sera automatiquement recréé.
• Facilité de gestion et d’administration.
• Tous les avantages de l’utilisation de GIT basés sur les avantages des conteneurs.

Inconvénients

Il existe un inconvénient majeur qui est le stockage des objets Secrets dans Git. Rappelons qu’une valeur cryptée d’un secret a en fait été convertie en base64, et qu’il est donc très facile de la décrypter. Certaines entreprises ont apporté une solution à ce problème, comme Bitnami en développant « Sealed Secret », que tout le monde peut facilement mettre en œuvre dans son cluster.

D’autres entreprises proposeront certainement leur système GitOps et apporteront une solution à ce problème.

GitOps dans Kubernetes

Comme mentionné précédemment, GitOps et Kubernetes sont liés, car tout dans Kubernetes est défini comme des objets. Ces objets sont définis en yaml ou json, et sont donc faciles à gérer dans Git. Par exemple, un configmap enregistré dans Git doit correspondre à celui déployé dans le cluster.

GitOps sur OpenShift

RedHat s’est appuyé sur ArgoCD pour ajouter GitOps avec un support d’entreprise.

Il a développé un opérateur (RedHat OpenShift GitOps) qui déploie Argo et est entièrement intégré à OpenShift, par exemple si un objet n’est pas dans l’état souhaité, alertmanager enverra une notification à partir d’ArgoCD.

Il s’intègre également à OpenShift Pipelines (tekton) pour le CI. Tekton est un outil CI/CD qui gère toutes les parties du cycle de vie du développement, de la création de l’image au déploiement des objets du cluster.

Depuis le 3 mai, RedHat a annoncé la « General Availability » (GA) d’OpenShift GitOps et d’OpenShift Pipelines.

Outil GitOps : ArgoCD

Un des outils les plus populaires pour GitOps appartenant à la CNCF, il étend l’API Kubernetes à travers des CRDs (Custom Resource Definitions), de sorte que nous pouvons définir la configuration des applications et des instances argocd comme des objets Kubernetes.

Il offre une interface claire et facile à gérer, il peint automatiquement tous les objets et leurs dépendances.

Une fois déployé, il se charge d’effectuer des pulls vers les dépôts agrégés pour comparer l’état souhaité des objets avec ceux déployés dans le ou les clusters.

Il nous permettra de déployer facilement une application dans plusieurs clusters de manière centralisée, en s’assurant que chaque application est correctement déployée dans tous les clusters.

Il est capable de déployer des manifestes traditionnels tels que yamls, json, mais aussi à partir d’outils tels que Helm, Kustomize, Ksonnet, etc.

Il supporte l’authentification : OIDC, OAuth2, LDAP, SAML 2.0, GitHub, GitLab, Microsoft , etc. Et il utilise une politique basée sur les rôles.

Pour la gestion des secrets, ce gros problème dont nous avons parlé plus tôt, il offre un support pour : Bitnami Sealed Secrets, Godaddy K8S External Secrets, Vault, Banzai Cloud Bank Vaults, Helm Secrets, Kustomize secret, AWS secret operator.

Conclusions

L’utilisation de GitOps est devenue essentielle dans mon travail. En administrant et en gérant plusieurs clusters à partir de plusieurs clients, je garde une trace de ce qui, quand et comment cet objet a été modifié, ce qui a conduit à un problème et à sa résolution rapide grâce à l’utilisation de Git.

Le déploiement d’objets à l’aide d’outils CI/CD traditionnels ne peut être assimilé à l’utilisation de GitOps. Par exemple, vous pouvez déployer un configmap dans un namespace en utilisant Jenkins, mais personne ne peut garantir qu’après plusieurs mois, ce configmap sera dans le bon état.

Peu importe que vous soyez développeur, administrateur… Dès que vous commencerez à utiliser GitOps, vous découvrirez que vous ne pouvez pas travailler sans ces facilités.