Nesta página, descrevemos como usar o Cloud Deploy para conseguir seu aplicativo nos ambientes de execução de destino pretendidos. Antes de fazer isso, você precisa Crie os destinos e o pipeline de entrega.
Antes de começar
Esta seção descreve o que você precisa configurar 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 de entrega e os destinos.
O Cloud Deploy pode implantar em clusters do Google Kubernetes Engine, Cloud Run e GKE Enterprise. A configuração de destino é diferente dependendo da implantação.
Ter imagens e manifestos de contêiner.
Você precisa implantar uma ou mais imagens de contêiner 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. Sua ferramenta de CI pode ser o Cloud Build, o Jenkins ou qualquer coisa que resulte em imagens de contêiner que que você pode fornecer ao pipeline de entrega do Cloud Deploy.
Tenha 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 isso, o Skaffold requer pelo menos umskaffold.yaml
mínimo. Você pode conseguir um deles de duas maneiras:Crie o seu.
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/v4beta7`
Gere os dados para você.
Se você ainda não tiver um arquivo
skaffold.yaml
, poderá peça que o Cloud Deploy crie uma para você. Este arquivo é adequado para integração, aprendizado ou demonstração 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, consulte Como gerenciar manifestos no Cloud Deploy. tem mais detalhes sobre como usar o Skaffold e o Cloud Deploy com ferramentas de gerenciamento de manifesto, 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:
Invoque o pipeline de entrega para criar uma versão
Depois de configurar o Cloud Deploy para implantar no seu ambiente de execução, faça o seguinte: agora pode enviar seu aplicativo para ser implantado de acordo com a entrega pipeline que você criou.
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 de um lançamento.
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
Como esse comando cria um arquivo .tar de todo o conteúdo do e subdiretórios, talvez não queira executar esse comando do diretório principal ou raiz. Execute o comando no diretório contendo sua configuração do Skaffold ou inclua a opção
--source=
, descrita mais tarde.Neste comando...
RELEASE_NAME
é um nome que será atribuído à versão. O nome precisa ser exclusivo entre todas as versões do pipeline de entrega.É possível especificar nomes dinâmicos de versão incluindo
'$DATE'
,'$TIME'
ou os dois. Por exemplo, se você invocar esse comando às 15h07 UTC,'rel-$TIME'
se refere arel-1507
.'$DATE'
e'$TIME'
precisam estar entre aspas simples, e o horário é o 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 que contém as configurações para um bucket do Cloud Storage e cria a versão. O Cloud Deploy também automaticamente cria um lançamento e implanta a 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 compilação do Skaffold, que pode ser transmitido 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 flags para que o Cloud Deploy
gerar 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. Use essa sinalização com a sinalização
--skaffold-file
ou--source
gera um erro. Consulte Gerando oskaffold.yaml
para mais detalhes.--from-run-manifest=RUN_MANIFEST
A configuração do Skaffold gerada é baseada no Cloud Run YAML de serviço em que essa sinalização é transmitida. Usar essa sinalização com o as sinalizações
--skaffold-file
ou--source
geram um erro. Consulte Gerando oskaffold.yaml
para mais detalhes.
Essas duas opções são mutuamente exclusivas.
Também é possível incluir um arquivo .gcloudignore
se houver arquivos no
diretório que você não quer incluir no arquivo tar.
Criar uma versão no console do Google Cloud
Use o console do Google Cloud para criar uma versão de entrega pipeline. 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 uma ou mais segmentações. 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 uma entrega específica pipeline, clique em Criar versão.
No campo Escolha um contêiner, cole ou digite o caminho do contêiner. imagem que você quer implantar. Você também pode usar o contêiner padrão pré-preenchido neste campo, para avaliação.
Também é possível clicar em Selecionar para escolher uma imagem de contêiner do Artifact Registry. ou Container Registry.
Informe um nome exclusivo para essa 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 as nome padrão fornecido.
Esse nome é usado para o lançamento no primeiro destino, para esta versão. Para segmentações subsequentes, nomeie o lançamento na caixa de diálogo Promover ou o comando
gcloud deploy releases promote
.Se quiser, inclua uma descrição no campo Descrição .
Em Detalhes da implantação, insira um nome para o GKE. implantação ou serviço do Cloud Run ou use o nome padrão fornecidas.
Para o GKE, o Cloud Deploy gera o manifesto para para você. Para o Cloud Run, o Cloud Deploy gera a definição do serviço, usada para criá-lo.
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 timeouts separados que afetam o tempo que o sistema espera para que o Kubernetes informe uma implantação estável:
O Cloud Build tem um tempo limite de 1 hora em operações que O Cloud Build é executado no Cloud Deploy.
É possível alterar esse tempo limite nas do ambiente de execução.
O Skaffold tem um tempo limite de verificação de integridade (
deploy.statusCheckDeadlineSeconds
), que é o tempo, em segundos, de espera para que as implantações sejam estabilizadas.O padrão é 600 segundos (10 minutos). Para usar esse tempo limite,
deploy.statusCheck
precisa ser definido comotrue
. Por padrão, é a configuração padrão. SestatusCheck
forfalse
, haverá não há verificação de status, o lançamento será marcado como bem-sucedido apóskubectl apply
é concluída com sucesso.Para os recursos do Kubernetes de
kind: Deployment
, háDeployment.spec.progressDeadlineSeconds
, que é o tempo que o Kubernetes espera para que a implantação seja relatada como o estábulo.Esse tempo limite é aplicável apenas a recursos
Deployment
. Confira como esses dois primeiros tempos limite funcionam juntos:Se
Deployment.spec.progressDeadlineSeconds
não estiver definido no Kubernetes, o tempo limite da verificação de integridade do Skaffold é o tempo limite efetivo, seja padrão ou é definido explicitamente.Se
Deployment.spec.progressDeadlineSeconds
estiver definido no Kubernetes, O Skaffold ignora o próprio tempo limite de verificação de integridade, e o progresso do Kubernetes prazo é o tempo limite efetivo. No entanto, se o tempo limite do Kubernetes for explicitamente definido como600
(10 minutos), então o Skaffold vai presumir que é o padrão (não definido) e o ignora, e o tempo limite do Skaffold é usado (se definido).Se nenhum tempo limite for definido, o tempo limite efetivo será o Skaffold o padrão é
600
(10 minutos).
Além dos
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 para garantir que não estejam em conflito com o tempo limite de estabilidade.Se o Skaffold (ou o Cloud Build) expirar, o GKE e implantação continua em execução. O Cloud Deploy mostra uma falha, ele ainda poderá ter êxito ou falhar no cluster do GKE.
Para mudar o tempo limite de estabilidade da implantação:
Confira se
deploy.statusCheck
está definido comotrue
emskaffold.yaml
.O padrão é
true
. Quandotrue
, o Skaffold aguarda as verificações de integridade informar uma implantação estável, sujeita ao valor de tempo limite na próxima etapa.No
skaffold.yaml
, definastatusCheckDeadlineSeconds
pelo número de segundos que você quer esperar.deploy: ... statusCheck: true statusCheckDeadlineSeconds: 600 ...
O padrão é
600
(10 minutos). O Skaffold aguarda esse tempo por uma implantação estável. Se esse tempo for excedido antes que a implantação esteja estável, a implantação vai falhar.Também é possível adicionar
tolerateFailuresUntilDeadline: true
apósstatusCheckDeadlineSeconds
.Essa configuração informa ao Skaffold que ele não deve sair se uma única implantação falhar, mas tolerar falhas até que
statusCheckDeadlineSeconds
expire. Esta configuração pode ajudar quando 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 Cloud 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 só funciona 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 como implantar no GKE Enterprise
Saiba como criar pipelines e destinos de entrega.
Saiba como promover uma versão.