O projeto de aplicação empresarial é implementado através de uma série de sistemas e pipelines automatizados. Cada pipeline implementa um aspeto específico do projeto. Os pipelines oferecem um mecanismo controlável, auditável e repetível para criar o plano. O diagrama seguinte mostra a interação dos vários pipelines, repositórios e perfis fictícios.
O plano usa os seguintes pipelines:
- O pipeline de infraestrutura de base (parte do projeto de base empresarial) implementa a fábrica de aplicações, o pipeline de infraestrutura multiinquilino e o pipeline de âmbito da frota.
- O pipeline de infraestrutura multiinquilino implementa os clusters do GKE e os outros serviços geridos nos quais o esquema da aplicação empresarial se baseia.
- A configuração do pipeline ao nível da frota configura âmbitos da frota, espaços de nomes e funções e associações de RBAC.
- A fábrica de aplicações oferece um mecanismo para implementar novos pipelines de aplicações através de um processo baseado em modelos.
- O pipeline de CI/CD da aplicação fornece um pipeline de CI/CD para implementar serviços em clusters do GKE.
- A sincronização de configurações implementa e mantém configurações adicionais do Kubernetes, incluindo restrições do Policy Controller.
Repositórios, colaboradores do repositório e aprovadores de alterações do repositório
Os pipelines de planos são acionados através de alterações aos repositórios Git. A tabela seguinte descreve os repositórios usados em todo o projeto, quem contribui para o repositório, quem aprova alterações ao repositório, que pipeline usa o repositório e a descrição do conteúdo do repositório.
| Repositório | Colaborador do repositório | Aprovador de alteração de repositório | Fornecimento | Descrição |
|---|---|---|---|---|
|
Programador da plataforma para programadores |
Administrador da plataforma para programadores |
Pipeline de infraestrutura de base |
Repositório que contém o código para implementar o pipeline de infraestrutura multiinquilino, a aplicação e o pipeline de âmbito da frota |
|
Programador da plataforma para programadores |
Administrador da plataforma para programadores |
Infraestrutura multi-inquilino |
Os módulos do Terraform que são usados pelas equipas da plataforma de programadores quando criam a infraestrutura |
|
Programador da plataforma para programadores |
Administrador da plataforma para programadores |
Âmbito da frota |
O repositório que define os âmbitos e os espaços de nomes da equipa de frota no fleet |
|
Programador da plataforma para programadores |
Administrador da plataforma para programadores |
Application factory |
O código que define o repositório da aplicação e faz referência aos módulos no repositório |
|
Programador de aplicações |
Operador de aplicações |
Application factory |
O código base que é colocado no repositório |
|
Programador da plataforma para programadores |
Administrador da plataforma para programadores |
Application factory Infraestrutura multi-inquilino |
Os módulos do Terraform que definem a aplicação e a infraestrutura |
|
Programador de aplicações |
Operador de aplicações |
CI/CD de aplicações |
O código da aplicação implementado nos clusters do GKE |
|
Programador da plataforma para programadores |
Administrador da plataforma para programadores |
Config Sync |
As políticas usadas pelos clusters do GKE para manter as respetivas configurações |
Os pipelines automatizados ajudam a incorporar segurança, capacidade de auditoria, rastreabilidade, repetibilidade, capacidade de controlo e conformidade no processo de implementação. Ao usar diferentes sistemas com diferentes autorizações e colocar diferentes pessoas em diferentes grupos operacionais, cria uma separação de responsabilidades e segue o princípio do menor privilégio.
Pipeline de infraestrutura de base
A pipeline de infraestrutura de base está descrita no projeto de base empresarial e é usada como um ponto de entrada genérico para implementações de recursos adicionais. A tabela seguinte descreve os componentes criados pelo pipeline.
| Componente | Descrição |
|---|---|
Cria a infraestrutura partilhada que é usada por todos os inquilinos da plataforma de programadores. |
|
Cria espaços de nomes e associações de funções RBAC. |
|
Cria os pipelines de CI/CD da aplicação que são usados para implementar os serviços. |
Pipeline de infraestrutura multi-inquilino
O pipeline de infraestrutura de vários inquilinos implementa frotas, clusters do GKE e recursos partilhados relacionados. O diagrama seguinte mostra os componentes do pipeline de infraestrutura multiinquilino.
A tabela seguinte descreve os componentes que a pipeline de infraestrutura multilocatária cria.
| Componente | Descrição |
|---|---|
Clusters do GKE |
Oferece alojamento para os serviços da aplicação em contentor. |
Controlador de políticas |
Fornece políticas que ajudam a garantir a configuração adequada dos clusters e serviços do GKE. |
Config Sync |
Aplica as políticas do Policy Controller aos clusters e mantém a aplicação consistente das políticas. |
Cria a chave de encriptação baseada na chave de encriptação gerida pelo cliente (CMEK) para o GKE, o AlloyDB para PostgreSQL e o Secret Manager. |
|
Segredo do Secret Manager |
Fornece um repositório secreto para o par de chaves RSA que é usado para a autenticação do utilizador com tokens Web JSON (JWT). |
Fornece a política usada pela firewall de aplicações Web do Cloud Armor. |
Pipeline ao nível da frota
O pipeline de âmbito da frota é responsável pela configuração dos espaços de nomes e das associações RBAC nos clusters do GKE da frota. A tabela seguinte descreve os componentes que o pipeline de âmbito da frota cria.
| Componente | Descrição |
|---|---|
Define os clusters lógicos no cluster físico. |
|
Define a autorização que uma conta de serviço do Kubernetes tem ao nível do cluster ou do espaço de nomes. |
Application factory
A fábrica de aplicações é implementada pelo pipeline de infraestrutura de base e é usada para criar infraestrutura para cada nova aplicação. Esta infraestrutura inclui um projeto que contém o pipeline de CI/CD da aplicação. Google Cloud
À medida que as organizações de engenharia crescem, a equipa de aplicações pode integrar novas aplicações através da fábrica de aplicações. O escalamento permite o crescimento através da adição de pipelines de CI/CD de aplicações discretas e do suporte da infraestrutura para implementar novas aplicações na arquitetura multiinquilino. O diagrama seguinte mostra a fábrica de aplicações.
A fábrica de aplicações tem os seguintes componentes:
- Repositório da fábrica de aplicações: um repositório Git que armazena a definição declarativa da aplicação.
- Pipelines para criar aplicações: pipelines que requerem que o Cloud Build conclua o seguinte:
- Crie uma definição de aplicação declarativa e armazene-a no catálogo de aplicações.
- Aplique a definição declarativa da aplicação para criar os recursos da aplicação.
- Repositório de modelos de aplicações iniciais: modelos para criar uma aplicação simples (por exemplo, um microsserviço Python, Golang ou Java).
- Módulos partilhados: módulos Terraform criados com práticas padrão e usados para vários fins, incluindo a integração e a implementação de aplicações.
A tabela seguinte lista os componentes que a fábrica de aplicações cria para cada aplicação.
| Componente | Descrição |
|---|---|
Repositório de código-fonte da aplicação |
Contém código fonte e configuração relacionada usados para criar e implementar uma aplicação específica. |
Pipeline de CI/CD da aplicação |
Um pipeline baseado no Cloud Build que é usado para estabelecer ligação ao repositório de código fonte e fornece um pipeline de CI/CD para implementar serviços de aplicações. |
Pipeline de CI/CD da aplicação
O pipeline de CI/CD de aplicações permite a criação e a implementação automatizadas de aplicações baseadas em contentores. O pipeline consiste em passos de integração contínua (CI) e implementação contínua (CD). A arquitetura de pipeline baseia-se no projeto de CI/CD seguro.
O pipeline de CI/CD da aplicação usa imagens de contentores imutáveis em todos os seus ambientes. As imagens de contentores imutáveis ajudam a garantir que a mesma imagem é implementada em todos os ambientes e não é modificada enquanto o contentor está em execução. Se tiver de atualizar o código da aplicação ou aplicar um patch, cria uma nova imagem e volta a implementá-la. A utilização de imagens de contentores imutáveis requer que externalize a configuração do contentor para que as informações de configuração sejam lidas durante o tempo de execução.
Para alcançar clusters do GKE através de um caminho de rede privada e gerir a kubeconfig
autenticação, o pipeline de CI/CD da aplicação interage com os
clusters do GKE através do gateway do Connect. O pipeline também usa
pools privados
para o ambiente de CI/CD.
Cada repositório de código fonte da aplicação inclui configurações do Kubernetes. Estas configurações permitem que as aplicações sejam executadas com êxito como serviços do Kubernetes no GKE. A tabela seguinte descreve os tipos de configurações do Kubernetes que o pipeline de CI/CD da aplicação aplica.
| Componente | Descrição |
|---|---|
Define um conjunto dimensionado de pods (contentores). |
|
Torna uma implementação acessível através da rede do cluster. |
|
Torna um serviço parte da malha de serviço. |
|
Define como os pares na malha de serviços devem alcançar um serviço virtual. Usado no projeto para configurar o equilíbrio de carga de localidade para tráfego leste-oeste. |
|
Define o controlo de acesso entre cargas de trabalho na malha de serviços. |
|
Define a identidade usada por um serviço Kubernetes. A federação de identidades da carga de trabalho para o GKE define a Google Cloud conta de serviço que é usada para aceder aos Google Cloud recursos. |
|
Permite que o tráfego de entrada externo alcance um serviço. O gateway só é necessário para implementações que recebem tráfego externo. |
|
Configure o SSL, o Cloud Armor, a afinidade de sessão e a drenagem de ligações para implementações que recebem tráfego externo. A GCPBackendPolicy é usada apenas por implementações que recebem tráfego externo. |
|
Configura a recolha de métricas do Prometheus exportadas por uma aplicação. |
Integração contínua
O diagrama seguinte mostra o processo de integração contínua.
O processo é o seguinte:
- Um programador compromete o código da aplicação com o repositório de origem da aplicação. Esta operação aciona o Cloud Build para iniciar o pipeline de integração.
- O Cloud Build cria uma imagem de contentor, envia a imagem de contentor para o Artifact Registry e cria um resumo da imagem.
- O Cloud Build executa testes automáticos para a aplicação. Consoante o idioma da aplicação, podem ser realizados diferentes pacotes de testes.
- O Cloud Build executa as seguintes análises na imagem de contentor:
- O Cloud Build analisa o contentor através da estrutura Container Structure Tests. Esta estrutura executa testes de comandos, testes de existência de ficheiros, testes de conteúdo de ficheiros e testes de metadados.
- O Cloud Build usa a análise de vulnerabilidades para identificar vulnerabilidades na imagem do contentor em comparação com uma base de dados de vulnerabilidades mantida pela Google Cloud.
- O Cloud Build aprova a imagem para continuar no pipeline após resultados de análise bem-sucedidos.
- A autorização binária assina a imagem. A Autorização binária é um serviço no Google Cloud que oferece segurança da cadeia de fornecimento de software para aplicações baseadas em contentores através da utilização de políticas, regras, notas, atestations, attestors, e signers. No momento da implementação, o aplicador de políticas de autorização binária ajuda a garantir a proveniência do contentor antes de permitir a implementação do contentor.
- O Cloud Build cria um lançamento no Cloud Deploy para iniciar o processo de implementação.
Para ver as informações de segurança de uma compilação, aceda ao painel Estatísticas de segurança. Estas estatísticas incluem vulnerabilidades detetadas através da análise de artefactos e o nível de garantia de segurança da compilação indicado pelas diretrizes da SLSA.
Implementação contínua
O diagrama seguinte mostra o processo de implementação contínua.
O processo é o seguinte:
- No final do processo de compilação, o pipeline de CI/CD da aplicação cria um novo lançamento do Cloud Deploy para iniciar as imagens de contentores recém-criadas progressivamente em cada ambiente.
- O Cloud Deploy inicia uma implementação gradual no primeiro ambiente do pipeline de implementação, que é normalmente o de desenvolvimento. Cada fase de implementação está configurada para exigir aprovação manual.
- Os pipelines do Cloud Deploy usam a implementação sequencial para implementar imagens em cada cluster num ambiente por ordem.
- No final de cada fase de implementação, o Cloud Deploy valida a funcionalidade dos contentores implementados. Estes passos são configuráveis na configuração do Skaffold para as aplicações.
Implementar uma nova aplicação
O diagrama seguinte mostra como a fábrica de aplicações e o pipeline de CI/CD de aplicações funcionam em conjunto para criar e implementar uma nova aplicação.
O processo para definir uma nova aplicação é o seguinte:
- Um operador de aplicações define uma nova aplicação no respetivo inquilino executando um acionador do Cloud Build para gerar a definição da aplicação.
- O acionador adiciona uma nova entrada para a aplicação no Terraform e confirma a alteração no repositório da fábrica de aplicações.
- A alteração confirmada aciona a criação de repositórios e projetos específicos da aplicação.
- O Cloud Build conclui o seguinte:
- Cria dois novos repositórios Git para alojar o código fonte da aplicação e a IaC.
- Envia os manifestos do Kubernetes para políticas de rede e Workload Identity Federation para o GKE para o repositório de gestão de configuração.
- Cria o projeto de CI/CD da aplicação e o acionador de IaC do Cloud Build.
- O acionador de IaC do Cloud Build para a aplicação cria o pipeline de CI/CD da aplicação e o repositório do Artifact Registry no projeto de CI/CD da aplicação.
- O Config Sync implementa as políticas de rede e a Workload Identity Federation para configurações do GKE nos clusters do GKE multiinquilino.
- O pipeline de criação do âmbito da frota cria o âmbito da frota e o espaço de nomes para a aplicação em clusters do GKE multiinquilino.
- A pipeline de CI/CD da aplicação faz a implementação inicial da aplicação nos clusters do GKE.
- Opcionalmente, a equipa de aplicações usa o acionador de IaC do Cloud Build para implementar projetos e recursos adicionais (por exemplo, bases de dados e outros serviços geridos) em projetos de inquilino único dedicados, um para cada ambiente.
Gestão de políticas e configuração do GKE Enterprise
No plano, os administradores da plataforma de programadores usam a sincronização de configuração para criar configurações ao nível do cluster em cada ambiente. O Config Sync liga-se a um repositório Git que serve como fonte de verdade para o estado escolhido da configuração do cluster. O Config Sync monitoriza continuamente o estado real da configuração nos clusters e reconcilia quaisquer discrepâncias aplicando atualizações para garantir a conformidade com o estado escolhido, apesar das alterações manuais. As configurações são aplicadas aos ambientes (desenvolvimento, não produção e produção) através de uma estratégia de ramificação no repositório.
Neste esquema, o Config Sync aplica restrições do Policy Controller. Estas configurações definem os controlos de segurança e conformidade, conforme definidos pelos administradores da plataforma de programadores para a organização. Este esquema baseia-se noutros pipelines para aplicar outras configurações: os pipelines de CI/CD da aplicação aplicam a configuração específica da aplicação e o pipeline de âmbito da frota cria espaços de nomes e associações de funções associadas.
O que se segue?
- Leia acerca da arquitetura da aplicação Cymbal Bank (documento seguinte nesta série).