Il file o i file di configurazione di Cloud Deploy definiscono pipeline di distribuzione, i target in cui eseguire il deployment l'avanzamento degli obiettivi.
Il file di configurazione della pipeline di distribuzione può includere
le definizioni del target o che possono essere in un file separato
. Per convenzione, un file contenente sia la configurazione della pipeline di distribuzione
la configurazione di destinazione si chiama clouddeploy.yaml
, mentre una configurazione della pipeline
target è delivery-pipeline.yaml
. Ma puoi assegnare a questi file qualsiasi
il nome che desideri.
Istruzioni
Cloud Deploy utilizza due file di configurazione principali:
- Definizione della pipeline di distribuzione
- Definizione del target
Possono essere file separati oppure la pipeline di distribuzione e i target possono configurate nello stesso file.
Struttura di un file di configurazione di una pipeline di distribuzione
La seguente configurazione include una definizione di destinazione:
# 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]
Questo YAML ha tre componenti principali:
La pipeline di distribuzione principale e la progressione
Il file di configurazione può includere un numero illimitato di definizioni di pipeline.
Definizioni dei target
Per semplicità, in questo esempio viene mostrato un solo target, ma può esserci qualsiasi numero di questi. Inoltre, le destinazioni possono essere definite in uno o più file separati.
Definizioni dei tipi di target personalizzati
Target personalizzati, richiedono un tipo di target personalizzato. definizione di Kubernetes. Come per i target e le automazioni, i tipi di target personalizzati possono essere definiti nello stesso file della pipeline di distribuzione o in un file separato.
Definizioni di Automation
Puoi creare qualsiasi automazione di deployment nello stesso come pipeline di distribuzione e target oppure in uno o più file separati. Per semplicità, qui viene mostrato un solo
Automation
, ma puoi creare come quanti ne vuoi.
Questi componenti sono definiti nel resto del documento.
Definizione e avanzamento della pipeline
Oltre ai metadati della pipeline, come name
, la definizione principale della pipeline
include un elenco di riferimenti ai target in
della sequenza di deployment. In altre parole, il primo target elencato è il primo
target del deployment. Dopo aver eseguito il deployment nel target, promuovere la release
per il deployment al target successivo nell'elenco.
Di seguito sono riportate le proprietà di configurazione per una pipeline di distribuzione, non incluse le definizioni dei target.
metadata.name
Il campo name
accetta una stringa che deve essere univoca per progetto e località.
metadata.annotations
e metadata.labels
La configurazione della pipeline di distribuzione può includere annotazioni ed etichette. Annotazioni vengono archiviate insieme alla risorsa della pipeline di distribuzione dopo la pipeline è stata registrata.
Per ulteriori informazioni, consulta Utilizzo di etichette e annotazioni con Cloud Deploy.
description
Una stringa arbitraria che descrive questa pipeline di distribuzione. Questa descrizione viene mostrata nei dettagli della pipeline di distribuzione nella console Google Cloud.
suspended
Un valore booleano, che se true
sospende la pipeline di distribuzione
in modo che non possa essere usato per creare, promuovere, eseguire il rollback o rieseguire il deployment delle release.
Inoltre, se la pipeline di distribuzione è sospesa, non puoi approvare o rifiutare un
un'implementazione creata da quella pipeline.
Il valore predefinito è false
.
serialPipeline
Inizio della definizione di una pipeline di distribuzione della progressione seriale. Questo la stanza è obbligatoria.
stages
Un elenco di tutti i target in cui è configurata la configurazione del deployment per questa pipeline di distribuzione.
L'elenco deve seguire l'ordine della sequenza di pubblicazione che preferisci. Ad esempio:
se hai target chiamati dev
, staging
e production
, elencali in
nello stesso ordine, quindi il primo deployment è in dev
e il deployment finale
è in production
.
Compila ogni campo stages.targetId
con il valore metadata.name
nella definizione della destinazione corrispondente. E in targetId
, includi
profiles
:
serialPipeline:
stages:
- targetId:
profiles: []
strategy:
standard:
verify:
targetId
Identifica il target specifico da utilizzare per questa fase della pipeline di distribuzione.
Il valore è la proprietà metadata.name
della definizione target.
strategy.standard.verify
impostata su true
attiva
verifica del deployment nella destinazione. In caso contrario
viene specificata la strategia di deployment, viene utilizzata la strategia di deployment standard
,
con verifica impostata su false
.
profiles
Prende un elenco di zero o più nomi di profilo Skaffold, da skaffold.yaml
.
Cloud Deploy utilizza il profilo con skaffold render
durante la creazione della release. I profili Skaffold ti consentono di variare la configurazione tra i target utilizzando un unico file di configurazione.
strategy
Include le proprietà per specificare una strategia di deployment. Le seguenti sono supportate:
standard:
Il deployment dell'applicazione viene eseguito completamente nella destinazione specificata.
Questa è la strategia di deployment predefinita. Se ometti
strategy
, Cloud Deploy utilizza la strategia di deploymentstandard
.canary:
In un deployment canary, il deployment progressivo di una nuova versione dell'applicazione, sostituendo per incrementi in percentuale (ad esempio, 25%, 50%, 75% e poi completamente).
La strategia di deployment viene definita in base al target. Ad esempio, potresti avere una
strategia canary per il target prod
, ma una strategia standard (non strategy
specificati) per gli altri target.
Per ulteriori informazioni, consulta Utilizzare una strategia di deployment.
Configurazione di strategy
Questa sezione mostra gli elementi di configurazione per strategy
, per ogni elemento supportato
runtime.
Strategia di deployment standard
La strategia standard include solo i seguenti elementi:
strategy:
standard:
verify: true|false
La proprietà verify
è facoltativa. Il valore predefinito è false
, il che significa che non verrà eseguita la fase di verifica per le implementazioni risultanti.
Puoi omettere l'elemento strategy
per una strategia di implementazione standard.
Strategia di deployment canary
Le seguenti sezioni descrivono la configurazione di un di deployment canary, a ogni runtime supportato da Cloud Deploy.
Per le destinazioni Cloud Run
strategy:
canary:
runtimeConfig:
cloudRun:
automaticTrafficControl: true | false
canaryDeployment:
percentages: [PERCENTAGES]
verify: true | false
Per le destinazioni GKE e GKE Enterprise
Il seguente YAML mostra come configurare una strategia di deployment per Target GKE o GKE Enterprise, utilizzando networking basato su servizi:
canary:
runtimeConfig:
kubernetes:
serviceNetworking:
service: "SERVICE_NAME"
deployment: "DEPLOYMENT_NAME"
disablePodOverprovisioning: true | false
canaryDeployment:
percentages: [PERCENTAGES]
verify: true | false
Il seguente YAML mostra come configurare una strategia di deployment per Target GKE o GKE Enterprise, utilizzando API Gateway:
canary:
runtimeConfig:
kubernetes:
gatewayServiceMesh:
httpRoute: "HTTP_ROUTE_NAME"
service: "SERVICE_NAME"
deployment: "DEPLOYMENT_NAME"
routeUpdateWaitTime: "WAIT_TIME"
canaryDeployment:
percentages: ["PERCENTAGES"]
verify: true | false
Nota in questo esempio
routeUpdateWaitTime
. Questo
è incluso perché l'API Gateway suddivide il traffico utilizzando una risorsa HTTPRoute
,
e a volte si verifica un ritardo nella propagazione delle modifiche apportate a HTTPRoute
. Nel
poiché il traffico viene inviato alle risorse,
le richieste di questo tipo possono essere ignorate,
che non sono disponibili. Puoi usare routeUpdateWaitTime
per causare
Cloud Deploy attende dopo l'applicazione di HTTPRoute
modifiche, se
osservare questo ritardo.
Il seguente YAML mostra come configurare una configurazione personalizzata
o custom-automated
la strategia di deployment canary. configurazione specifica per il runtime,
Sezione runtimeConfig
, omessa per la versione canary personalizzata, ma inclusa nella
una configurazione canary automatizzata
e personalizzata.
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
Operatore booleano facoltativo che indica se supportare o meno la verifica del deployment
per questo target. Il valore predefinito è false
.
Per abilitare la verifica del deployment è richiesta anche una stanza verify
in skaffold.yaml
. Se non fornisci questa proprietà, il job di verifica
errore.
deployParameters
Ti consente di specificare coppie chiave-valore per passare valori ai manifest per i target con corrispondenza delle etichette, quando utilizzi i parametri di implementazione.
Puoi includere questo indirizzo anche nei target.
I parametri di deployment impostati in una pipeline di distribuzione utilizzano le etichette per trovare corrispondenze con le destinazioni:
deployParameters:
- values:
someKey: "value1"
matchTargetLabels:
label1: firstLabel
- values:
someKey: "value2"
matchTargetLabels:
label2: secondLabel
In questo esempio, sono forniti due valori per la chiave e per ogni valore, esiste un'etichetta. Il valore viene applicato al manifest per qualsiasi target che ha un con l'etichetta corrispondente.
predeploy
e postdeploy
job
che ti consentono di fare riferimento ad azioni personalizzate.
(definite separatamente, nel
skaffold.yaml
) da eseguire prima del job di deployment (predeploy
) e dopo la verifica
job, se presente (postdeploy
). Se non esiste un job di verifica, il job post-deployment
viene eseguito dopo il job di deployment.
Gli hook di deployment sono configurati in strategy.standard
o
strategy.canary
come segue:
serialPipeline:
stages:
- targetId:
strategy:
standard:
predeploy:
actions: [ACTION_NAME]
postdeploy:
actions: [ACTION_NAME]
Dove ACTION_NAME è il nome configurato in skaffold.yaml
per
customActions.name
.
Puoi configurare predeploy
e postdeploy
job in qualsiasi strategia
(standard
, canary
, ad esempio).
Per saperne di più sulla configurazione e sull'uso degli hook pre e post-deployment, consulta Eseguire gli hook prima e dopo il deployment.
Definizioni dei target
Il file di definizione della pipeline di distribuzione può contenere definizioni della destinazione, specificare i target in un file separato. Puoi ripetere i nomi dei target all'interno di un progetto, ma devono essere univoci all'interno di una pipeline di importazione.
Puoi riutilizzare i target tra più pipeline di distribuzione. Tuttavia, puoi solo fare riferimento a una destinazione una sola volta dall'avanzamento di una singola pipeline di distribuzione.
Vedi anche: Definizioni dei tipi di target personalizzati
Per le destinazioni GKE
Il seguente YAML mostra come configurare una destinazione in un cluster GKE:
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
Il nome di questo target. Questo nome deve essere univoco a livello globale.
metadata.annotations
e metadata.labels
La configurazione di destinazione supporta annotazioni ed etichette Kubernetes. ma Cloud Deploy non li richiede.
Le annotazioni e le etichette vengono archiviate insieme alla risorsa di destinazione. Per ulteriori informazioni, consulta Utilizzo di etichette e annotazioni con Cloud Deploy.
description
Questo campo accetta una stringa arbitraria che descrive l'utilizzo del target.
deployParameters
Puoi includere parametri di deployment su qualsiasi destinazione, insieme ai valori. Questi valori vengono assegnati alle chiavi corrispondenti manifest dopo il rendering.
La stanza deployParameters
accetta coppie chiave-valore, come indicato di seguito:
deployParameters:
someKey: "someValue"
someOtherKey: "someOtherValue"
Se imposti i parametri di deployment su una multi-target, il valore viene assegnato a il manifest per tutte le variabili target secondari.
multiTarget.targetIds: []
Questa proprietà è facoltativa ed è utilizzata per configurare una multi-target da utilizzare per deployment parallelo.
Il valore è un elenco separato da virgole di target secondari.
I target secondari sono configurati come target normali e non includono questa proprietàmultiTarget
.
requireApproval
Indica se la promozione a questo target richiede l'approvazione manuale. Può essere true
o
false
.
Questa proprietà è facoltativa. Il valore predefinito è false
.
Quando configuri il deployment parallelo, puoi richiedere l'approvazione solo sui target multipli, non sui target secondari.
gke
Solo per i cluster GKE, il percorso della risorsa che identifica in cui verrà eseguito il deployment della tua applicazione:
gke:
cluster: projects/[project_name]/locations/[location]/clusters/[cluster_name]
project_name
Il progetto Google Cloud in cui si trova il cluster.
location
La località in cui si trova il cluster. Ad esempio,
us-central1
. Il cluster può anche essere a livello di zona (us-central1-c
).cluster_name
Il nome del cluster, così come appare nell'elenco dei cluster nella console Google Cloud.
Ecco un esempio:
gke:
cluster: projects/cd-demo-01/locations/us-central1/clusters/prod
Ometti la proprietà gke
quando configuri un target multiplo.
Il cluster GKE è configurato invece all'interno
target secondario.
Per le descrizioni, consulta executionConfigs
in questo articolo.
delle proprietà dell'ambiente di esecuzione.
internalIp
Indica se il cluster GKE specificato utilizza o meno una
Indirizzo IP. Questa proprietà è facoltativa. Per impostazione predefinita, Cloud Deploy utilizza
l'indirizzo IP disponibile pubblicamente per il cluster. Se è presente un IP privato
di destinazione e vuoi utilizzarlo, impostalo su true
.
proxyUrl
Se accedi ai cluster tramite proxy, fornisci proxyUrl
proprietà qui. Il valore è l'URL del tuo proxy GKE
cluster, ovvero
passato a kubectl
quando ti connetti al cluster.
Per le destinazioni Cloud Run
Il seguente codice YAML mostra come configurare una destinazione di deployment in un servizio Cloud Run:
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
Il nome di questo target. Questo nome deve essere univoco per regione.
metadata.annotations
e metadata.labels
La configurazione di destinazione supporta annotazioni ed etichette, ma Cloud Deploy non li richiede.
Le annotazioni e le etichette vengono archiviate insieme alla risorsa di destinazione. Per ulteriori informazioni, consulta Utilizzo di etichette e annotazioni con Cloud Deploy.
description
Questo campo accetta una stringa arbitraria che descrive l'utilizzo del target.
multiTarget.targetIds: []
Questa proprietà è facoltativa ed è utilizzata per configurare una multi-target da utilizzare per deployment parallelo.
Il valore è un elenco separato da virgole di target secondari.
I target secondari sono configurati come target normali e non includono questi
multiTarget
proprietà.
requireApproval
Indica se la promozione a questo target richiede l'approvazione manuale. Può essere true
o
false
.
Questa proprietà è facoltativa. Il valore predefinito è false
.
Quando configuri il deployment parallelo, puoi richiedere l'approvazione solo sui target multipli, non sui target secondari.
run
Solo per i servizi Cloud Run, la località in cui si trova verranno create:
run:
location: projects/[project_name]/locations/[location]
project_name
Il progetto Google Cloud in cui si troverà il servizio.
location
La località in cui si trova il servizio. Ad esempio,
us-central1
.
Ometti la proprietà run
quando configuri un attributo [multi-target]. La posizione
Il servizio Cloud Run è configurato invece all'interno
target secondario corrispondente.
Per le descrizioni, consulta executionConfigs
in questo articolo.
delle proprietà dell'ambiente di esecuzione.
Per i target di GKE Enterprise
Configurazione di destinazione per
il deployment in un cluster GKE è simile
configurando una destinazione per un target GKE,
tranne per il fatto che la proprietà è anthosCluster.membership
, anziché gke.cluster
,
il percorso della risorsa è diverso e internalIp
non è applicabile.
anthosCluster:
membership: projects/[project_name]/locations/global/memberships/[membership_name]
project_name
Il progetto Google Cloud in cui si trova il cluster GKE Enterprise.
/location/global/
La località in cui è registrato il cluster.
global
in tutti i casi.membership_name
Il nome dell'appartenenza al cluster GKE Enterprise.
Ecco un esempio:
anthosCluster:
membership: projects/cd-demo-01/locations/global/memberships/prod
Ometti la proprietà anthosCluster
quando configuri un attributo [multi-target]. La
Il cluster GKE Enterprise è configurato invece all'interno del cluster
target secondario.
Per ulteriori informazioni sul deployment nei cluster GKE, consulta Deployment nei cluster utente Anthos.
Per target personalizzati
La configurazione dei target personalizzati è simile a:
tutti gli altri tipi di targeting, ad eccezione del fatto che non include una stanza gke
, né un
run
stanza, né anthosCluster
stanza.
I target personalizzati includono invece una stanza customTarget
:
customTarget:
customTargetType: [CUSTOM_TARGET_TYPE_NAME]
Dove CUSTOM_TARGET_TYPE_NAME
è il nome utilizzato nel
definizione del tipo di target personalizzato.
Ecco un esempio:
apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
name: sample-env
customTarget:
customTargetType: basic-custom-target
executionConfigs
Un insieme di campi per specificare un ambiente di esecuzione non predefinito per questo target.
usages
RENDER
oDEPLOY
o entrambi, piùPREDEPLOY
,VERIFY
oppurePOSTDEPLOY
se verifica o gli hook di deployment sono abilitati nella destinazione. che indicano quale di queste operazioni perform per questo target utilizzando questa dell'ambiente di esecuzione. Per indicare che un ambiente di esecuzione personalizzato essere utilizzato per l'hook pre-deployment, il rendering, il deployment, l'hook post-deployment e la verifica, devi configurarlo nel seguente modo:usages: - RENDER - PREDEPLOY - DEPLOY - VERIFY - POSTDEPLOY
Se la verifica è abilitata nella fase della pipeline, e non specifichi
VERIFY
in una stanzausages
, Cloud Deploy utilizza l'ambiente di esecuzione predefinito per la verifica. Pre-deployment gli hook post-deployment funzionano allo stesso modo.Tuttavia, se esiste un ambiente di esecuzione personalizzato per
RENDER
eDEPLOY
, devi specificarne uno perVERIFY
,PREDEPLOY
OPOSTDEPLOY
se sono nella pipeline di distribuzione.VERIFY
,PREDEPLOY
ePOSTDEPLOY
può essere nello stessousages
diRENDER
oDEPLOY
oppure inusages
separati.Non puoi specificare
usages.VERIFY
,usages.PREDEPLOY
ousages.POSTDEPLOY
a meno cheRENDER
eDEPLOY
non vengano specificati nella stessa riga ambienti di esecuzione.workerPool
Configurazione da utilizzare per il pool di worker. Questa operazione richiede percorso della risorsa che identifica il pool di worker di Cloud Build da utilizzare questo target. Ad esempio:
projects/p123/locations/us-central1/workerPools/wp123
.Per utilizzare il pool di Cloud Build predefinito, ometti questa proprietà.
Un determinato target può avere due
workerPool
(uno perRENDER
e uno perDEPLOY
). Quando configuri il pool predefinito, puoi specificare un account di servizio, posizione di archiviazione o entrambi.serviceAccount
Il nome dell'account di servizio da utilizzare per questa operazione (
RENDER
oDEPLOY
) per questo target.artifactStorage
Il bucket Cloud Storage da utilizzare per questa operazione (
RENDER
oDEPLOY
) per questo target, anziché il bucket predefinito.executionTimeout
Facoltativo. Imposta il timeout, in secondi, per le operazioni che Cloud Build per Cloud Deploy. Per impostazione predefinita, sono
3600
secondi (1 ora).
Esempio:executionTimeout: "5000s"
verbose
Facoltativo. Se
true
, i livelli di dettaglio sono impostati sudebug
per quanto segue strumenti:Skaffold
--verbosity
è impostato sudebug
. Il valore predefinito di Skaffold èwarn
.kubectl
--v
è impostato su4
, che è il debug. Il valore predefinito di kubectl è2
.Google Cloud CLI
--verbosity
è impostato sudebug
. Il valore predefinito èwarning
.
Sintassi alternativa supportata
La configurazione di executionConfigs
descritta in questo documento è nuova. La
la sintassi precedente è ancora supportata:
executionConfigs:
- privatePool:
workerPool:
serviceAccount:
artifactStorage:
usages:
- [RENDER | DEPLOY]
- defaultPool:
serviceAccount:
artifactStorage:
usages:
- [RENDER | DEPLOY]
Quando configuri una stanza executionConfigs
per un
multitarget, ogni target secondario
può ereditare l'ambiente di esecuzione
da quel target multiplo.
Definizioni dei tipi di target personalizzati
Questa sezione descrive i campi utilizzati per definire tipi di target personalizzati
Come per i target e le automazioni standard, le definizioni di CustomTargetType
possono essere
incluso nella definizione della pipeline di distribuzione o in uno o più file separati.
Il seguente codice YAML mostra come configurare un tipo di target personalizzato:
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:
Dove:
[CUSTOM_TARGET_TYPE_NAME]
È un nome arbitrario assegnato a questa definizione del tipo di target personalizzato. Questo nome viene fatto riferimento nella definizione del target per qualsiasi che utilizza il tipo di targeting personalizzato che definisci.
[RENDER_ACTION_NAME]
Indica il nome dell'azione di rendering personalizzato. Questo valore è il
customAction.name
definita inskaffold.yaml
.[DEPLOY_ACTION_NAME]
È il nome dell'azione di deployment personalizzato. Questo valore è il
customAction.name
definita inskaffold.yaml
.Per
includeSkaffoldModules
, vedi Utilizza configurazioni Skaffold remote.
Definizioni di Automation
Questa sezione descrive i campi utilizzati per definire i deployment di Cloud Deploy di automazione.
Come per i target, puoi includere Automation
definizioni nella consegna
definizione della pipeline, oppure in uno o più file separati.
Per saperne di più sull'automazione in Cloud Deploy, consulta documentazione sull'automazione.
Il seguente YAML mostra come configurare un'automazione. Tieni presente che le specifiche di una regola di automazione sono diverse a seconda della regola. (configurazione per tipi di regole di automazione sono nel documento Utilizzo delle regole di automazione.)
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]
Dove:
[PIPELINE_NAME]
È uguale al valore
metadata.name
nella pipeline di distribuzione che utilizza questa automazione. Tutte le automazioni sono esclusive delle pipeline di distribuzione con cui vengono create. Ciò significa che non puoi condividere un'automazione tra di una pipeline di distribuzione.[PURPOSE]
Un altro nome descrittivo per questa automazione. In genere si tratta di l'azione automatizzata. Ad esempio,
my-app-pipeline/promote
.labels
eannotations
sono etichette o annotazioni che vuoi associare a questa automazione.[DESCRIPTION]
È una descrizione facoltativa per questa automazione.
suspended
true
ofalse
, che indica se l'automazione è attiva o sospesa. Se impostato sutrue
, l'automazione non viene utilizzata. Questo può essere utile per testare un'automazione senza influire sulla pipeline di distribuzione.[SERVICE_ACCOUNT_ID]
L'ID dell'account di servizio utilizzato per eseguire la l'automazione. Ad esempio, se l'automazione utilizza
promoteReleaseRule
, questo l'account di servizio esegue la promozione della release e quindi richiede autorizzazioni necessarie per promuovere un'uscita.È richiesto un valore per questa proprietà. Cloud Deploy non utilizza L'account di servizio predefinito per le automazioni.
Questo account di servizio deve avere le seguenti autorizzazioni:
Autorizzazione
actAs
per impersonare l'account di servizio di esecuzione.l'autorizzazione per eseguire l'operazione automatica, ad esempio
clouddeploy.releases.promote
promuovere una release oclouddeploy.rollouts.advance
per far avanzare un'implementazione durante la fase di sviluppo.
[TARGET_ID]
È l'ID del target per cui viene utilizzata l'automazione. Sebbene l'automazione è collegata a una pipeline di distribuzione, viene eseguita solo target o target.
Puoi impostarlo su
*
per selezionare tutti i target nella pipeline di distribuzione.[LABEL_KEY]:[LABEL_VALUE]
È una coppia chiave-valore da abbinare a una coppia chiave-valore definita nel target. Seleziona tutti i target associati alla pipeline di distribuzione con la stessa etichetta e lo stesso valore.
[RULE_TYPE]
È il nome della regola di automazione utilizzata per questa automazione. Questo è
promoteReleaseRule
oadvanceRolloutRule
. Puoi includere più di una in un'automazione, includendo più di uno degli stessiRULE_TYPE
. Per ad esempio, puoi avere più di una regolapromoteReleaseRule
nello stesso e l'automazione degli annunci. Scopri di più.[RULE_NAME]
Un nome per la regola. Questo nome deve essere univoco all'interno della pipeline di distribuzione. È richiesto un valore per questa proprietà.
[RULE-SPECIFIC_CONFIG]
La configurazione è diversa per ogni tipo di automazione supportato. Quelli le configurazioni sono mostrate in Utilizzo delle regole di automazione.
Passaggi successivi
Scopri di più su come funziona Cloud Deploy.
Scopri come configurare una pipeline di distribuzione per la tua applicazione.
Scopri come gestire i manifest.
Evita le mancate corrispondenze tra la tua release e la tua pipeline di distribuzione imparando sulle istanze della pipeline.