Arquitetura de serviço do Cloud Deploy

Este documento descreve as relações entre o Cloud Deploy e os sistemas externos com os quais funciona para implementar as suas aplicações. Estes sistemas são outros Google Cloud serviços e ferramentas de terceiros.

A vista de nível superior

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

Relações entre os componentes do Cloud Deploy

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

  • O seu sistema de CI

    O Cloud Deploy suporta 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 seus manifestos e para implementar no tempo de execução de destino.

  • Skaffold

    O Cloud Deploy usa o Skaffold através do Cloud Build para renderizar e implementar os seus manifestos, implementando assim a sua aplicação.

  • Cloud Storage

    O Cloud Deploy armazena a origem de renderização e os manifestos renderizados num contentor do Cloud Storage.

  • Google Cloud Observability e registos de auditoria do Cloud.

    O Google Cloud Observability recolhe e disponibiliza dados de registo para o Cloud Deploy.

    Veja também o Registo de auditoria.

  • Pub/Sub

    O Cloud Deploy publica mensagens em vários tópicos do Pub/Sub. Pode usar este serviço para integrar com fluxos de trabalho externos, testes e outros sistemas relacionados.

    Consulte o artigo Subscrever notificações do Cloud Deploy para mais informações.

  • Tempo de execução de destino

    O Cloud Deploy usa o skaffold apply, através do Cloud Build, para implementar as suas aplicações no tempo de execução de destino (GKE ou GKE Enterprise).

Recursos do Cloud Deploy

O diagrama seguinte mostra os recursos que o Cloud Deploy usa para implementar as suas aplicações e as relações entre esses recursos:

Relações entre 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 lançamentos e pode fazer referência a um ou mais alvos, incluindo vários alvos e os respetivos alvos secundários associados.

  • O pipeline de implementação também pode fazer referência a uma ou mais automatizações, que automatizam ações em recursos do Cloud Deploy.

  • Cada lançamento inclui a instância do pipeline, uma "imagem" do pipeline de fornecimento e dos alvos tal como foram configurados quando o lançamento foi criado.

  • Cada lançamento pode gerar zero ou mais implementações e pode fazer referência a zero ou mais artefactos.

    Cada implementação inclui, pelo menos, uma fase, que representa um conjunto de operações (tarefas) numa implementação que estão logicamente agrupadas, por exemplo, uma implementação ou uma implementação e validação.

    Cada fase inclui uma ou mais tarefas, que representam o que deve ser feito na implementação: implementar ou validar. Cada tarefa pode incluir uma ou mais execuções de tarefas, que são instâncias de tarefas, por exemplo, uma tentativa de implementação. Uma execução de tarefa é um recurso secundário da implementação.

    As segmentações múltiplas, usadas para a implementação paralela, criam implementações de controlo, que criam implementações secundárias, que correspondem a segmentações secundárias.

  • Cada implementação está associada a um alvo.

    Para a implementação paralela , cada alvo secundário está associado a uma implementação secundária.

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

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

  • Um artefacto é qualquer resultado do seu processo de CI (por exemplo, uma imagem de contentor) que é implementado num tempo de execução de destino como parte de uma implementação.

Além disso, uma implementação tem uma ou mais fases, e as fases têm uma ou mais tarefas e uma ou mais execuções de tarefas.

Recursos de implementação

Conforme mostrado neste diagrama, uma implementação inclui o seguinte:

  • Fases

    Uma fase contém uma ou mais tarefas (por exemplo, implementar ou implementar e validar). Cada implementação tem uma ou mais fases. Uma fase é uma submensagem numa implementação.

  • Empregos

    A operação específica a realizar numa implementação, por exemplo, implementar ou validar. Uma tarefa é uma submagem numa implementação.

  • JobRuns

    Uma instância de uma tarefa, por exemplo, uma tentativa de validação. Cada tarefa pode ter zero ou mais JobRuns. O JobRun é um recurso secundário de uma implementação.

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

Recursos de automatização

Como se encaixam para disponibilizar o seu lançamento

Esta secção descreve como o Cloud Deploy interage com os componentes indicados neste documento para automatizar a entrega da sua aplicação como uma versão.

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

    O processo de IC chama o Cloud Deploy através da CLI ou da API para criar um novo lançamento, transmitindo os artefactos de compilação ou as referências a imagens.

    Para mais informações sobre a integração do seu sistema de CI, consulte o artigo Integrar o Cloud Deploy com outros sistemas.

  2. Quando é criado um novo lançamento, o Cloud Deploy faz o seguinte:

    1. Armazena uma instância do pipeline de fornecimento como parte do lançamento.

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

      Além disso, a versão do Skaffold é armazenada como parte do lançamento. Na maioria dos casos, esta é a versão do Skaffold predefinida, mas, como pode especificar outras versões, essas informações são armazenadas.

    2. Chama o Cloud Build, que obtém a origem de renderização do Skaffold a partir do Cloud Storage.

      O Cloud Deploy armazena a origem de renderização no contentor do Cloud Storage predefinido ou alternativo.

    3. Chama skaffold diagnose (usando a versão do Skaffold armazenada na criação da versão) para gerar um único manifesto eficaz.

    4. Chama a operação render.

      Se estiver a usar destinos incorporados, o Cloud Deploy chama o comando skaffold render para renderizar o manifesto usando as imagens ou os artefactos de compilação fornecidos. O Cloud Deploy substitui os nomes das imagens em spec.templates.spec.containers.image pelos caminhos completos das imagens (incluindo resumos ou etiquetas) fornecidos no comando gcloud deploy releases create ou num ficheiro de artefactos de compilação referenciado por esse comando.

      Se estiver a usar um alvo personalizado, o Cloud Deploy chama a operação render definida para o respetivo tipo de alvo personalizado.

      O Cloud Deploy armazena o manifesto renderizado no contentor do Cloud Storage predefinido ou alternativo.

      O Cloud Deploy executa estas ações através do ambiente de execução predefinido ou alternativo.

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

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

      Se estiver a usar uma estratégia de implementação canary, os hooks de pré-implementação são chamados no início da primeira fase.

    2. Chama a operação deploy.

      Se estiver a usar alvos incorporados, o Cloud Deploy cria e implementa automaticamente uma implementação gradual no primeiro alvo chamando skaffold apply. Se estiver a usar um destino incorporado, o primeiro lançamento é criado automaticamente após a criação do lançamento.

      Se estiver a usar um alvo personalizado, o Cloud Deploy cria automaticamente uma implementação gradual para o primeiro alvo, chamando a operação deploy definida para o respetivo tipo de alvo personalizado.

      Para segmentações incorporadas e segmentações personalizadas, a implementação na primeira segmentação é automática apenas quando a versão é criada através da linha de comandos.

      O processo de implementação no primeiro destino é o mesmo que para as promoções, conforme descrito no passo seguinte.

    3. Chamadas skaffold verify, se verify for true para o destino no pipeline de entrega config e se a validação for especificada na configuração do Skaffold.

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

      Se estiver a usar uma estratégia de implementação canary, os hooks pós-implementação são executados como a última tarefa na fase de implementação final.

  4. Quando chega a altura de promover a versão para o destino seguinte, o Cloud Build obtem o manifesto específico do destino a partir do Cloud Storage. Em seguida, o Cloud Build invoca o skaffold apply para aplicar o manifesto renderizado ao tempo de execução de destino especificado.

    Se o destino exigir aprovação, pode aprovar ou rejeitar através da CLI ou da consola.

    Além disso, o Cloud Deploy gera uma mensagem do Pub/Sub, à qual se pode subscrever para iniciar automaticamente um fluxo de trabalho de aprovação.

    O Cloud Deploy usa a versão do Skaffold e a instância do pipeline associadas a esta versão e executa este passo no ambiente de execução predefinido ou personalizado.

    Este processo aplica-se não só às promoções, mas também às reversões e às reimplementações.

  5. Ao longo das operações do Cloud Deploy, o serviço publica notificações em vários tópicos do Pub/Sub (por exemplo, quando uma implementação requer aprovação).

    Esta e outras integrações são descritas mais detalhadamente no artigo Integrar o Cloud Deploy com sistemas externos.

  6. Pode especificar uma automatização para realizar automaticamente várias operações no pipeline de entrega. Estas podem ser executadas na hora designada. Um automationRun representa uma execução de regra de automatização.

  7. Durante a operação do Cloud Deploy, o serviço escreve registos da plataforma e registos de auditoria no Google Cloud Observability e nos registos de auditoria da nuvem.

Em todos estes passos, o controlo do fluxo e o acesso aos recursos são restritos através da gestão de identidade e de acesso.

O que se segue?