Organisation GitOps et hargo

Références externes :

Contexte et description de la problématique

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

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

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

✅ 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

👍 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