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. Zuvor müssen Sie jedoch Ihre Bereitstellungspipeline und Ziele erstellen.

Hinweise

In diesem Abschnitt wird beschrieben, was erforderlich ist, um Ihre Anwendung mit Cloud Deploy bereitstellen zu können.

Prüfen Sie, ob das Ausführungsdienstkonto die erforderlichen IAM-Rollen und -Berechtigungen hat.
Bereitstellungspipeline und -ziele erstellen

Cloud Deploy kann in Google Kubernetes Engine-, Cloud Run- und GKE Enterprise-Clustern bereitgestellt werden. Die Zielkonfiguration unterscheidet sich je nachdem, in welcher Konfiguration Sie die Bereitstellung vornehmen.
Halten Sie Ihre Container-Images und -Manifeste bereit.

Sie benötigen ein oder mehrere Container-Images zum Bereitstellen und ein oder mehrere Kubernetes-Manifeste (zum Bereitstellen in GKE) oder Dienst-YAML-Dateien (zum Bereitstellen in Cloud Run).

Sie benötigen eine CI-Pipeline oder einen anderen Prozess, um Ihre Images zu erstellen und zu platzieren. Das CI-Tool kann Cloud Build, Jenkins oder ein anderes Tool sein, das zu Container-Images führt, die Sie in Ihrer Cloud Deploy-Bereitstellungspipeline bereitstellen können.
Sie benötigen eine skaffold.yaml-Konfigurationsdatei.

Cloud Deploy ruft skaffold render auf, um die Kubernetes-Manifeste mithilfe dieser Datei zu rendern, und skaffold apply, um sie in Ihrem Ziel bereitzustellen. Dazu benötigt Skaffold mindestens eine minimale skaffold.yaml. Sie haben zwei Möglichkeiten, eine ID zu erhalten:
- Erstellen Sie Ihre eigene.
  
  Die Datei skaffold.yaml muss wie in diesem Beispiel in der ersten Zeile auf den Namespace verweisen, der einer unterstützten Skaffold-Version entspricht:
```
`apiVersion: skaffold/v4beta7`
```
- Lassen Sie sie für Sie erstellen.
  
  Wenn Sie noch keine Datei skaffold.yaml haben, können Sie Cloud Deploy eine Datei für Sie erstellen lassen. Diese Datei eignet sich für das Onboarding, Lernen oder die Demonstration 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 Laufzeitumgebung Ihrer Wahl einrichten

Cloud Deploy kann Ihre Anwendung in jeder der folgenden Laufzeitumgebungen bereitstellen:

Bereitstellungspipeline aufrufen, um einen Release zu erstellen

Nachdem Sie Cloud Deploy für die Bereitstellung in Ihrer Laufzeit konfiguriert haben, können Sie Ihre Anwendung zur Bereitstellung gemäß der von Ihnen erstellten Bereitstellungspipeline senden.

Führen Sie Ihren regulären CI-Prozess (Continuous Integration) aus und erstellen Sie bereitstellbare Artefakte.
Starten Sie die Bereitstellungspipeline, indem Sie Cloud Deploy aufrufen, 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 dieser Befehl eine TAR-Datei mit dem gesamten Inhalt des Verzeichnisses und aller Unterverzeichnisse erstellt, sollten Sie diesen Befehl nicht von Ihrem Basis- oder Stammverzeichnis aus ausführen. Führen Sie den Befehl entweder in dem Verzeichnis aus, das Ihre Skaffold-Konfiguration enthält, oder binden Sie die Option --source= ein, die weiter unten beschrieben wird.

In diesem Befehl...

RELEASE_NAME ist der Name, der diesem Release gegeben werden soll. Der Name muss unter allen Releases für diese Bereitstellungspipeline eindeutig sein.

Sie können dynamische Releasenamen angeben, indem Sie '$DATE' oder '$TIME' oder beide angeben. Wenn Sie diesen Befehl beispielsweise um 15:07 Uhr UTC aufrufen, wird 'rel-$TIME' in rel-1507 aufgelöst. '$DATE' und '$TIME' müssen in einfachen Anführungszeichen stehen und die Zeit ist die UTC-Zeit auf dem Computer, von 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 außerdem automatisch ein Rollout und stellt Ihr Image für das erste in der Bereitstellungspipeline definierte Ziel bereit.

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

--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 der Skaffold-Build-Artefakte, die übergeben werden kann, um die vollständigen Bildpfadersetzungen darzustellen.

Diese beiden Optionen schließen sich gegenseitig aus.

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

--from-k8s-manifest=K8S_MANIFEST

Die generierte Skaffold-Konfiguration basiert auf dem Kubernetes-Manifest, das Sie dieses Flag übergeben. Die Verwendung dieses Flags mit dem Flag --skaffold-file oder dem Flag --source führt zu einem Fehler. Weitere Informationen finden Sie unter skaffold.yaml generieren.
--from-run-manifest=RUN_MANIFEST

Die generierte Skaffold-Konfiguration basiert auf der YAML-Datei für den Cloud Run-Dienst, die Sie mit diesem Flag übergeben. Die Verwendung dieses Flags mit dem Flag --skaffold-file oder --source führt zu einem Fehler. Weitere Informationen finden Sie unter skaffold.yaml generieren.

Diese beiden Optionen schließen sich gegenseitig aus.

Sie können auch eine .gcloudignore-Datei einschließen, wenn sich im Verzeichnis Dateien befinden, die nicht in die TAR-Datei aufgenommen werden sollen.

Release über die Google Cloud Console erstellen

Mit der Google Cloud Console können Sie einen Release für eine Bereitstellungspipeline erstellen. Dies ist nützlich, um Cloud Deploy zu testen, eignet sich jedoch 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 Console 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 zu dem Container-Image ein, das Sie bereitstellen möchten. Sie können zur Auswertung auch den in diesem Feld bereits ausgefüllten Standardcontainer verwenden.

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

Dieser Name wird in diesem Release für das Roll-out auf dem ersten Ziel verwendet. Für nachfolgende Ziele können Sie dem Roll-out im Dialogfeld Hochstufen oder mit dem Befehl gcloud deploy releases promote einen Namen geben.
Optional können Sie im Feld Beschreibung eine Beschreibung für diesen Release eingeben.
Geben Sie unter Bereitstellungsdetails einen Namen für das GKE-Deployment oder den 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, mit der der Dienst erstellt wird.
Klicken Sie auf Erstellen.

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

Zeitlimit für Bereitstellung ändern

Für Deployments in GKE- und GKE Enterprise-Zielclustern gibt es drei separate Zeitlimits, die sich darauf auswirken, wie lange das System darauf wartet, dass Kubernetes eine stabile Bereitstellung meldet:

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

Sie können dieses Zeitlimit in der Konfiguration der Ausführungsumgebung ändern.
Skaffold hat ein Zeitlimit für die Systemdiagnose (deploy.statusCheckDeadlineSeconds), das die Zeit in Sekunden angibt, die auf die Stabilisierung von Bereitstellungen gewartet werden soll.

Die Standardeinstellung beträgt 600 Sekunden (10 Minuten). Wenn Sie dieses Zeitlimit verwenden möchten, muss deploy.statusCheck auf true festgelegt sein. Dies ist standardmäßig der Fall. Wenn statusCheck auf false gesetzt ist, gibt es keine Statusprüfung und das Roll-out wird als erfolgreich markiert, nachdem kubectl apply erfolgreich abgeschlossen wurde.
Für Kubernetes-Ressourcen von kind: Deployment gibt es Deployment.spec.progressDeadlineSeconds. Dies 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 Zeitlimits zusammen:
- Wenn Deployment.spec.progressDeadlineSeconds in Kubernetes nicht festgelegt ist, ist das Zeitlimit der Skaffold-Systemdiagnose das effektive Zeitlimit, unabhängig davon, ob es die Standardeinstellung oder explizit festgelegt ist.
- Wenn Deployment.spec.progressDeadlineSeconds in Kubernetes festgelegt ist, ignoriert Skaffold das eigene Zeitlimit für die Systemdiagnose. Die Kubernetes-Fortschrittsfrist ist das gültige Zeitlimit. Wenn das Kubernetes-Zeitlimit jedoch explizit auf 600 (10 Minuten) festgelegt ist, geht Skaffold davon aus, dass dies die Standardeinstellung (nicht festgelegt) ist, und ignoriert sie. Das Skaffold-Zeitlimit wird verwendet (falls festgelegt).
- Wenn keines der beiden Zeitlimits festgelegt ist, ist das effektive Zeitlimit der Skaffold-Standardwert von 600 (10 Minuten).
Abgesehen von Deployments können andere Kubernetes-Ressourcen Zeitüberschreitungen haben, die keinen Einfluss auf die Zeitüberschreitung haben. Prüfen Sie gegebenenfalls, ob sie mit dem Stabilitätszeitlimit in Konflikt stehen.

Wenn bei Skaffold (oder Cloud Build) eine Zeitüberschreitung auftritt, wird das GKE-Deployment weiter ausgeführt. Cloud Deploy zeigt einen Fehler an, kann aber im GKE-Cluster trotzdem erfolgreich sein oder fehlschlagen.

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

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

Standardmäßig ist true ausgewählt. Wenn true, wartet Skaffold darauf, dass Systemdiagnosen eine stabile Bereitstellung melden, vorbehaltlich des Zeitlimits im nächsten Schritt.
Legen Sie in skaffold.yaml für statusCheckDeadlineSeconds die Anzahl der Sekunden fest, die Sie warten möchten.
```
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 sie fehl.
Optional können Sie tolerateFailuresUntilDeadline: true nach statusCheckDeadlineSeconds einfü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 hilfreich sein, wenn Sie Ressourcen haben, die mehr Zeit (bis zum Ende der Statusüberprüfung) benötigen, um einen stabilen Zustand zu erreichen.

Wenn Sie beispielsweise Istio oder Cloud Service Mesh verwenden, ist möglicherweise eine fehlgeschlagene Bereitstellung mit einer Nachricht ähnlich der folgenden aufgetreten:
```
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.
```
Die Einstellung funktioniert nur mit Skaffold 2.0 oder höher.
Legen Sie im Kubernetes-Manifest für Ressourcen von kind: Deployment Deployment.spec.progressDeadlineSeconds auf denselben Wert fest, den Sie für statusCheckDeadlineSeconds festgelegt haben.