Eine Cloud Deploy-Ausführungsumgebung ist die Umgebung, in der Cloud Deploy seine Rendering-, Pre-Deploy-, Deployment-, Prüf- und Post-Deploy-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-Deploy-, Deployment-, Überprüfungs- und Post-Deployments ausführt
Das Dienstkonto (Standard- oder alternatives Konto), das Cloud Deploy zum Ausführen dieser Aktionen aufruft
Der Speicherort (Standard oder alternativer Speicherort) für gerenderte Manifeste in Cloud Storage
Das Cloud Build-Zeitlimit für Vorgänge (Standard oder benutzerdefiniert)
In diesem Artikel werden die standardmäßige Ausführungsumgebung, die Dienstkonten und der Speicher für Cloud Deploy beschrieben. Außerdem erfahren Sie, 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 Cloud Build-Worker-Standardpool ausgeführt. Sie können Cloud Deploy jedoch für die Verwendung eines privaten Worker-Pools von Cloud Build konfigurieren.
Weitere Informationen zu Worker-Pools finden Sie in der Cloud Build-Übersicht zu Standardpools und privaten Pools.
Dienstkonto für die Standardausführung
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. Er hat das folgende Format:
<location>.deploy-artifacts.<project ID>.appspot.com
Cloud Build-Standardzeitlimit
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 Spezifikation der Ausführungsumgebung in der 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:
-
Der Standard-Worker-Pool ist eine sichere, gehostete Umgebung mit Zugriff auf das öffentliche Internet. Rendering-, Bereitstellungs-, Pre-Deploy-, Post-Deploy- und Prüfvorgänge werden in diesem Pool und von anderen Arbeitslasten isoliert ausgeführt.
Ein privater Pool
Private Worker-Pools sind private, dedizierte Pools, die mehr angepasst werden können als der Standard-Worker-Pool. Diese Anpassung kann auch die Möglichkeit umfassen, auf Ressourcen in einem privaten Netzwerk zuzugreifen. Wie der Standard-Worker-Pool werden auch private Worker-Pools von Cloud Build gehostet und vollständig verwaltet. Diese Pools können hoch- oder herunterskaliert 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 den folgenden Umständen können Sie die Ausführungsumgebung von Cloud Deploy ändern:
Sie möchten eine Bereitstellung in einem privaten Google Kubernetes Engine-Cluster vornehmen.
Sie möchten, dass Rendering-, Bereitstellungs-, Pre-Deploy-, Post-Deploy- oder Prüfvorgänge oder eine Kombination dieser Vorgänge in einer Umgebung ausgeführt werden, die von anderen Organisationen isoliert ist.
Diese Vorgänge sollen 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 Speicherort als dem Cloud Storage-Standard-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, damit der Pool für RENDER
, DEPLOY
, PREDEPLOY
, POSTDEPLOY
oder VERIFY
(oder eine Kombination aus diesen fünf) nur für dieses Ziel verwendet wird.
Wenn Sie den Standard-Worker-Pool sowohl für Rendering- als auch für Bereitstellungsvorgänge verwenden möchten, müssen Sie nichts weiter tun.
Das folgende Beispiel zeigt eine Zielkonfiguration, in der ein privater Worker-Pool für DEPLOY
und der Standard-Worker-Pool für RENDER
, PREDEPLOY
, POSTDEPLOY
und VERIFY
angegeben werden:
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
enthalten, wie im Dokument Cloud Deploy-Dienstkonten beschrieben.
Weitere Informationen zu dieser Konfiguration finden Sie unter Zieldefinitionen.
Speicherort ändern
Wenn Sie den Storage-Bucket aus der Cloud Deploy-Standardeinstellung ändern möchten, fügen Sie der Zieldefinition in der Stanza workerPool
die folgende Zeile hinzu:
artifactStorage: "gs://[bucket_name]/[dir]"
Diese Konfiguration ändert den Speicherort der gerenderten Manifeste. Sie hat jedoch keinen Einfluss darauf, wo die Renderingquelle gespeichert wird.
Cloud Deploy in einem VPC Service Controls-Perimeter verwenden
Cloud Deploy unterstützt VPC Service Controls.
Informationen zum Einrichten eines Dienstperimeters finden Sie in der Kurzanleitung zu VPC Service Controls.
Beschränkungen
Sie müssen für die Ausführungsumgebung des Ziels einen privaten Cloud Build-Worker-Pool verwenden, nicht den Standard-Worker-Pool.
Das Projekt mit dem Worker-Pool und das Projekt mit Ihren Cloud Deploy-Ressourcen müssen 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
Weitere Informationen zur Zielkonfiguration von Cloud Deploy
Mehr über die Private Cloud Build-Pools erfahren.
Erfahren Sie mehr darüber, wie Cloud Build VPC Service Controls verwendet.
Dienstkonten von Cloud Deploy verwenden
Auf private GKE-Cluster mit privaten Cloud Build-Pools zugreifen.