carnufex/intégration-app-gitops

Intégration d'application GitOps

La méthode est générique ; les faits du cluster (chemins, listes blanches, registre, classes de stockage, passerelles, applications de référence, où vivent les alertes) se trouvent dans .claude/profiles/gitops.md dans le dépôt GitOps. Lisez d'abord le profil. S'il est manquant, créez-le à partir de templates/profile.md en lisant le dépôt (l'ApplicationSet, l'AppProject, le magasin de secrets, une ou deux applications existantes, le dossier de surveillance) et informez l'utilisateur en une ligne que vous l'avez écrit. Ne devinez jamais un chemin.

Comment une application devient active

• Un ApplicationSet avec un générateur de répertoire transforme chaque dossier sous le répertoire des applications du profil en sa propre application ArgoCD et son propre namespace. Un dossier se déploie une fois qu'il contient un kustomization.yaml valide.
• Rien n'atteint le cluster tant qu'il n'est pas poussé sur la branche suivie par ArgoCD. Une modification appliquée uniquement avec kubectl est annulée à la prochaine synchronisation.
• Les composants de la plateforme (CNI, stockage, contrôleurs) ne vont pas dans le répertoire des applications ; le profil indique où ils se trouvent.

Un nouveau namespace doit être mis en liste blanche partout, dans le même commit

La section Listes blanches du profil liste chaque fichier qui nomme des namespaces (typiquement : les destinations de l'AppProject, les conditions du ClusterSecretStore, et le pool d'IP LoadBalancer et les sélecteurs d'annonce L2/BGP si l'application a besoin d'une IP LB). Si on en manque un, l'application échoue à se synchroniser, ses ExternalSecret restent en SecretSyncError, ou son IP LB n'est jamais annoncée. Ajoutez le namespace à chaque fichier applicable dans le commit qui ajoute le dossier.

Ordre d'intégration (la plus petite configuration sécurisée d'abord)

1. ns.yaml : le namespace avec les labels de sécurité pod du profil.
2. kustomization.yaml : ressources dans l'ordre des dépendances (namespace et configuration, puis charges de travail, puis routes).
3. Secrets : créez d'abord les entrées dans le backend de secrets (profil : Secrets), puis un ExternalSecret par secret. Ne commettez jamais les valeurs de secret ; les secrets d'amorçage et de secours restent en dehors de Git.
4. Manifestes d'exécution (Deployment, Service, PVCs, ConfigMap), seulement après que les noms d'image et les noms de secret sont confirmés. Sondes de préparation et de vivacité sur un point de terminaison de santé réel, demandes de ressources, et le contexte de sécurité que le niveau de sécurité pod du namespace exige.
5. Le signal 3h du matin (ci-dessous), dans le même changement que la charge de travail.
6. La route, en dernier, une fois que l'image s'exécute, que les secrets se résolvent et que les sondes passent (voir Exposition).
7. Un README.md dans le dossier de l'application : ce qu'elle est, ses dépendances d'exécution, ses noms de secret, son stockage, comment on y accède.

Conventions (le profil contient les valeurs)

• Images : épinglez tag@sha256:<digest> sauf si le profil indique que l'application suit une balise mobile ; les images propres proviennent du registre du profil avec des balises immuables. Les images privées ont besoin du modèle de pull-secret du profil.
• Secrets : ressources ExternalSecret contre le ClusterSecretStore du profil, jamais de données Secret en ligne.
• Stockage : les classes de stockage du profil et leur usage (petits volumes bloc répliqués vs données volumineuses sur NFS). Les limites de capacité dans le profil sont des limites strictes.
• Routage : passerelles publiques et internes et leurs modèles d'hôte ; TCP/UDP brut via un Service LoadBalancer.
• Copiez la forme des Applications de référence du profil plutôt que d'en inventer une nouvelle.

Le signal 3h du matin

Demandez avant de pousser : si cette application se cassait à 3h du matin, comment le saurait-on, et que regarderait-on en premier ?

• L'application doit être couverte par une alerte qui atteint une personne : ajoutez son namespace et sa charge de travail aux règles d'alerte Surveillance du profil (réplicas indisponibles, boucles de plantage, pods ou PVCs en attente), ou ajoutez une règle spécifique à l'application si elle a un mode de défaillance que celles-ci ne peuvent pas détecter (une file d'attente qui cesse de se vider, un job qui cesse de s'exécuter, un certificat ou un jeton qui expire).
• Les logs de l'application doivent indiquer ce qui a échoué avec les identifiants qui le localisent ; si l'image est la nôtre et qu'ils ne le font pas, c'est une tâche.
• Écrivez le signal dans le message du commit : 3h du matin : <nom de l'alerte> via <récepteur>.

Exposition

N'ajoutez pas de route publique tant que l'application ne s'exécute pas, que ses secrets ne se résolvent pas et que ses contrôles de santé ne passent pas. Les outils internes uniquement s'attachent seulement à la passerelle interne et n'obtiennent pas de route publique. Lorsque vous exposez publiquement, suivez les Compétences connexes du profil pour le chemin d'entrée public (DNS, tunnel, certificats).

Après l'intégration (vérifiez, ne supposez pas)

1. Poussez ; regardez la nouvelle application apparaître et converger (kubectl get applications.argoproj.io -n argocd, ou les commandes Vérifier du profil). Demandez un rafraîchissement pour sauter le délai d'interrogation si le profil montre comment.
2. Vérifiez : application Synced et Healthy, chaque ExternalSecret SecretSynced, pods prêts, la route répond, et la règle d'alerte est chargée (elle apparaît dans la liste des règles de la pile de surveillance).
3. Si elle ne converge pas, parcourez la chaîne de haut en bas : listes blanches → secrets → erreurs de synchronisation ArgoCD → pods → routage. Les listes blanches sont le coupable habituel. La section Compétences connexes du profil nomme la compétence de diagnostic du cluster.