Anwendung bereitstellen

Auf dieser Seite wird beschrieben, wie Sie Ihre Anwendung mit Cloud Deploy in die gewünschten Ziellaufzeitumgebungen bringen. Dazu müssen Sie zuerst Ihre Lieferpipeline und Ziele erstellen.

Hinweis

In diesem Abschnitt werden die Voraussetzungen beschrieben, die erfüllt sein müssen, bevor Sie Ihre Anwendung mit Cloud Deploy bereitstellen können.

Prüfen Sie, ob Ihr Ausführungs-Dienstkonto die erforderlichen IAM-Rollen und -Berechtigungenhat.
Erstellen Sie Ihre Lieferpipeline und Ziele.

Mit Cloud Deploy können Sie in Google Kubernetes Engine, Cloud Run, GKE-angehängten Clustern und benutzerdefinierten Zielen bereitstellen. Die Zielkonfiguration unterscheidet sich je nachdem, wo Sie bereitstellen.
Halten Sie Ihre Container-Images und Manifeste bereit.

Sie benötigen mindestens ein Container-Image für die Bereitstellung und mindestens ein Kubernetes-Manifest (für die Bereitstellung in GKE) oder eine YAML-Datei für den Dienst (für die Bereitstellung in Cloud Run).

Sie benötigen eine CI-Pipeline (Continuous Integration) oder einen anderen Prozess, um Ihre Images zu erstellen und zu platzieren. Ihr CI-Tool kann Cloud Build, Jenkins oder ein beliebiges anderes Tool sein, das Container-Images erzeugt, die Sie Ihrer Cloud Deploy-Lieferpipeline zur Verfügung stellen können.
Halten Sie eine skaffold.yaml Konfigurationsdatei bereit.

Cloud Deploy calls skaffold render zum Rendern der Kubernetes-Manifeste mit dieser Datei und skaffold apply zum Bereitstellen in Ihrem Ziel. Dazu benötigt Skaffold mindestens eine minimale skaffold.yaml. Sie haben zwei Möglichkeiten, eine zu erhalten:
- Erstellen Sie Ihre eigene.
  
  Die skaffold.yaml-Datei muss in der ersten Zeile auf die apiVersion verweisen, die von Skaffold unterstützt wird, wie in diesem Beispiel:
```
`apiVersion: skaffold/v4beta7`
```
- Lassen Sie sie für sich generieren.
  
  Wenn Sie noch keine skaffold.yaml-Datei haben, können Sie sie von Cloud Deploy erstellen lassen. Diese Datei eignet sich für das Onboarding, zum Lernen oder zum Vorführen von Cloud Deploy und sollte nicht für Produktionsarbeitslasten verwendet werden.
Weitere Informationen finden Sie unter Skaffold mit Cloud Deploy verwenden. Unter Manifeste in Cloud Deploy verwalten finden Sie weitere Informationen zur Verwendung von Skaffold und Cloud Deploy mit Manifestverwaltungstools wie Helm, Kustomize und kpt.

Cloud Deploy für die gewünschte Laufzeitumgebung einrichten

Mit Cloud Deploy können Sie Ihre Anwendung in einer der folgenden Laufzeitumgebungen bereitstellen:

Lieferpipeline aufrufen, um einen Release zu erstellen

Nachdem Sie Cloud Deploy für die Bereitstellung in Ihrer Laufzeitumgebung konfiguriert haben, können Sie Ihre Anwendung jetzt für die Bereitstellung entsprechend der von Ihnen erstellten Lieferpipeline senden.

Führen Sie Ihren regulären CI-Prozess (Continuous Integration) aus und erstellen Sie bereitstellbare Artefakte.
Um die Lieferpipeline zu initiieren, rufen Sie Cloud Deploy auf, um einen Release zu erstellen.

Führen Sie folgenden Befehl in dem Verzeichnis aus, das Ihre Skaffold-Konfiguration enthält:
```
gcloud deploy releases create RELEASE_NAME --delivery-pipeline=PIPELINE_NAME --region=REGION
```
Da mit diesem Befehl eine Tar-Datei des gesamten Inhalts des Verzeichnisses und aller Unterverzeichnisse erstellt wird, sollten Sie diesen Befehl nicht in Ihrem Home- oder Stammverzeichnis ausführen. Führen Sie den Befehl entweder im Verzeichnis mit Ihrer Skaffold-Konfiguration aus oder fügen Sie die Option --source= ein, die später beschrieben wird.

In diesem Befehl gilt Folgendes:

RELEASE_NAME ist ein Name für diesen Release. Der Name muss unter allen Releases für diese Lieferpipeline eindeutig sein.

Sie können dynamische Release-Namen angeben, indem Sie '$DATE' oder '$TIME' oder beides einfügen. Wenn Sie diesen Befehl beispielsweise um 15:07 Uhr UTC aufrufen, 'rel-$TIME' wird in rel-1507 aufgelöst. '$DATE' und '$TIME' müssen in einfachen Anführungszeichen stehen. Die Zeit ist die UTC-Zeit auf dem Computer, auf dem Sie den Befehl aufrufen.

PIPELINE_NAME ist der Name der Lieferpipeline, die die Bereitstellung dieses Releases in der Abfolge der Ziele verwaltet. Dieser Name muss mit dem name Feld in der Pipelinedefinition übereinstimmen.

REGION ist der Name der Region, in der Sie den Release erstellen, z. B. us-central1. Das ist ein Pflichtfeld.

Mit diesem Befehl wird eine Tar-Datei mit Ihren Konfigurationen in einen Cloud Storage-Bucket hochgeladen und der Release erstellt. Cloud Deploy erstellt weiter automatisch einen Rollout und stellt Ihr Image im ersten in der Lieferpipeline definierten Ziel bereit.

Zusätzlich zu den mit diesem Befehl gezeigten Parametern können Sie eine der folgenden Optionen einfügen:

--images=<name=path/name:$IMAGE_SHA>,<name=path/name:$IMAGE_SHA>

Eine Sammlung von Image-Namen zu Image-Pfad-Ersetzungen.
--build-artifacts=<path/file>

Ein Verweis auf eine Ausgabedatei für Skaffold-Build-Artefakte, die übergeben werden kann, um eine vollständigen Pfadersetzungen für das Image darzustellen.

Diese beiden Optionen schließen sich gegenseitig aus.

Sie können auch eines der folgenden Flags einfügen, damit Cloud Deploy eine skaffold.yaml-Datei für Sie generiert:

--from-k8s-manifest=K8S_MANIFEST

Die generierte Skaffold-Konfiguration basiert auf dem Kubernetes-Manifest, das Sie mit diesem Flag übergeben. Wenn Sie dieses Flag mit dem Flag --skaffold-file oder dem Flag --source verwenden, wird ein Fehler generiert. Weitere Informationen finden Sie unter Generieren Sie Ihre skaffold.yaml.
--from-run-manifest=RUN_MANIFEST

Die generierte Skaffold-Konfiguration basiert auf der Cloud Run-Dienst-YAML, die Sie mit diesem Flag übergeben. Wenn Sie dieses Flag mit dem Flag --skaffold-file oder dem Flag --source verwenden, wird ein Fehler generiert. Weitere Informationen finden Sie unter Generieren Sie Ihre skaffold.yaml.

Diese beiden Optionen schließen sich gegenseitig aus.

Sie können auch eine .gcloudignore-Datei einfügen, wenn sich im Verzeichnis Dateien befinden, die nicht in die Tar-Datei aufgenommen werden sollen.

Release über die Google Cloud Console erstellen

Sie können die Google Cloud Console verwenden, um einen Release für eine Liefer pipeline zu erstellen. Das ist nützlich, um Cloud Deploy auszuprobieren, aber nicht für Produktionsarbeitslasten geeignet.

Bei der folgenden Vorgehensweise wird davon ausgegangen, dass Sie bereits eine Lieferpipeline und mindestens ein Ziel erstellt haben. Sie können auch die Google Cloud Console verwenden, um Ihre Lieferpipeline zu erstellen.

Klicken Sie auf der Seite Details zur Lieferpipeline für eine bestimmte Lieferpipeline auf Release erstellen.
Fügen Sie im Feld Container auswählen den Pfad zum Container-Image ein, das Sie bereitstellen möchten, oder geben Sie ihn ein. Sie können auch den in diesem Feld vorab ausgefüllten Standardcontainer für die Evaluierung verwenden.

Sie können auch auf Auswählen klicken, um ein Container-Image aus Artifact Registry auszuwählen.
Geben Sie im Feld Release-Name einen eindeutigen Namen für diesen Release an oder verwenden Sie den angegebenen Standardnamen.
Geben Sie im Feld Rollout-Name einen Namen für den Rollout an oder verwenden Sie den angegebenen Standardnamen.

Dieser Name wird für den Rollout zum ersten Ziel für diesen Release verwendet. Für nachfolgende Ziele können Sie den Rollout im Dialogfeld Hochstufen oder mit dem Befehl gcloud deploy releases promote benennen.
Optional können Sie im Feld Beschreibung eine Beschreibung für diesen Release hinzufügen.
Geben Sie unter Details zur Bereitstellung einen Namen für Ihre GKE Bereitstellung oder Ihren Cloud Run-Dienst ein oder verwenden Sie den angegebenen Standardnamen.

Für GKE generiert Cloud Deploy das Manifest für Sie. Für Cloud Run generiert Cloud Deploy die Dienstdefinition, die zum Erstellen des Dienstes verwendet wird.
Klicken Sie auf Erstellen.

Cloud Deploy verwendet das generierte Manifest oder die generierte Cloud Run-Dienstdefinition und die generierte skaffold.yaml-Datei, um den Release zu erstellen.

Zeitlimit für die Bereitstellung ändern

Für Bereitstellungen in GKE und GKE-angehängten Clustern gibt es drei separate Zeitlimits, die sich darauf auswirken, wie lange das System wartet, bis Kubernetes eine stabile Bereitstellung meldet:

Cloud Build hat ein Zeitlimit von 1 Stunde für Vorgänge, die Cloud Build für Cloud Deploy ausführt.

Sie können dieses Zeitlimit in der Konfiguration für Ihre Ausführungsumgebung ändern.
Skaffold hat ein Zeitlimit für die Systemdiagnose (deploy.statusCheckDeadlineSeconds), das die Zeit in Sekunden angibt, die gewartet wird, bis sich die Bereitstellungen stabilisiert haben.

Der Standardwert ist 600 Sekunden (10 Minuten). Damit dieses Zeitlimit verwendet wird, deploy.statusCheck muss auf true gesetzt sein. Standardmäßig ist das der Fall. Wenn statusCheck auf false gesetzt ist, erfolgt keine Statusprüfung. Der Rollout wird als erfolgreich markiert, nachdem kubectl apply erfolgreich abgeschlossen wurde.
Für Kubernetes-Ressourcen vom Typ kind: Deployment gibt es Deployment.spec.progressDeadlineSeconds, das ist die Zeit, die Kubernetes wartet, bis die Bereitstellung als stabil gemeldet wird.

Dieses Zeitlimit gilt nur für Deployment-Ressourcen. So funktionieren die ersten beiden Zeitlimits zusammen:
- Wenn Deployment.spec.progressDeadlineSeconds in Kubernetes nicht festgelegt ist, ist das Zeitlimit für die Skaffold-Systemdiagnose das effektive Zeitlimit, unabhängig davon, ob es der Standardwert ist oder explizit festgelegt wurde.
- Wenn Deployment.spec.progressDeadlineSeconds in Kubernetes festgelegt ist, ignoriert Skaffold das eigene Zeitlimit für die Systemdiagnose und das Kubernetes-Zeitlimit ist das effektive Zeitlimit. Wenn das Kubernetes-Zeitlimit jedoch explizit auf 600 (10 Minuten) festgelegt ist, geht Skaffold davon aus, dass es der Standardwert (nicht festgelegt) ist, ignoriert es und das Skaffold-Zeitlimit wird verwendet (falls festgelegt).
- Wenn keines der Zeitlimits festgelegt ist, ist das effektive Zeitlimit der Skaffold-Standardwert von 600 (10 Minuten).
Neben Deployments können auch andere Kubernetes-Ressourcen Zeitlimits haben, die das Zeitlimit für die Stabilität nicht beeinflussen. Wenn solche Zeitlimits vorhanden sind, überprüfen Sie sie, um sicherzustellen, dass sie nicht mit dem Zeitlimit für die Stabilität in Konflikt stehen.

Wenn für Skaffold (oder Cloud Build) ein Zeitlimit überschritten wird, wird die GKE-Bereitstellung weiter ausgeführt. Cloud Deploy zeigt einen Fehler an, aber die Bereitstellung kann im GKE-Cluster trotzdem erfolgreich sein oder fehlschlagen.

So ändern Sie das Zeitlimit für die Bereitstellungsstabilität:

Achten Sie darauf, dass deploy.statusCheck auf true in skaffold.yaml gesetzt ist.

true ist der Standardwert. Wenn true festgelegt ist, wartet Skaffold, bis die Systemdiagnosen eine stabile Bereitstellung melden, wobei der Zeitlimitwert im nächsten Schritt gilt.
Legen Sie in skaffold.yaml für statusCheckDeadlineSeconds die Anzahl der Sekunden fest, die gewartet werden soll.
```
deploy:
  ...
  statusCheck: true
  statusCheckDeadlineSeconds: 600
  ...
```
Der Standardwert ist 600 (10 Minuten). Skaffold wartet so lange auf eine stabile Bereitstellung. Wenn diese Zeit überschritten wird, bevor die Bereitstellung stabil ist, schlägt die Bereitstellung fehl.
Optional können Sie nach statusCheckDeadlineSeconds die Option tolerateFailuresUntilDeadline: true hinzufügen.

Mit dieser Einstellung wird Skaffold angewiesen, nicht zu beenden, wenn eine einzelne Bereitstellung fehlschlägt, sondern Fehler bis zum Ablauf von statusCheckDeadlineSeconds zu tolerieren. Diese Einstellung kann in Situationen hilfreich sein, in denen Ressourcen mehr Zeit (bis zum Zeitlimit für die Statusprüfung) benötigen, um einen stabilen Zustand zu erreichen.

Wenn Sie beispielsweise Istio oder Cloud Service Mesh verwenden, kann es vorkommen, dass eine Bereitstellung fehlschlägt und eine Meldung wie die folgende angezeigt wird:
```
error iptables validation failed; workload is not ready for Istio.
When using Istio CNI, this can occur if a pod is scheduled before the node is ready.
```
Legen Sie in Ihrem Kubernetes-Manifest für Ressourcen vom Typ kind: Deployment für Deployment.spec.progressDeadlineSeconds denselben Wert fest wie für statusCheckDeadlineSeconds.

Nächste Schritte

Informationen zur Bereitstellung in GKE
Informationen zur Bereitstellung in Cloud Run
Informationen zur Bereitstellung in GKE-angehängten Clustern
Erfahren Sie, wie Sie Ihre Lieferpipeline und Ziele erstellen
Erfahren Sie, wie Sie eine Version hochstufen