Konfigurationsschemareferenz

Die Cloud Deploy-Konfigurationsdatei oder -Dateien definieren die Bereitstellungspipeline Ziele für die Bereitstellung und der Fortschritt dieser Ziele.

Die Konfigurationsdatei für die Bereitstellungspipeline kann Folgendes enthalten: Zieldefinitionen. Diese können sich auch in einer separaten Datei befinden oder -Dateien. Konventionsgemäß kann eine Datei sowohl die Konfiguration der Bereitstellungspipeline heißt die Zielkonfiguration clouddeploy.yaml und eine Pipelinekonfiguration ohne hat den Namen delivery-pipeline.yaml. Sie können diesen Dateien jedoch beliebige den gewünschten Namen.

Aufbau

Cloud Deploy verwendet zwei Hauptkonfigurationsdateien:

Dabei kann es sich um separate Dateien handeln oder es lassen sich die Bereitstellungspipeline und Ziele die in derselben Datei konfiguriert sind.

Struktur einer Konfigurationsdatei für eine Lieferpipeline.

Die folgende Konfiguration enthält eine Zieldefinition:

# Delivery pipeline config
apiVersion: deploy.cloud.google.com/v1
kind: DeliveryPipeline
metadata:
 name:
 annotations:
 labels:
description:
suspended:
serialPipeline:
 stages:
 - targetId:
   profiles: []
# Deployment strategies
# One of:
#   standard:
#   canary:
# See the strategy section in this document for details.
   strategy:
     standard:
       verify:
       predeploy:
         actions: []
       postdeploy:
         actions: []
   deployParameters:
   - values:
     matchTargetLabels:
 - targetId:
   profiles: []
   strategy:
   deployParameters:
---

# Target config
apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
 name:
 annotations:
 labels:
description:
multiTarget:
 targetIds: []
deployParameters:
requireApproval:
#
# Runtimes
# one of the following runtimes:
gke:
 cluster:
 internalIp:
 proxyUrl:
#
# or:
anthosCluster:
 membership:
#
# or:
run:
 location:
#
# or:
customTarget:
  customTargetType:
#
# (End runtimes. See documentation in this article for more details.)
#
executionConfigs:
- usages:
  - [RENDER | PREDEPLOY | DEPLOY | VERIFY | POSTDEPLOY]
  workerPool:
  serviceAccount:
  artifactStorage:
  executionTimeout:
---

# Custom target type config
apiVersion: deploy.cloud.google.com/v1
kind: CustomTargetType
metadata:
  name:
  annotations:
  labels:
description:
customActions:
  renderAction:
  deployAction:
  includeSkaffoldModules:
    - configs:
    # either:
    googleCloudStorage:
      source:
      path:
    # or:
    git:
      repo:
      path:
      ref:
---

# Automation config
apiVersion: deploy.cloud.google.com/v1
kind: Automation
metadata:
  name:
  labels:
  annotations:
description:
suspended:
serviceAccount:
selector:
- target:
    id:
    # or
    labels:
rules:
- [RULE_TYPE]:
  name:
  [RULE-SPECIFIC_CONFIG]

Diese YAML-Datei besteht aus drei Hauptkomponenten:

  • Hauptlieferpipeline und Fortschritt

    Die Konfigurationsdatei kann eine beliebige Anzahl an Pipelinedefinitionen enthalten.

  • Zieldefinitionen

    Der Einfachheit halber wird in diesem Beispiel nur ein Ziel gezeigt, es können aber auch beliebige wie viele davon. Außerdem können Ziele in einer oder mehreren separaten Dateien definiert werden.

  • Definitionen für benutzerdefinierte Zieltypen

    Benutzerdefinierte Ziele (benutzerdefinierter Zieltyp erforderlich) Definition. Wie bei Zielen und Automatisierungen lassen sich auch benutzerdefinierte Zieltypen in derselben Datei wie die Bereitstellungspipeline oder in einer separaten Datei definiert ist.

  • Automatisierungsdefinitionen

    Sie können beliebige Automatisierungen für die Bereitstellung in derselben als Bereitstellungspipeline und -ziele oder in separaten Dateien. Zur Vereinfachung wird hier nur eine Automation angezeigt. Sie können aber beliebig viele erstellen.

Diese Komponenten werden im Rest dieses Dokuments definiert.

Pipelinedefinition und -fortschritt

Neben Pipeline-Metadaten wie name enthält die Hauptpipelinedefinition eine Liste mit Verweisen auf Ziele in der Reihenfolge der Bereitstellungssequenz. Das heißt, das erste aufgeführte Ziel ist das erste Bereitstellungsziel. Nach der Bereitstellung auf diesem Ziel wird der Release hochgestuft. für das nächste Ziel in der Liste bereitgestellt.

Im Folgenden sind die Konfigurationsattribute für eine Bereitstellungspipeline aufgeführt, nicht einschließlich Zieldefinitionen.

metadata.name

Das name-Feld verwendet einen String, der pro Projekt und Standort einmalig sein muss.

metadata.annotations und metadata.labels

Die Konfiguration der Lieferpipeline kann Annotationen und Labels enthalten. Annotationen und Labels werden mit der Ressource der Lieferpipeline gespeichert, nachdem die Pipeline registriert wurde.

Weitere Informationen finden Sie unter Labels und Annotationen mit Cloud Deploy verwenden.

description

Beliebiger String, der diese Lieferpipeline beschreibt. Diese Beschreibung wird angezeigt in den Details zur Bereitstellungspipeline in der Google Cloud Console.

suspended

Ein boolescher Wert, der bei true die Bereitstellungspipeline pausiert, sodass damit keine Releases erstellt, hochgestuft, rückgängig gemacht oder neu bereitgestellt werden können. Wenn die Bereitstellungspipeline ausgesetzt ist, können Sie ein mit dieser Pipeline erstelltes Roll-out.

Der Standardwert ist false.

serialPipeline

Der Anfang der Definition einer Pipeline für die Bereitstellung serieller Fortsetzungen. Dieses Stanza ist erforderlich.

stages

Liste aller Ziele, für die diese Lieferpipeline konfiguriert wurde.

Die Liste muss in der gewünschten Reihenfolge der Auslieferung angeordnet sein. Beispiel: Wenn Sie Ziele mit den Namen dev, staging und production haben, listen Sie diese in dieser Reihenfolge auf, damit Ihre erste Bereitstellung für dev und Ihre letzte Bereitstellung für production erfolgt.

Geben Sie in jedem Feld stages.targetId den Wert des Felds metadata.name in der entsprechenden Zieldefinition ein. Fügen Sie unter targetId profiles:

serialPipeline:
 stages:
 - targetId:
   profiles: []
   strategy:
     standard:
       verify:

targetId

Gibt das spezifische Ziel an, das für diese Phase der Lieferpipeline verwendet werden soll. Der Wert ist das metadata.name-Attribut aus der Zieldefinition.

strategy.standard.verify wird auf true festgelegt, aktiviert Bereitstellungsprüfung für das Ziel. Falls nein Bereitstellungsstrategie ist angegeben, die Bereitstellungsstrategie standard wird verwendet, wobei die Bestätigung auf false festgelegt ist.

profiles

Nimmt eine Liste mit null oder mehr Skaffold-Profilnamen aus skaffold.yaml an. Cloud Deploy verwendet das Profil mit skaffold render beim Erstellen des Release. Mit Skaffold-Profilen können Sie mit nur einer Konfigurationsdatei.

strategy

Enthält Attribute zum Festlegen einer Bereitstellungsstrategie. Die folgenden Strategien werden unterstützt:

  • standard:

    Die Anwendung wird vollständig auf dem angegebenen Ziel bereitgestellt.

    Dies ist die Standard-Bereitstellungsstrategie. Wenn Sie strategy weglassen, gilt Folgendes: Cloud Deploy verwendet die Bereitstellungsstrategie standard.

  • canary:

    Bei einem Canary-Deployment eine neue Version Ihrer Anwendung schrittweise bereitstellen, wodurch die bereits ausgeführte Version in prozentualen Schritten (z. B. 25%, dann 50%, dann 75 % und dann voll)

Die Bereitstellungsstrategie wird pro Ziel definiert. Beispiel: Sie haben eine Canary-Strategie für Ihr prod-Ziel, aber eine Standardstrategie (keine strategy für Ihre anderen Ziele.

Weitere Informationen finden Sie unter Bereitstellungsstrategie verwenden.

strategy Konfiguration

In diesem Abschnitt werden die Konfigurationselemente für strategy für jedes unterstützte Laufzeit.

Standardbereitstellungsstrategie

Die Standardstrategie umfasst nur die folgenden Elemente:

strategy:
  standard:
    verify: true|false

Das Attribut verify ist optional. Die Standardeinstellung ist false, was bedeutet, dass keine verify-Phase für die resultierenden Roll-outs.

Du kannst das strategy-Element für einen Standard weglassen. der Implementierungsstrategie.

Canary-Bereitstellungsstrategie

In den folgenden Abschnitten wird die Konfiguration eines Canary-Bereitstellungsstrategie für jede von Cloud Deploy unterstützte Laufzeit.

Für Cloud Run-Ziele
strategy:
  canary:
    runtimeConfig:
      cloudRun:
        automaticTrafficControl: true | false
    canaryDeployment:
      percentages: [PERCENTAGES]
      verify: true | false
Für GKE- und GKE Enterprise-Ziele

Die folgende YAML-Datei zeigt, wie Sie eine Bereitstellungsstrategie für eine GKE- oder GKE Enterprise-Ziel mit dienstbasiertes Netzwerk:

      canary:
        runtimeConfig:
          kubernetes:
            serviceNetworking:
              service: "SERVICE_NAME"
              deployment: "DEPLOYMENT_NAME"
              disablePodOverprovisioning: true | false
        canaryDeployment:
          percentages: [PERCENTAGES]
          verify: true | false

Die folgende YAML-Datei zeigt, wie Sie eine Bereitstellungsstrategie für eine GKE- oder GKE Enterprise-Ziel mit Gateway API:

      canary:
        runtimeConfig:
          kubernetes:
            gatewayServiceMesh:
              httpRoute: "HTTP_ROUTE_NAME"
              service: "SERVICE_NAME"
              deployment: "DEPLOYMENT_NAME"
              routeUpdateWaitTime: "WAIT_TIME"
        canaryDeployment:
          percentages: ["PERCENTAGES"]
          verify: true | false

Hinweis in diesem Beispiel routeUpdateWaitTime Dieses ist enthalten, da die Gateway API den Traffic mithilfe einer HTTPRoute-Ressource aufteilt. Manchmal kommt es bei der Übertragung von Änderungen an HTTPRoute zu Verzögerungen. In in solchen Fällen werden Anfragen unter Umständen verworfen, da der Traffic die nicht verfügbar sind. Wenn Sie diese Verzögerung feststellen, können Sie mit routeUpdateWaitTime festlegen, dass Cloud Deploy nach dem Anwenden von HTTPRoute-Änderungen wartet.

Im folgenden YAML-Code sehen Sie, wie ein benutzerdefinierter oder custom-automated Canary-Bereitstellungsstrategie. Die laufzeitspezifische Konfiguration im Abschnitt runtimeConfig wird für benutzerdefinierte Canary-Versionen weggelassen, aber in die Konfiguration für automatische und benutzerdefinierte automatische Canary-Versionen aufgenommen.

strategy:
       canary:
         # Runtime configs are configured as shown in the
         # Canary Deployment Strategy section of this document.
         runtimeConfig:

         # Manual configuration for each canary phase
         customCanaryDeployment:
           - name: "PHASE1_NAME"
             percent: PERCENTAGE1
             profiles: [ "PROFILE1_NAME" ]
             verify: true | false
           - …
           - name: "stable"
             percent: 100
             profiles: [ "LAST_PROFILE_NAME" ]
             verify: true|false

verify

Optionaler boolescher Wert, der angibt, ob die Bereitstellungsprüfung unterstützt werden soll für dieses Ziel. Der Standardwert ist false.

Das Aktivieren der Bereitstellungsüberprüfung erfordert auch eine verify-Stanza in skaffold.yaml. Wenn Sie diese Property nicht angeben, wird der Überprüfungsjob scheitern.

deployParameters

Ermöglicht das Angeben von Schlüssel/Wert-Paaren, um Werte an Manifeste zu übergeben mit Labels übereinstimmende Ziele, wenn Parameter zum Bereitstellen verwendet werden.

Sie können es auch in Ziele aufnehmen.

Stellen Sie Parameter, die in einer Bereitstellungspipeline festgelegt wurden, mithilfe von Labels bereit, um Ziele abzugleichen:

deployParameters:
- values:
    someKey: "value1"
  matchTargetLabels:
    label1: firstLabel
- values:
    someKey: "value2"
  matchTargetLabels:
    label2: secondLabel

In diesem Beispiel werden für den Schlüssel zwei Werte angegeben, gibt es ein Label. Der Wert wird auf das Manifest für jedes Ziel angewendet, das einen zugehörigen Labels.

predeploy- und postdeploy-Jobs

Damit können Sie auf benutzerdefinierte Aktionen (separat definiert, in skaffold.yaml), der vor dem Bereitstellungsjob (predeploy) und nach der Überprüfung ausgeführt werden soll Job, falls vorhanden (postdeploy). Wenn kein Prüfjob vorhanden ist, wird der Job nach der Bereitstellung nach dem Bereitstellungsjob ausgeführt wird.

Bereitstellungs-Hooks werden unter strategy.standard konfiguriert oder strategy.canary so:

serialPipeline:
  stages:
  - targetId: 
    strategy:
      standard:
        predeploy:
          actions: [ACTION_NAME]
        postdeploy:
          actions: [ACTION_NAME]

Dabei ist ACTION_NAME der in skaffold.yaml konfigurierte Name für customActions.name

Sie können predeploy- und postdeploy-Jobs unter jeder Strategie konfigurieren (z. B. standard oder canary).

Weitere Informationen zum Konfigurieren und Verwenden von Hooks vor und nach der Bereitstellung Siehe Hooks vor und nach der Bereitstellung ausführen.

Zieldefinitionen

Die Definitionsdatei der Lieferpipeline kann Zieldefinitionen enthalten. Alternativ können Sie Ziele in einer separaten Datei angeben. Sie können Zielnamen innerhalb eines Projekts wiederholen, diese müssen aber innerhalb einer Lieferpipeline einmalig sein.

Sie können Ziele in mehreren Lieferpipelines wiederverwenden. Sie können jedoch nur einmal innerhalb einer einzelnen Lieferpipeline auf ein Ziel verweisen.

Weitere Informationen finden Sie unter Definitionen benutzerdefinierter Zieltypen.

Für GKE-Ziele

Im folgenden YAML-Code wird gezeigt, wie ein Ziel konfiguriert wird, das in einem GKE-Cluster bereitgestellt wird:

     apiVersion: deploy.cloud.google.com/v1
     kind: Target
     metadata:
      name:
      annotations:
      labels:
     description:
     deployParameters:
     multiTarget:
      targetIds: []

     requireApproval:
     gke:
      cluster: projects/[project_name]/locations/[location]/clusters/[cluster_name]
      internalIp:
      proxyUrl:

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

metadata.name

Der Name dieses Ziels. Dieser Name muss global eindeutig sein.

metadata.annotations und metadata.labels

Die Zielkonfiguration unterstützt Kubernetes-Annotationen und Labels. aber für Cloud Deploy sind sie nicht erforderlich.

Annotationen und Labels werden mit der Zielressource gespeichert. Weitere Informationen Siehe Labels und Annotationen mit Cloud Deploy verwenden.

description

Dieses Feld verwendet einen beliebigen String, der die Verwendung des Ziels beschreibt.

deployParameters

Sie können Bereitstellungsparameter für jedes Ziel, zusammen mit den Werten. Diese Werte werden nach dem Rendern den entsprechenden Schlüsseln in Ihrem Manifest zugewiesen.

Die Stanza deployParameters nimmt Schlüssel/Wert-Paare an, wie hier gezeigt:

deployParameters:
  someKey: "someValue"
  someOtherKey: "someOtherValue"

Wenn Sie Bereitstellungsparameter für eine multi-target hat, wird der Wert das Manifest für alle Ziele untergeordnete Ziele festlegen.

multiTarget.targetIds: []

Diese Property ist optional und wird verwendet, um ein Multi-Target für die parallele Bereitstellung zu konfigurieren.

Der Wert ist eine durch Kommas getrennte Liste von untergeordneten Zielen. Untergeordnete Ziele werden als normale Ziele konfiguriert und schließen dies nicht ein multiTarget-Property.

requireApproval

Gibt an, ob das Hochstufen zu diesem Ziel eine manuelle Genehmigung erfordert. Kann true oder false sein.

Dieses Attribut ist optional. Der Standardwert ist false.

Beim Konfigurieren der parallelen Bereitstellung können Sie Folgendes festlegen: Genehmigung für mehrere Ziele, nicht für untergeordnete Ziele.

gke

Nur bei GKE-Clustern: Der Ressourcenpfad zur Identifizierung des Cluster, in dem Ihre Anwendung bereitgestellt wird:

gke:
  cluster: projects/[project_name]/locations/[location]/clusters/[cluster_name]

  • project_name

    Das Google Cloud-Projekt, in dem sich der Cluster befindet.

  • location

    Der Standort, an dem sich der Cluster befindet. Beispiel: us-central1. Der Cluster kann auch zonal sein (us-central1-c).

  • cluster_name

    Der Name des Clusters, wie er in der Liste der Cluster in Google Cloud Console

Beispiel:

gke:
  cluster: projects/cd-demo-01/locations/us-central1/clusters/prod

Lassen Sie das Attribut gke weg, wenn Sie ein Multi-Ziel konfigurieren. Der GKE-Cluster wird stattdessen im entsprechenden untergeordneten Ziel konfiguriert.

Eine Beschreibung finden Sie in diesem Artikel unter executionConfigs. der Ausführungsumgebung.

internalIp

Gibt an, ob der angegebene GKE-Cluster einen privaten GKE-Cluster verwendet IP-Adresse. Dieses Attribut ist optional. Standardmäßig verwendet Cloud Deploy Die öffentlich verfügbare IP-Adresse für den Cluster. Wenn eine private IP-Adresse vorhanden ist und Sie diese verwenden möchten, legen Sie dafür true fest.

proxyUrl

Wenn Sie über einen Proxy auf Cluster zugreifen, geben Sie hier die proxyUrl-Eigenschaft an. Der Wert ist die URL Ihrer Proxy-GKE-Instanz „Cluster“, also an kubectl übergeben wenn Sie eine Verbindung zu Ihrem Cluster herstellen.

Für Cloud Run-Ziele

Die folgende YAML-Datei zeigt, wie ein Ziel konfiguriert wird, in einem Cloud Run-Dienst bereitgestellt:

     apiVersion: deploy.cloud.google.com/v1
     kind: Target
     metadata:
      name:
      annotations:
      labels:
     description:
     multiTarget:
      targetIds: []

     requireApproval:
     run:
      location: projects/[project_name]/locations/[location]

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

metadata.name

Der Name dieses Ziels. Dieser Name muss in jeder Region eindeutig sein.

metadata.annotations und metadata.labels

Die Zielkonfiguration unterstützt Annotationen und Labels. aber für Cloud Deploy sind sie nicht erforderlich.

Annotationen und Labels werden mit der Zielressource gespeichert. Weitere Informationen Siehe Labels und Annotationen mit Cloud Deploy verwenden.

description

Dieses Feld verwendet einen beliebigen String, der die Verwendung des Ziels beschreibt.

multiTarget.targetIds: []

Dieses Attribut ist optional und wird verwendet, um ein mehrere Ziele, die für parallele Bereitstellung.

Der Wert ist eine durch Kommas getrennte Liste von untergeordneten Zielen. Untergeordnete Ziele werden als normale Ziele konfiguriert und schließen dies nicht ein multiTarget-Property.

requireApproval

Gibt an, ob das Hochstufen zu diesem Ziel eine manuelle Genehmigung erfordert. Kann true oder false sein.

Dieses Attribut ist optional. Der Standardwert ist false.

Beim Konfigurieren der parallelen Bereitstellung können Sie Folgendes festlegen: Genehmigung für mehrere Ziele, nicht für untergeordnete Ziele.

run

Nur für Cloud Run-Dienste den Standort, an dem der Dienst wird erstellt:

run:
  location: projects/[project_name]/locations/[location]

  • project_name

    Das Google Cloud-Projekt, in dem der Dienst gespeichert wird.

  • location

    Der Standort, an dem der Dienst bereitgestellt wird. Beispiel: us-central1.

Lassen Sie das Attribut run bei der Konfiguration eines [multi-target] weg. Der Standort des Der Cloud Run-Dienst wird stattdessen im entsprechendes untergeordnetes Ziel.

Eine Beschreibung finden Sie in diesem Artikel unter executionConfigs. der Ausführungsumgebung.

Für GKE Enterprise-Ziele

Zielkonfiguration für Die Bereitstellung in einem GKE-Cluster ähnelt der Konfigurieren eines Ziels für ein GKE-Ziel außer dass das Attribut anthosCluster.membership statt gke.cluster ist, Der Ressourcenpfad ist anders und internalIp ist nicht anwendbar.

anthosCluster:
  membership: projects/[project_name]/locations/global/memberships/[membership_name]

  • project_name

    Das Google Cloud-Projekt, in dem sich der GKE Enterprise-Cluster befindet.

  • /location/global/

    Der Standort, an dem der Cluster registriert ist. In allen Fällen global.

  • membership_name

    Der Name der GKE Enterprise-Clustermitgliedschaft.

Beispiel:

anthosCluster:
  membership: projects/cd-demo-01/locations/global/memberships/prod

Lassen Sie das Attribut anthosCluster weg, wenn Sie ein [mehreres Ziel] konfigurieren. Die Der GKE Enterprise-Cluster wird stattdessen im entsprechenden Cluster konfiguriert untergeordnetes Ziel.

Weitere Informationen zum Bereitstellen in GKE-Clustern finden Sie unter In Anthos-Nutzerclustern bereitstellen.

Für benutzerdefinierte Ziele

Die Konfiguration für benutzerdefinierte Ziele ähnelt der alle anderen Zieltypen, außer dass sie weder eine gke-Stanza noch eine Stanza run noch anthosCluster.

Stattdessen enthalten benutzerdefinierte Ziele eine customTarget-Stanza:

customTarget:
  customTargetType: [CUSTOM_TARGET_TYPE_NAME]

Dabei ist CUSTOM_TARGET_TYPE_NAME der Name, den Sie in den Definition des benutzerdefinierten Zieltyps.

Beispiel:

apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
  name: sample-env
customTarget:
  customTargetType: basic-custom-target

executionConfigs

Eine Reihe von Feldern zur Angabe einer nicht standardmäßigen Ausführungsumgebung für dieses Ziel.

  • usages

    Entweder RENDER oder DEPLOY oder beides sowie PREDEPLOY, VERIFY oder POSTDEPLOY, wenn die Bestätigung oder Bereitstellungshooks auf dem Ziel aktiviert sind. Diese geben an, welche dieser Vorgänge für dieses Ziel perform mit diesem der Ausführungsumgebung. Um anzugeben, dass eine benutzerdefinierte Ausführungsumgebung die für Pre-Deploy-Hooks, Rendering-, Bereitstellungs-, Post-Deploy-Hooks und -Prüfungen verwendet werden. würden Sie es so konfigurieren:

    usages:
- RENDER
- PREDEPLOY
- DEPLOY
- VERIFY
- POSTDEPLOY

    Wenn die Überprüfung in der Pipeline-Phase aktiviert ist und Sie in einer usages-Strophe keine VERIFY angeben, verwendet Cloud Deploy die Standardausführungsumgebung für die Überprüfung. Vor der Bereitstellung und Hooks nach der Bereitstellung funktionieren auf die gleiche Weise.

    Wenn jedoch eine benutzerdefinierte Ausführungsumgebung für RENDER und DEPLOY vorhanden ist, Sie müssen eine für VERIFY, PREDEPLOY oder POSTDEPLOY angeben, wenn in der Bereitstellungspipeline konfiguriert.VERIFY PREDEPLOY und POSTDEPLOY kann sich im selben usages wie RENDER oder DEPLOY oder in einem separaten usages befinden.

    Sie können usages.VERIFY, usages.PREDEPLOY oder usages.POSTDEPLOY nur angeben, wenn RENDER und DEPLOY in derselben oder in separaten benutzerdefinierten Ausführungsumgebungen angegeben sind.

  • workerPool

    Konfiguration für den zu verwendenden Worker-Pool. Dies dauert eine Ressourcenpfad, der den Cloud Build-Worker-Pool angibt, der für den Dienst verwendet werden soll für dieses Ziel. Beispiel:

    projects/p123/locations/us-central1/workerPools/wp123.

    So verwenden Sie den Cloud Build-Standardpool: diese Eigenschaft weg.

    Ein bestimmtes Ziel kann zwei workerPools haben (eine für RENDER und eine für DEPLOY. Beim Konfigurieren des Standardpools können Sie einen alternativen Pool angeben Dienstkonto und/oder Speicherstandort.

  • serviceAccount

    Der Name des Dienstkontos, das für diesen Vorgang verwendet werden soll (RENDER oder DEPLOY) für dieses Ziel.

  • artifactStorage

    Der Cloud Storage-Bucket, der für diesen Vorgang verwendet werden soll (RENDER oder DEPLOY) für dieses Ziel anstelle des Standard-Buckets.

  • executionTimeout

    Optional. Legt das Zeitlimit in Sekunden für Vorgänge fest, die von Cloud Build ausgeführt werden für Cloud Deploy ausgeführt wird. Standardmäßig ist dies 3600 Sekunden (1 Stunde).
    Beispiel: executionTimeout: "5000s"

  • verbose

    Optional. Wenn true, werden die Ausführlichkeitsstufen für Folgendes auf debug gesetzt: Tools:

    • Skaffold --verbosity ist auf debug festgelegt. Der Skaffold-Standardwert ist warn.

    • kubectl --v ist auf 4 gesetzt, was dem Debugging-Dienst entspricht. Der kubectl-Standardwert ist 2.

    • --verbosity der Google Cloud CLI ist festgelegt an debug. Der Standardwert ist warning.

Alternative unterstützte Syntax

Die in diesem Dokument beschriebene executionConfigs-Konfiguration ist neu. Die wird die bisherige Syntax weiterhin unterstützt:

executionConfigs:
- privatePool:
    workerPool:
    serviceAccount:
    artifactStorage:
  usages:
  - [RENDER | DEPLOY]
- defaultPool:
    serviceAccount:
    artifactStorage:
  usages:
  - [RENDER | DEPLOY]

Wenn Sie eine executionConfigs-Stanza für eine mehrere Ziele, jedes untergeordnete Ziel können diese Ausführungsumgebung übernehmen von diesem Multi-Ziel.

Definitionen benutzerdefinierter Zieltypen

In diesem Abschnitt werden die Felder beschrieben, mit denen benutzerdefinierten Zieltypen

Wie bei Standardzielen und automatisierten Abläufen können CustomTargetType-Definitionen in Ihrer Bereitstellungspipeline-Definition oder in separaten Dateien enthalten.

Die folgende YAML-Datei zeigt, wie ein benutzerdefinierter Zieltyp konfiguriert wird:

apiVersion: deploy.cloud.google.com/v1
kind: CustomTargetType
metadata:
  name: [CUSTOM_TARGET_TYPE_NAME]
  annotations:
  labels:
description:
customActions:
  renderAction: [RENDER_ACTION_NAME]
  deployAction: [DEPLOY_ACTION_NAME]
  includeSkaffoldModules:
    - configs:
    # either:
    googleCloudStorage:
      source:
      path:
    # or:
    git:
      repo:
      path:
      ref:

Wobei:

  • [CUSTOM_TARGET_TYPE_NAME]

    Dies ist ein beliebiger Name, den Sie dieser benutzerdefinierten Zieltypdefinition geben. Dieser Name wird in der Zieldefinition für ein beliebiges Ziel verwiesen für die der von Ihnen definierte benutzerdefinierte Zieltyp verwendet wird.

  • [RENDER_ACTION_NAME]

    Der Name der benutzerdefinierten Renderingaktion. Dieser Wert ist der customAction.name definiert in skaffold.yaml.

  • [DEPLOY_ACTION_NAME]

    Der Name der benutzerdefinierten Bereitstellungsaktion. Dieser Wert ist der customAction.name definiert in skaffold.yaml.

  • Informationen zu includeSkaffoldModules finden Sie unter Remote-Skaffold-Konfigurationen verwenden.

Automatisierungsdefinitionen

In diesem Abschnitt werden die Felder beschrieben, die zum Definieren von Cloud Deploy verwendet werden automation-Ressourcen.

Wie bei Zielen können Automation-Definitionen in die Lieferung aufgenommen werden oder in einer oder mehreren separaten Dateien.

Weitere Informationen zur Automatisierung in Cloud Deploy finden Sie in der Dokumentation zur Automatisierung.

Der folgende YAML-Code zeigt, wie eine Automatisierung konfiguriert wird. Die Details einer Automatisierungsregel unterscheiden sich je nach Regel. Die Konfiguration der verfügbaren Arten von Automatisierungsregeln finden Sie im Dokument Automatisierungsregeln verwenden.

apiVersion: deploy.cloud.google.com/v1
kind: Automation
metadata:
  name: [PIPELINE_NAME]/[PURPOSE]
  labels:
  annotations:
description: [DESCRIPTION]
suspended: true | false
serviceAccount: [SERVICE_ACCOUNT_ID]
selector:
  targets:
    -  id: [TARGET_ID]
       labels:
         [LABEL_KEY]:[LABEL_VALUE]

rules:
- [RULE_TYPE]:
    name:[RULE_NAME]
  [RULE-SPECIFIC_CONFIG]

Wobei:

  • [PIPELINE_NAME]

    Ist mit dem Wert metadata.name in der Bereitstellungspipeline identisch, die für diese Automatisierung. Alle Automatisierungen gelten ausschließlich für die Bereitstellungspipelines für die sie erstellt werden. Sie können eine Automatisierung also nicht für mehrere als eine Bereitstellungspipeline.

  • [PURPOSE]

    Gibt einen weiteren beschreibenden Namen für diese Automatisierung an. In der Regel was automatisiert wird. Beispiel: my-app-pipeline/promote.

  • labels und annotations sind beliebige Labels oder Anmerkungen, die Sie mit dieser Automatisierung verknüpfen.

  • [DESCRIPTION]

    Ist eine optionale Beschreibung für diese Automatisierung.

  • suspended

    true oder false: gibt an, ob diese Automatisierung aktiv oder gesperrt ist. Wenn true festgelegt ist, wird die Automatisierung nicht verwendet. Dies kann nützlich sein, Automatisierung testen, ohne die Bereitstellungspipeline zu beeinträchtigen.

  • [SERVICE_ACCOUNT_ID]

    Ist die ID des Dienstkontos, das zum Ausführen der automation Wenn die Automatisierung beispielsweise promoteReleaseRule verwendet, ist dies Dienstkonto das Release hochgestuft und erfordert daher die erforderlichen Berechtigungen eine Veröffentlichung hochzustufen.

    Für diese Property ist ein Wert erforderlich. Cloud Deploy verwendet für Automatisierungen nicht das Standarddienstkonto.

    Dieses Dienstkonto muss die folgenden Berechtigungen haben:

    • actAs-Berechtigung, um die Identität des Ausführungsdienstkontos zu übernehmen.

    • Berechtigung zum Ausführen der Vorgang wird automatisiert, z. B. clouddeploy.releases.promote, um Release hochstufen oder clouddeploy.rollouts.advance, um ein Roll-out voranzutreiben .

  • [TARGET_ID]

    Ist die ID des Ziels, für das diese Automatisierung verwendet wird. Obwohl ein an eine Bereitstellungspipeline gebunden ist, wird sie nur auf der angegebenen oder Ziele.

    Sie können diese Einstellung auf * festlegen, um alle Ziele in der Auslieferungspipeline auszuwählen.

  • [LABEL_KEY]:[LABEL_VALUE]

    Ist ein Schlüssel/Wert-Paar zum Abgleich mit einem auf dem Ziel definierten Schlüssel/Wert-Paar. Dadurch werden alle Ziele ausgewählt, die mit der Bereitstellungspipeline verknüpft sind und die mit demselben Label und Wert.

  • [RULE_TYPE]

    Der Name der Automatisierungsregel, die für diese Automatisierung verwendet wird. Dies ist entweder promoteReleaseRule oder advanceRolloutRule. Sie können auch mehrere in einer Automatisierung, einschließlich mehrerer gleicher RULE_TYPE-Regeln. So können Sie beispielsweise in einer Automatisierung mehrere promoteReleaseRule-Regeln haben. Weitere Informationen

  • [RULE_NAME]

    Ein Name für die Regel. Dieser Name muss innerhalb der Bereitstellungspipeline eindeutig sein. Für diese Property ist ein Wert erforderlich.

  • [RULE-SPECIFIC_CONFIG]

    Die Konfiguration ist für jeden unterstützten Automatisierungstyp unterschiedlich. Diese Konfigurationen werden in Automatisierungsregeln verwenden:

Nächste Schritte