Esta página descreve como usar o Cloud Deploy para implementar a sua aplicação nos ambientes de tempo de execução de destino pretendidos. Antes de o fazer, tem de criar o pipeline de entrega e os alvos.
Antes de começar
Esta secção descreve os aspetos que tem de ter em vigor antes de poder implementar a sua aplicação através do Cloud Deploy.
Certifique-se de que a conta de serviço de execução tem as autorizações e funções do IAM necessárias.
Crie o seu pipeline de entrega e segmentações.
O Cloud Deploy pode ser implementado no Google Kubernetes Engine, no Cloud Run e nos clusters do GKE Enterprise. A configuração de destino difere consoante o local de implementação.
Tenha as imagens e os manifestos dos contentores.
Precisa de uma ou mais imagens de contentores para implementar e um ou mais manifestos do Kubernetes (para implementar no GKE) ou ficheiros YAML de serviços (para implementar no Cloud Run).
Precisa de um pipeline de integração contínua ou de outro processo para criar e colocar as suas imagens. A sua ferramenta de CI pode ser o Cloud Build, o Jenkins ou qualquer outra ferramenta que resulte em imagens de contentores que possa fornecer ao pipeline de entrega do Cloud Deploy.
Ter um
skaffold.yaml
ficheiro de configuração.O Cloud Deploy chama
skaffold render
para renderizar os manifestos do Kubernetes através deste ficheiro eskaffold apply
para os implementar no seu destino. Para o fazer, o Skaffold requer, pelo menos, umskaffold.yaml
mínimo. Pode obter um de duas formas:Crie o seu.
Tenha em atenção que o ficheiro
skaffold.yaml
tem de fazer referência ao espaço de nomes correspondente a uma versão do Skaffold suportada na primeira linha, como neste exemplo:`apiVersion: skaffold/v4beta7`
Peça para o gerar.
Se ainda não tiver um ficheiro
skaffold.yaml
, pode pedir ao Cloud Deploy que crie um para si. Este ficheiro é adequado para a integração, a aprendizagem ou a demonstração do Cloud Deploy e não deve ser usado para cargas de trabalho de produção.
Consulte o artigo Usar o Skaffold com o Cloud Deploy para ver mais detalhes. Além disso, o artigo Gerir manifestos no Cloud Deploy tem mais detalhes sobre a utilização do Skaffold e do Cloud Deploy com ferramentas de gestão de manifestos, como o Helm, o Kustomize e o kpt.
Configure o Cloud Deploy para o ambiente de tempo de execução da sua escolha
O Cloud Deploy pode implementar a sua aplicação em qualquer um dos seguintes ambientes de tempo de execução:
Invoque o pipeline de entrega para criar um lançamento
Depois de configurar o Cloud Deploy para implementação no seu tempo de execução, pode enviar a sua aplicação para implementação de acordo com o pipeline de entrega que criou.
Execute o processo de integração contínua (IC) normal, criando o artefacto ou os artefactos implementáveis.
Inicie o pipeline de fornecimento chamando o Cloud Deploy para criar um lançamento.
Execute o seguinte comando a partir do diretório que contém a configuração do Skaffold:
gcloud deploy releases create RELEASE_NAME --delivery-pipeline=PIPELINE_NAME --region=REGION
Uma vez que este comando cria um ficheiro TAR de todo o conteúdo do diretório e de quaisquer subdiretórios, é recomendável não executar este comando a partir do diretório principal ou raiz. Execute o comando a partir do 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 a atribuir a este lançamento. O nome tem de ser exclusivo entre todos os lançamentos desta pipeline de entrega.Pode especificar nomes de lançamentos dinâmicos incluindo
'$DATE'
ou'$TIME'
ou ambos. Por exemplo, se invocar este comando às 15:07 UTC,'rel-$TIME'
é resolvido comorel-1507
.'$DATE'
e'$TIME'
têm de estar entre aspas simples e a hora é a hora UTC na máquina onde invoca o comando.PIPELINE_NAME
é o nome do pipeline de fornecimento que vai gerir a implementação desta versão através da progressão dos alvos. Este nome tem de corresponder ao camponame
na definição do pipeline.REGION
é o nome da região na qual está a criar o lançamento, por exemplo,us-central1
. Este campo é obrigatório.
Este comando carrega um ficheiro TAR com as suas configurações para um contentor do Cloud Storage e cria o lançamento. O Cloud Deploy também cria automaticamente uma implementação gradual e implementa a sua imagem no primeiro destino definido no pipeline de entrega.
Além dos parâmetros apresentados com este comando, pode incluir qualquer uma das seguintes opções:
--images=<name=path/name:$IMAGE_SHA>,<name=path/name:$IMAGE_SHA>
Uma coleção de substituições do nome da imagem pelo caminho completo da imagem.
--build-artifacts=<path/file>
Uma referência a um ficheiro de saída de artefactos de compilação do Skaffold, que pode ser transmitido para representar as substituições do caminho completo da imagem.
Estas duas opções são mutuamente exclusivas.
Também pode incluir uma das seguintes flags para que o Cloud Deploy gere um ficheiro skaffold.yaml
para si:
--from-k8s-manifest=K8S_MANIFEST
A configuração do Skaffold gerada baseia-se no manifesto do Kubernetes que transmite esta flag. A utilização desta flag com a flag
--skaffold-file
ou a flag--source
gera um erro. Consulte o artigo Gerar o seuskaffold.yaml
para ver mais detalhes.--from-run-manifest=RUN_MANIFEST
A configuração do Skaffold gerada baseia-se no YAML do serviço do Cloud Run que transmite esta flag. A utilização desta sinalização com a sinalização
--skaffold-file
ou a sinalização--source
gera um erro. Consulte o artigo Gerar o seuskaffold.yaml
para ver mais detalhes.
Estas duas opções são mutuamente exclusivas.
Também pode incluir um ficheiro .gcloudignore
se existirem ficheiros no diretório que não quer incluir no ficheiro TAR.
Crie um lançamento a partir da Google Cloud consola
Pode usar a Google Cloud consola para criar um lançamento para um pipeline de entrega. Isto é útil para experimentar o Cloud Deploy, mas não é adequado para cargas de trabalho de produção.
O procedimento seguinte pressupõe que já criou um pipeline de entrega e um ou mais alvos. (Também pode usar a Google Cloud consola) para criar o seu pipeline de entrega.)
Na página Detalhes do pipeline de fornecimento, para um pipeline de fornecimento específico, clique em Criar lançamento.
No campo Escolha um contentor, cole ou escreva o caminho para a imagem do contentor que quer implementar. Também pode usar o contentor predefinido pré-preenchido neste campo para avaliação.
Também pode clicar em Selecionar para escolher uma imagem de contentor a partir do Artifact Registry.
Indique um nome exclusivo para este lançamento no campo Nome do lançamento ou use o nome predefinido fornecido.
Indique um nome para a implementação no campo Nome da implementação ou use o nome predefinido.
Este nome é usado para a implementação no primeiro alvo desta versão. Para alvos subsequentes, pode atribuir um nome à implementação na caixa de diálogo Promover ou no comando
gcloud deploy releases promote
.Opcionalmente, inclua uma descrição para este lançamento no campo Descrição.
Em Detalhes da implementação, introduza um nome para a implementação do GKE ou o serviço do Cloud Run, ou use o nome predefinido fornecido.
Para o GKE, o Cloud Deploy gera o manifesto por si. 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.
Altere o limite de tempo de implementação
Para implementações em clusters de destino do GKE e GKE Enterprise, existem três limites de tempo separados que afetam o tempo que o sistema aguarda que o Kubernetes comunique uma implementação estável:
O Cloud Build tem um limite de tempo de 1 hora nas operações que o Cloud Build realiza para o Cloud Deploy.
Pode alterar este limite de tempo na configuração do seu ambiente de execução.
O Skaffold tem um tempo limite de verificação do estado (
deploy.statusCheckDeadlineSeconds
), que é o tempo, em segundos, a aguardar pela estabilização das implementações.A predefinição é 600 segundos (10 minutos). Para usar este limite de tempo,
deploy.statusCheck
tem de estar definido comotrue
. Por predefinição, é. SestatusCheck
forfalse
, não existe uma verificação do estado. A implementação é marcada como bem-sucedida após a conclusão com êxito dekubectl apply
.Para os recursos do Kubernetes de
kind: Deployment
, existeDeployment.spec.progressDeadlineSeconds
, que é o tempo que o Kubernetes aguarda que a implementação seja comunicada como estável.Este limite de tempo aplica-se apenas a recursos
Deployment
. Veja como estes dois primeiros limites de tempo funcionam em conjunto:Se
Deployment.spec.progressDeadlineSeconds
, no Kubernetes, não estiver definido, o tempo limite da verificação de estado do Skaffold é o tempo limite efetivo, quer seja o predefinido ou esteja definido explicitamente.Se
Deployment.spec.progressDeadlineSeconds
, no Kubernetes, estiver definido, o Skaffold ignora o respetivo limite de tempo da verificação de estado e o prazo do progresso do Kubernetes é o limite de tempo efetivo. No entanto, se o limite de tempo do Kubernetes estiver definido explicitamente como600
(10 minutos), o Skaffold assume que é o predefinido (não definido) e ignora-o, e o limite de tempo do Skaffold é usado (se estiver definido).Se nenhum dos limites de tempo estiver definido, o limite de tempo efetivo é o predefinido do Skaffold de
600
(10 minutos).
Além dos
Deployment
s, outros recursos do Kubernetes podem ter limites de tempo, que não influenciam o limite de tempo de estabilidade. Se algum destes estiver presente, reveja-o para garantir que não está em conflito com o limite de tempo de estabilidade.Se o Skaffold (ou o Cloud Build) atingir o limite de tempo, a implementação do GKE continua a ser executada. O Cloud Deploy mostra uma falha, mas ainda pode ter êxito ou falhar no cluster do GKE.
Para alterar o limite de tempo de estabilidade da implementação:
Certifique-se de que
deploy.statusCheck
está definido comotrue
emskaffold.yaml
.true
é a predefinição. Quandotrue
, o Skaffold aguarda que as verificações de funcionamento comuniquem uma implementação estável, sujeita ao valor de tempo limite no passo seguinte.Em
skaffold.yaml
, definastatusCheckDeadlineSeconds
para o número de segundos que quer esperar.deploy: ... statusCheck: true statusCheckDeadlineSeconds: 600 ...
A predefinição é
600
(10 minutos). O Skaffold aguarda este período para uma implementação estável. Se este tempo for excedido antes de a implementação estar estável, a implementação falha.Opcionalmente, pode adicionar
tolerateFailuresUntilDeadline: true
depois destatusCheckDeadlineSeconds
.Esta definição indica ao Skaffold que não deve sair se uma única implementação falhar, mas sim tolerar falhas até que
statusCheckDeadlineSeconds
expire. Esta definição pode ajudar em situações em que tem recursos que podem precisar de mais tempo (até ao prazo de verificação do estado) para atingir um estado estável.Por exemplo, se estiver a usar o Istio ou o Cloud Service Mesh, pode ter uma implementação com falhas 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
, definaDeployment.spec.progressDeadlineSeconds
com o mesmo valor que definiu parastatusCheckDeadlineSeconds
.
O que se segue?
Saiba mais sobre a implementação no GKE
Saiba mais sobre a implementação no Cloud Run
Saiba mais sobre a implementação no GKE Enterprise
Saiba como promover um lançamento