Point Argo 💙 Kontinuous

[revolunet]

Faire un point pour étudier quel serait le chemin pour avoir nos review branches déployées par Argo

• [x] templating : voir si la derniere release Argo permettrait d'utiliser des configs kontinuous : NON
• [x] déploiement : voir les difficultés pour avoir des initContainers fonctionnels pour pouvoir déployer avec kubectl : réglé avec
• [ ] Voir le generateur ApplicationSet + pull requests
• [ ] Voir comment générer avec tooling kontinuous
• [ ] RBAC accès à Argo pour les devs

Gains possibles :

• webhook argo (plus besoin de kubeconfig sur GH)
• sync-waves argos
• accès à Argo pour les devs
• moins d'adhérence kontinuous
• plus facile de vendre kontinuous (scope plus précis)

[revolunet]

interesting : https://argo-cd.readthedocs.io/en/stable/user-guide/sync-waves/

[revolunet]

#hypotheses

Un moyen pour exploiter ArgoCD sans impacter son setup ArgoCD serait simplement de pusher sur un GIT les manifests créés par kontinuous dans la CI, avec un dossier par env par exemple.

(L'alternative est de faire tourner kontinuous côté Argo mais c'est pas si simple à mettre en place ou à "vendre" comme approche.)

pros:

• plus de KUBECONFIG nécessaire sur GitHub ? (quid des rancher-project-id?) ArgoCD est branché sur le GIT.
• exploitation des sync waves pour les "needs"
• déploiements visibles dans argo; nécessite de pouvoir setup des acces/RBAC pour les devs. a priori c'est possible
• scope de kontinuous limité à la CI (workflows) + templating
• channel mattermost avec alertes argo pour les SE : annotation notifications.argoproj.io/subscribe.mattermost
• permet d'être compatible CloudPI sur certains aspects (depots des manifests sur GIT, argocd)

cons:

• quid des logs du pipeline GitHub si on déploie avec Argo ? lien vers page Argo ?
• paramétrage spécifique pour kontinuous pour exploiter Argo ? par ex si on veut utiliser kontinuous deploy hors Argo il faudra s'assurer que les "needs" marchent quand même.

Qs:

• nécessité de séparer les repos git par SE ? repo ? ou dans des branches de leur repo (a la gh-pages)?
• quid janitor VS nettoyage du repo GIT ? Si janitor supprime le NS, est-ce qu'Argo le recréé ?

couts:

• setup un ArgoCD dédié kontinuous (si tests OK)
• setup acces/RBAC argo : limiter chaque equipe admins GH à un "projet" particulier de cet ArgoCD. cf github RBAC
• setup CI/git : kontinuous push le résultat dans un GIT ou utiliser une action qui fait déjà ça
• setup argo/git : argo déploie depuis le GIT en question. gérer les paramétrages de try/prune/replace... et envs preprod/prod. par ex que se passe-t-il si on modifie manuellement une ressource sur le cluster (hotfix) ?
• setup script nettoyage GIT : supprimer régulièrement les manifests des envs de reviews ?

En passant, je vois qu'ArgoCD permet d'annoter les namespaces qu'il créé via les Application. ca permettrait de ne pas avoir à connaitre le rancherProjectId pour build le manifest ?

[devthejo]

CRD KontinuousEnv

[devthejo]

gestion des droits:

• ArgoCD: tenant par convention de namespace
• validation webhook to match rancher project separation

[revolunet]

tests sur recosanté : https://github.com/SocialGouv/recosante/compare/fix/use-cnpg-in-dev...test-argo-waves

tests sur template : https://github.com/SocialGouv/template/compare/hasura...hasura-argo

Un souci detecté : les jobs sont recrées en permanence par argo (build, create-secret, seeds)

[revolunet]

Si besoin de mettre des labels type rancher project id sur les NS crées : https://argo-cd.readthedocs.io/en/stable/user-guide/sync-options/#namespace-metadata