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.
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ührungs-Dienstkonto die erforderlichen IAM-Rollen und -Berechtigungen hat.
Erstellen Sie eine Bereitstellungspipeline und Ziele.
Mit Cloud Deploy können Sie in der Google Kubernetes Engine, in Cloud Run und in GKE Enterprise-Clustern bereitstellen. Die Zielkonfiguration unterscheidet sich je nachdem, für welche dieser Plattformen Sie die Bereitstellung vornehmen.
Sie benötigen Ihre Container-Images und Manifeste.
Sie benötigen ein oder mehrere Container-Images zur Bereitstellung und ein oder mehrere Kubernetes-Manifeste (zur Bereitstellung in GKE) oder Dienst-YAML-Dateien (zur 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. Als CI-Tool können Sie Cloud Build, Jenkins oder ein anderes Tool verwenden, das Container-Images generiert, die Sie Ihrer Cloud Deploy-Lieferpipeline zur Verfügung stellen können.
Sie haben eine
skaffold.yaml
-Konfigurationsdatei.Cloud Deploy ruft
skaffold render
auf, um die Kubernetes-Manifeste mit dieser Datei zu rendern, undskaffold apply
, um sie in Ihrem Ziel bereitzustellen. Dazu ist mindestensskaffold.yaml
erforderlich. Sie haben zwei Möglichkeiten, einen Code zu erhalten:Sie können auch Ihre eigene erstellen.
Die
skaffold.yaml
-Datei muss in der ersten Zeile auf den Namespace verweisen, der einer unterstützten Skaffold-Version entspricht, wie in diesem Beispiel:`apiVersion: skaffold/v4beta7`
Sie können sich eine generieren lassen.
Wenn Sie noch keine
skaffold.yaml
-Datei haben, können Sie Cloud Deploy bitten, eine für Sie zu erstellen. Diese Datei eignet sich für das Onboarding, Lernen oder Vorführen von Cloud Deploy und sollte nicht für Produktionsarbeitslasten verwendet werden.
Weitere Informationen finden Sie unter Skaffold mit Cloud Deploy verwenden. Im Artikel 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 ein Release zu erstellen
Nachdem Sie Cloud Deploy für die Bereitstellung in Ihrer Laufzeit konfiguriert haben, können Sie Ihre Anwendung jetzt für die Bereitstellung entsprechend der von Ihnen erstellten Bereitstellungspipeline einreichen.
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 mit dem gesamten Inhalt des Verzeichnisses und aller Unterverzeichnisse erstellt wird, sollten Sie diesen Befehl nicht aus Ihrem Basis- oder Stammverzeichnis ausführen. Führen Sie den Befehl entweder aus dem Verzeichnis aus, das Ihre Skaffold-Konfiguration enthält, oder verwenden Sie die Option
--source=
, die weiter unten beschrieben wird.In diesem Befehl…
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) ausführen, wird'rel-$TIME'
inrel-1507
aufgelöst.'$DATE'
und'$TIME'
müssen in einfache Anführungszeichen gesetzt werden. 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 demname
-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 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 angeben, 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--source
verwenden, wird ein Fehler ausgegeben. Weitere Informationen finden Sie unterskaffold.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. Die Verwendung dieses Flags mit dem Flag
--skaffold-file
oder dem Flag--source
führt zu einem Fehler. Weitere Informationen finden Sie unterskaffold.yaml
generieren.
Diese beiden Optionen schließen sich gegenseitig aus.
Sie können auch eine .gcloudignore
-Datei angeben, wenn sich im Verzeichnis Dateien befinden, die nicht in der TAR-Datei enthalten sein sollen.
Release über die Google Cloud Console erstellen
In der Google Cloud Console können Sie eine Version für eine Bereitstellungspipeline erstellen. Das ist nützlich, um Cloud Deploy auszuprobieren, eignet sich jedoch nicht für Produktionsarbeitslasten.
Bei der folgenden Anleitung 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 eine 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. Sie können auch den Standardcontainer verwenden, der bereits in diesem Feld ausgefüllt ist.
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 diese Version ein oder verwenden Sie den angegebenen Standardnamen.
Geben Sie im Feld Roll-out-Name einen Namen für das Roll-out ein oder verwenden Sie den angegebenen Standardnamen.
Dieser Name wird für das Roll-out auf das erste Ziel für diesen Release verwendet. Für nachfolgende Ziele können Sie das Roll-out im Dialogfeld Bewerben oder im Befehl
gcloud deploy releases promote
benennen.Geben Sie optional im Feld Beschreibung eine Beschreibung für diese Version ein.
Geben Sie unter Bereitstellungsdetails 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
, um den 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 wartet, bis Kubernetes eine stabile Bereitstellung meldet:
Cloud Build hat eine Zeitüberschreitung von einer Stunde für Vorgänge, die Cloud Build für Cloud Deploy ausführt.
Sie können diese Zeitüberschreitung in der Konfiguration für Ihre Ausführungsumgebung ändern.
Skaffold hat ein Zeitlimit für die Systemdiagnose (
deploy.statusCheckDeadlineSeconds
), das angibt, wie lange in Sekunden auf die Stabilisierung von Bereitstellungen gewartet werden soll.Der Standardwert beträgt 600 Sekunden (10 Minuten). Wenn Sie diese Zeitüberschreitung verwenden möchten, muss
deploy.statusCheck
auftrue
gesetzt sein. Standardmäßig ist das der Fall. WennstatusCheck
=false
ist, erfolgt keine Statusprüfung und das Roll-out wird als erfolgreich gekennzeichnet, nachdemkubectl apply
abgeschlossen wurde.Für Kubernetes-Ressourcen vom Typ
kind: Deployment
gibt esDeployment.spec.progressDeadlineSeconds
. Das ist die Zeit, die Kubernetes wartet, bis das Deployment als stabil gemeldet wird.Diese Zeitüberschreitung gilt nur für
Deployment
-Ressourcen. So funktionieren die ersten beiden Zeitüberschreitungen 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 sich um das Standardzeitlimit oder ein explizit festgelegtes Zeitlimit handelt.Wenn
Deployment.spec.progressDeadlineSeconds
in Kubernetes festgelegt ist, ignoriert Skaffold seine eigene Zeitüberschreitung für die Systemdiagnose und die Kubernetes-Frist für den Fortschritt ist die effektive Zeitüberschreitung. Wenn das Kubernetes-Zeitlimit jedoch explizit auf600
(10 Minuten) festgelegt ist, geht Skaffold davon aus, dass es sich um den Standardwert (nicht festgelegt) handelt, und ignoriert es. Stattdessen wird das Skaffold-Zeitlimit verwendet (falls festgelegt).Wenn keine Zeitüberschreitung festgelegt ist, gilt die standardmäßige Skaffold-Zeitüberschreitung von
600
(10 Minuten).
Neben
Deployment
s können auch andere Kubernetes-Ressourcen Zeitüberschreitungen haben, die sich nicht auf die Stabilitäts-Zeitüberschreitung auswirken. Wenn eine dieser Optionen vorhanden ist, prüfen Sie, ob sie nicht mit dem Zeitlimit für die Stabilität in Konflikt stehen.Wenn Skaffold (oder Cloud Build) ein Zeitlimit überschreitet, wird die GKE-Bereitstellung fortgesetzt. Cloud Deploy zeigt einen Fehler an, die Bereitstellung im GKE-Cluster kann aber trotzdem erfolgreich oder fehlschlagen.
So ändern Sie das Zeitlimit für die Stabilität der Bereitstellung:
Achten Sie darauf, dass
deploy.statusCheck
inskaffold.yaml
auftrue
festgelegt ist.Standardmäßig ist
true
ausgewählt. Beitrue
wartet Skaffold, bis die Systemdiagnosen eine stabile Bereitstellung melden, vorbehaltlich des Zeitüberschreitungswerts im nächsten Schritt.Legen Sie unter
skaffold.yaml
fürstatusCheckDeadlineSeconds
die Anzahl der Sekunden fest, die gewartet werden soll.deploy: ... statusCheck: true statusCheckDeadlineSeconds: 600 ...
Der Standardwert ist
600
(10 Minuten). Skaffold wartet diese Zeit auf eine stabile Bereitstellung. Wenn diese Zeit überschritten wird, bevor die Bereitstellung stabil ist, schlägt sie fehl.Optional können Sie nach
statusCheckDeadlineSeconds
tolerateFailuresUntilDeadline: true
hinzufügen.Mit dieser Einstellung wird Skaffold angewiesen, nicht zu beenden, wenn eine einzelne Bereitstellung fehlschlägt, sondern Fehler zu tolerieren, bis
statusCheckDeadlineSeconds
abläuft. Diese Einstellung kann in Situationen hilfreich sein, in denen Ressourcen mehr Zeit (bis zum Termin für die Statusprüfung) benötigen, um einen stabilen Zustand zu erreichen.Wenn Sie beispielsweise Istio oder Cloud Service Mesh verwenden, wird bei einer fehlgeschlagenen Bereitstellung möglicherweise eine ähnliche Meldung angezeigt:
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 in Ihrem Kubernetes-Manifest für Ressourcen von
kind: Deployment
denselben Wert fürDeployment.spec.progressDeadlineSeconds
fest wie fürstatusCheckDeadlineSeconds
.