carnufex/gitops-app-onboarding

Was macht gitops-app-onboarding?

Die Methode ist generisch; die Fakten des Clusters (Pfade, Whitelists, Registry, Storage-Klassen, Gateways, Referenz-Apps, wo Alarme leben) befinden sich in .claude/profiles/gitops.md im GitOps-Repository. Lesen Sie zuerst das Profil. Wenn es fehlt, erstellen Sie es aus templates/profile.md, indem Sie das Repository lesen (das ApplicationSet, das AppProject, den Secret Store, eine oder zwei bestehende Apps, den Monitoring-Ordner) und teilen Sie dem Benutzer in einer Zeile mit, dass Sie es geschrieben haben. Raten Sie niemals einen Pfad.

Wie eine App live wird

• Ein ApplicationSet mit einem Directory-Generator macht jeden Ordner unter dem App-Verzeichnis des Profils zu einer eigenen ArgoCD Anwendung und einem eigenen Namespace. Ein Ordner wird bereitgestellt, sobald er eine gültige kustomization.yaml enthält.
• Nichts erreicht den Cluster, bis es auf den Branch gepusht wird, den ArgoCD verfolgt. Eine Änderung, die nur mit kubectl angewendet wird, wird beim nächsten Sync rückgängig gemacht.
• Plattformkomponenten (CNI, Storage, Controller) gehören nicht in das App-Verzeichnis; das Profil sagt, wo sie leben.

Ein neuer Namespace muss überall in demselben Commit auf die Whitelist gesetzt werden

Der Abschnitt Whitelists des Profils listet jede Datei auf, die Namespaces benennt (typischerweise: die destinations des AppProject, die conditions des ClusterSecretStore und den LoadBalancer-IP-Pool und die L2/BGP-Ankündigungsselektoren, wenn die App eine LB-IP benötigt). Fehlt eine, synchronisiert die App nicht, bleiben ihre ExternalSecrets im Zustand SecretSyncError oder ihre LB-IP wird nie angekündigt. Fügen Sie den Namespace in jede zutreffende Datei in dem Commit ein, der den Ordner hinzufügt.

Onboarding-Reihenfolge (kleinste sichere Form zuerst)

1. ns.yaml: der Namespace mit den Pod-Sicherheitslabels des Profils.
2. kustomization.yaml: Ressourcen in Abhängigkeitsreihenfolge (Namespace und Konfiguration, dann Workloads, dann Routen).
3. Secrets: Erstellen Sie zuerst die Einträge im Secret-Backend (Profil: Secrets), dann ein ExternalSecret pro Secret. Committen Sie niemals Secret-Werte; Bootstrap- und Notfall-Secrets bleiben außerhalb von Git.
4. Runtime-Manifeste (Deployment, Service, PVCs, ConfigMap), erst nachdem die Imagenamen und Secret-Namen bestätigt wurden. Readiness- und Liveness-Probes auf einem echten Health-Endpunkt, Ressourcenanforderungen und der Sicherheitskontext, den die Pod-Sicherheitsstufe des Namespace erfordert.
5. Das 3-Uhr-morgens-Signal (unten), in derselben Änderung wie der Workload.
6. Die Route, zuletzt, sobald das Image läuft, Secrets aufgelöst sind und die Probes bestehen (siehe Exposure).
7. Eine README.md im App-Ordner: was es ist, seine Runtime-Abhängigkeiten, seine Secret-Namen, sein Storage, wie es erreicht wird.

Konventionen (das Profil enthält die Werte)

• Images: Pin tag@sha256:<digest>, es sei denn, das Profil sagt, dass die App einem beweglichen Tag folgt; eigene Images stammen aus der Registry des Profils mit unveränderlichen Tags. Private Images benötigen das Pull-Secret-Muster des Profils.
• Secrets: ExternalSecret-Ressourcen gegen den ClusterSecretStore des Profils, niemals Inline-Secret-Daten.
• Storage: Die Storage-Klassen des Profils und wofür jede ist (kleine replizierte Block-Volumes vs. Bulk-Daten auf NFS). Kapazitätsgrenzen im Profil sind harte Grenzen.
• Routing: Öffentliche und interne Gateways und deren Host-Muster; Raw-TCP/UDP über einen LoadBalancer-Service.
• Kopieren Sie die Form der Referenz-Apps des Profils, anstatt eine neue zu erfinden.

Das 3-Uhr-morgens-Signal

Fragen Sie vor dem Pushen: Wenn diese App um 3 Uhr morgens kaputt ginge, wie würde das jemand erfahren, und was würde er sich zuerst ansehen?

• Die App muss durch einen Alarm abgedeckt sein, der eine Person erreicht: Fügen Sie ihren Namespace und Workload zu den Monitoring- Alarmregeln des Profils hinzu (nicht verfügbare Replicas, Crash-Loops, ausstehende Pods oder PVCs), oder fügen Sie eine app-spezifische Regel hinzu, wenn sie einen Ausfallmodus hat, den diese nicht sehen können (eine Warteschlange, die nicht abfließt, ein Job, der nicht mehr läuft, ein ablaufendes Zertifikat oder Token).
• Die Logs der App müssen sagen, was fehlgeschlagen ist, mit den IDs, die es lokalisieren; wenn das Image von uns ist und sie das nicht tun, ist das eine Aufgabe.
• Schreiben Sie das Signal in die Commit-Nachricht: 3 Uhr morgens: <Alarmname> via <Empfänger>.

Exposure

Fügen Sie keine öffentliche Route hinzu, bevor die App läuft, ihre Secrets aufgelöst sind und ihre Health-Checks bestanden sind. Nur-interne Tools werden nur an das interne Gateway angebunden und erhalten keine öffentliche Route. Wenn Sie es öffentlich machen, folgen Sie den Verwandten Fähigkeiten des Profils für den öffentlichen Ingress-Pfad (DNS, Tunnel, Zertifikate).

Nach dem Onboarding (überprüfen, nicht annehmen)

1. Pushen; beobachten Sie, wie die neue Anwendung erscheint und konvergiert (kubectl get applications.argoproj.io -n argocd, oder die Verify-Befehle des Profils). Fordern Sie eine Aktualisierung an, um die Poll-Verzögerung zu überspringen, wenn das Profil zeigt, wie.
2. Überprüfen: Anwendung Synced und Healthy, jedes ExternalSecret SecretSynced, Pods bereit, die Route antwortet, und die Alarmregel ist geladen (sie erscheint in der Regel-Liste des Monitoring-Stacks).
3. Wenn es nicht konvergiert, gehen Sie die Kette von oben nach unten durch: Whitelists → Secrets → ArgoCD-Sync-Fehler → Pods → Routing. Die Whitelists sind der übliche Übeltäter. Die Verwandten Fähigkeiten des Profils nennen die Diagnosefähigkeit des Clusters.