Cloud Deploy-Ausführungsumgebungen verwenden

Eine Cloud Deploy-Ausführungsumgebung ist die Umgebung, in der Cloud Deploy seine Rendering-, Predeploy-, Bereitstellungs-, Überprüfungs- und Postdeploy-Vorgänge ausführt. Die Ausführungsumgebung besteht aus den folgenden Komponenten:

  • Der Cloud Build-Worker-Pool (Standard oder Privat), in dem Cloud Deploy die Vorgänge „render“, „predeploy“, „deploy“, „verify“ und „postdeploy“ ausführt.

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

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

  • Das Cloud Build-Zeitlimit für Vorgänge (Standard oder benutzerdefiniert)

In diesem Dokument werden die Standardausführungsumgebung, die Dienstkonten und der Speicher für Cloud Deploy beschrieben, sowie Gründe und Vorgehensweisen für die Änderung dieser Standardeinstellungen.

Standardeinstellungen

Im Folgenden finden Sie die Standardwerte, die Cloud Deploy zum Ausführen, zum Rendering, zur Bereitstellung sowie zum Speichern von Assets, darunter gerenderte Manifeste, verwendet:

  • 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 privater Cloud Build-Worker-Pool verwendet wird.

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

  • Standarddienstkonto für die Ausführung

    Cloud Deploy verwendet standardmäßig das Compute Engine-Standarddienstkonto.

  • 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 einen Cloud Storage-Bucket in derselben Region wie die Cloud Deploy-Ressourcen. Der Bucket hat das folgende Format:

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

  • Cloud Build-Standardzeitlimit

    Standardmäßig gilt für Vorgänge, die Cloud Build für Cloud Deploy ausführt, ein Zeitlimit von einer Stunde. Sie können dieses Zeitlimit in der Spezifikation der Ausführungsumgebung in der Zielkonfiguration ändern.

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

    Standardmäßig sind die Protokollebenen für diese Tools auf die jeweiligen Standardwerte festgelegt, in der Regel warn oder das Äquivalent. Sie können dies ändern, indem Sie debug oder das Äquivalent verwenden.

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

Cloud Build-Worker-Pools

Für die Cloud Deploy-Ausführungsumgebung kann Folgendes verwendet werden:

  • Der Cloud Build-Standardpool

    Der Standard-Worker-Pool ist eine sichere, gehostete Umgebung mit Zugriff auf das öffentliche Internet. In diesem Pool werden von anderen Arbeitslasten isolierte Rendering-, Bereitstellungs-, Vorbereitungs-, Nachbereitstellungs- und Überprüfungsvorgänge ausgeführt.

  • Privater Pool

    Private Worker-Pools sind private, dedizierte Pools, die tiefer angepasst werden können als der standardmäßige Worker-Pool. Diese Anpassung kann die Möglichkeit bieten, auf Ressourcen in einem privaten Netzwerk zuzugreifen. Wie der standardmäßige Worker-Pool werden private Worker-Pools von Cloud Build gehostet und vollständig verwaltet. Diese Pools können vertikal oder horizontal auf null skaliert werden. Dabei muss keine Infrastruktur eingerichtet, aktualisiert oder skaliert werden.

    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, dass Render-, Bereitstellungs-, Vorbereitungs-, Nachbereitungs- oder Überprüfungsvorgänge oder eine Kombination der fünf in einer Umgebung ausgeführt werden, die von anderen Organisationen isoliert ist.

  • Sie möchten, dass diese Vorgänge in einer Umgebung ausgeführt werden, die nicht 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 Ort als im 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

Sie konfigurieren Worker-Pools pro Ziel, sodass der Pool für RENDER, DEPLOY, PREDEPLOY, POSTDEPLOY oder VERIFY (oder eine Kombination der fünf) nur für das jeweilige Ziel verwendet wird.

Wenn Sie den Standard-Worker-Pool für Render- und Bereitstellungsvorgänge verwenden möchten, müssen Sie nichts weiter tun.

Folgendes Beispiel zeigt eine Zielkonfiguration, die einen privaten Worker-Pool für DEPLOY und den Standard-Worker-Pool für RENDER, PREDEPLOY, POSTDEPLOY und VERIFY angibt:

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 zu dieser Konfiguration finden Sie unter Zieldefinitionen.

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]"

Mit dieser Konfiguration wird geändert, wo die gerenderten Manifeste gespeichert werden. Wo die Rendering-Quelle gespeichert wird, wird dadurch jedoch nicht beeinflusst.

Logebene für Skaffold, gcloud CLI und kubectl ändern

Wenn Sie die Protokollierungsstufe für Skaffold, die gcloud CLI und kubectl von den jeweiligen Standardwerten auf debug (oder das Äquivalent) ändern möchten, legen Sie verbose in den Ausführungskonfigurationen auf true fest. 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.

Sie können sich an der VPC Service Controls-Kurzanleitung orientieren, um einen Dienstperimeter einzurichten.

Beschränkungen

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

  • Das Projekt, das den Worker-Pool enthält, und das Projekt, das Ihre Cloud Deploy-Ressourcen enthält, müssen sich im selben VPC Service Controls-Sicherheitsperimeter befinden.

  • 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