Deployments auf Scaleway: aus Git, Image oder Chart in den Cluster

• Welche Quellen kann ein Deployment haben?

  Drei: eine Anwendung aus Git, deren Image Clusterward aus dem Repository baut; ein fertiges Container-Image aus Ihrer Scaleway-Registry; oder ein Helm-Chart aus der Template-Bibliothek. Die Art ist beim Anlegen fest, ein Container-Service kann aber später mit einem Build in eine Git-Anwendung umgewandelt werden, ohne dass die Cluster-Objekte neu entstehen.

• Wo wird das Image gebaut?

  Entweder im Cluster durch einen Kaniko-Job, der das Repository klont, das Dockerfile baut und in die Registry des Clusters pusht, oder auf GitHub-Runnern: Clusterward startet einen Workflow per workflow_dispatch, wartet auf das Ergebnis und rollt das gepushte Image aus. Die zweite Variante belastet den Cluster nicht. Im Cluster pusht der Build mit einem eigenen Schlüssel, der nur die Container Registry nutzen darf – nie mit dem Schlüssel, der Cluster und Datenbanken anlegt.

• Was passiert, wenn der Workflow grün ist, aber kein Image gepusht wurde?

  Clusterward prüft das Image-Tag vor dem Rollout über die Registry-API. Ein eindeutiges „nicht vorhanden“ stoppt das Deployment mit einem Hinweis auf die tags-Zeile des Workflows. Ein Netzwerkfehler oder eine unklare Antwort blockiert dagegen nichts, damit eine flüchtige Störung kein funktionierendes Deployment aufhält.

• Wie aktiviere ich geänderte Umgebungsvariablen?

  Mit der Aktion „Restart“. Sie wendet das aktuelle Image mit der aktuellen Konfiguration erneut an und rollt die Pods über eine Annotation neu aus, ohne das Image zu bauen. Das Cockpit zeigt außerdem einen Hinweis „Restart ausstehend“, sobald eine Änderung gespeichert, aber noch nicht ausgerollt ist.

• Wie lange wartet Clusterward auf einen gesunden Start?

  Standardmäßig zwei Minuten, pro Service einstellbar. Läuft die Zeit ab, meldet das Deployment einen Fehler, weist aber ausdrücklich darauf hin, dass der Rollout im Cluster weiterläuft. Ein langsam startender Dienst wird also nicht abgebrochen, sondern nur als nicht rechtzeitig bereit markiert.

• Kann ich ein laufendes Deployment abbrechen?

  Während der Build-Phase ja: Der Kaniko-Job oder der GitHub-Actions-Lauf wird gestoppt, im Cluster ist noch nichts verändert. Sobald der eigentliche Rollout läuft, dauert er nur Sekunden und wird nicht mehr unterbrochen. Hängen gebliebene Deployments erkennt Clusterward über einen Heartbeat und markiert sie als fehlgeschlagen.

• Was macht Undeploy mit meinen Daten?

  Undeploy entfernt Ingress, Autoscaler, Deployment, Service und Secrets des Services in dieser Reihenfolge und bereinigt Hook-Jobs. Persistente Volumes und Datenbanken bleiben unberührt. Ein Service kann erst gelöscht werden, wenn er nicht mehr ausgerollt ist, damit kein Pod und kein Hostname verwaist.

• Sind die Pods abgesichert?

  Jeder von Clusterward ausgerollte Pod erhält ein Seccomp-Profil, verbietet Privilegien-Eskalation und legt alle Linux-Capabilities ab. Pro Umgebung lassen sich zusätzlich NetworkPolicies anwenden, die eingehenden Verkehr auf den Ingress-Controller beschränken und den Zugriff auf die Cloud-Metadaten-Adresse blockieren.

• Kann ich aus GitHub Actions deployen?

  Ja. Legen Sie unter System → API-Tokens ein Token mit der Rolle „CI deploy“ an und hinterlegen Sie es als Secret im Repository. Der Workflow ruft Deploy oder Neustart per Bearer-Header auf und fragt den Status ab, bis das Deployment gesund ist.

• Wie komme ich zu einer früheren Version zurück?

  In der Deploy-Historie über ⋯ → „Diese Version wiederherstellen“. Ausgerollt wird genau das Image der damaligen gesunden Version, bei Helm-Services Chart-Version und Werte. Konfiguration und Daten bleiben unverändert.

• Was passiert, wenn latest plötzlich auf ein neues Image zeigt?

  Nichts, bis Sie deployen: Jeder Rollout hält das Image per Digest fest, und ein Restart bleibt beim laufenden Image. Die Historie zeigt die ersten acht Zeichen des Digests neben Tag und Commit.

• Wie finde ich heraus, warum ein Deployment gescheitert ist?

  Über den Link am gescheiterten Deployment: Er öffnet die Logs des Services, bei einem Absturz direkt den vorherigen Lauf des Containers. Dort stehen Fehlermeldung und Stacktrace; „Errors only“ blendet alles andere aus.

Ihre Frage ist nicht dabei? Schreiben Sie uns, wir antworten in der Regel am selben Werktag.