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.

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, und skaffold apply, um sie in Ihrem Ziel bereitzustellen. Dazu ist mindestens skaffold.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.

  1. Führen Sie Ihren regulären CI-Prozess (Continuous Integration) aus und erstellen Sie bereitstellbare Artefakte.

  2. 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' in rel-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 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 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 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. 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.

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.

  1. Klicken Sie auf der Seite Details zur Bereitstellungspipeline für eine bestimmte Bereitstellungspipeline auf Release erstellen.

    Details zur Bereitstellungspipeline mit der Schaltfläche „Release erstellen“

  2. 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.

  3. Geben Sie im Feld Release-Name einen eindeutigen Namen für diese Version ein oder verwenden Sie den angegebenen Standardnamen.

  4. 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.

  5. Geben Sie optional im Feld Beschreibung eine Beschreibung für diese Version ein.

  6. 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.

  7. Klicken Sie auf Erstellen.

    Dialogfeld „Release 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 auf true gesetzt sein. Standardmäßig ist das der Fall. Wenn statusCheck = false ist, erfolgt keine Statusprüfung und das Roll-out wird als erfolgreich gekennzeichnet, nachdem kubectl apply 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.

    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 auf 600 (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 Deployments 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:

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

    Standardmäßig ist true ausgewählt. Bei true wartet Skaffold, bis die Systemdiagnosen eine stabile Bereitstellung melden, vorbehaltlich des Zeitüberschreitungswerts im nächsten Schritt.

  2. Legen Sie unter 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 diese Zeit auf eine stabile Bereitstellung. Wenn diese Zeit überschritten wird, bevor die Bereitstellung stabil ist, schlägt sie fehl.

  3. 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.

  4. Legen Sie in Ihrem Kubernetes-Manifest für Ressourcen von kind: Deployment denselben Wert für Deployment.spec.progressDeadlineSeconds fest wie für statusCheckDeadlineSeconds.

Nächste Schritte