Organisation GitOps et hargo
Références externes :
Contexte et description de la problématique
Problèmes rencontrés
- Une part importante du code est dupliqué entre Kity et toucasser, c’est peu réutilisable tel quel
- Il est difficile de publier des configurations compatibles avec hepto autrement que du boilerplate
- L’organisation du dépôt devient complexe avec les dossiers à plat lorsque les applications se multiplient
Alternatives considérées
- Proposer des dépôts à clôner qui contiennent les manifests et s’appuyer sur Git pour la gestion
- Tout packager sous forme de Helm et utiliser les mêmes charts sur tous les clusters
- Organiser sous forme d’overlays Kustomize
Éléments moteurs de la décision
- Nous avons déjà basculé assez largment vers des manifests bruts plutôt que des charts Helm
- Nous utilisons Kustomize en overlay ponctuellement, par exemple pour déployer Calico
- Systématiser à base d’overlay Kustomize n’est pas incompatible avec le mode manifests bruts, voire un dépôt en submodule le jour où ce sera pertinent, et cela permet aussi d’utiliser des charts Helm là où c’est nécessaire
Conclusion
- ✅ Configuration d’ApplicationSets par projet qui pointent vers des sous-dossiers du repo
- ✅ Chaque sous-dossier contient soit une application en manifests bruts, soit un kustomize
- ✅ Les kustomize sont des overlay soit de sources kustomize existantes, soit d’un dépôt source commun
- ✅ Le projet hargo est créé sous ACIDES pour gérer les applications communes aux clusters que nous déployons
- ✅ Les overlays sont référencées par commit pour éviter les déploiement inopportuns sur un commit erronné upstream
Conséquences
- 👍 Simplification de la structure de nos dépôts GitOps
- 👍 Factorisation des applications entre Kity et toucasser, réutilisabilité par d’autres
- 👎 Beaucoup d’applications deviennent très succintes, une simple overlay, et la logique nécessite d’alterner entre les dépôts