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.
Conforme mostrado neste diagrama, o Cloud Deploy interage com os seguintes sistemas:
O seu sistema de IC
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.
-
O Cloud Deploy chama o Cloud Build para renderizar os seus manifestos e para fazer a implementação no tempo de execução de destino.
-
O Cloud Deploy usa o Skaffold através do Cloud Build para renderizar e implementar os seus manifestos, implementando assim a sua aplicação.
-
O Cloud Deploy armazena a origem da renderização e os manifestos renderizados num contentor do Cloud Storage.
Observabilidade do Google Cloud 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.
-
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, Cloud Run ou um destino personalizado).
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:
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, ou seja, 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 controlador, 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 destino secundário está associado a uma implementação secundária.
Cada destino está associado a um cluster do GKE 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.
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 submensagem 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.
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.
O seu sistema de CI invoca um pipeline de entrega do Cloud Deploy.
O seu processo de CI 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.
Quando é criado um novo lançamento, o Cloud Deploy faz o seguinte:
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, as versões das ferramentas são armazenadas como parte do lançamento. Na maioria dos casos, estas são as versões das ferramentas predefinidas, mas, como pode especificar outras versões, essas informações são armazenadas.