Nesta página, descrevemos como usar o Cloud Deploy para colocar seu aplicativo nos ambientes de execução de destino pretendidos. Antes de fazer isso, crie o pipeline de entrega e os destinos.
Antes de começar
Nesta seção, descrevemos o que você precisa ter antes de implantar seu aplicativo usando o Cloud Deploy.
Verifique se a conta de serviço de execução tem os papéis e permissões do IAM necessários.
Crie o pipeline e os destinos de entrega.
O Cloud Deploy pode ser implantado nos clusters do Google Kubernetes Engine, do Cloud Run e do GKE Enterprise. A configuração de destino varia dependendo de qual deles você está implantando.
As imagens de contêiner e os manifestos
Você precisa de uma ou mais imagens de contêiner para implantar e um ou mais manifestos do Kubernetes (para implantar no GKE) ou arquivos YAML de serviço (para implantar no Cloud Run).
Você precisa de um pipeline de integração contínua ou algum outro processo para criar e posicionar as imagens. A ferramenta de CI pode ser o Cloud Build, o Jenkins ou qualquer coisa que resulte em imagens de contêiner que você pode fornecer ao seu pipeline de entrega do Cloud Deploy.
Ter um arquivo de configuração
skaffold.yaml
.O Cloud Deploy chama
skaffold render
para renderizar os manifestos do Kubernetes usando esse arquivo eskaffold apply
para implantá-los no destino. Para fazer isso, o Skaffold requer pelo menos umskaffold.yaml
mínimo. É possível conseguir um de duas maneiras:Crie o seu próprio.
Observe que o arquivo
skaffold.yaml
precisa referenciar o namespace correspondente a uma versão compatível do Skaffold na primeira linha, como neste exemplo:`apiVersion: skaffold/v2beta28`
Ele será gerado para você.
Se você ainda não tiver um arquivo
skaffold.yaml
, peça que o Cloud Deploy crie um para você. Esse arquivo é adequado para integração, aprendizado ou demonstração do Cloud Deploy e não deve ser usado para cargas de trabalho de produção.
Consulte Como usar o Skaffold com o Cloud Deploy para mais detalhes. Além disso, o artigo Como gerenciar manifestos no Cloud Deploy tem mais detalhes sobre como usar o Skaffold e o Cloud Deploy com ferramentas de gerenciamento de manifestos, como Helm, Kustomize e kpt.
Configure o Cloud Deploy para o ambiente de execução de sua escolha
O Cloud Deploy pode implantar seu aplicativo em qualquer um dos seguintes ambientes de execução:
Invocar o pipeline de entrega para criar uma versão
Depois de configurar o Cloud Deploy para implantar no ambiente de execução, é possível enviar seu aplicativo para implantação de acordo com o pipeline de entrega criado.
Execute seu processo regular de integração contínua (CI, na sigla em inglês), criando os artefatos implantáveis.
Inicie o pipeline de entrega chamando o Cloud Deploy para criar uma versão.
Execute o seguinte comando no diretório que contém a configuração do Skaffold:
gcloud deploy releases create RELEASE_NAME --delivery-pipeline=PIPELINE_NAME --region=REGION
Em que:
RELEASE_NAME
é um nome que será atribuído à versão. O nome precisa ser exclusivo entre todas as versões do pipeline de entrega.Para especificar nomes de versões dinâmicas, inclua
'$DATE'
,'$TIME'
ou ambos. Por exemplo, se você invocar esse comando às 15h07 UTC,'rel-$TIME'
será resolvido comorel-1507
.'$DATE'
e'$TIME'
precisam estar entre aspas simples e o horário é UTC na máquina em que você invoca o comando.PIPELINE_NAME
é o nome do pipeline de entrega que gerenciará a implantação dessa versão por meio da progressão de destinos. Esse nome precisa corresponder ao camponame
na definição do pipeline.REGION
é o nome da região em que você está criando a versão, por exemplo,us-central1
. Obrigatório.
Esse comando faz upload de um arquivo .tar contendo suas configurações para um bucket do Cloud Storage e cria a versão. O Cloud Deploy também cria automaticamente um lançamento e implanta sua imagem no primeiro destino definido no pipeline de entrega.
Além dos parâmetros exibidos com o comando, inclua qualquer uma das seguintes opções:
--images=<name=path/name:$IMAGE_SHA>,<name=path/name:$IMAGE_SHA>
Uma coleção de nomes de imagens para substituições de caminhos completos.
--build-artifacts=<path/file>
Uma referência a um arquivo de saída de artefatos de build do Skaffold, que pode ser transmitida para representar as substituições de caminho completo da imagem.
Essas duas opções são mutuamente exclusivas.
Também é possível incluir uma das seguintes sinalizações para que o Cloud Deploy
gere um arquivo skaffold.yaml
para você:
--from-k8s-manifest=K8S_MANIFEST
A configuração do Skaffold gerada é baseada no manifesto do Kubernetes que você transmite essa sinalização. O uso dessa sinalização com a sinalização
--skaffold-file
ou--source
gera um erro. Consulte Como gerar seuskaffold.yaml
para mais detalhes.--from-run-manifest=RUN_MANIFEST
A configuração do Skaffold gerada é baseada no YAML de serviço do Cloud Run em que você transmite essa sinalização. O uso dessa sinalização com a sinalização
--skaffold-file
ou--source
gera um erro. Consulte Como gerar seuskaffold.yaml
para mais detalhes.
Essas duas opções são mutuamente exclusivas.
Criar uma versão no console do Google Cloud
Use o console do Google Cloud para criar uma versão para um pipeline de entrega. Isso é útil para testar o Cloud Deploy, mas não é adequado para cargas de trabalho de produção.
O procedimento a seguir pressupõe que você já criou um pipeline de entrega e um ou mais destinos. Também é possível usar o console do Google Cloud para criar seu pipeline de entrega.
Na página Detalhes do pipeline de entrega, para um pipeline de entrega específico, clique em Criar versão.
No campo Escolher um contêiner, cole ou digite o caminho para a imagem do contêiner que você quer implantar. Também é possível usar o contêiner padrão pré-preenchido nesse campo para avaliação.
Também é possível clicar em Selecionar para escolher uma imagem de contêiner do Artifact Registry ou do Container Registry.
Forneça um nome exclusivo para a versão no campo Nome da versão ou use o nome padrão fornecido.
Forneça um nome para o lançamento, no campo Nome do lançamento, ou use o nome padrão fornecido.
Esse nome é usado para o lançamento do primeiro destino desta versão. Para destinos subsequentes, é possível nomear o lançamento na caixa de diálogo Promover ou no comando
gcloud deploy releases promote
.Se quiser, inclua uma descrição para essa versão no campo Descrição.
Em Detalhes da implantação, insira um nome para a implantação do GKE ou o serviço do Cloud Run, ou use o nome padrão fornecido.
Para o GKE, o Cloud Deploy gera o manifesto para você. Para o Cloud Run, o Cloud Deploy gera a definição do serviço, que é usada para criar o serviço.
Clique em Criar.
O Cloud Deploy usa o manifesto gerado ou a definição do serviço do Cloud Run e o skaffold.yaml
gerado para criar a versão.
Alterar o tempo limite da implantação
Para implantações em clusters de destino do GKE e do GKE Enterprise, há três tempos limite separados que afetam quanto tempo o sistema aguarda o Kubernetes relatar uma implantação estável:
O Cloud Build tem um tempo limite de 1 hora em operações que ele executa para o Cloud Deploy.
É possível alterar esse tempo limite na configuração do seu ambiente de execução.
O Skaffold tem um tempo limite de verificação de integridade (
deploy.statusCheckDeadlineSeconds
), que é o tempo, em segundos, de espera até que as implantações se estabilizem.O padrão é 600 segundos (10 minutos). Para usar esse tempo limite,
deploy.statusCheck
precisa ser definido comotrue
. Por padrão, é. SestatusCheck
forfalse
, não haverá verificação de status. O lançamento será marcado como bem-sucedido depois quekubectl apply
for concluído.Para recursos do Kubernetes de
kind: Deployment
, háDeployment.spec.progressDeadlineSeconds
, que é o tempo que o Kubernetes aguarda até que a implantação seja relatada como estável.Esse tempo limite é aplicável apenas a recursos
Deployment
. Veja como esses dois primeiros tempos limite funcionam juntos:Se
Deployment.spec.progressDeadlineSeconds
, no Kubernetes, não estiver definido, o tempo limite da verificação de integridade do Skaffold será o tempo limite efetivo, seja ele padrão ou definido explicitamente.Se
Deployment.spec.progressDeadlineSeconds
estiver definido no Kubernetes, o Skaffold ignorará o próprio tempo limite de verificação de integridade, e o prazo de progresso do Kubernetes será o tempo limite efetivo. No entanto, se o tempo limite do Kubernetes for explicitamente definido como600
(10 minutos), o Skaffold presumirá que é o padrão (não definido) e o ignorará, e o tempo limite do Skaffold será usado (se definido).Se nenhum tempo limite for definido, o tempo limite efetivo será o padrão do Skaffold de
600
(10 minutos).
Além de
Deployment
s, outros recursos do Kubernetes podem ter tempos limite, que não influenciam o tempo limite de estabilidade. Se algum deles estiver presente, revise-o para garantir que não esteja em conflito com o tempo limite de estabilidade.Se o Skaffold (ou Cloud Build) expirar, a implantação do GKE continuará em execução. O Cloud Deploy mostra uma falha, mas ainda pode ser bem-sucedido ou falhar no cluster do GKE.
Para alterar o tempo limite de estabilidade da implantação, faça o seguinte:
Verifique se
deploy.statusCheck
está definido comotrue
emskaffold.yaml
.O padrão é
true
. Quandotrue
, o Skaffold aguarda as verificações de integridade para informar uma implantação estável, sujeito ao valor de tempo limite na próxima etapa.Em
skaffold.yaml
, definastatusCheckDeadlineSeconds
como o número de segundos que você quer aguardar.deploy: ... statusCheck: true statusCheckDeadlineSeconds: 600 ...
O padrão é
600
(10 minutos). O Skaffold espera esse tempo por uma implantação estável. Se esse tempo for excedido antes da implantação se tornar estável, ela falhará.Opcionalmente, você pode adicionar
tolerateFailuresUntilDeadline: true
depois destatusCheckDeadlineSeconds
.Essa configuração instrui o Skaffold a não sair se uma única implantação falhar, mas a tolerar falhas até que
statusCheckDeadlineSeconds
expire. Essa configuração pode ser útil em situações em que você tem recursos que talvez precisem de mais tempo (até o prazo de verificação de status) para atingir um estado estável.Por exemplo, se você estiver usando o Istio ou o Anthos Service Mesh, talvez tenha uma implantação com falha com uma mensagem semelhante a esta:
error iptables validation failed; workload is not ready for Istio. When using Istio CNI, this can occur if a pod is scheduled before the node is ready.
A configuração funciona somente com o Skaffold 2.0 ou posterior.
No manifesto do Kubernetes, para recursos de
kind: Deployment
, definaDeployment.spec.progressDeadlineSeconds
com o mesmo valor definido parastatusCheckDeadlineSeconds
.
A seguir
Saiba mais sobre como implantar no GKE
Saiba mais sobre como implantar no Cloud Run
Saiba mais sobre como implantar no GKE Enterprise
Saiba como criar o pipeline e os destinos de entrega.
Saiba como promover uma versão