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:
- Definition der Bereitstellungspipeline
- Zieldefinition
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 benutzerdefinierter 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. Der Einfachheit halber wird hier nur eine
Automation
angezeigt. Sie können sie aber auch als wie Sie möchten.
Diese Komponenten werden im Rest dieses Dokuments definiert.
Pipelinedefinition und -fortschritt
Zusätzlich zu den Pipeline-Metadaten wie name
ist die Hauptpipeline-Definition
enthält eine Liste mit Verweisen auf Ziele in
Sequenzreihenfolge der Bereitstellung festlegen. 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 für 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
Einen booleschen Wert, der den Fall, dass true
die Bereitstellungspipeline anhält
sodass sie nicht zum Erstellen, Hochstufen, Rollback oder zum erneuten Bereitstellen von Releases verwendet 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.
Füllen Sie jedes stages.targetId
-Feld mit dem Wert von metadata.name
.
in der entsprechenden Zieldefinition. 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
Erstellt eine Liste mit null oder mehr Skaffold-Profilnamen aus skaffold.yaml
.
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 werden folgende Strategien unterstützt:
standard:
Die Anwendung wird vollständig auf dem angegebenen Ziel bereitgestellt.
Dies ist die standardmäßige Bereitstellungsstrategie. Wenn Sie
strategy
weglassen, gilt Folgendes: Cloud Deploy verwendet die Bereitstellungsstrategiestandard
.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 können Anfragen
abfallen, da der Traffic an Ressourcen
die nicht verfügbar sind. Sie können routeUpdateWaitTime
verwenden, um
Cloud Deploy wartet nach dem Anwenden von HTTPRoute
-Änderungen, wenn Sie
diese Verzögerung zu berücksichtigen.
Im folgenden YAML-Code sehen Sie, wie ein benutzerdefinierter
oder benutzerdefiniert automatisiert
Canary-Bereitstellungsstrategie. Laufzeitspezifische Konfiguration im
Der Abschnitt runtimeConfig
wurde bei der benutzerdefinierten Canary-Version weggelassen, ist aber enthalten in
automatisierte und benutzerdefinierte
automatische Canary-Konfiguration.
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 bereit, die in einer Bereitstellungspipeline festgelegt wurden, um Ziele mithilfe von Labels 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 übereinstimmendes Label.
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.
Siehe auch: Definitionen benutzerdefinierter Zieltypen
Für GKE-Ziele
Die folgende YAML-Datei zeigt, wie ein Ziel konfiguriert wird, in einem GKE-Cluster bereitstellt:
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 den entsprechenden Schlüsseln in Ihrem Manifests nach dem Rendern.
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: []
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
.
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
untergeordnetes Ziel.
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 die proxyUrl
an.
Property hier. 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 einer 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
.
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
weg, wenn Sie ein [mehreres Ziel] konfigurieren. 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
oderDEPLOY
oder beide, plusPREDEPLOY
,VERIFY
oderPOSTDEPLOY
, wenn Bestätigung oder Bereitstellungs-Hooks sind für das Ziel aktiviert. Diese geben an, welche dieser Vorgänge für dieses Ziel leistung 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 Pipelinephase aktiviert ist, und Sie
VERIFY
nicht in einerusages
-Stanza angeben, wird Cloud Deploy verwendet die standardmäßige Ausführungsumgebung zur Überprüfung. Vor der Bereitstellung und Hooks nach der Bereitstellung funktionieren auf die gleiche Weise.Wenn jedoch eine benutzerdefinierte Ausführungsumgebung für
RENDER
undDEPLOY
vorhanden ist, Sie müssen eine fürVERIFY
,PREDEPLOY
oderPOSTDEPLOY
angeben, wenn in der Bereitstellungspipeline konfiguriert.VERIFY
PREDEPLOY
undPOSTDEPLOY
kann sich im selbenusages
wieRENDER
oderDEPLOY
oder in einem separatenusages
befinden.Sie können nicht
usages.VERIFY
,usages.PREDEPLOY
oderusages.POSTDEPLOY
angeben es sei denn,RENDER
undDEPLOY
sind im selben oder in separaten benutzerdefinierten Ausführungsumgebungen.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
workerPool
s haben (eine fürRENDER
und eine fürDEPLOY
. 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
oderDEPLOY
) für dieses Ziel.artifactStorage
Der Cloud Storage-Bucket, der für diesen Vorgang verwendet werden soll (
RENDER
oderDEPLOY
) 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 sind das
3600
Sekunden (1 Stunde).
Beispiel:executionTimeout: "5000s"
verbose
Optional. Wenn
true
, werden die Ausführlichkeitsstufen für Folgendes aufdebug
gesetzt: Tools:Skaffold
--verbosity
ist aufdebug
festgelegt. Der Skaffold-Standardwert istwarn
.kubectl
--v
ist auf4
gesetzt, was dem Debug-Dienst entspricht. Der kubectl-Standardwert ist2
.--verbosity
der Google Cloud CLI ist festgelegt andebug
. Der Standardwert istwarning
.
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 inskaffold.yaml
.[DEPLOY_ACTION_NAME]
Der Name der benutzerdefinierten Bereitstellungsaktion. Dieser Wert ist der
customAction.name
definiert inskaffold.yaml
.Für
includeSkaffoldModules
siehe 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 Besonderheiten einer Automatisierungsregel unterscheiden sich je nach Regel. (Konfiguration für die Regeltypen für Automatisierung sind 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
undannotations
sind beliebige Labels oder Anmerkungen, die Sie mit dieser Automatisierung verknüpfen.[DESCRIPTION]
Ist eine optionale Beschreibung für diese Automatisierung.
suspended
true
oderfalse
: gibt an, ob diese Automatisierung aktiv oder gesperrt ist. Wenntrue
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 keine das Standarddienstkonto für Automatisierungen.
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 oderclouddeploy.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 diesen Wert auf
*
festlegen, um alle Ziele in der Bereitstellungspipeline 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
oderadvanceRolloutRule
. Sie können auch mehrere in einer Automatisierung, einschließlich mehrerer gleicherRULE_TYPE
-Regeln. Für Beispiel: Sie können mehrerepromoteReleaseRule
-Regeln in derselben Automatisierung. 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
Weitere Informationen zum Einrichten einer Lieferpipeline für Ihre Anwendung.
Erfahren Sie, wie Sie Manifeste verwalten.
Vermeiden Sie Nichtübereinstimmungen zwischen Ihrem Release und Ihrer Lieferpipeline. Dazu können sollten Sie mehr über Pipelineinstanzen erfahren.