Neste documento, descrevemos como executar programas ou operações arbitrárias antes e/ou depois da implantação.
É possível configurar o Cloud Deploy e o Skaffold para executar ações para executar ações pré-implantação, ações pós-implantação ou ambas. Esses programas, executados dessa forma, são chamados de "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 especificado do Cloud Deploy, mas, se você estiver implantando no Google Kubernetes Engine, será possível configurá-lo 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 determinada ação for executada mais de uma vez, não haverá efeito adicional.
Como os ganchos de implantação funcionam?
Veja a seguir as etapas para configurar hooks de implantação e o processo do Skaffold e do Cloud Deploy para executar esses hooks:
Configure o
skaffold.yaml
usado em uma determinada versão para incluircustomActions
, que identificam as imagens de 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 hooks em um ou mais estágios na progressão do pipeline de entrega, cada um dos quais referencia 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 referenciados em uma estrofepredeploy
na progressão do pipeline.O hook
predeploy
sempre é executado como o primeiro job na fase.Após a execução do job de implantação do lançamento, o Cloud Deploy executa todos os comandos configurados em
skaffold.yaml
que são referenciados em uma estrofepostdeploy
na progressão do pipeline.
Os hooks de implantação são executados no ambiente de execução padrão do Cloud Deploy ou em um ambiente de execução alternativo especificado. Para implantações no GKE e no GKE Enterprise, é possível executar os hooks no mesmo cluster em que o aplicativo está sendo implantado.
Como usar hooks de implantação com uma implantação canário
Ao configurar hooks de implantação para uma implantação canário, há várias informações que você precisa saber:
No estágio do pipeline de entrega, a configuração do hook (
predeploy
epostdeploy
) está emstrategy.canary.canaryDeployment
oustrategy.canary.customCanaryDeployment.phaseConfigs
, e não emstrategy.standard
.Para um canário automatizado, os hooks
predeploy
são executados antes da implantação apenas na primeira fase, e os hookspostdeploy
são executados apenas após a implantação na última fase (estável).
Configurar ações no Skaffold
No arquivo skaffold.yaml
, a estrofe customActions
toma 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 a ação. Esse nome pode ser o que você quiser, mas precisa ser exclusivo dentro de
skaffold.yaml
. Esse é o nome que será referenciado nas ações pré e pós-implantação definidas no estágio do pipeline de entrega.CONTAINER_NAME
É o nome do contêiner específico. Esse nome pode ser o que você quiser, mas precisa ser exclusivo no
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 para executar nesse contêiner.
"/bin/sh"
é um comando típico para especificar aqui, para invocar um shell. Você inclui o comando a ser executado nesse shell nos argumentos.LIST_OF_ARGS
É uma lista de argumentos a serem fornecidos ao comando. Esta é uma lista separada por vírgulas, com cada argumento entre aspas. Se COMMAND_TO_RUN for
"/bin/sh"
, um dos argumentos aqui será"-c"
e outro argumento será o comando inteiro que você quer executar no shell que está invocando.Veja um exemplo:
command: ["/bin/sh"] args: ["-c", `echo "This command ran!"`]
Consulte a documentação do Skaffold para saber mais sobre as ações personalizadas dele.
Configurar o pipeline para fazer referência às ações
Para concluir a configuração dos hooks de implantação, configure o pipeline de entrega para fazer referência às ações personalizadas definidas no arquivo skaffold.yaml
. As ações pré e pós-implantação são configuradas em um ou mais estágios específicos na progressão do pipeline.
Veja a seguir como configurar hooks de pré e pós-implantação em um estágio de 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 em
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 em
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 foram especificadas. O job (pré-implantação ou pós-implantação) falha na primeira ação que falhar, e as ações restantes não serão executadas.
Por padrão, se você estiver executando mais de um contêiner, em paralelo, e um job falhar, os dois 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 do aplicativo
Por padrão, os hooks de implantação são executados no ambiente de execução do Cloud Deploy. Também é possível configurar o Skaffold para executar essas ações personalizadas no mesmo cluster em que seu aplicativo está sendo executado. Quando você configura ações personalizadas no skaffold.yaml
e as ativa em um estágio de pipeline, a ação é executada automaticamente no cluster de destino.
Esse recurso está disponível apenas para implantações no GKE e no GKE Enterprise, não para o Cloud Run. As implantações no Cloud Run só podem executar hooks no ambiente de execução do Cloud Deploy.
Para executar o hook no cluster, inclua uma estrofe executionMode.kubernetesCluster
no arquivo de configuração skaffold.yaml
, dentro da estrofe customActions
da 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 do aplicativo:
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 executará o 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 as seguintes variáveis de ambiente no ambiente de execução, que você pode usar para os hooks:
ANTHOS_MEMBERSHIP
Para destinos do tipo
ANTHOS
, o nome de recurso totalmente especificado da assinatura 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
No caso de destinos do tipo
RUN
, são os URLs (lista separada por vírgulas) que os usuários finais vão usar para acessar o serviço. É possível encontrá-las nos detalhes do serviço do Cloud Run para seu serviço, no console do Google Cloud.CLOUD_RUN_REVISION
Para destinos 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 específico de ambiente de execução do destino.
GKE
,ANTHOS
ouRUN
. No caso de segmentações personalizadas, ele 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 hooks.
CLOUD_DEPLOY_JOB_RUN
O ID de execução do job que representa a execução atual dele.
CLOUD_DEPLOY_PHASE
A fase no lançamento que contém o job para os ganchos.
A seguir
Teste o guia de início rápido: executar hooks antes e depois da implantação.
Saiba mais sobre o Skaffold.