Anwendung bereitstellen

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

Hinweise

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

  • Das Ausführungsdienstkonto muss die erforderlichen IAM-Rollen und -Berechtigungen haben.

  • Bereitstellungspipeline und ‐ziele erstellen

    Cloud Deploy kann in Google Kubernetes Engine-, Cloud Run- und GKE Enterprise-Clustern bereitgestellt werden. Die Zielkonfiguration variiert je nachdem, auf welcher Ebene 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 (für das Deployment in GKE) oder Dienst-YAML-Dateien (für das Deployment in Cloud Run).

    Sie benötigen eine Continuous-Integration-Pipeline oder einen anderen Prozess, um Ihre Images zu erstellen und zu platzieren. Als CI-Tool kommen Cloud Build, Jenkins oder ein beliebiges anderes Tool zum Einsatz, das Container-Images erzeugt, die Sie für die Cloud Deploy-Bereitstellungspipeline bereitstellen.

  • Verwenden Sie 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 einen skaffold.yaml-Wert. Sie haben zwei Möglichkeiten:

    • Erstelle deine eigene.

      Beachten Sie, dass die Datei skaffold.yaml in der ersten Zeile auf den Namespace verweisen muss, der einer unterstützten Skaffold-Version entspricht, wie in diesem Beispiel:

      `apiVersion: skaffold/v4beta7`
      
    • Lassen Sie es für Sie generieren.

      Wenn Sie noch keine skaffold.yaml-Datei haben, können Sie eine von Cloud Deploy 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. Weitere Informationen zur Verwendung von Skaffold und Cloud Deploy mit Tools zur Manifestverwaltung wie Helm, Kustomize und kpt finden Sie unter Manifeste in Cloud Deploy verwalten.

Cloud Deploy für die Laufzeitumgebung Ihrer Wahl einrichten

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

Rufen Sie Ihre Bereitstellungspipeline auf, 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.

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

  2. Initiieren 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 mit diesem Befehl eine TAR-Datei mit dem gesamten Inhalt des Verzeichnisses und aller Unterverzeichnisse erstellt wird, sollten Sie ihn nicht von Ihrem Start- oder Stammverzeichnis aus ausführen. Führen Sie den Befehl entweder über das Verzeichnis aus, das Ihre Skaffold-Konfiguration enthält, oder fügen Sie die weiter unten beschriebene Option --source= ein.

    In diesem Befehl gilt Folgendes:

    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', '$TIME' oder beides 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. Die Zeit ist die UTC-Zeit der Maschine, auf der 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 Roll-out und stellt das Image für das erste in der Bereitstellungspipeline definierte Ziel bereit.

Zusätzlich zu den mit diesem Befehl angezeigten 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 des Skaffold-Build-Artefakts, die übergeben werden kann, um die vollständigen Bildersetzungen 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, an das Sie dieses Flag übergeben. Wenn Sie dieses Flag entweder mit dem Flag --skaffold-file oder --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 YAML-Datei des Cloud Run-Dienstes, an die Sie dieses Flag übergeben. Wenn Sie dieses Flag entweder mit dem Flag --skaffold-file oder --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 Console erstellen

Mit der Google Cloud Console können Sie einen Release für eine Bereitstellungspipeline erstellen. Dies ist zum Testen von Cloud Deploy nützlich, für Produktionsarbeitslasten jedoch nicht geeignet.

Im folgenden Verfahren 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.

  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 oder geben 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 Standardcontainer in diesem Feld verwenden.

    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 diesen Release an oder verwenden Sie den angegebenen Standardnamen.

  4. Geben Sie im Feld Rollout-Name einen Namen für das Roll-out an oder verwenden Sie den angegebenen Standardnamen.

    Dieser Name wird für das Roll-out des ersten Ziels in diesem Release verwendet. Für nachfolgende Ziele können Sie das Roll-out im Dialogfeld Hochstufen oder mit dem Befehl gcloud deploy releases promote benennen.

  5. Geben Sie im Feld Beschreibung optional eine Beschreibung für den Release ein.

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

  7. Klicken Sie auf Erstellen.

    Dialogfeld „Release erstellen“

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

Zeitlimit für Bereitstellung ändern

Für Bereitstellungen in GKE- und GKE Enterprise-Zielclustern gibt es drei separate Zeitlimits, die beeinflussen, wie lange das System darauf wartet, dass Kubernetes ein stabiles Deployment 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 für Ihre Ausführungsumgebung ändern.

  • Skaffold hat ein Zeitlimit für Systemdiagnosen (deploy.statusCheckDeadlineSeconds). Dies ist die Zeit in Sekunden, die gewartet werden soll, bis sich Bereitstellungen stabilisiert haben.

    Der Standardwert beträgt 600 Sekunden (10 Minuten). Damit Sie dieses Zeitlimit verwenden können, muss deploy.statusCheck auf true gesetzt sein. Dies ist das standardmäßig der Fall. Wenn statusCheck auf false gesetzt ist, gibt es keine Statusprüfung. Das Roll-out wird als erfolgreich markiert, nachdem kubectl apply erfolgreich abgeschlossen wurde.

  • Für Kubernetes-Ressourcen vom Typ kind: Deployment steht Deployment.spec.progressDeadlineSeconds zur Verfügung. Dies gibt an, wie lange Kubernetes wartet, bis das Deployment als stabil gemeldet wird.

    Dieses Zeitlimit gilt nur für Deployment Ressourcen. So arbeiten diese 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 die Standardeinstellung ist oder explizit festgelegt ist.

    • Wenn Deployment.spec.progressDeadlineSeconds in Kubernetes festgelegt ist, ignoriert Skaffel sein eigenes Zeitlimit für die Systemdiagnose und die Kubernetes-Fortschrittsfrist ist das effektive Zeitlimit. Wenn das Kubernetes-Zeitlimit jedoch explizit auf 600 (10 Minuten) festgelegt ist, geht Skaffold davon aus, dass es die Standardeinstellung ist (nicht festgelegt) und ignoriert es. Das Skaffold-Zeitlimit wird verwendet (falls festgelegt).

    • Wenn keines der beiden Zeitlimits festgelegt ist, ist das effektive Zeitlimit der Skaffold-Standardwert 600 (10 Minuten).

    Neben Deployments können andere Kubernetes-Ressourcen Zeitüberschreitungen haben, die sich nicht auf das Stabilitätszeitlimit auswirken. Prüfen Sie gegebenenfalls, ob sie mit dem Stabilitäts-Timeout in Konflikt stehen.

    Wenn bei Skaffold (oder Cloud Build) eine Zeitüberschreitung auftritt, wird das GKE-Deployment weiterhin ausgeführt. Cloud Deploy zeigt einen Fehler an, aber im GKE-Cluster kann der Vorgang trotzdem erfolgreich sein 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. Wenn true, wartet Skaffold auf Systemdiagnosen, um eine stabile Bereitstellung zu melden. Dies unterliegt dem Zeitlimitwert im nächsten Schritt.

  2. 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). So lange wartet Skaffold auf eine stabile Bereitstellung. Wenn diese Zeit überschritten wird, bevor die Bereitstellung stabil ist, schlägt die Bereitstellung fehl.

  3. Optional können Sie tolerateFailuresUntilDeadline: true nach statusCheckDeadlineSeconds hinzufügen.

    Mit dieser Einstellung wird Skaffold angewiesen, den Vorgang nicht zu beenden, wenn eine einzelne Bereitstellung fehlschlägt, sondern dass Fehler bis zum Ablauf von statusCheckDeadlineSeconds toleriert werden. Diese Einstellung kann in Situationen hilfreich sein, in denen Ressourcen vorhanden sind, die (bis zum Zeitlimit der Statusprüfung) möglicherweise mehr Zeit benötigen, um einen stabilen Zustand zu erreichen.

    Wenn Sie beispielsweise Istio oder Anthos Service Mesh verwenden, ist die Bereitstellung möglicherweise fehlgeschlagen. Sie erhalten dann eine Nachricht wie diese:

    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 Deployment.spec.progressDeadlineSeconds auf denselben Wert fest, den Sie für statusCheckDeadlineSeconds festgelegt haben.

Nächste Schritte