Anwendung bereitstellen

Auf dieser Seite wird beschrieben, wie Sie Ihre Anwendung mit Cloud Deploy abrufen können in die gewünschten Ziellaufzeitumgebungen. Zuvor müssen Sie Bereitstellungspipeline 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ührungsdienstkonto hat die erforderlichen IAM-Rollen und -Berechtigungen.

  • Bereitstellungspipeline und -ziele erstellen

    Cloud Deploy kann in Google Kubernetes Engine, Cloud Run und GKE Enterprise-Cluster. Zielkonfiguration unterschiedlich je nachdem, für welche Version Sie die Bereitstellung vornehmen.

  • Halten Sie Ihre Container-Images und -Manifeste bereit.

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

    Sie benötigen eine CI-Pipeline oder einen anderen Prozess, und platzieren Sie Ihre Bilder. Ihr CI-Tool kann Cloud Build, Jenkins oder andere Anwendungen, die zu Container-Images führen, die Sie in Ihrer Cloud Deploy-Bereitstellungspipeline bereitstellen können.

  • Sie haben eine skaffold.yaml-Konfigurationsdatei.

    Cloud Deploy-Aufrufe skaffold render zum Rendern der Kubernetes-Manifeste mithilfe dieser Datei skaffold apply um sie im Ziel bereitzustellen. Dafür benötigt Skaffold mindestens Minimal skaffold.yaml. Sie haben zwei Möglichkeiten, eine zu erhalten:

    • Erstellen Sie Ihre eigene.

      Die Datei skaffold.yaml muss auf den Namespace verweisen. entspricht einer unterstützten Skaffold-Version in die erste Zeile ein, wie in diesem Beispiel:

      `apiVersion: skaffold/v4beta7`
      
    • Lassen Sie sie für Sie erstellen.

      Wenn Sie noch keine skaffold.yaml-Datei haben, können Sie eine von Cloud Deploy erstellen lassen. Diese Datei eignet sich für das Onboarding, Lernen oder Vorführen von Cloud Deploy und sollte nicht für Produktionsarbeitslasten verwendet werden.

    Siehe Skaffold mit Cloud Deploy verwenden . Weitere Informationen finden Sie unter Manifeste in Cloud Deploy verwalten. finden Sie weitere Informationen zur Verwendung von Skaffold und Cloud Deploy mit Manifest-Managementtools wie Helm, Kustomize und Kpt.

Cloud Deploy für die Laufzeitumgebung Ihrer Wahl einrichten

Cloud Deploy kann Ihre Anwendung auf folgenden Plattformen bereitstellen: Laufzeitumgebungen:

Bereitstellungspipeline aufrufen, um einen Release zu erstellen

Nachdem Sie Cloud Deploy für die Bereitstellung in Ihrer Laufzeit konfiguriert haben, kann Ihre Anwendung nun zur Bereitstellung gemäß eine von Ihnen erstellte Pipeline.

  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 dieser Befehl eine TAR-Datei mit dem gesamten Inhalt der und Unterverzeichnissen enthält, sollten Sie diesen Befehl aus Ihrem Start- oder Stammverzeichnis. 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, der diesem Release gegeben werden soll. Die Der Name muss unter allen Releases für diese Bereitstellungspipeline eindeutig sein.

    Sie können dynamische Releasenamen angeben, indem Sie '$DATE', '$TIME' oder beides. Wenn Sie diesen Befehl beispielsweise um 15:07 Uhr UTC aufrufen, wird 'rel-$TIME' wird 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 sich befinden. Erstellen des Release, 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 wird auch automatisch erstellt ein Roll-out und stellt Ihr Image für das erste Ziel bereit, das im Bereitstellungspipeline.

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

Diese beiden Optionen schließen sich gegenseitig aus.

Sie können auch eines der folgenden Flags hinzufügen, um Cloud Deploy zu verwenden Generieren Sie eine skaffold.yaml-Datei für Sie:

  • --from-k8s-manifest=K8S_MANIFEST

    Die generierte Skaffold-Konfiguration basiert auf dem Kubernetes-Manifest, das Sie mit diesem Flag übergeben. Die Verwendung dieses Flags mit dem Flag --skaffold-file oder dem --source-Flag, generiert einen Fehler. Weitere Informationen finden Sie unter skaffold.yaml wird generiert .

  • --from-run-manifest=RUN_MANIFEST

    Die generierte Skaffold-Konfiguration basiert auf Cloud Run Dienst-YAML-Datei übergeben, übergeben Sie dieses Flag. Die Verwendung dieses Flags mit dem --skaffold-file oder --source generiert einen Fehler. Weitere Informationen finden Sie unter skaffold.yaml wird generiert .

Diese beiden Optionen schließen sich gegenseitig aus.

Sie können auch eine .gcloudignore-Datei einschließen, falls im Ordner das nicht in die TAR-Datei aufgenommen werden soll.

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 Vorgehensweise wird davon ausgegangen, dass Sie bereits eine Bereitstellungspipeline erstellt haben und mindestens ein Ziel. Sie können auch die Google Cloud Console verwenden, um Bereitstellungspipeline 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 ein oder fügen Sie ihn ein. Image, das Sie bereitstellen möchten. Sie können auch den vorab ausgefüllten Standardcontainer verwenden. in diesem Feld zur Bewertung ein.

    Sie können auch auf Auswählen klicken, um ein Container-Image aus Artifact Registry auszuwählen. oder Container Registry.

  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 Rollout-Name einen Namen für die Einführung ein oder verwenden Sie die Standardname angegeben.

    Dieser Name wird in diesem Release für das Roll-out auf dem ersten Ziel verwendet. Für nachfolgenden Zielen können Sie den Roll-out im Dialogfeld Hochstufen oder in den Befehl gcloud deploy releases promote.

  5. Optional können Sie unter Beschreibung eine Beschreibung für diesen Release eingeben ein.

  6. Geben Sie unter Bereitstellungsdetails einen Namen für die GKE ein. Bereitstellung oder Cloud Run-Dienst oder verwenden Sie den Standardnamen bereitgestellt.

    Für GKE generiert Cloud Deploy das Manifest für von dir. Für Cloud Run generiert Cloud Deploy den Dienstdefinition, mit der der Dienst erstellt wird.

  7. Klicken Sie auf Erstellen.

    Dialogfeld „Release erstellen“

Cloud Deploy verwendet das generierte Manifest oder 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 gibt es drei verschiedene 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 einen Zeitlimit für Systemdiagnose (deploy.statusCheckDeadlineSeconds), Dies ist die Zeit in Sekunden, die gewartet wird, bis sich die Bereitstellungen stabilisiert haben.

    Die Standardeinstellung beträgt 600 Sekunden (10 Minuten). Um diese Zeitüberschreitung zu verwenden, deploy.statusCheck muss auf true festgelegt sein. Dies ist standardmäßig der Fall. Wenn statusCheck den Wert false hat, gibt es keine Statusprüfung ist, wird das Roll-out nach dem kubectl apply als erfolgreich gekennzeichnet erfolgreich abgeschlossen wird.

  • Für Kubernetes-Ressourcen von kind: Deployment gibt es Deployment.spec.progressDeadlineSeconds, Dies ist die Zeit, die Kubernetes darauf wartet, dass das Deployment stabil sein.

    Dieses Zeitlimit gilt nur für Deployment Ressourcen. Hier sehen Sie, wie diese die ersten beiden Timeouts zusammen:

    • Wenn Deployment.spec.progressDeadlineSeconds in Kubernetes nicht festgelegt ist, gilt: Das Skaffold-Systemdiagnose-Zeitlimit ist das effektive Zeitlimit, unabhängig davon, ob es sich um Standard- oder explizit festgelegt ist.

    • Wenn Deployment.spec.progressDeadlineSeconds in Kubernetes festgelegt ist, gilt: Skaffold ignoriert das eigene Systemdiagnose-Zeitlimit und der Kubernetes-Fortschritt Deadline ist das effektive Zeitlimit. Wenn das Kubernetes-Zeitlimit jedoch explizit auf 600 (10 Minuten) festgelegt ist, geht Skaffold davon aus, Standardeinstellung (nicht festgelegt) und ignoriert es, und das Skaffold-Zeitlimit wird verwendet (falls festgelegt).

    • Wenn keine Zeitüberschreitung festgelegt ist, gilt die standardmäßige Skaffold-Zeitüberschreitung von 600 (10 Minuten).

    Neben Deployments können andere Kubernetes-Ressourcen Zeitüberschreitungen haben, die haben keinen Einfluss auf das Stabilitäts-Timeout. Wenn eines davon vorhanden ist, um sicherzustellen, dass sie nicht mit dem Stabilitäts-Timeout in Konflikt stehen.

    Wenn bei Skaffold (oder Cloud Build) ein Zeitlimit erreicht wird, 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 ist auf true in skaffold.yaml eingestellt.

    Standardmäßig ist true ausgewählt. Wenn true, wartet Skaffold auf Systemdiagnosen, eine stabile Bereitstellung vorbehaltlich der im nächsten Schritt angegebenen Zeitüberschreitung melden.

  2. Legen Sie in skaffold.yaml Folgendes fest: statusCheckDeadlineSeconds auf die Anzahl der Sekunden, die Sie warten möchten.

    deploy:
      ...
      statusCheck: true
      statusCheckDeadlineSeconds: 600
      ...
    

    Der Standardwert ist 600 (10 Minuten). Skaffold wartet so lange auf eine eine stabile Bereitstellung ermöglichen. Wenn diese Zeit überschritten wird, bevor die Bereitstellung stabil ist, die Bereitstellung fehlschlägt.

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

    Diese Einstellung weist Skaffold an, nicht zu beenden, wenn eine einzelne Bereitstellung fehlschlägt, sondern Fehler bis zum Ablauf von statusCheckDeadlineSeconds tolerieren. Diese Einstellung kann dir helfen, wenn du Ressourcen hast, die mehr Zeit benötigen (bis zur Frist für die Statusüberprüfung), um einen stabilen Zustand zu erreichen.

    Wenn Sie beispielsweise Istio oder Cloud Service Mesh verwenden, haben Sie möglicherweise eine fehlgeschlagene Bereitstellung mit einer Meldung wie der folgenden 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 im Kubernetes-Manifest für Ressourcen von kind: Deployment Folgendes fest: Deployment.spec.progressDeadlineSeconds auf denselben Wert, den Sie für statusCheckDeadlineSeconds

Nächste Schritte