Este documento descreve como executar programas ou operações arbitrárias antes e/ou após a implantação.
É possível configurar o Cloud Deploy e o Skaffold para executar ações para realizar ações de pré-implantação ou ações pós-implantação ou ambas. Esses programas, executados dessa forma, são chamados "ganchos". Os hooks de pré e pós-implantação são executados como jobs de pré e pós-implantação no lançamento.
É possível configurar cada hook para ser executado em um ambiente de execução do Cloud Deploy especificado, mas, se você estiver implantando no Google Kubernetes Engine, poderá configurar o hook para ser executado no cluster do GKE em que você está implantando o aplicativo.
Os hooks de implantação são considerados idempotentes. Se uma ação for executada mais de uma vez, não haverá efeito extra.
Como os hooks de implantação funcionam?
Veja a seguir as etapas para configurar hooks de implantação e as Processo do Skaffold e do Cloud Deploy para executar esses hooks:
Você configura o
skaffold.yaml
usado para uma determinada versão para incluircustomActions
que identificam a imagem ou as imagens do contêiner a serem usadas para executar os hooks e o comando ou script específico a ser executado em cada contêiner.Você configura os hooks em um ou mais estágios da progressão do pipeline de envio, cada um deles faz referência a um dos
customActions
configurados emskaffold.yaml
.Antes da execução do job de implantação do lançamento, o Skaffold executa todos os comandos configurados em
skaffold.yaml
, que são referenciadas em uma estrofepredeploy
no pipeline. progressão.O gancho
predeploy
sempre é executado como o primeiro job na fase.Depois que o job de implantação do lançamento for executado, o Cloud Deploy vai executar comandos configurados em
skaffold.yaml
que são referenciados em umpostdeploy
. estrofe na progressão do pipeline.
Os hooks de implantação são executados na execução padrão do Cloud Deploy ou em um ambiente de execução alternativo especificado. Para implantações ao GKE e ao GKE Enterprise, é possível executar os ganchos no mesmo cluster onde o aplicativo está sendo implantado.
Como usar hooks de implantação com uma implantação canário
Ao configurar os hooks de implantação para uma implantação canário, há várias coisas a serem consideradas:
No estágio do pipeline de entrega, a configuração do hook (
predeploy
epostdeploy
) está emstrategy.canary.canaryDeployment
oustrategy.canary.customCanaryDeployment.phaseConfigs
, em vez destrategy.standard
.Para um canário automatizado, os hooks
predeploy
são executados antes da implantação em somente na primeira fase, e os hookspostdeploy
são executados após a implantação apenas a última fase (estável).
Configurar ações no Skaffold
No arquivo skaffold.yaml
, a estrofe customActions
usa uma ou mais
estrofes customActions
, configuradas
da seguinte maneira:
customActions
- name: ACTION_NAME
containers:
- name: CONTAINER_NAME
image: IMAGE
command: [COMMANDS_TO_RUN]
args: [LIST_OF_ARGS]
Nesta estrofe de customerActions
:
ACTION_NAME
É um nome para essa ação. Esse nome pode ser o que você quiser, mas deve ser exclusivo nesse
skaffold.yaml
. Esse é o nome que será referenciado das ações pré e pós-implantação definido na etapa do pipeline de entrega.CONTAINER_NAME
É um nome para o contêiner específico. Esse nome pode ser qualquer coisa, mas precisa ser exclusivo neste
skaffold.yaml
.IMAGE
É o nome da imagem do contêiner em que seu comando será executado.
COMMANDS_TO_RUN
É uma lista de pontos de entrada a serem executados nesse contêiner.
"/bin/sh"
é um comando típico para especificar aqui, para invocar um shell. Inclua o comando a ser executado nesse shell nos argumentos.LIST_OF_ARGS
É uma lista de argumentos para fornecer ao comando. Essa é uma lista separada por vírgulas, com cada argumento entre aspas. Se o COMMAND_TO_RUN for
"/bin/sh"
, um dos argumentos aqui seria"-c"
e outro seria todo o comando que você quer executar no shell invocando.Veja um exemplo:
command: ["/bin/sh"] args: ["-c", `echo "This command ran!"`]
Para saber mais sobre as ações personalizadas do Skaffold, consulte a documentação do Skaffold.
Configurar o pipeline para referenciar as ações
Para configurar os hooks de implantação,
configure o pipeline de entrega para referenciar as ações personalizadas definidas
no arquivo skaffold.yaml
. As ações pré e pós-implantação são configuradas em uma
ou etapas mais específicas no pipeline
progressão.
Confira a seguir como configurar os hooks de pré-implantação e pós-implantação em um estágio
do pipeline ao usar uma estratégia de implantação standard
:
serialPipeline:
stages:
- targetId: hooks-staging
profiles: []
strategy:
standard:
predeploy:
actions: ["PREDEPLOY-ACTION"]
postdeploy:
actions: ["POSTDEPLOY-ACTION"]
Neste yaml:
PREDEPLOY_ACTION
É o mesmo que o ACTION_NAME usado no
skaffold.yaml
para definir a ação personalizada que você quer executar antes da implantação.POSTDEPLOY_ACTION
É o mesmo que o ACTION_NAME usado no
skaffold.yaml
para definir a ação personalizada que você quer executar após a implantação.
É possível especificar mais de uma ação para predeploy
e postdeploy
, separadas
por vírgulas. Quando mais de uma ação é especificada, elas são executadas em série, na
ordem em que são especificadas. O job (pré-implantação ou pós-implantação) falha na primeira
ação que falha, e as demais ações não são executadas.
Por padrão, se você estiver executando mais de um contêiner em paralelo e um job falhar, ambos os contêineres serão interrompidos. É possível configurar esse comportamento usando a estratégia de falha de ação personalizada do Skaffold.
Executar os hooks no cluster de aplicativos
Por padrão, os hooks de implantação são executados no
ambiente de execução. Também é possível
configurar o Skaffold para executar essas ações personalizadas no mesmo cluster em que o
aplicativo está sendo executado. Quando você
configura ações personalizadas em skaffold.yaml
e as
ativa em um estágio do pipeline, a ação é executada
automaticamente no cluster do destino.
Esse recurso está disponível para implantações no GKE e Apenas no GKE Enterprise, não para o Cloud Run. Implantações para O Cloud Run só pode executar hooks no bucket ou ambiente de execução.
Para executar o hook no cluster, inclua uma estrofe executionMode.kubernetesCluster
no arquivo de configuração skaffold.yaml
, dentro da estrofe customActions
para a ação personalizada específica:
customActions
- name: ACTION_NAME
containers:
- name: CONTAINER_NAME
image: IMAGE
command: [COMMANDS_TO_RUN]
args: [LIST_OF_ARGS]
executionMode:
kubernetesCluster: {}
Confira a seguir um exemplo de estrofe customActions
que inclui executionMode
para invocar o contêiner de gancho no cluster de aplicativos:
customActions:
- name: predeploy-action
containers:
- name: predeploy-echo
image: ubuntu
command: ["/bin/sh"]
args: ["-c", 'echo "this is a predeploy action"' ]
executionMode:
kubernetesCluster: {}
A estrofe executionMode
é opcional e, se você omiti-la, o Skaffold executa a
contêiner de ações personalizadas no ambiente de execução do Cloud Deploy.
Variáveis de ambiente disponíveis
O Cloud Deploy fornece e preenche o seguinte ambiente variáveis no ambiente de execução que você pode usar para os ganchos:
ANTHOS_MEMBERSHIP
Para destinos do tipo
ANTHOS
, o nome do recurso totalmente especificado da associação do Anthos.CLOUD_RUN_LOCATION
Para destinos do tipo
RUN
, a região em que o serviço do Cloud Run é implantado.CLOUD_RUN_PROJECT
Para destinos do tipo
RUN
, o projeto em que o serviço do Cloud Run foi criado.CLOUD_RUN_SERVICE
Para destinos do tipo
RUN
, o nome do serviço do Cloud Run implantado.CLOUD_RUN_SERVICE_URLS
Para destinos do tipo
RUN
, os URLs (lista separada por vírgulas) que terminam que os usuários usarão para acessar seu serviço. Eles estão disponíveis nos detalhes do serviço do Cloud Run no console do Google Cloud.CLOUD_RUN_REVISION
Para metas do tipo
RUN
, a revisão específica do serviço do Cloud Run.GKE_CLUSTER
Para destinos do tipo
GKE
, o nome de recurso totalmente especificado do Cluster do Google Kubernetes Engine, por exemplo,projects/p/locations/us-central1/clusters/dev
.TARGET_TYPE
O tipo de ambiente de execução específico do destino.
GKE
,ANTHOS
ouRUN
. No caso de segmentações personalizadas, isso não será definido.CLOUD_DEPLOY_LOCATION
A região que contém os recursos do Cloud Deploy.
CLOUD_DEPLOY_DELIVERY_PIPELINE
O ID do pipeline de entrega.
CLOUD_DEPLOY_TARGET
O ID do destino.
CLOUD_DEPLOY_PROJECT
O projeto do Google Cloud que contém os recursos do Cloud Deploy.
CLOUD_DEPLOY_RELEASE
O ID da versão em que os hooks serão executados.
CLOUD_DEPLOY_ROLLOUT
O ID do lançamento que contém os jobs para os ganchos.
CLOUD_DEPLOY_JOB_RUN
O ID da execução do job que representa a execução atual do job.
CLOUD_DEPLOY_PHASE
A fase no lançamento que contém o job para os hooks.
Implantar parâmetros como variáveis de ambiente
Além das variáveis de ambiente listadas nesta seção, o Cloud Deploy pode transmitir aos contêineres personalizados todos os parâmetros de implantação definidos.
A seguir
Teste o guia de início rápido: executar hooks antes e depois da implantação.
Saiba mais sobre o Skaffold.