Cloud Deploy-Ausführungsumgebungen verwenden

Eine Cloud Deploy-Ausführungsumgebung ist die Umgebung, in der Cloud Deploy führt Rendering, Vorabbereitstellung, Bereitstellung, Überprüfung Vorgänge nach der Bereitstellung. Die Ausführungsumgebung besteht aus den folgenden Komponenten:

  • Der Cloud Build-Worker-Pool (Standard oder privat), in dem Cloud Deploy Rendering-, Vorabbereitstellungs-, Bereitstellungs-, Überprüfungs- und Bereitstellungsnachbereitungsvorgänge ausführt

  • Das Dienstkonto (Standard oder alternativ), das Cloud Deploy aufruft zum Ausführen dieser Aktionen

  • Der Speicherort (Standard oder alternativer Speicherort) für gerenderte Manifeste in Cloud Storage

  • Die Cloud Build-Zeitüberschreitung für Vorgänge (Standard oder benutzerdefiniert)

In diesem Artikel werden die standardmäßige Ausführungsumgebung, Dienstkonten und Speicher für Cloud Deploy erfahren. Außerdem erfahren Sie, warum und wie Sie diese Standardeinstellungen.

Standardeinstellungen

Im Folgenden sind die Standardeinstellungen aufgeführt, die Cloud Deploy für die Ausführung verwendet, um Führen Sie das Rendering und die Bereitstellung aus und speichern Sie Assets wie gerenderte Manifeste:

  • Standard-Worker-Pool

    Standardmäßig wird Cloud Deploy im standardmäßigen Cloud Build-Worker-Pool ausgeführt. Sie können jedoch Cloud Deploy so konfigurieren, dass ein Cloud Build-Projekt verwendet wird privaten Worker-Pool.

    Weitere Informationen zu Worker-Pools finden Sie in der Cloud Build-Übersicht zu Standardpools und privaten Pools.

  • Standarddienstkonto für die Ausführung

    Standardmäßig verwendet Cloud Deploy die standardmäßige Compute Engine Dienstkonto.

  • Standardmäßiger Cloud Deploy-Speicherort

    Dieser Wert ist der Cloud Storage-Bucket, in dem Cloud Deploy Ihre gerenderten Manifeste speichert. Standardmäßig erstellt Cloud Deploy ein Cloud Storage-Bucket in derselben Region als Cloud Deploy-Ressourcen. Sie haben folgendes Format:

    <location>.deploy-artifacts.<project ID>.appspot.com

  • Standardmäßiges Cloud Build-Zeitlimit

    Standardmäßig hat Cloud Build für Vorgänge ein Zeitlimit von 1 Stunde für Cloud Deploy ausgeführt wird. Sie können diese Zeitüberschreitung ändern in der Spezifikation der Ausführungsumgebung in Zielkonfiguration an.

  • Standardausführlichkeit für Skaffold, gcloud CLI und kubectl

    Standardmäßig sind die Protokollebenen für diese Tools auf ihre jeweiligen Standardeinstellungen eingestellt. in der Regel warn oder ein äquivalenter Wert. Sie können dies ändern. auf debug oder einen äquivalenten Wert.

In folgenden Abschnitten werden die Umstände beschrieben, unter denen Sie diese Werte ändern würden, sowie Links zu entsprechenden Anleitungen.

Informationen zu Cloud Build-Worker-Pools

Die Cloud Deploy-Ausführungsumgebung kann eine der folgenden Optionen verwenden:

  • Der Cloud Build-Standardpool

    Der Standard-Worker-Pool ist eine sichere, gehostete Umgebung mit Zugriff auf das öffentliche Internet. Vorgänge rendern, bereitstellen, vorab bereitstellen und nach der Bereitstellung überprüfen werden in diesem Pool isoliert von anderen Arbeitslasten ausgeführt.

  • Privater Pool

    Private Worker-Pools sind private, dedizierte Pools, die stärker angepasst werden können als die Standard-Worker -Pools. Diese Anpassung kann die Möglichkeit beinhalten, auf Ressourcen in einem in einem privaten Netzwerk. Wie der Standard-Worker-Pool werden private Worker-Pools und vollständig von Cloud Build verwaltet. Diese Pools können hochskaliert oder eine Skalierung auf null, ohne dass eine Infrastruktur eingerichtet, aktualisiert oder skaliert werden muss.

    In der Übersicht über private Pools von Cloud Build werden Standard-Worker-Pools und private Worker-Pools ausführlicher beschrieben. Dort findet sich auch eine Tabelle, in der die Funktionen verglichen werden.

Cloud Deploy-Ausführungsumgebung ändern

Unter folgenden Umständen können Sie die Cloud Deploy-Ausführungsumgebung ändern:

  • Sie möchten eine Bereitstellung in einem privaten Google Kubernetes Engine-Cluster vornehmen.

  • Sie möchten Vorgänge rendern, bereitstellen, vorab bereitstellen, nach der Bereitstellung überprüfen oder Vorgänge überprüfen. Kombination dieser fünf Elemente, die in einer Umgebung durchgeführt werden sollen, die von der andere Organisationen.

  • Sie möchten, dass diese Vorgänge in einer Umgebung ausgeführt werden, mit dem öffentlichen Internet verbunden ist.

  • Sie möchten separate Umgebungen für Rendering und Bereitstellung erstellen.

  • Sie möchten ein dediziertes Dienstkonto mit Berechtigungen verwenden, die für Ihre Nutzung spezifischer sind als die im Standarddienstkonto verfügbaren Berechtigungen.

  • Sie möchten gerenderte Manifeste an einem anderen Speicherort als dem standardmäßigen Cloud Storage-Bucket speichern.

Die Konfiguration aller drei Teile der Ausführungsumgebung (Worker-Pool, Dienstkonto und Speicher) erfolgt pro Ziel in der YAML-Konfiguration der einzelnen Ziele.

Vom Standardpool zu einem privaten Pool wechseln

Worker-Pools werden pro Ziel konfiguriert, sodass der Pool für RENDER, DEPLOY, PREDEPLOY, POSTDEPLOY oder VERIFY (oder eine Kombination aus diesen fünf) nur für dieses Ziel verwenden.

Wenn Sie den Standard-Worker-Pool sowohl für Rendering- als auch Bereitstellungsvorgänge verwenden möchten, müssen Sie irgendetwas unternehmen muss.

Im folgenden Beispiel wird eine Zielkonfiguration mit einem privaten Worker-Pool für DEPLOY und dem Standard-Worker-Pool für RENDER, PREDEPLOY, POSTDEPLOY und VERIFY gezeigt:

executionConfigs:
- usages:
  - DEPLOY
  privatePool:
    workerPool: "projects/p123/locations/us-central1/workerPools/wp123"
- usages:
  - RENDER
  - PREDEPLOY
  - VERIFY
  - POSTDEPLOY

Weitere Informationen zum Konfigurieren privater Pools für Ziele finden Sie in der Dokumentation zur Konfiguration der Lieferpipeline.

Vom Standarddienstkonto zum benutzerdefinierten Ausführungsdienstkonto wechseln

Wie beim Worker-Pool können Sie ein alternatives Dienstkonto angeben, das für Rendering oder Bereitstellung (oder beides) pro Ziel verwendet werden soll. Fügen Sie dazu folgende Zeile in die Zielkonfiguration ein, nach dem workerPool-Element:

serviceAccount: "[name]@[project_name].iam.gserviceaccount.com"

Das angegebene Dienstkonto muss die Rolle clouddeploy.jobRunner haben, wie im Dokument Cloud Deploy-Dienstkonten beschrieben.

Weitere Informationen finden Sie unter Zieldefinitionen. Details zu dieser Konfiguration.

Speicherort ändern

Um den Storage-Bucket vom Cloud Deploy-Standard zu ändern, fügen Sie folgende Zeile der Zieldefinition in der workerPool-Stanza hinzu:

artifactStorage: "gs://[bucket_name]/[dir]"

Durch diese Konfiguration wird der Speicherort der gerenderten Manifeste geändert, sie wird jedoch nicht wirken sich darauf aus, wo die Renderingquelle gespeichert wird.

Logebene für Skaffold, gcloud-Befehlszeile und kubectl ändern

So ändern Sie die Logebene für Skaffold, gcloud CLI und kubectl aus ihre jeweiligen Standardwerte auf debug (oder die entsprechende Entsprechung) legen, setzen Sie verbose auf true in den Ausführungskonfigurationen. Beispiel:

executionConfigs:
- usages:
  - [RENDER | PREDEPLOY|  DEPLOY | VERIFY | POSTDEPLOY]
  workerPool:
  serviceAccount:
  artifactStorage:
  executionTimeout:
  verbose: true

Cloud Deploy in einem VPC Service Controls-Perimeter verwenden

Cloud Deploy unterstützt VPC Service Controls.

Weitere Informationen finden Sie in der Kurzanleitung zu VPC Service Controls. um einen Dienstperimeter einzurichten.

Beschränkungen

  • Sie müssen einen privaten Cloud Build-Worker-Pool für die Ausführungsumgebung – nicht den Standard-Worker-Pool.

  • Das Projekt, das den Worker-Pool enthält, und das Projekt mit dem Cloud Deploy-Ressourcen müssen in VPC Service Controls bleiben Sicherheitsbereich.

  • GKE-Cluster, die Sie im VPC Service Controls-Perimeter bereitstellen, müssen private Cluster sein.

    Informationen zum Einrichten eines privaten Pools für einen privaten Cluster finden Sie in dieser Anleitung.

Nächste Schritte