GitOps und Secrets

GitOps ist der unterstützte Deployment-Pfad. Ein Commit in das konfigurierte Repository ändert den gewünschten Anwendungszustand; die Plattform reconciled diesen Zustand.

Secrets dürfen nicht in Git committed werden. Speichern Sie Secret-Werte im konfigurierten Secret-Workflow und referenzieren Sie sie aus Manifesten.

Repository verbinden

Applications öffnen.
GitOps-Binding-Bereich finden.
Repository URL, Branch, Pfad und Transportinformationen eintragen.
Sanitized Preview prüfen.
Speichern und Reconciliation State abwarten.

Nutzen Sie gh0stservice/ghc-gitops-example nur als strukturelle Referenz.

Repository-Struktur

Starten Sie klein:

kustomize/
  base/
    app/
  overlays/
    gh0stcloud/
      kustomization.yaml

Erweiterte Overlays erst hinzufügen, wenn der erste Deployment-Pfad funktioniert.

Secrets Workflow

Schritt	Owner
Secret-Wert liegt im Tenant-Secret-Backend-Pfad aus dem Portal.	Tenant oder gh0stservice, je nach Scope
Git enthält nur Referenzen auf Secret-Pfad oder -Name.	GitOps Owner
Die Plattform synchronisiert das resultierende Kubernetes Secret, sofern erlaubt.	Platform Runtime
Die Workload referenziert das generierte Secret.	Application Owner

Secret-Werte niemals in Manifeste, Support Tickets, Beispiele oder Agent Prompts kopieren.

Vor Agent-Arbeit an Manifesten

Bereitstellen:

Namespace aus gh0stportal;
Anwendungsname und Image Tag;
Service Port;
Hostname aus Network & Exposure, falls öffentlich;
PVC-Name und Größe, falls stateful;
Secret-Namen oder Referenzen, keine Secret-Werte;
erwartete externe Ziele oder Managed-Service-Abhängigkeiten.