Arquitetura de serviço do Cloud Deploy

Neste documento, descrevemos as relações entre o Cloud Deploy e os sistemas externos com os quais 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.

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

• Seu sistema de CI

  O Cloud Deploy oferece suporte à 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 os manifestos e 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 e os manifestos renderizados em um bucket do Cloud Storage.

• Observabilidade do Google Cloud e Registros de auditoria do Cloud.

  A observabilidade 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 nas notificações do Cloud Deploy para mais informações.

• Tempo de execução de destino

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

Recursos do Cloud Deploy

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

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

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

• O pipeline de entrega também pode referenciar uma ou mais automações, que automatizam as ações nos recursos do Cloud Deploy.

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

• Cada versão pode gerar zero ou mais lançamentos e pode fazer referência a zero ou mais artefatos.

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

  Cada fase inclui um ou mais jobs, representando o que será feito no lançamento: implantação ou verificação. Cada job pode incluir uma ou mais execuções de jobs, 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 lançamentos do controlador, que criam distribuições filhas que correspondem aos 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, e as fases têm um ou mais jobs e uma ou mais execuções de jobs.

Como 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 executada 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.

As automações contêm regras de automação, que podem ser referenciadas por zero ou mais recursos do AutomationRun. AutomationRuns são instâncias de regras de automação executadas, por exemplo, uma promoção automatizada de um destino para outro. Os recursos Automation e AutomationRun são recursos filhos de peering abaixo de um pipeline de entrega.

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 as referências às imagens.

   Para mais informações sobre como integrar seu sistema de CI, consulte Como integrar o Cloud Deploy com 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 de 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 a operação render;

      Se você estiver usando destinos integrados, o Cloud Deploy chamará skaffold render para renderizar o manifesto usando as imagens ou artefatos de compilação fornecidos. O Cloud Deploy substitui nomes de imagem 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 build referenciado por esse comando.

      Se você estiver usando um destino personalizado, o Cloud Deploy chamará a operação render definida para o tipo de destino personalizado.

      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 alternativo.

3. Quando um lançamento é criado (automaticamente após a criação da versão ou sob demanda posteriormente), o Cloud Deploy faz o seguinte:

   1. Chama hooks de pré-implantação, se algum for especificado.

      Se você estiver usando uma estratégia de implantação canário, os hooks de pré-implantação serão chamados no início da primeira fase.

   2. chama a operação deploy;

      Se você estiver usando destinos integrados, o Cloud Deploy criará e implantará automaticamente um lançamento no primeiro destino, chamando skaffold apply. Se você estiver usando um destino integrado, o primeiro lançamento será criado automaticamente após a criação da versão.

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

      Se você estiver usando um destino personalizado, o Cloud Deploy criará automaticamente um lançamento para o primeiro destino, chamando a operação deploy definida para o tipo de destino personalizado.

      Para destinos integrados e personalizados, o lançamento para o primeiro destino é automático somente quando a versão é criada usando a linha de comando.

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

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

   4. Chama hooks pós-implantação, se houver algum especificado, após verify, se um verify for especificado. Caso contrário, os hooks pós-implantação serão chamados após deploy.

      Se você estiver usando uma estratégia de implantação canário, os hooks pós-implantação serão executados como o último job na fase final de lançamento.

4. 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, na qual você pode 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 associadas a esta 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.

5. 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 exige aprovação).

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

6. É possível especificar uma automação para executar automaticamente várias operations no pipeline de entrega. Elas podem ser executadas no horário designado. Um automationRun representa a execução de uma regra de automação.

7. Durante a operação do Cloud Deploy, o serviço grava registros da plataforma e registros de auditoria nos Registros de auditoria do Cloud e de observabilidade do Google 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 com 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.

• Confira o tutorial de perfis do Skaffold do Cloud Deploy.

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