Arquitetura de serviço do Cloud Deploy

Neste documento, descrevemos as relações entre o Cloud Deploy e os sistemas externos com que ele trabalha para implantar seus aplicativos. Esses sistemas são outros serviços do Google Cloud e ferramentas de terceiros.

A visualização de alto nível

O diagrama a seguir mostra as relações entre o Cloud Deploy e os sistemas separados dos quais ele depende.

Conforme mostrado neste diagrama, o Cloud Deploy interage com os seguintes sistemas:

• Seu sistema de CI

  O Cloud Deploy é compatível com a maioria das ferramentas de CI, desde que uma saída do processo de CI possa ser uma chamada para a API ou a CLI do Cloud Deploy para criar uma versão.

• Cloud Build

  O Cloud Deploy chama o Cloud Build para renderizar seus manifestos e para implantar no ambiente de execução de destino.

• Skaffold

  O Cloud Deploy usa o Skaffold no Cloud Build para renderizar e implantar os manifestos, implantando assim o aplicativo.

• Cloud Storage

  O Cloud Deploy armazena a origem da renderização e os manifestos renderizados em um bucket do Cloud Storage.

• Pacote de operações do Google Cloud e Registros de auditoria do Cloud.

  O pacote de operações do Google Cloud coleta e disponibiliza dados de geração de registros para o Cloud Deploy.

  Consulte também Registro de auditoria.

• Pub/Sub

  O Cloud Deploy publica mensagens em vários tópicos do Pub/Sub. Use esse serviço para fazer a integração com fluxo de trabalho externo, testes e outros sistemas relacionados.

  Consulte Como se inscrever em notificações do Cloud Deploy para mais informações.

• Tempo de execução de destino

  O Cloud Deploy usa skaffold apply, pelo Cloud Build, para implantar os aplicativos no ambiente de execução de destino (GKE ou GKE Enterprise).

Recursos do Cloud Deploy

No diagrama a seguir, mostramos os recursos que o Cloud Deploy usa para entregar seus aplicativos e as relações entre esses recursos:

Como mostrado nesse diagrama, as relações entre os recursos são as seguintes:

• O pipeline de entrega pode produzir zero ou mais versões e pode referenciar um ou mais destinos, incluindo vários destinos e os destinos filhos associados deles.

• Cada versão inclui a instância do pipeline, um "snapshot" do pipeline de entrega e dos destinos como eles foram configurados quando a versão foi criada.

• Cada versão pode produzir zero ou mais lançamentos e pode referenciar zero ou mais artefatos.

  Cada lançamento inclui pelo menos uma fase, representando uma coleção de operações (jobs) em um lançamento que são agrupadas logicamente, por exemplo, uma implantação ou uma implantação e verificação.

  Cada fase inclui um ou mais jobs, representando o que será feito na implantação: implantação ou verificação. Cada job pode incluir uma ou mais execuções de job, que são instâncias de jobs, por exemplo, uma tentativa de implantação. Uma execução de job é um recurso filho do lançamento.

  Vários destinos, usados para implantação paralela, criam distribuições do controlador, que criam lançamentos filhos que correspondem a destinos filhos.

• Cada lançamento está associado a um destino.

  Para a implantação paralela , cada destino filho está associado a um lançamento filho.

• Cada destino está associado a um cluster do GKE ou do Anthos ou a outro destino de ambiente de execução para o aplicativo.

• Um destino pode ser associado a um ou mais pipelines de entrega.

• Um artefato é qualquer saída do processo de CI (por exemplo, uma imagem de contêiner) implantada em um ambiente de execução de destino como parte de um lançamento.

Além disso, um lançamento tem uma ou mais fases, que têm um ou mais jobs e uma ou mais execuções de jobs.

Conforme mostrado neste diagrama, um lançamento inclui o seguinte:

• Fases

  Uma fase contém um ou mais jobs (por exemplo, implantar ou implantar e verificar). Cada lançamento tem uma ou mais fases. Uma fase é uma submensagem em um lançamento.

• Jobs

  A operação específica a ser realizada em um lançamento, por exemplo, implantação ou verificação. Um job é uma submensagem em um lançamento.

• JobRuns

  Uma instância de um job, por exemplo, uma tentativa de verificação. Cada job pode ter zero ou mais JobRuns. O JobRun é um recurso filho de um lançamento.

Como eles funcionam juntos para entregar sua versão

Nesta seção, descrevemos como o Cloud Deploy interage com os componentes listados neste documento para automatizar a entrega do aplicativo como uma versão.

1. Seu sistema de CI invoca um pipeline de entrega do Cloud Deploy.

   Seu processo de CI chama o Cloud Deploy usando a CLI ou a API para criar uma nova versão, transmitindo os artefatos de build ou referências a imagens.

   Para mais informações sobre como integrar o sistema de CI, consulte Como integrar o Cloud Deploy a outros sistemas.

2. Quando uma nova versão é criada, o Cloud Deploy faz o seguinte:

   1. Armazena uma instância do pipeline de entrega como parte da versão.

      Esta instância de pipeline permanece inalterada nesta versão, mesmo que a configuração do pipeline de entrega seja alterada. Consulte Instâncias de pipeline por versão para mais informações.

      Além disso, a versão do Skaffold é armazenada como parte da versão. Na maioria dos casos, essa será a versão padrão do Skaffold, mas, como é possível especificar outras versões, essas informações são armazenadas.

   2. Chama o Cloud Build, que recebe a origem de renderização do Skaffold do Cloud Storage.

      O Cloud Deploy armazena a origem da renderização no bucket padrão ou alternativo do Cloud Storage.

   3. Chamar skaffold diagnose (usando a versão do Skaffold armazenada após a criação da versão) para gerar um único manifesto efetivo.

   4. Chama skaffold render para renderizar o manifesto usando as imagens ou os artefatos de compilação fornecidos.

      O Cloud Deploy substitui nomes de imagens em spec.templates.spec.containers.image pelos caminhos de imagem completos (incluindo resumos ou tags) fornecidos no comando gcloud deploy releases create ou em um arquivo de artefatos de compilação referenciado por esse comando.

      O Cloud Deploy armazena o manifesto renderizado no bucket padrão ou alternativo do Cloud Storage.

      O Cloud Deploy executa essas ações usando o ambiente de execução padrão ou um alternativo.

   5. Cria e implanta automaticamente um lançamento para o primeiro destino chamando skaffold apply.

      Isso só ocorre quando o Cloud Deploy é invocado a partir da CLI para criar uma versão.

      O processo de implantação na primeira meta é o mesmo das promoções, conforme descrito na próxima etapa.

      Observação: skaffold apply inclui a verificação de integridade do Skaffold, que aguarda a estabilização das implantações.

   6. Chama skaffold verify se verify for true para o destino na configuração do pipeline de entrega e se a verificação for especificada na configuração do Skaffold.

3. Na hora de promover a versão para o próximo destino, o Cloud Build recupera o manifesto específico do destino do Cloud Storage. Em seguida, o Cloud Build invoca skaffold apply para aplicar o manifesto renderizado ao ambiente de execução de destino especificado.

   Se o destino exigir a aprovação, será possível aprová-la ou rejeitá-la por meio da CLI ou usando o console.

   Além disso, o Cloud Deploy gera uma mensagem do Pub/Sub, em que é possível se inscrever para iniciar automaticamente um fluxo de trabalho de aprovação.

   O Cloud Deploy usa a versão do Skaffold e a instância de pipeline associada a essa versão e executa essa etapa no ambiente de execução padrão ou personalizado.

   Esse processo ocorre não só para promoções, mas também para reversões e reimplantações.

4. Durante as operações do Cloud Deploy, o serviço publica notificações em vários tópicos do Pub/Sub (por exemplo, quando um lançamento requer aprovação).

   Essa e outras integrações são descritas em mais detalhes em Como integrar o Cloud Deploy com sistemas externos.

5. Durante a operação do Cloud Deploy, o serviço grava registros da plataforma e registros de auditoria no pacote de operações do Google Cloud e nos Registros de auditoria do Cloud.

Em todas essas etapas, o controle de fluxo e o acesso a recursos são restritos usando o gerenciamento de identidade e acesso.

A seguir

• Saiba mais sobre como integrar o Cloud Deploy a outros sistemas

• Veja informações importantes sobre o ciclo de vida da versão do Skaffold.

• Saiba mais sobre os ambientes de execução do Cloud Deploy.

• Teste o tutorial sobre perfis do Skaffold do Cloud Deploy

• Aprenda a combinar as ferramentas de CI/CD do Google Cloud para desenvolver e fornecer software ao GKE.