O blueprint do aplicativo empresarial é implantado por meio de uma série de sistemas e pipelines automatizados. Cada pipeline implanta um aspecto específico do blueprint. Os pipelines fornecem um mecanismo controlável, auditável e repetível para criar o blueprint. O diagrama a seguir mostra a interação de vários pipelines, repositórios e perfis.
O blueprint usa os seguintes pipelines:
- O pipeline de infraestrutura de base (parte do blueprint de bases empresariais) implanta a fábrica de aplicativos, o pipeline de infraestrutura multilocatário e o pipeline com escopo rápido.
- O pipeline de infraestrutura de vários locatários implanta os clusters do GKE e os outros serviços gerenciados que são usados no blueprint do aplicativo empresarial.
- O pipeline do escopo da frota configura escopos, namespaces, papéis e vinculações do RBAC da frota.
- A fábrica de aplicativos oferece um mecanismo para implantar novos pipelines de aplicativos por meio de um processo de modelo.
- O pipeline de CI/CD do aplicativo fornece um pipeline de CI/CD para implantar serviços em clusters do GKE.
- O Config Sync implanta e mantém outras configurações do Kubernetes, incluindo restrições do Policy Controller.
Repositórios, colaboradores do repositório e aprovadores de alterações no repositório
Os pipelines de blueprint são acionados por alterações nos repositórios Git. Na tabela a seguir, descrevemos os repositórios usados no blueprint, quem contribui com o repositório, quem aprova mudanças nele, qual pipeline usa o repositório e a descrição do que o repositório contém.
| Repositório | Colaborador do repositório | Aprovador de alterações no repositório | Pipeline | Descrição |
|---|---|---|---|---|
|
Desenvolvedor da plataforma para desenvolvedores |
Administrador da plataforma do desenvolvedor |
Pipeline de infraestrutura de base |
Repositório que contém o código para implantar o pipeline de infraestrutura multilocatário, o aplicativo e o pipeline do escopo da frota |
|
Desenvolvedor da plataforma para desenvolvedores |
Administrador da plataforma do desenvolvedor |
Infraestrutura multilocatária |
Os módulos do Terraform que são usados pelas equipes de plataforma de desenvolvimento ao criar a infraestrutura |
|
Desenvolvedor da plataforma para desenvolvedores |
Administrador da plataforma do desenvolvedor |
Escopo da frota |
O repositório que define os escopos e os namespaces da equipe da frota na frota |
|
Desenvolvedor da plataforma para desenvolvedores |
Administrador da plataforma do desenvolvedor |
Fábrica de aplicativos |
O código que define o repositório do aplicativo e faz referência aos
módulos no repositório |
|
Desenvolvedor de aplicativos |
Operador do aplicativo |
Fábrica de aplicativos |
O código base que é colocado no repositório |
|
Desenvolvedor da plataforma para desenvolvedores |
Administrador da plataforma do desenvolvedor |
Fábrica de aplicativos Infraestrutura multilocatária |
Os módulos do Terraform que definem o aplicativo e a infraestrutura |
|
Desenvolvedor de aplicativos |
Operador do aplicativo |
CI/CD de aplicativos |
O código do aplicativo implantado nos clusters do GKE |
|
Desenvolvedor da plataforma para desenvolvedores |
Administrador da plataforma do desenvolvedor |
Config Sync |
As políticas usadas pelos clusters do GKE para manter as configurações |
Os pipelines automatizados ajudam a criar segurança, auditoria, rastreabilidade, repetibilidade, controle e conformidade no processo de implantação. Ao usar sistemas diferentes com permissões distintas e colocar pessoas diferentes em grupos operacionais distintos, você cria uma separação de responsabilidades e segue o princípio de privilégio mínimo.
Pipeline de infraestrutura de base
O pipeline da infraestrutura de base é descrito no blueprint de bases corporativas e é usado como um ponto de entrada genérico para outras implantações de recursos. A tabela a seguir descreve os componentes criados pelo pipeline.
| Componente | Descrição |
|---|---|
Cria a infraestrutura compartilhada que é usada por todos os locatários da plataforma de desenvolvimento. |
|
Cria namespaces e vinculações de papéis do RBAC. |
|
Cria os pipelines de CI/CD do aplicativo que são usados para implantar os serviços. |
Pipeline de infraestrutura multilocatário
O pipeline de infraestrutura de vários locatários implanta frotas, clusters do GKE e recursos compartilhados relacionados. O diagrama a seguir mostra os componentes do pipeline de infraestrutura de vários locatários.
A tabela a seguir descreve os componentes criados pelo pipeline de infraestrutura multilocatário.
| Componente | Descrição |
|---|---|
Clusters do GKE |
Fornece hospedagem para os serviços do aplicativo conteinerizado. |
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 criptografia baseada na chave de criptografia gerenciada pelo cliente (CMEK) para GKE, AlloyDB para PostgreSQL e Secret Manager. |
|
Secret de Secret Manager |
Fornece um repositório de secrets para o par de chaves RSA usado para a autenticação do usuário com JSON Web Tokens (JWT). |
Fornece a política usada pelo firewall do aplicativo da Web do Google Cloud Armor. |
Pipeline do escopo da frota
O pipeline com escopo da frota é responsável por configurar os namespaces e as vinculações do RBAC nos clusters do GKE da frota. Na tabela a seguir, descrevemos os componentes criados pelo pipeline com escopo da frota.
| Componente | Descrição |
|---|---|
Define os clusters lógicos no cluster físico. |
|
RBAC (Papéis e vinculações) (em inglês) |
Define a autorização que uma conta de serviço do Kubernetes tem no nível do cluster ou do namespace. |
Fábrica de aplicativos
Ela é implantada pelo pipeline de infraestrutura da fundação e é usada para criar a infraestrutura para cada aplicativo novo. Essa infraestrutura inclui um projeto do Google Cloud que contém o pipeline de CI/CD do aplicativo.
À medida que as organizações de engenharia escalonam, a equipe de aplicativos pode integrar novos aplicativos usando a fábrica de aplicativos. O escalonamento permite o crescimento adicionando pipelines de CI/CD de aplicativos discretos e oferecendo suporte à infraestrutura para implantar novos aplicativos na arquitetura multilocatária. O diagrama a seguir mostra a fábrica do aplicativo.
Essa fábrica tem os seguintes componentes:
- Repositório de fábrica de aplicativos:um repositório Git que armazena a definição declarativa do aplicativo.
- Pipelines para criar aplicativos:pipelines que exigem
que o Cloud Build conclua o seguinte:
- Criar uma definição de aplicativo declarativa e armazená-la no catálogo de aplicativos.
- Aplique a definição declarativa de aplicativo para criar os recursos do aplicativo.
- Repositório de modelos de aplicativos iniciais:modelos para criar um aplicativo simples, como um microsserviço em Python, Golang ou Java.
- Módulos compartilhados:módulos do Terraform criados com práticas padrão e usados para várias finalidades, incluindo a integração e implantação de aplicativos.
A tabela a seguir lista os componentes que a fábrica de aplicativos cria para cada aplicativo.
| Componente | Descrição |
|---|---|
Repositório de código-fonte do aplicativo |
Contém o código-fonte e a configuração relacionada usados para criar e implantar um aplicativo específico. |
Pipeline de CI/CD do aplicativo |
Um pipeline baseado no Cloud Build que é usado para se conectar ao repositório de código-fonte e fornece um pipeline de CI/CD para implantar serviços de aplicativos. |
Pipeline de CI/CD do aplicativo
O pipeline de CI/CD do aplicativo permite a criação e implantação automatizadas de aplicativos baseados em contêiner. O pipeline consiste em etapas de integração contínua (CI) e implantação contínua (CD). A arquitetura do pipeline é baseada no Blueprint de CI/CD seguro.
O pipeline de CI/CD do aplicativo usa imagens de contêiner imutáveis em todos os ambientes. Imagens de contêiner imutáveis ajudam a garantir que a mesma imagem seja implantada em todos os ambientes e não seja modificada enquanto o contêiner estiver em execução. Se precisar atualizar o código do aplicativo ou aplicar um patch, crie uma nova imagem e implante-a novamente. O uso de imagens de contêiner imutáveis exige que você externalize a configuração do contêiner para que as informações de configuração sejam lidas durante o tempo de execução.
Para alcançar os clusters do GKE por um caminho de rede particular e gerenciar a autenticação kubeconfig, o pipeline de CI/CD do aplicativo interage com os
clusters do GKE pelo gateway do Connect. O pipeline também usa pools privados (em inglês) para o ambiente de CI/CD.
Cada repositório de código-fonte do aplicativo inclui configurações do Kubernetes. Com essas configurações, os aplicativos podem ser executados como serviços do Kubernetes no GKE. Na tabela a seguir, descrevemos os tipos de configurações do Kubernetes aplicadas pelo pipeline de CI/CD do aplicativo.
| Componente | Descrição |
|---|---|
Define um conjunto escalonado de pods (contêineres). |
|
Torna uma implantação acessível pela rede do cluster. |
|
Torna um serviço parte da malha de serviço. |
|
Define como os peerings na malha de serviço devem alcançar um serviço virtual. Usado no blueprint para configurar o balanceamento de carga da localidade para o tráfego leste-oeste. |
|
Define o controle de acesso entre as cargas de trabalho na malha de serviço. |
|
Define uma identidade usada por um serviço do Kubernetes. A Identidade da carga de trabalho define a conta de serviço do Google Cloud usada para acessar os recursos do Google Cloud. |
|
Permite que o tráfego de entrada externo alcance um serviço. O gateway só é exigido por implantações que recebem tráfego externo. |
|
Configure o SSL, o Google Cloud Armor, a afinidade da sessão e a diminuição da conexão para implantações que recebem tráfego externo. A GCPBackendPolicy é usada apenas por implantações que recebem tráfego externo. |
|
Configura a coleta de métricas do Prometheus exportadas por um aplicativo. |
Integração contínua
O diagrama a seguir mostra o processo de integração contínua.
O processo é o seguinte:
- O desenvolvedor confirma o código do aplicativo no repositório de origem do aplicativo. Esta operação aciona o Cloud Build para iniciar o pipeline de integração.
- O Cloud Build cria uma imagem de contêiner, envia a imagem do contêiner para o Artifact Registry e cria um resumo de imagem.
- O Cloud Build executa testes automatizados para o aplicativo. Dependendo da linguagem do aplicativo, diferentes pacotes de teste podem ser executados.
- O Cloud Build faz as seguintes verificações na imagem do contêiner:
- O Cloud Build analisa o contêiner usando o framework de testes de estrutura de contêiner. Esse framework realiza testes de comando, testes de existência de arquivos, testes de conteúdo de arquivos e testes de metadados.
- O Cloud Build usa a verificação de vulnerabilidades para identificar qualquer vulnerabilidade na imagem do contêiner em relação a um banco de dados de vulnerabilidades mantido pelo Google Cloud.
- O Cloud Build aprova a imagem para continuar no pipeline após os resultados da verificação bem-sucedidos.
- A autorização binária assina a imagem. A autorização binária é um serviço do Google Cloud que fornece segurança de cadeia de fornecimento de software para aplicativos baseados em contêiner usando políticas, regras, observações, atestados, atestadores e signatários. No momento da implantação, o implementador de políticas de autorização binária garante a procedência do contêiner antes de permitir que ele seja implantado.
- O Cloud Build cria uma versão no Cloud Deploy para iniciar o processo de implantação.
Para conferir as informações de segurança de um build, acesse o Painel de insights de segurança. Esses insights incluem vulnerabilidades que foram detectadas usando o Artifact Analysis e o nível de garantia de segurança do build indicado pelas diretrizes da SLSA.
Ao criar seu aplicativo, siga as práticas recomendadas para criar contêineres.
Implantação contínua
O diagrama a seguir mostra o processo de implantação contínua.
O processo é o seguinte:
- No final do processo de compilação, o pipeline de CI/CD do aplicativo cria uma nova versão do Cloud Deploy para iniciar as imagens de contêiner recém-criadas progressivamente em cada ambiente.
- O Cloud Deploy inicia um lançamento no primeiro ambiente do pipeline de implantação, que geralmente é desenvolvimento. Cada estágio de implantação é configurado para exigir aprovação manual.
- Os pipelines do Cloud Deploy usam implantação sequencial para implantar imagens em cada cluster em um ambiente em ordem.
- Ao final de cada estágio de implantação, o Cloud Deploy verifica a funcionalidade dos contêineres implantados. Essas etapas podem ser definidas na configuração do Skaffold dos aplicativos.
Como implantar um novo aplicativo
O diagrama a seguir mostra como a fábrica de aplicativos e o pipeline de CI/CD de aplicativos trabalham juntos para criar e implantar um novo aplicativo.
Este é o processo para definir um novo aplicativo:
- Um operador de aplicativo define um novo aplicativo no locatário dele executando um gatilho do Cloud Build para gerar a definição do aplicativo.
- O gatilho adiciona uma nova entrada para o aplicativo no Terraform e confirma a alteração no repositório da fábrica do aplicativo.
- A alteração confirmada aciona a criação de projetos e repositórios específicos do aplicativo.
- O Cloud Build completa o seguinte:
- Cria dois novos repositórios Git para hospedar o código-fonte e a IaC do aplicativo.
- Envia os manifestos do Kubernetes para políticas de rede e a Identidade da carga de trabalho para o repositório de gerenciamento de configuração.
- Cria o projeto de CI/CD do aplicativo e o acionador de IaC do Cloud Build.
- O gatilho de IaC do Cloud Build para o aplicativo cria o pipeline de CI/CD do aplicativo e o repositório do Artifact Registry no projeto de CI/CD do aplicativo.
- O Config Sync implanta as políticas de rede e as configurações de Identidade da carga de trabalho nos clusters multilocatários do GKE.
- O pipeline de criação do escopo da frota cria o escopo e o namespace da frota para o aplicativo em clusters do GKE multilocatário.
- O pipeline de CI/CD do aplicativo executa a implantação inicial do aplicativo nos clusters do GKE.
- Opcionalmente, a equipe do aplicativo usa o gatilho de IaC do Cloud Build para implantar projetos e recursos adicionais (por exemplo, bancos de dados e outros serviços gerenciados) em projetos dedicados de locatário único, um para cada ambiente.
Configuração do GKE Enterprise e gerenciamento de políticas
No blueprint, os administradores da plataforma de desenvolvimento usam o Config Sync para criar configurações no nível do cluster em cada ambiente. O Config Sync se conecta a um repositório Git que serve como a fonte da verdade para o estado escolhido da configuração do cluster. O Config Sync monitora continuamente o estado real da configuração nos clusters e reconcilia qualquer discrepância aplicando atualizações para garantir a adesão ao estado escolhido, apesar das alterações manuais. As configurações são aplicadas aos ambientes (desenvolvimento, não produção e produção) por meio de uma estratégia de ramificação no repositório.
Nesse blueprint, o Config Sync aplica as restrições do Policy Controller. Essas configurações definem os controles de segurança e conformidade conforme definidos pelos administradores da plataforma de desenvolvimento da organização. Esse blueprint depende de outros pipelines para aplicar outras configurações: os pipelines de CI/CD do aplicativo aplicam uma configuração específica do aplicativo, e o pipeline com escopo da frota cria namespaces e vinculações de papéis associadas.
A seguir
- Leia sobre a arquitetura de aplicativos do Cymbal Bank (próximo documento desta série).