Principes de GitOps

Ce document explique le workflow GitOps utilisé actuellement par la plateforme Atlas, ses principes fondamentaux et comment il est mis en œuvre pour gérer les ressources et les déploiements.

Note importante sur l'évolution future : Le mode de fonctionnement actuel basé sur GitOps sera dans un futur proche remplacé par un portail complet où les utilisateurs pourront commander leurs ressources via un formulaire web. À terme, le dépôt GitOps ne sera qu'un détail d'implémentation. Cette documentation reflète le fonctionnement présent de la plateforme.

Qu'est-ce que GitOps ?

GitOps est une approche de gestion de l'infrastructure et des applications où l'état souhaité est déclaré dans des fichiers YAML stockés dans un dépôt Git. Les changements sont automatiquement appliqués lorsqu'ils sont poussés vers le dépôt. Cette approche offre plusieurs avantages :

Versionnable : Toutes les modifications sont versionnées dans Git.
Auditabilité : L'historique des modifications est facilement accessible.
Reproductibilité : L'état de l'infrastructure peut être reproduit à partir du code source.
Collaboration : Les équipes peuvent collaborer en utilisant les mêmes outils que pour le développement logiciel (pull requests, revues de code, etc.).
Automatisation : Les changements sont automatiquement appliqués, réduisant les erreurs humaines.

Principes de GitOps

L'état souhaité est déclaratif : L'infrastructure est définie de manière déclarative dans des fichiers YAML.
L'état souhaité est versionné dans Git : Git est la source unique de vérité pour l'état souhaité.
Les changements approuvés sont automatiquement appliqués : Une fois les changements poussés vers le dépôt, ils sont automatiquement appliqués à l'infrastructure.
Les divergences sont automatiquement corrigées : Si l'état réel diverge de l'état souhaité, le système tente automatiquement de corriger la divergence.

Mise en œuvre de GitOps dans Atlas

Atlas utilise ArgoCD comme outil GitOps pour synchroniser l'état souhaité (défini dans les dépôts Git) avec l'état réel des ressources déployées.

Structure et restrictions des dépôts

Atlas utilise une structure de dépôts Git hiérarchique, chacun avec des règles spécifiques :

Dépôt d'organisation : Dédié à la création et gestion des workspaces.
Chemin : resources/
Contenu : Fichiers YAML définissant les workspaces.
Restrictions :
- Seules les ressources appartenant au groupe org.fabrique.social.gouv.fr (comme Workspace) sont autorisées
- Les ressources doivent exister dans l'espace de noms approprié de l'organisation
- Il est recommandé d'omettre le champ metadata.namespace pour utiliser l'espace de noms par défaut
Dépôt de workspace : Utilisé pour créer des ressources et déployer des applications.
Structure en deux parties distinctes :

a. Ressources de workspace : - Chemin : resources/ - Contenu : Fichiers YAML définissant les ressources (buckets, databaseclusters, deploymenttargets). - Restrictions : - Seules les ressources appartenant au groupe workspace.fabrique.social.gouv.fr (comme DeploymentTarget) sont autorisées - Les ressources doivent exister dans l'espace de noms approprié du workspace - Il est recommandé d'omettre le champ metadata.namespace pour utiliser l'espace de noms par défaut

b. Ressources de déploiement : - Chemin : deployment-targets/<nom-du-deployment-target>/ - Contenu : Fichiers YAML définissant les ressources Kubernetes à déployer dans le DeploymentTarget. - Restrictions : - Actuellement, aucune restriction de groupe n'est appliquée, permettant aux utilisateurs de déployer leurs applications comme ils le souhaitent - À noter qu'il existe des discussions en cours concernant la création de CRD spécifiques aux applications dans un nouveau groupe (par exemple apps.fabrique.social.gouv.fr) et la restriction à ces seules ressources

Note : Ces dépôts sont conçus comme des détails d'implémentation. À terme, toutes les modifications seront effectuées via le portail utilisateur ou par automatisation. Néanmoins, les utilisateurs peuvent manipuler directement les dépôts sous leur propre responsabilité.

Flux de travail

Création d'un workspace

L'administrateur d'organisation clone le dépôt de l'organisation.
Il crée un fichier YAML dans le dossier resources/ pour définir un nouveau workspace.
Il pousse les changements vers le dépôt.
ArgoCD détecte les changements et crée le workspace.
Un nouveau dépôt Git est créé pour le workspace.

Création d'une ressource (bucket, databasecluster, deploymenttarget)

L'administrateur de workspace clone le dépôt du workspace.
Il crée un fichier YAML dans le dossier resources/ pour définir une nouvelle ressource.
Il pousse les changements vers le dépôt.
ArgoCD détecte les changements et crée la ressource.
Les secrets d'accès à la ressource sont automatiquement livrés aux DeploymentTargets spécifiés.

Déploiement d'une application

L'administrateur de workspace ou un utilisateur avec les droits appropriés clone le dépôt du workspace.
Il crée un DeploymentTarget s'il n'existe pas déjà.
Il crée ou modifie des fichiers YAML dans le dossier deployment-targets/<nom-du-deployment-target>/ pour définir les ressources Kubernetes à déployer.
Il pousse les changements vers le dépôt.
ArgoCD détecte les changements et déploie les ressources dans le namespace du DeploymentTarget.

Synchronisation et réconciliation

ArgoCD surveille en permanence les dépôts Git et compare l'état souhaité (défini dans les fichiers YAML) avec l'état réel des ressources déployées. Si une divergence est détectée, ArgoCD tente automatiquement de réconcilier l'état réel avec l'état souhaité.

Avantages du workflow GitOps dans Atlas

Self-service : Les utilisateurs peuvent déployer et gérer leurs ressources de manière autonome.
Traçabilité : Toutes les modifications sont tracées dans Git.
Reproductibilité : Les environnements peuvent être reproduits à partir du code source.
Rollback facile : En cas de problème, il est facile de revenir à une version précédente.
Collaboration : Les équipes peuvent collaborer en utilisant les outils Git (pull requests, revues de code, etc.).
Automatisation : Les déploiements sont automatisés, réduisant les erreurs humaines.

Bonnes pratiques

Utilisez des branches : Pour les changements importants, utilisez des branches et des pull requests pour permettre la revue de code.
Testez localement : Utilisez des outils comme kubectl apply --dry-run pour tester vos manifestes avant de les pousser.
Utilisez des commentaires : Documentez vos ressources avec des commentaires pour faciliter la compréhension.
Structurez vos dépôts : Organisez vos fichiers de manière logique pour faciliter la navigation.
Utilisez des outils de validation : Utilisez des outils comme kubeval ou kube-linter pour valider vos manifestes.
Limitez les accès : Limitez les droits d'écriture sur les dépôts aux personnes qui en ont besoin.

Conclusion

Le workflow GitOps utilisé par Atlas offre une approche puissante et flexible pour gérer l'infrastructure et les déploiements. En suivant les principes de GitOps, Atlas permet aux utilisateurs de gérer leurs ressources de manière autonome, tout en garantissant la traçabilité, la reproductibilité et l'automatisation des déploiements.