Diese Seite wurde von der Cloud Translation API übersetzt.

Anwendung bereitstellen

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

Hinweise

In diesem Abschnitt wird beschrieben, was Sie benötigen, bevor Sie Ihre Anwendung mit Cloud Deploy bereitstellen können.

Prüfen Sie, ob Ihr Ausführungsdienstkonto die erforderlichen IAM-Rollen und -Berechtigungen hat.
Lieferpipeline und Ziele erstellen.

Mit Cloud Deploy können Bereitstellungen für Google Kubernetes Engine-, Cloud Run- und GKE Enterprise-Cluster erfolgen. Die Zielkonfiguration hängt davon ab, auf welchem dieser Geräte Sie die App bereitstellen.
Sie haben Ihre Container-Images und ‑Manifeste.

Sie benötigen ein oder mehrere Container-Images für die Bereitstellung und ein oder mehrere Kubernetes-Manifeste (für die Bereitstellung in GKE) oder YAML-Dateien für Dienste (für die Bereitstellung in Cloud Run).

Sie benötigen eine Pipeline für die kontinuierliche Integration oder einen anderen Prozess, um Ihre Bilder 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.
Eine skaffold.yaml-Konfigurationsdatei haben.

Cloud Deploy ruft skaffold render auf, um die Kubernetes-Manifeste mit dieser Datei zu rendern, und skaffold apply, um sie in Ihrem Ziel bereitzustellen. Dazu ist in Skaffold mindestens eine minimale skaffold.yaml erforderlich. Dafür gibt es zwei Möglichkeiten:
- Sie können auch selbst eine erstellen.
  
  Die skaffold.yaml-Datei muss gemäß einer unterstützten Skaffold-Version in der ersten Zeile auf den Namespace verweisen, wie in diesem Beispiel:
```
`apiVersion: skaffold/v4beta7`
```
- Lassen Sie es für sich generieren.
  
  Wenn Sie noch keine skaffold.yaml-Datei haben, können Sie Cloud Deploy eine für Sie erstellen lassen. Diese Datei eignet sich für das Onboarding, zum Lernen oder zum Demonstrieren von Cloud Deploy und sollte nicht für Produktionsarbeitslasten verwendet werden.
Weitere Informationen finden Sie unter Skaffold mit Cloud Deploy verwenden. Manifeste in Cloud Deploy verwalten enthält 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 ein 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 Bereitstellungspipeline senden.

Führen Sie Ihren regulären CI-Prozess (Continuous Integration) aus und erstellen Sie bereitstellbare Artefakte.
Um die IAM-Berechtigung zu initiieren rufen Sie Cloud Deploy auf, um ein 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 ihn 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 der Name, den Sie diesem Release zuweisen. Der Name muss unter allen Releases für diese Bereitstellungspipeline 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, wird 'rel-$TIME' zu 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 das 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 außerdem automatisch einen Rollout und stellt Ihr Image im ersten in der Lieferpipeline definierten Ziel bereit.

Zusätzlich zu den mit diesem Befehl angezeigten Parametern können Sie eine der folgenden Optionen angeben:

--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 skaffold.yaml generieren.
--from-run-manifest=RUN_MANIFEST

Die generierte Skaffold-Konfiguration basiert auf der Cloud Run-Dienst-YAML-Datei, 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 skaffold.yaml generieren.

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 der TAR-Datei enthalten sein sollen.

Release über die Google Cloud Konsole erstellen

Sie können die Google Cloud Console verwenden, um ein Release für eine Bereitstellungspipeline zu erstellen. Das ist nützlich, um Cloud Deploy auszuprobieren, eignet sich aber nicht für Produktionsarbeitslasten.

Bei der folgenden Vorgehensweise wird davon ausgegangen, dass Sie bereits eine Bereitstellungspipeline und ein oder mehrere Ziele erstellt haben. Sie können auch die Google Cloud Konsole verwenden, um Ihre Bereitstellungspipeline zu erstellen.

Klicken Sie auf der Seite Details zur Bereitstellungspipeline für eine bestimmte Bereitstellungspipeline 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 Standardcontainer verwenden, der in diesem Feld für die Auswertung vorab ausgefüllt ist.

Sie können auch auf Auswählen klicken, um ein Container-Image aus Artifact Registry auszuwählen.
Geben Sie im Feld Releasename 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 ein oder verwenden Sie den angegebenen Standardnamen.

Dieser Name wird für das Roll-out für das erste Ziel für diesen Release verwendet. Bei nachfolgenden Zielen können Sie den Rollout im Dialogfeld Promote (Bewerben) oder mit dem Befehl gcloud deploy releases promote benennen.
Optional können Sie im Feld Beschreibung eine Beschreibung für diese Version eingeben.
Geben Sie unter Bereitstellungsdetails einen Namen für Ihre GKE-Bereitstellung oder Ihren Cloud Run-Dienst ein oder verwenden Sie den 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 Cloud Run-Dienstdefinition und das generierte skaffold.yaml, um das Release zu erstellen.

Zeitlimit für die Bereitstellung ändern

Bei Bereitstellungen in GKE- und GKE Enterprise-Zielclustern gibt es drei separate Zeitüberschreitungen, die sich darauf auswirken, wie lange das System darauf wartet, dass Kubernetes eine stabile Bereitstellung meldet:

Für Vorgänge, die Cloud Build für Cloud Deploy ausführt, gilt ein Zeitlimit von einer Stunde.

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 ist die Zeit in Sekunden, die gewartet wird, bis sich Deployments stabilisiert haben.

Der Standardwert beträgt 600 Sekunden (10 Minuten). Wenn Sie dieses Zeitlimit verwenden möchten, muss deploy.statusCheck auf true festgelegt sein. Standardmäßig ist das der Fall. Wenn statusCheck gleich false 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 das Deployment als stabil gemeldet wird.

Dieses Zeitlimit gilt nur für Deployment-Ressourcen. So funktionieren die ersten beiden Zeitüberschreitungen:
- Wenn Deployment.spec.progressDeadlineSeconds in Kubernetes nicht festgelegt ist, ist das Skaffold-Timeout für Systemdiagnosen das effektive Timeout, unabhängig davon, ob es das Standard-Timeout 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 für den Fortschritt ist das effektive Zeitlimit. Wenn das Kubernetes-Zeitlimit jedoch explizit auf 600 (10 Minuten) festgelegt ist, geht Skaffold davon aus, dass es sich um den Standardwert (nicht festgelegt) handelt, ignoriert es und verwendet das Skaffold-Zeitlimit (falls festgelegt).
- Wenn keine Zeitüberschreitung festgelegt ist, beträgt die effektive Zeitüberschreitung den Skaffold-Standardwert von 600 (10 Minuten).
Neben Deployments können auch andere Kubernetes-Ressourcen Zeitüberschreitungen haben, die sich nicht auf das Stabilitätstimeout auswirken. Wenn eine dieser Bedingungen vorhanden ist, prüfen Sie, ob sie mit dem Stabilitäts-Timeout in Konflikt steht.

Wenn bei Skaffold (oder Cloud Build) ein Zeitlimit überschritten wird, wird die GKE-Bereitstellung fortgesetzt. Cloud Deploy meldet einen Fehler, aber der Vorgang kann im GKE-Cluster trotzdem erfolgreich sein oder fehlschlagen.

So ändern Sie das Zeitlimit für die Stabilität der Bereitstellung:

Prüfen Sie, ob deploy.statusCheck in skaffold.yaml auf true gesetzt ist.

Standardmäßig ist true ausgewählt. Wenn true, wartet Skaffold darauf, dass die Systemdiagnosen ein stabiles Deployment melden. Dabei wird der Zeitüberschreitungswert im nächsten Schritt berücksichtigt.
Legen Sie in skaffold.yaml statusCheckDeadlineSeconds auf 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 tolerateFailuresUntilDeadline: true nach statusCheckDeadlineSeconds 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 möglicherweise mehr Zeit (bis zur Frist für die Statusprüfung) benötigen, um einen stabilen Zustand zu erreichen.

Wenn Sie beispielsweise Istio oder Cloud Service Mesh verwenden, kann es sein, dass eine Bereitstellung mit einer Meldung wie der folgenden fehlschlägt:
```
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.