Arquitetura do serviço Google Cloud Deploy

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Neste documento, descrevemos as relações entre o Google 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 Google Cloud Deploy e os sistemas separados de que ele depende.

Relacionamentos entre os componentes do Cloud Deploy

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

  • Seu sistema de CI

    O Google 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 o Google Cloud Deploy API ou osCLI criar uma versão.

  • Cloud Build

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

  • Skaffold

    O Google Cloud Deploy usa o Skaffold por meio do Cloud Build para renderizar e implantar seus manifestos, implantando assim seu aplicativo.

  • Cloud Storage

    O Google Cloud Deploy armazena manifestos de origem e 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 Google Cloud Deploy.

    Consulte também Registro de auditoria.

  • Pub/Sub

    O Google 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 Google Cloud Deploy para mais informações.

  • Tempo de execução de destino

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

Recursos do Google Cloud Deploy

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

Relacionamentos entre os recursos do Cloud Deploy

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

  • O pipeline de entrega pode gerar zero ou mais versões e pode referenciar um ou mais destinos.

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

  • Cada versão pode render zero ou mais implementações e 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 um lançamento agrupadas de maneira lógica, por exemplo, uma implantação ou uma implantação e verificação.

    Cada fase inclui um ou mais jobs, representando o que precisa ser feito na implantação, seja de implantação ou verificação. Cada job pode incluir uma ou mais execuções, 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.

  • Cada lançamento é associado a um destino.

  • Cada destino está associado a um cluster do GKE ou do Anthos ou a outro destino de ambiente 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) 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.

Recursos de lançamento

Como mostrado neste diagrama, o 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, a implantação ou a verificação. Um job é uma submensagem em um lançamento.

  • Execuções do job

    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 Google 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 Google Cloud Deploy.

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

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

  2. Quando uma nova versão é criada, o Google 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 serão armazenadas.

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

      O Google 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 Google 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 versão referenciado por esse comando.

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

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

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

      Isso só acontece quando o Google Cloud Deploy é invocado na 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.

    6. Chame 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 Google Cloud Deploy gera uma mensagem do Pub/Sub, que você pode assinar para iniciar automaticamente um fluxo de trabalho de aprovação.

    O Google 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.

  4. Em todas as operações do Google 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 Google Cloud Deploy a sistemas externos.

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