Implantar aplicativo

Nesta página, descrevemos como usar o Google Cloud Deploy para colocar o aplicativo nos seus ambientes de execução de destino pretendido. Antes de fazer isso, você precisa criar o pipeline e os destinos de entrega.

Antes de começar

Nesta seção, descrevemos os requisitos necessários para implantar o aplicativo usando o Google 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 as metas.

  O Google Cloud Deploy pode implantar em clusters do Google Kubernetes Engine, Cloud Run e Anthos. A configuração de destino varia de acordo com o em que você está implantando.

• Ter os manifestos e imagens de contêiner.

  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 de outro processo, para criar e posicionar suas imagens. A ferramenta de CI pode ser o Cloud Build, o Jenkins ou qualquer item que resulte em imagens de contêiner fornecidas ao pipeline de entrega do Google Cloud Deploy.

• Ter um arquivo de configuração skaffold.yaml.

  O Google Cloud Deploy chama skaffold render para renderizar os manifestos do Kubernetes usando esse arquivo e skaffold apply para implantá-los no seu destino de dados. Para fazer isso, o Skaffold exige pelo menos um skaffold.yaml mínimo. É possível receber uma de duas maneiras:

  • Crie o seu.

    O arquivo skaffold.yaml precisa referenciar o namespace correspondente a uma versão do Skaffold compatível na primeira linha, como neste exemplo:

    `apiVersion: skaffold/v2beta28`
    

  • Ele é gerado automaticamente.

    Se você ainda não tiver um arquivo skaffold.yaml, faça o Google Cloud Deploy criar um para você. Esse arquivo é adequado para integração, aprendizado ou demonstração do Google Cloud Deploy e não deve ser usado para cargas de trabalho de produção.

  Consulte Como usar o Skaffold com o Google Cloud Deploy para mais detalhes. Além disso, Como gerenciar manifestos no Google Cloud Deploy tem mais detalhes sobre o uso do Skaffold e do Google Cloud Deploy com ferramentas de gerenciamento de manifestos, como Helm, Kustomize e kpt.

Configurar o Google Cloud Deploy para o ambiente de execução de sua escolha

O Google Cloud Deploy pode implantar seu aplicativo em qualquer um destes ambientes de execução:

• GKE
• Anthos
• Cloud Run

Invocar o pipeline de entrega para criar uma versão

Depois de configurar o Google Cloud Deploy para implantar no ambiente de execução, é possível enviar seu aplicativo para ser implantado de acordo com o pipeline de entrega que você criou.

1. Execute seu processo regular de integração contínua (CI, na sigla em inglês), criando os artefatos implantáveis.

2. Inicie o pipeline de entrega chamando o Google 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.

   Você pode especificar nomes de versões dinâmicas incluindo '$DATE', '$TIME' ou ambos. Por exemplo, se você invocar esse comando às 15h07 UTC, 'rel-$TIME' é resolvido como rel-1507. '$DATE' e '$TIME' precisam estar entre aspas simples, e a hora é 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.

Observação: opcionalmente, é possível incluir --source=SOURCE_PATH para especificar o local do arquivo skaffold.yaml. O padrão é o diretório atual.

Esse comando faz upload de um tarball que contém os configs para um bucket do Cloud Storage e cria a versão. O Google 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 versã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 sinalizações para que o Google 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 transmitido nesta sinalização. O uso dessa sinalização com a sinalização --skaffold-file ou --source gera um erro. Consulte Como gerar skaffold.yaml para ver mais detalhes.

• --from-run-manifest=RUN_MANIFEST

  A configuração do Skaffold gerada é baseada no YAML de serviço do Cloud Run transmitido por essa sinalização. O uso dessa sinalização com a sinalização --skaffold-file ou --source gera um erro. Consulte Como gerar skaffold.yaml para ver mais detalhes.

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

Alterar o tempo limite da implantação

Para implantações nos clusters de destino do GKE e do Anthos, há três tempos limite separados que afetam quanto tempo o sistema aguarda 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 executa para o Google Cloud Deploy.

  É possível alterar 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, para aguardar a estabilização das implantações.

  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 há nenhuma verificação de status, o lançamento vai ser marcado como concluído depois que kubectl apply for concluído.

• Para recursos do Kubernetes de kind: Deployment, há Deployment.spec.progressDeadlineSeconds, que é o tempo que o Kubernetes espera que a implantação gere um relatório 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 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 estiver explicitamente definido como 600 (10 minutos), o Skaffold vai presumir que ele é 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 600 do Skaffold (10 minutos).

  Além de 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 ele não esteja em conflito com o tempo limite de estabilidade.

  Se o Skaffold (ou o Cloud Build) expirar, a implantação do GKE continuará em execução. O Google 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:

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

   O padrão é true. Quando true, o Skaffold espera que as verificações de integridade informem uma implantação estável, sujeita ao valor do tempo limite na próxima etapa.

2. Em skaffold.yaml, defina statusCheckDeadlineSeconds como o número de segundos que você quer aguardar.

   deploy:
     ...
     statusCheck: true
     statusCheckDeadlineSeconds: 600
     ...
   

   O padrão é 600 (10 minutos). O Skaffold aguarda esse período por uma implantação estável. Se esse tempo for excedido antes que a implantação seja estável, a implantação falhará.

3. Também é possível adicionar tolerateFailuresUntilDeadline: true após statusCheckDeadlineSeconds.

   Essa configuração diz ao Skaffold para não sair se uma única implantação falhar, mas tolerar falhas até que statusCheckDeadlineSeconds expire. Essa configuração pode ajudar em situações em que você tenha 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, poderá ter 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 apenas com o Skaffold 2.0 ou mais recente.

4. No manifesto do Kubernetes, para recursos de kind: Deployment, defina Deployment.spec.progressDeadlineSeconds com o mesmo valor definido em statusCheckDeadlineSeconds.

A seguir

• Saiba mais sobre como implantar no GKE

• Saiba mais sobre como implantar no Cloud Run.

• Saiba mais sobre como implantar no Anthos

• Saiba como criar pipelines e destinos de entrega

• Saiba como promover uma versão.