Cloud Deploy-Ausführungsumgebungen verwenden

Eine Cloud Deploy-Ausführungsumgebung ist die Umgebung, in der Cloud Deploy ihre Rendering-, Prebereitstellung-, Deploy, Verify- 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 Rendering-, Pre-Deployment-, Deployment-, Überprüfungs- und Postdeploy-Vorgänge ausführt

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

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

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

In diesem Artikel werden die Standardausführungsumgebung, Dienstkonten und der Speicher für Cloud Deploy beschrieben sowie warum und wie Sie diese Standardeinstellungen ändern können.

Standardeinstellungen

Im Folgenden finden Sie die Standardeinstellungen, die Cloud Deploy zum Ausführen, Rendern und Bereitstellen sowie zum Speichern von Assets wie gerenderten Manifesten verwendet:

  • Standard-Worker-Pool

    Cloud Deploy wird standardmäßig im Standard-Cloud Build-Worker-Pool ausgeführt. Sie können jedoch Cloud Deploy für die Verwendung eines privaten Cloud Build-Worker-Pools konfigurieren.

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

  • Standard-Ausführungsdienstkonto

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

  • Standardspeicherort für Cloud Deploy

    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 im folgenden Format:

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

  • Standard-Cloud Build-Zeitüberschreitung

    Standardmäßig hat Cloud Build ein Zeitlimit von 1 Stunde für Vorgänge, die für Cloud Deploy ausgeführt werden. Sie können dieses Zeitlimit in der Ausführungsumgebungsspezifikation unter Zielkonfiguration ändern.

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:

  • Cloud Build-Standardpool

    Der Standard-Worker-Pool ist eine sichere, gehostete Umgebung mit Zugriff auf das öffentliche Internet. In diesem Pool werden die Vorgänge gerendert, bereitgestellt, vorbereitet, nachgestellt und geprüft, getrennt von anderen Arbeitslasten.

  • Privater Pool

    Private Worker-Pools sind private, dedizierte Pools, die stärker angepasst werden können als der Standard-Worker-Pool. Diese Anpassung kann die Möglichkeit umfassen, auf Ressourcen in einem privaten Netzwerk zuzugreifen. Wie der Standard-Worker-Pool werden private Worker-Pools von Cloud Build gehostet und vollständig verwaltet. Diese Pools können auf null skaliert werden, 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, dass die Vorgänge gerendert, bereitgestellt, vorab bereitgestellt, nachbereitet oder verifiziert werden oder eine Kombination aus diesen fünf in einer Umgebung ausgeführt wird, 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 nur für dieses Ziel, DEPLOY, PREDEPLOY, POSTDEPLOY oder VERIFY (oder eine Kombination aus diesen) verwendet wird.RENDER

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

Im Folgenden finden Sie eine Beispielkonfiguration für ein Ziel, die einen privaten Worker-Pool für DEPLOY und den Standard-Worker-Pool für RENDER, PREDEPLOY, POSTDEPLOY und VERIFY angibt:

executionConfigs:
- usages:
  - DEPLOY
  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 enthalten, wie im Dokument Cloud Deploy-Dienstkonten beschrieben.

Weitere Informationen zu dieser Konfiguration finden Sie unter Zieldefinitionen.

Speicherort ändern

Wenn Sie den Storage-Bucket von der Cloud Deploy-Standardeinstellung ändern möchten, fügen Sie die folgende Zeile in die Zieldefinition in der workerPool-Stanza ein:

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

Diese Konfiguration ändert den Speicherort der gerenderten Manifeste, hat aber keinen Einfluss darauf, wo die Renderingquelle gespeichert wird.

Cloud Deploy in einem VPC Service Controls-Perimeter verwenden

Cloud Deploy unterstützt VPC Service Controls.

Folgen Sie der VPC Service Controls-Kurzanleitung, um einen Dienstperimeter einzurichten.

Beschränkungen

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

  • Das Projekt, das den Worker-Pool und das Projekt mit Ihren Cloud Deploy-Ressourcen enthält, muss im selben VPC Service Controls-Sicherheitsperimeter bleiben.

  • 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