Google Cloud Deploy-Ausführungsumgebungen verwenden

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Eine Google Cloud Deploy-Ausführungsumgebung ist die Umgebung, in der Google Cloud Deploy ihre Rendering-, Bereitstellungs- und Überprüfungsvorgänge ausführt. Die Ausführungsumgebung besteht aus den folgenden Komponenten:

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

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

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

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

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

Standardeinstellungen

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

  • Standard-Worker-Pool

    Google Cloud Deploy wird standardmäßig im Cloud Build-Standard-Worker-Pool ausgeführt. Sie können Google Cloud Deploy jedoch 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.

  • Standardausführungsdienstkonto

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

  • Standardspeicherort von Google Cloud Deploy

    Dieser Wert ist der Cloud Storage-Bucket, in dem Google Cloud Deploy Ihre gerenderten Manifeste speichert. Standardmäßig erstellt Google Cloud Deploy einen Cloud Storage-Bucket in derselben Region wie die Google Cloud Deploy-Ressourcen im folgenden 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 Google 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 Ausführungsumgebung Google Cloud Deploy kann eine der folgenden Optionen verwenden:

  • Cloud Build-Standardpool

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

  • Ein 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 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.

Google Cloud Deploy-Ausführungsumgebung ändern

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

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

  • Sie möchten, dass Vorgänge in einer Umgebung, die von anderen Organisationen isoliert ist, ausgeführt, bereitgestellt oder überprüft werden oder eine Kombination aus diesen drei Vorgängen besteht.

  • 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 Speicherort als im 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

Sie konfigurieren Worker-Pools pro Ziel, sodass der Pool nur für dieses Ziel für RENDER, DEPLOY oder VERIFY (oder eine Kombination aus drei) 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 unternehmen.

Hier ein Beispiel einer Zielkonfiguration, die einen privaten Worker-Pool für DEPLOY und den Standard-Worker-Pool für RENDER und VERIFY angibt:

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

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 clouddeploy.jobRunner-Rolle haben, wie im Dokument Google Cloud Deploy-Dienstkonten beschrieben.

Weitere Informationen zu dieser Konfiguration finden Sie unter Zieldefinitionen.

Speicherort ändern

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

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

Durch diese Konfiguration wird geändert, wo die gerenderten Manifeste gespeichert werden. Dies hat jedoch keinen Einfluss darauf, wo die Rendering-Quelle gespeichert wird.

Bereitstellung für einen privaten Cluster in einem Virtual Private Cloud-Netzwerk

Sie können ein Ziel für die Bereitstellung in einem privaten GKE-Cluster konfigurieren, der mit einem Virtual Private Cloud-Netzwerk verbunden ist:

  1. Privaten Cluster erstellen

    Ein privater Cluster ist ein VPC-nativer Cluster, dessen Knoten und Pods standardmäßig vom öffentlichen Internet isoliert sind.

    Wenn Sie die interne IP-Adresse des privaten Clusterziels verwenden möchten, setzen Sie internalIp in der Zielkonfiguration unter gke auf true.

  2. Erstellen Sie in Cloud Build einen privaten Worker-Pool, den Sie für die Bereitstellung in diesem privaten Cluster verwenden können.

  3. Konfigurieren Sie die Ausführungsumgebung für die Verwendung dieses privaten Pools.

    Sie müssen diesen Pool für RENDER verwenden. Sie können sie auch für DEPLOY und VERIFY verwenden. Hier ein Beispiel, in dem RENDER und DEPLOY verwendet werden:

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

Weitere Informationen finden Sie unter Mit privaten Cloud Build-Pools auf private GKE-Cluster zugreifen.

Hinweise zu Projekten und Berechtigungen

Es ist einfach, ein Ziel für die Verwendung eines privaten Worker-Pools zu konfigurieren, der in einem privaten Cluster Bereitstellungen ausführen kann. Es sind jedoch einige Dinge zu beachten, wenn sich Ressourcen in verschiedenen Projekten befinden.

Wenn sich Google Cloud Deploy und der Worker-Pool in separaten Projekten befinden

Für die Kommunikation mit einem privaten Pool, der Zugriff auf eine VPC hat und sich in einem anderen Projekt als Ihr Ziel befindet, benötigt der Dienst-Agent von Google Cloud Deploy ausreichende Berechtigungen, um mit diesem Projekt zu kommunizieren.

Das Ausführungsdienstkonto benötigt außerdem Berechtigungen für den Zugriff auf den Cloud Storage-Bucket.

Wenn sich der Worker-Pool und der Cluster in separaten Projekten befinden

Befindet sich der private GKE-Cluster in einem anderen Projekt als der private Worker-Pool, benötigt das Ausführungs-Dienstkonto ausreichende Berechtigungen zur Kommunikation mit dem Projekt, in dem sich der Cluster befindet.

Google Cloud Deploy in einem VPC Service Controls-Perimeter verwenden

Google Cloud Deploy unterstützt VPC Service Controls.

Folgen Sie 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 des Ziels verwenden, nicht den Standard-Worker-Pool.

  • Das Projekt, das den Worker-Pool enthält, und das Projekt, das Ihre Google 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