Laufender Betrieb

Für Updates gibt es keinen eigenen Werkzeugsatz. Jeder Eingriff im laufenden Betrieb, ob neues Image, geänderte Konfiguration, rotiertes Secret oder mehr Kapazität, läuft über dieselben nyx_*-Tools wie der erste Deploy, nur anders kombiniert. (Wie Sie eine App beobachten, statt sie zu ändern, also Logs, Ressourcennutzung und Traffic, steht unter Monitoring.)

Ändern, neu starten, skalieren, einsehen

• Neuen Image-Build ausliefern (gleiche Quelle, neu gebaut). Ihr Agent ruft erneut nyx_build_and_push_image auf. Das liefert eine neue image_ref mit fortlaufend hochgezähltem Suffix -N. Danach ruft er nyx_deploy_manifests nur mit dem aktualisierten Deployment-Dokument auf und lässt app_manifest weg, damit das Tool die UID der App selbst aus dem Cluster ermittelt.
• ConfigMap, Service oder Ingress ändern. Derselbe Weg über nyx_deploy_manifests mit dem geänderten Dokument, auch hier ohne app_manifest.
• Secret rotieren. nyx_set_secret schreibt den neuen Wert, danach führt nyx_shell den Befehl kubectl rollout restart deployment/<app> -n <namespace> aus, damit der Pod den neuen Ciphertext übernimmt. Derselbe Befehl dient auch für einen einfachen Neustart ohne Änderung an der Spezifikation.
• Skalieren. Entweder nyx_shell mit kubectl scale deployment/<app> --replicas=N -n <namespace> für eine einmalige Änderung oder nyx_deploy_manifests mit einer aktualisierten Deployment-YAML, damit die Änderung bestehen bleibt.
• Einsehen. nyx_app_list / nyx_app_get für den Überblick auf App-Ebene, nyx_app_get mit view: deployments für die Rollout-Historie der ReplicaSets und nyx_shell mit lesendem kubectl get ... -o ... für alles andere.
• Löschen. Eine einzelne Ressource läuft über nyx_shell (kubectl delete <kind>/<name> -n <namespace>). Eine ganze App läuft über kubectl delete app/<name> -n <namespace>, und die ownerRef-Kaskade entfernt alles, was ihr gehört, Volumes und Buckets eingeschlossen. Wenn Sie Daten behalten wollen, lesen Sie vor dem Löschen Speicher und Backups.

Hinweis: Fehlt app_manifest, liest nyx_deploy_manifests das Label app.kubernetes.io/instance aus jedem Dokument, bestätigt, dass alle zur selben App gehören, ermittelt die UID dieser App im Cluster, setzt sie für <APP_UID> ein, validiert die ownerRefs und wendet dann an. Existiert die App noch nicht, schlägt das mit app-not-found fehl, und app_manifest wird Pflicht.

Mehrere Apps in einem Projekt betreiben

Ein Projekt kann beliebig viele Apps enthalten, etwa ein Compose-Monorepo mit Frontend, API und Datenbank oder eine Aufteilung in Web, Worker und Queue. Jede App bekommt ihren eigenen Aufruf von nyx_deploy_manifests mit eigenem app_manifest. Das Tool arbeitet atomar pro App und fasst keine Aufrufe zusammen.

Unabhängige Apps lassen sich in beliebiger Reihenfolge ausrollen. Bei abhängigen Apps (etwa einer API, deren Datenbank zuerst laufen muss) rollen Sie erst die Abhängigkeit aus und warten auf sie, bevor die abhängige App folgt:

kubectl wait --for=condition=Ready pod -l app.kubernetes.io/instance=<dependency> -n <namespace> --timeout=25s

Halten Sie jedes Warten unter etwa 25 Sekunden und fragen Sie nach einem Timeout erneut ab. Ein einzelner langer Timeout oder eine Sleep-Schleife überdauert den Timeout des MCP-Clients nicht.

Entstehen nach dem Plan mehrere Workload-Pods, prüfen Sie vor dem ersten Deploy-Aufruf die Reserven bei RAM und CPU. Das Kontingent des Projekts teilen sich alle Pods im Namespace.

In Repos mit docker-compose.yml wird jeder Service zu einem eigenen App-CRD, nie eine einzige App für die ganze Compose-Datei. depends_on ergibt direkt die Reihenfolge der Deploys. environment-Blöcke aus Compose werden entweder zu einem Secret auf Projektebene (gemeinsame Werte) oder zu einem App-Secret pro Service.

Helm-Charts rendern Sie mit helm template, ergänzen die Standard-Labels und ownerRefs und wenden das Ergebnis dann mit kubectl apply an. Verwenden Sie helm install nicht direkt. Es umgeht das Eigentumsmodell des App-CRD und hinterlässt Ressourcen, wenn die App später gelöscht wird.

Andere Apps im Projekt erreichen

Eine App erreicht eine andere App im selben Namespace über deren Service-Namen als Host, als Kurznamen (db) oder als FQDN (db.<namespace>.svc.cluster.local), und zwar auf dem port des Service, nicht auf seinem targetPort. Das läuft über das normale Cluster-DNS, zusätzlich bereitstellen müssen Sie nichts.

Sprechen Sie eine andere App nie über die Pod-IP an (sie ändert sich bei jedem Neustart) und nie über ihre öffentliche URL {{ .AppDomainPattern }}. Dieser Weg führt ins Internet und über den Ingress zurück. Datenbankprotokolle liefern dort ein 502, und Dienste ohne HTTP bekommen gar keine öffentliche Domain.

Bauen Sie den Connection-String aus Service-Namen und Service-Port, speichern Sie ihn mit nyx_set_secret auf Projektebene, damit jede App im Namespace ihn lesen kann, und binden Sie ihn über envFrom ein:

DATABASE_URL=postgres://user:pass@db:5432/appdb

Dasselbe Muster gilt für jeden Dienst, auf den eine App zugreift. Nur Schema und Port ändern sich:

• redis://cache:6379/0
• mongodb://mongo:27017/appdb
• amqp://mq:5672
• http://api:8080 für eine interne HTTP-API (Port ohne Namen bzw. nicht als HTTP kennzeichnen, damit er nicht über den Ingress läuft)

Für getrennte Umgebungsvariablen für Host und Port setzen Sie host = <service-name> und port = <service port>. Aufrufe über Namespaces hinweg brauchen den FQDN, innerhalb eines Namespace genügt der Kurzname.

Nächste Schritte

• Eigene Domain hinzufügen: Ihren eigenen Hostnamen anbinden
• Next.js-App ausrollen: der erste Deploy Schritt für Schritt