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 de que ele depende.

Relacionamentos entre os componentes do Cloud Deploy

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 seu 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 pelo Cloud Build para renderizar e implantar seus manifestos, implantando assim seu aplicativo.

  • Cloud Storage

    O Cloud Deploy armazena manifestos de origem e renderizados em um bucket do Cloud Storage.

  • Google Cloud Observability e Registros de auditoria do Cloud.

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

  • Tempo de execução de destino

    O Cloud Deploy usa o skaffold apply, pelo 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 eles:

Relações entre os recursos do Cloud Deploy

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

  • O pipeline de entrega pode gerar zero ou mais versões e pode fazer referência a um ou mais destinos, incluindo destinos múltiplos e os destinos filhos associados.

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

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

  • Cada versão pode gerar zero ou mais implantações e pode referenciar zero ou mais artefatos.

    Cada lançamento inclui pelo menos uma fase, que representa uma coleção de operações (jobs) em um lançamento que são agrupadas de forma lógica, por exemplo, um lançamento ou um lançamento e verificação.

    Cada fase inclui um ou mais jobs, que representam o que precisa ser feito no lançamento, seja a implantação ou a 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 implantações de controladores, que criam implantações filhos, que correspondem a destinos filhos.

  • Cada lançamento é associado a um destino.

    Na implantação paralela , cada destino filho é associado a um lançamento filho.

  • Cada destino é associado a um cluster do GKE ou do Anthos ou a outro destino de execução do 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) que é 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 job.

Recursos de lançamento

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

  • Fases

    Uma fase contém um ou mais jobs, por exemplo, implantação ou implantação e verificação. 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. A execução de job é 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 AutomationRun. As AutomationRuns são instâncias de regras de automação executadas, por exemplo, uma promoção automática de um destino para outro. Os recursos Automation e AutomationRun são recursos filhos de pares abaixo de um pipeline de envio.

Recursos de Automation

Como eles funcionam juntos para entregar sua versão

Esta seção descreve como o Cloud Deploy interage com os componentes listados neste documento para automatizar a entrega do seu 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 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, essa informação é armazenada.

    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 a operação render.

      Se você estiver usando destinos integrados, o Cloud Deploy vai chamar skaffold render para renderizar o manifesto usando as imagens ou os artefatos de build fornecidos. O Cloud Deploy substitui nomes de imagens em spec.templates.spec.containers.image pelos caminhos de imagens 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 vai 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 realiza 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 mais tarde), o Cloud Deploy faz o seguinte:

    1. Chama ganchos de pré-implantação, se especificados.

      Se você estiver usando uma estratégia de implantação de 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 vai 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.

      Se você estiver usando um destino personalizado, o Cloud Deploy vai 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 no pipeline de entrega config e se a verificação for especificada na configuração do Skaffold.

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

      Se você estiver usando uma estratégia de implantação de 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, que você pode assinar para iniciar automaticamente um fluxo de trabalho de aprovação.

    O Cloud Deploy usa a versão Skaffold e a instância do pipeline associada 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. Em todas 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).

    Esta e outras integrações são descritas mais detalhadamente em Como integrar o Cloud Deploy a sistemas externos.

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

  7. Durante a operação do Cloud Deploy, o serviço grava registros de plataforma e de auditoria na Observability e nos registros de auditoria 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