Esta página foi traduzida pela API Cloud Translation.

Implantar seu aplicativo

Nesta página, descrevemos como usar o Cloud Deploy para colocar o aplicativo nos seus ambientes de execução de destino pretendido. Antes de fazer isso, crie seu pipeline e destinos de entrega.

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 seu pipeline de entrega e destinos.

O Cloud Deploy pode fazer implantações em clusters do Google Kubernetes Engine, do Cloud Run e do GKE Enterprise. A configuração de destino varia de acordo com o ambiente de implantação.
Tenha suas imagens e manifestos de contêiner.

Você precisa de uma ou mais imagens de contêiner para implantação e um ou mais manifestos do Kubernetes (para implantação no GKE) ou arquivos YAML de serviço (para implantação no Cloud Run).

Você precisa de um pipeline de integração contínua ou de outro processo para criar e posicionar suas imagens. Sua ferramenta de CI pode ser o Cloud Build, o Jenkins ou qualquer coisa que resulte em imagens de contêiner que você possa fornecer ao 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 e skaffold apply para implantá-los no seu destino. Para isso, o Skaffold precisa de pelo menos um skaffold.yaml mínimo. Você pode conseguir um de duas maneiras:
- Crie o seu.
  
  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`
```
- Peça para ele gerar para você.
  
  Se você ainda não tiver um arquivo skaffold.yaml, peça para o Cloud Deploy criar 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, Como gerenciar manifestos no Cloud Deploy tem mais detalhes sobre o uso do Skaffold e do Cloud Deploy com ferramentas de gerenciamento de manifestos, como Helm, Kustomize e kpt.

Configurar 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 implantação no seu ambiente de execução, você pode enviar o aplicativo para ser implantado de acordo com o pipeline de entrega 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 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
```
Como esse comando cria um arquivo tar de todo o conteúdo do diretório e de todos os subdiretórios, talvez você não queira executá-lo no diretório inicial ou raiz. Execute o comando no diretório que contém a configuração do Skaffold ou inclua a opção --source=, descrita mais adiante.

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 de lançamento dinâmicos incluindo '$DATE', '$TIME' ou ambos. Por exemplo, se você invocar esse comando às 15h07 UTC, 'rel-$TIME' será resolvido como rel-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 campo name 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 os configs para um bucket do Cloud Storage e cria a versão. O Cloud Deploy também cria automaticamente 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 build do Skaffold, que pode ser transmitido para representar as substituições de caminho completo da imagem.

Essas duas opções são mutuamente exclusivas.

Você também pode incluir uma das seguintes flags 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 flag. Usar essa flag com a --skaffold-file ou a --source gera um erro. Consulte Como gerar seu skaffold.yaml para mais detalhes.
--from-run-manifest=RUN_MANIFEST

A configuração do Skaffold gerada é baseada no YAML do serviço do Cloud Run que você transmite a essa flag. Usar essa flag com a --skaffold-file ou a --source gera um erro. Consulte Como gerar seu skaffold.yaml para mais detalhes.

Essas duas opções são mutuamente exclusivas.

Você também pode 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 Google Cloud

Use o console Google Cloud para criar um lançamento 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 Google Cloud para criar seu pipeline de entrega.

Na página Detalhes do pipeline de entrega, clique em Criar lançamento para um pipeline de entrega específico.
No campo Escolher um contêiner, cole ou digite o caminho para a imagem do contêiner que você quer implantar. Você também pode usar o contêiner padrão pré-preenchido neste campo para avaliação.

Você também pode clicar em Selecionar para escolher uma imagem de contêiner do Artifact Registry.
Insira um nome exclusivo para esta versão no campo Nome da versão ou use o nome padrão fornecido.
Informe 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 no primeiro destino desta versão. Para outras metas, você pode nomear o lançamento na caixa de diálogo Promover ou no comando gcloud deploy releases promote.
Se quiser, inclua uma descrição para esta 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 de serviço, que é usada para criar o serviço.
Clique em Criar.

O Cloud Deploy usa o manifesto gerado ou a definição de serviço do Cloud Run e o skaffold.yaml gerado para criar a versão.

Mudar o tempo limite de implantação

Para implantações em clusters de destino do GKE e do GKE Enterprise, há três tempos limite separados que afetam o tempo que o sistema espera que o Kubernetes informe uma implantação estável:

O Cloud Build tem um tempo limite de uma hora nas operações que ele realiza para o Cloud Deploy.

É possível mudar esse tempo limite na configuração 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 se estabilizem.

O padrão é 600 segundos (10 minutos). Para usar esse tempo limite, deploy.statusCheck precisa ser definido como true. Por padrão, é. Se statusCheck for false, não haverá verificação de status. O lançamento será marcado como bem-sucedido após a conclusão de kubectl apply.
Para recursos do Kubernetes de kind: Deployment, há Deployment.spec.progressDeadlineSeconds, que é o tempo que o Kubernetes espera para que a implantação seja informada como estável.

Esse tempo limite se aplica 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 o padrão ou definido explicitamente.
- Se Deployment.spec.progressDeadlineSeconds, no Kubernetes, estiver definido, o Skaffold vai 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 definido explicitamente como 600 (10 minutos), o Skaffold vai presumir que é o padrão (não definido) e o ignorará. 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 dos Deployments, 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 o Cloud Build) atingir o tempo limite, a implantação do GKE vai continuar sendo executada. O Cloud Deploy mostra uma falha, mas ainda pode ter sucesso ou falhar no cluster do GKE.

Para mudar o tempo limite de estabilidade da implantação:

Verifique se deploy.statusCheck está definido como true em skaffold.yaml.

O padrão é true. Quando true, o Skaffold aguarda que as verificações de integridade informem uma implantação estável, sujeita ao valor de tempo limite na próxima etapa.
Em skaffold.yaml, defina statusCheckDeadlineSeconds como o número de segundos que você quer esperar.
```
deploy:
  ...
  statusCheck: true
  statusCheckDeadlineSeconds: 600
  ...
```
O padrão é 600 (10 minutos). O Skaffold aguarda esse tempo para uma implantação estável. Se esse tempo for excedido antes que a implantação fique estável, ela vai falhar.
Se quiser, adicione tolerateFailuresUntilDeadline: true depois de statusCheckDeadlineSeconds.

Essa configuração informa ao Skaffold para não sair se uma única implantação falhar, mas para tolerar falhas até que statusCheckDeadlineSeconds expire. Essa configuração pode ajudar em situações em que você tem recursos que podem precisar de mais tempo (até o prazo da 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.
```
No manifesto do Kubernetes, para recursos de kind: Deployment, defina Deployment.spec.progressDeadlineSeconds com o mesmo valor de statusCheckDeadlineSeconds.

A seguir

Saiba como implantar no GKE
Saiba como implantar no Cloud Run.
Saiba como fazer implantações no GKE Enterprise
Saiba como criar seu pipeline de entrega e destinos
Saiba como promover um lançamento.