Essa arquitetura de referência oferece um método e uma infraestrutura
inicial para criar um sistema moderno de integração/entrega contínuas
(CI/CD) usando ferramentas como
Google Kubernetes Engine,
Cloud Build,
Skaffold,
kustomize
,
Config Sync,
Controlador de Políticas,
Artifact Registry,
and
Cloud Deploy.
Este documento faz parte de uma série:
- CI/CD moderno com GKE: um framework de entrega de software
- CI/CD moderno com Anthos: como criar um sistema de CI/CD (este documento)
- CI/CD moderno com GKE: como aplicar o fluxo de trabalho do desenvolvedor
Este documento destina-se a arquitetos corporativos e desenvolvedores de aplicativos, bem como a equipes de TI, DevOps e engenharia de confiabilidade do site. Algumas experiências com processos e ferramentas de implantação automatizada são úteis para entender os conceitos deste documento.
Fluxo de trabalho de CI/CD
Para criar um sistema moderno de CI/CD, primeiro é preciso escolher ferramentas e serviços que executem as principais funções do sistema. O foco dessa arquitetura de referência é implementar as funções principais de um sistema de CI/CD mostrado no diagrama a seguir:
Essa implementação de referência usa as seguintes ferramentas para cada componente:
- Para gerenciamento de código-fonte: GitHub
- Armazena o código de aplicativo e configuração.
- Permite revisar as alterações.
- Para o gerenciamento de configuração do aplicativo:
kustomize
- Define a configuração pretendida de um aplicativo.
- Permite que você reutilize e estenda primitivos ou blueprints de configuração.
- Para integração contínua: Cloud Build
- Testa e valida o código-fonte.
- Cria artefatos consumidos pelo ambiente de implantação.
- Para entrega contínua: Cloud Deploy
- Define o processo de lançamento do código entre ambientes.
- Fornece reversão para alterações com falha.
- Para a configuração da infraestrutura: Config Sync
- Aplica consistentemente a configuração do cluster e da política.
- Para aplicação de política: Controlador de Políticas
- Fornece um mecanismo que pode ser usado para definir o que pode ser executado em um determinado ambiente com base nas políticas da organização.
- Para orquestração de contêineres: Google Kubernetes Engine
- Executa os artefatos criados durante a CI.
- Oferece metodologias de escalonamento, verificação de integridade e lançamento para cargas de trabalho.
- Para artefatos de contêiner: Artifact Registry
- Armazena os artefatos (imagens de contêiner) criados durante a CI.
Arquitetura
Nesta seção, descrevemos os componentes de CI/CD que você implementa usando esta arquitetura de referência: infraestrutura, repositórios de código e zonas de destino do aplicativo.
Para uma discussão geral sobre esses aspectos do sistema de CI/CD, consulte CI/CD moderno com Anthos: um framework de entrega de software.
Variantes da arquitetura de referência
A arquitetura de referência tem dois modelos de implantação:
- Variante de vários projetos que é mais parecida com uma implantação de produção com limites de isolamento aprimorados
- Uma variante de projeto único, que é útil para demonstrações
Arquitetura de referência de vários projetos
A versão multi-project
da arquitetura de referência simula cenários de produção. Nesses cenários, diferentes perfis criam infraestrutura, pipelines de CI/CD e aplicativos com limites de isolamento adequados. Essas personas ou equipes só podem acessar os recursos necessários.
Para mais informações, consulte CI/CD moderno com o GKE: um framework de entrega de software.
Para detalhes sobre como instalar e aplicar essa versão da arquitetura de referência, consulte o modelo de entrega de software.
Arquitetura de referência de projeto único
A versão single-project
da arquitetura de referência demonstra como configurar toda a plataforma de entrega de software em um único projeto do Google Cloud. Essa versão pode ajudar qualquer usuário que não tenha papéis elevados do IAM a instalar e testar a arquitetura de referência apenas com o papel de proprietário em um projeto. Neste documento, demonstramos a versão de projeto único da arquitetura de referência.
Infraestrutura de plataforma
A infraestrutura desta arquitetura de referência consiste em clusters do Kubernetes para oferecer suporte aos ambientes de aplicativos de desenvolvimento, preparo e produção. No diagrama a seguir, mostramos o layout lógico dos clusters:
Repositórios de código
Usando essa arquitetura de referência, você configura repositórios para operadores, desenvolvedores, plataforma e engenheiros de segurança.
No diagrama a seguir, veja a implementação da arquitetura de referência dos diferentes repositórios de código e como as equipes de operações, desenvolvimento e segurança interagem com eles.
Nesse fluxo de trabalho, seus operadores podem gerenciar as práticas recomendadas para CI/CD e configuração de aplicativo no repositório do operador. Quando seus desenvolvedores podem integrar aplicativos no repositório de desenvolvimento, eles recebem automaticamente práticas recomendadas, lógica de negócios do aplicativo e qualquer configuração especializada necessária para que o aplicativo funcione corretamente. Enquanto isso, sua equipe de operações e segurança pode gerenciar a consistência e a segurança da plataforma nos repositórios de configuração e política.
Zonas de destino do aplicativo
Nesta arquitetura de referência, a zona de destino de um aplicativo é criada quando o aplicativo é provisionado. No próximo documento desta série, CI/CD moderno com GKE: aplicar o fluxo de trabalho do desenvolvedor, você provisiona um novo aplicativo que cria a própria zona de destino. O diagrama a seguir ilustra os componentes importantes das zonas de destino usadas nesta arquitetura de referência:
Cada namespace inclui uma conta de serviço usada para que a federação de identidade da carga de trabalho para GKE acesse serviços fora do contêiner do Kubernetes, como o Cloud Storage ou o Spanner. O namespace também inclui outros recursos, como políticas de rede, para isolar ou compartilhar limites com outros namespaces ou aplicativos.
O namespace é criado pela conta de serviço de execução de CD. Recomendamos que as equipes sigam o princípio de privilégio mínimo para ajudar a garantir que uma conta de serviço de execução de CD só possa acessar os namespaces necessários.
É possível definir o acesso à conta de serviço no Config Sync e implementá-lo usando papéis do controle de acesso baseado em papéis (RBAC) e vinculações de papéis do Kubernetes. Com esse modelo, as equipes podem implantar qualquer recurso diretamente nos namespaces que gerenciam, mas são impedidos de substituir ou excluir recursos de outros namespaces.
Objetivos
- Implantar a arquitetura de referência de projeto único.
- Conhecer os repositórios de código
- Conhecer o pipeline e a infraestrutura.
Custos
Neste documento, você usará os seguintes componentes faturáveis do Google Cloud:
- Google Kubernetes Engine (GKE)
- Google Kubernetes Engine (GKE) Enterprise edition for Config Sync and Policy Controller
- Cloud Build
- Artifact Registry
- Cloud Deploy
Para gerar uma estimativa de custo baseada na projeção de uso deste tutorial, use a calculadora de preços.
Ao concluir as tarefas descritas neste documento, é possível evitar o faturamento contínuo excluindo os recursos criados. Saiba mais em Limpeza.
Antes de começar
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Verifique se a cobrança está ativada para o seu projeto do Google Cloud.
-
In the Google Cloud console, activate Cloud Shell.
Implantar a arquitetura de referência
Defina o projeto no Cloud Shell:
gcloud config set core/project PROJECT_ID
Substitua
PROJECT_ID
pelo ID do projeto do Google Cloud.No Cloud Shell, clone o repositório do Git:
git clone https://github.com/GoogleCloudPlatform/software-delivery-blueprint.git cd software-delivery-blueprint/launch-scripts git checkout single-project-blueprint
Crie um token de acesso pessoal no GitHub com os seguintes escopos:
repo
delete_repo
admin:org
admin:repo_hook
Há um arquivo vazio chamado
vars.sh
na pastasoftware-delivery-bluprint/launch-scripts
. Adicione o seguinte conteúdo ao arquivo:cat << EOF >vars.sh export INFRA_SETUP_REPO="gke-infrastructure-repo" export APP_SETUP_REPO="application-factory-repo" export GITHUB_USER=GITHUB_USER export TOKEN=TOKEN export GITHUB_ORG=GITHUB_ORG export REGION="us-central1" export SEC_REGION="us-west1" export TRIGGER_TYPE="webhook" EOF
Substitua
GITHUB_USER
pelo nome de usuário do GitHub.Substitua
TOKEN
pelo token de acesso pessoal do GitHub.Substitua
GITHUB_ORG
pelo nome da organização do GitHub.Execute o script
bootstrap.sh
: Se o Cloud Shell solicitar sua autorização, clique em Autorizar:./bootstrap.sh
O script inicializa a plataforma de entrega de software.
Conhecer os repositórios de código
Nesta seção, você conhecerá os repositórios de código.
Faça login no GitHub.
- Em um navegador da Web, acesse github.com e faça login na sua conta.
- Clique no ícone de imagem na parte superior da interface.
- Clique em Suas organizações.
- Escolha a organização que você forneceu como entrada no arquivo
vars.sh
. - Clique na guia repositório.
Conhecer os repositórios de ativação, operadora, configuração e infraestrutura
Nos repositórios de ativação, operador, configuração e infraestrutura, os operadores e administradores da plataforma definem as práticas recomendadas comuns para criar e operar a plataforma. Esses repositórios são criados na sua organização do GitHub quando a arquitetura de referência é inicializada.
Repositórios para iniciantes
Os repositórios iniciais ajudam na adoção de práticas recomendadas de CI/CD e desenvolvimento em toda a plataforma. Para mais informações, consulte CI/CD moderna com o GKE: um framework de entrega de software (em inglês)
Repositórios iniciais de aplicativos
Nos repositórios iniciais de aplicativos, os operadores podem codificar e documentar práticas recomendadas, como CI/CD, coleta de métricas, geração de registros, etapas de contêiner e segurança para aplicativos. A arquitetura de referência inclui exemplos de repositórios iniciais para aplicativos Go, Python e Java.
Os repositórios iniciais de código padrão app-template-python
, app-template-java
e app-template-golang
contém código boilerplate
que é possível usar para criar novos aplicativos. Além de criar aplicativos, é possível criar modelos com base nos requisitos deles. Os repositórios iniciais do aplicativo fornecidos pela arquitetura de referência contêm:
A base
kustomize
e os patches na pastak8s
.Código-fonte do aplicativo
Um
Dockerfile
que descreve como criar e executar o aplicativoUm arquivo
cloudbuild.yaml
que descreve as práticas recomendadas para as etapas de CI.Um arquivo
skaffold.yaml
que descreve as etapas da implantação.
No próximo documento desta série,
CI/CD moderna com GKE: aplicar o fluxo de trabalho do desenvolvedor,
use o repositório app-template-python
para criar um
novo aplicativo.
Repositórios básicos de infraestrutura
Nos repositórios iniciais de infraestrutura, os operadores e administradores de infraestrutura podem codificar e documentar práticas
recomendadas, como pipelines de CI/CD, IaC, coleta de métricas, geração de registros e segurança para
infraestrutura. A arquitetura de referência inclui exemplos de repositórios de infraestrutura inicial que usam o Terraform. O repositório inicial de infraestrutura infra-template
contém um código boilerplate do Terraform que pode ser usado para criar os recursos de infraestrutura exigidos por um aplicativo, como o bucket do Cloud Storage, o banco de dados do Spanner, entre outros.
Repositórios de modelos compartilhados
Nos repositórios de modelos compartilhados, os administradores e operadores de infraestrutura oferecem modelos padrão para realizar tarefas. Há um repositório chamado terraform-modules
fornecido com a arquitetura de referência. O repositório inclui um modelo de código do Terraform para criar vários recursos de infraestrutura.
Repositórios de operador
Na arquitetura de referência, os repositórios de operadores são os mesmos que os repositórios iniciais do aplicativo. Os operadores gerenciam os arquivos necessários para CI e CD nos repositórios iniciais do aplicativo.
A arquitetura de referência inclui os repositórios app-template-python
, app-template-java
e app-template-golang
.
- Eles são modelos iniciais e contêm os manifestos básicos do Kubernetes para os aplicativos em execução no Kubernetes na plataforma. Os operadores podem atualizar os manifestos nos modelos iniciais conforme necessário. As atualizações são recebidas quando um aplicativo é criado.
- Os arquivos
cloudbuild.yaml
eskaffold.yaml
nesses repositórios armazenam as práticas recomendadas para executar CI e CD, respectivamente, na plataforma. Assim como nas configurações do aplicativo, os operadores podem atualizar e adicionar etapas às práticas recomendadas. Pipelines de aplicativos individuais são criados usando as etapas mais recentes.
Nesta implementação de referência, os operadores usam
kustomize
para gerenciar as configurações básicas na pasta k8s
dos repositórios iniciais.
Os desenvolvedores podem estender os manifestos com mudanças específicas do aplicativo,
como nomes de recursos e arquivos de configuração. A ferramenta kustomize
é compatível com a configuração como dados. Com esta
metodologia, entradas e saídas kustomize
são recursos do Kubernetes. Você pode
usar as saídas de uma modificação dos manifestos para outra modificação.
O diagrama a seguir ilustra uma configuração básica para um aplicativo Spring Boot:
A configuração como modelo de dados em kustomize
tem um grande benefício: quando
os operadores atualizam a configuração base, as atualizações são consumidas
automaticamente pelo pipeline de implantação do desenvolvedor na próxima execução, sem nenhuma alteração
no do desenvolvedor.
Para mais informações sobre como usar o kustomize
para gerenciar manifestos do Kubernetes,
consulte a
documentação de kustomize
.
Repositórios de configuração e política
A arquitetura de referência inclui a implementação de um repositório de configurações e políticas
que usa o Config Sync e o Controlador de Políticas. O repositório
acm-gke-infrastructure-repo
contém a configuração e as políticas
implantadas em todos os clusters do ambiente de aplicativos. A configuração
definida e armazenada por administradores de plataforma nesses repositórios é importante para
garantir que a plataforma tenha uma aparência consistente para as equipes de operações
e desenvolvimento.
Nas seções a seguir, explicamos detalhadamente como a arquitetura de referência implementa repositórios de configuração e política.
Configuração
Nesta implementação de referência, você usa o Config Sync para gerenciar centralmente a configuração de clusters na plataforma e aplicar políticas. O gerenciamento centralizado permite propagar alterações de configuração em todo o sistema.
Usando o Config Sync, sua organização pode registrar clusters para sincronizar a configuração deles com um repositório Git, um processo conhecido como GitOps. Quando novos clusters são adicionados, eles são sincronizados automaticamente com a configuração mais recente e reconciliam continuamente seu estado com base nessa configuração, caso sejam feitas alterações fora da banda.
Para mais informações sobre o Config Sync, consulte a documentação dele.
Política
Nesta implementação de referência, use o Controlador de Políticas, que é baseado no Open Policy Agent, para interceptar e validar cada solicitação para os clusters do Kubernetes na plataforma. É possível criar políticas usando a linguagem da política de Rego, que permite controlar totalmente os tipos de recursos enviados ao cluster, mas também a configuração deles.
A arquitetura no diagrama a seguir mostra um fluxo de solicitação para usar o Policy Controller para criar um recurso:
Você cria e define regras no repositório do Config Sync, e essas alterações são aplicadas ao cluster. Depois disso, as novas solicitações de recursos da CLI ou dos clientes de API são validadas em relação às restrições pelo Controlador de políticas.
Para mais informações sobre como gerenciar políticas, consulte a visão geral do Policy Controller.
Repositórios de infraestrutura
O documento contém uma implementação do repositório
de infraestrutura usando o Terraform. O repositório gke-infrastructure-repo
contém uma infraestrutura como código para criar clusters do GKE nos ambientes de desenvolvimento, teste e produção, além de configurar o Config Sync neles usando o repositório acm-gke-infrastructure-repo
. gke-infrastructure-repo
contém três ramificações, uma para cada ambiente de desenvolvimento, preparo e produção. Ele também contém pastas de desenvolvimento, preparo e produção em cada ramificação.
Analisar o pipeline e a infraestrutura
A arquitetura de referência cria um pipeline no projeto do Google Cloud. Esse pipeline é responsável por criar a infraestrutura compartilhada.
Pipeline
Nesta seção, você vai analisar o pipeline de infraestrutura como código e executá-lo para criar a infraestrutura compartilhada, incluindo clusters do GKE. O pipeline é um gatilho do Cloud Build chamado create-infra
no projeto do Google Cloud vinculado ao repositório de infraestrutura gke-infrastructure-repo
. Você segue a metodologia GitOps para criar a infraestrutura, conforme explicado no vídeo sobre ambientes repetíveis do GCP em escala com pipelines de infraestrutura como código do Cloud Build.
gke-infrastructure-repo
tem ramificações de desenvolvimento, preparo e produção. No repositório, há também as pastas "dev", "staging" e "production" que correspondem a essas ramificações. Há regras de proteção de ramificação no repositório que garantem que o código só possa ser enviado para a ramificação de desenvolvimento. Para enviar o código para as ramificações de preparo e produção, é preciso criar uma solicitação de envio.
Normalmente, alguém com acesso ao repositório analisa as alterações e mescla a solicitação de envio para garantir que somente as mudanças pretendidas sejam promovidas para a ramificação superior. Para permitir que os indivíduos testem o blueprint, as regras de proteção de ramificação foram flexibilizadas na arquitetura de referência para que o administrador do repositório possa ignorar a revisão e mesclar a solicitação de envio.
Quando um push é feito para gke-infrastructure-repo
, ele invoca o gatilho create-infra
. Esse gatilho identifica a ramificação em que o push ocorreu e vai para a pasta correspondente no repositório dessa ramificação. Depois de encontrar a pasta correspondente, ele executa o Terraform usando os arquivos contidos nela. Por exemplo, se o código for enviado para a ramificação de desenvolvimento, o gatilho vai executar o Terraform na pasta de desenvolvimento da ramificação de dev para criar um cluster de desenvolvedor do GKE. Da mesma forma, quando um push acontece para a ramificação staging
, o gatilho executa o Terraform na pasta de preparo da ramificação de preparo para criar um cluster de preparo do GKE.
Execute o pipeline para criar clusters do GKE:
No console do Google Cloud, acesse a página do Cloud Build.
Acessar a página do Cloud Build
- Há cinco gatilhos do webhook do Cloud Build. Procure o gatilho com o nome
create-infra
. Esse gatilho cria a infraestrutura compartilhada, incluindo clusters do GKE.
- Há cinco gatilhos do webhook do Cloud Build. Procure o gatilho com o nome
Clique no nome do acionador. A definição do acionador é aberta.
Clique em ABRIR O EDITOR para ver as etapas executadas pelo acionador.
Os outros gatilhos são usados quando você integra um aplicativo em CI/CD moderna com o GKE: aplicar o fluxo de trabalho do desenvolvedor
No console do Google Cloud, acesse a página do Cloud Build.
Acessar a página de gatilhos do Cloud Build
Revise o pipeline presente na página do histórico. Quando você implantou a plataforma de entrega de software usando
bootstrap.sh
, o script enviou o código para a ramificação de desenvolvimento do repositóriogke-infrastructure-repo
que iniciou esse pipeline e criou o cluster dev do GKE.Para criar um cluster de preparo do GKE, envie uma solicitação de envio da ramificação de dev para a de preparo:
Acesse o GitHub e navegue até o repositório
gke-infrastructure-repo
.Clique em Solicitações de envio e em Nova solicitação de envio.
No menu Base, escolha staging e no menu Compare, selecione dev.
Clique em Criar solicitação de envio.
Se você for um administrador no repositório, mescle a solicitação de envio. Caso contrário, peça ao administrador para mesclar a solicitação de envio.
No console do Google Cloud, acesse a página Histórico do Cloud Build.
Acessar a página de gatilhos do Cloud Build
Um segundo pipeline do Cloud Build começa no projeto. Esse pipeline cria o cluster de preparo do GKE.
Para criar clusters do GKE de produção, envie um
pull request
do preparo para a ramificação de produção:Acesse o GitHub e navegue até o repositório
gke-infrastructure-repo
.Clique em Solicitações de envio e em Nova solicitação de envio.
No menu Base, escolha prod e no menu Comparar, escolha staging.
Clique em Criar solicitação de envio.
Se você for um administrador no repositório, mescle a solicitação de envio. Caso contrário, peça ao administrador para mesclar a solicitação de envio.
No console do Google Cloud, acesse a página Histórico do Cloud Build.
Acessar a página de gatilhos do Cloud Build
Um terceiro pipeline do Cloud Build começa no projeto. Esse pipeline cria o cluster de produção do GKE.
Infraestrutura
Nesta seção, você vai conhecer a infraestrutura criada pelos pipelines.
No Console do Google Cloud, acesse a página de clusters do Kubernetes.
Acessar a página de clusters do Kubernetes
Nesta página, listamos os clusters usados para desenvolvimento (
gke-dev-us-central1
), preparo (gke-staging-us-central1
) e produção (gke-prod-us-central1
,gke-prod-us-west1
):
Cluster de desenvolvimento
O cluster de desenvolvimento (gke-dev-us-central1
) permite que os desenvolvedores acessem um
namespace que pode ser usado para iterar nos aplicativos. Recomendamos que
as equipes usem ferramentas como o
Skaffold,
que fornece um fluxo de trabalho iterativo. Para isso, ele monitora ativamente o código
em desenvolvimento e o reaplica aos ambientes de desenvolvimento conforme as alterações são
feitas. Esse loop de iteração é semelhante à
recarga dinâmica.
No entanto, em vez de ser específico a uma linguagem de programação, o loop funciona com qualquer aplicativo que você possa criar com uma imagem do Docker. É possível executar o loop dentro de
um cluster do Kubernetes.
Como alternativa, os desenvolvedores podem seguir a repetição de CI/CD de um ambiente de desenvolvimento. Esse loop faz com que as alterações no código fiquem prontas para promoção em ambientes superiores.
No próximo documento desta série, CI/CD moderno com GKE: aplicar o fluxo de trabalho do desenvolvedor, use o Skaffold e a CI/CD para criar o loop de desenvolvimento.
Cluster de preparo
Este cluster executa o ambiente de preparação dos seus aplicativos. Nesta arquitetura de referência, você cria um cluster do GKE para preparo. Normalmente, um ambiente de preparo é uma réplica exata do ambiente de produção.
Cluster de produção
Na arquitetura de referência, você tem dois clusters do GKE para seus ambientes de produção. Para sistemas de redundância geográfica ou de alta disponibilidade (HA, na sigla em inglês), recomendamos adicionar vários clusters a cada ambiente. Para todos os clusters em que os aplicativos são implantados, o ideal é usar clusters regionais. Essa abordagem isola os aplicativos das falhas no nível da zona e de todas as interrupções causadas por upgrades de pool de nós ou de cluster.
Para sincronizar a configuração dos recursos do cluster, como namespaces, cotas e RBAC, recomendamos o uso do Config Sync. Para mais informações sobre como gerenciar esses recursos, consulte Repositórios de configuração e política.
Aplicar a arquitetura de referência
Agora que você conhece a arquitetura de referência, pode explorar um fluxo de trabalho de desenvolvedor baseado nessa implementação. No próximo documento desta série, CI/CD moderno com Anthos: como aplicar o fluxo de trabalho do desenvolvedor, você irá criar um novo aplicativo, adicionar um recurso e, depois, implantar o aplicativo nos ambientes de preparação e produção.
Limpar
Se você quiser testar o próximo documento desta série, CI/CD modernas com o GKE: como aplicar o fluxo de trabalho do desenvolvedor , não exclua o projeto ou os recursos associados a essa arquitetura de referência. Caso contrário, para evitar cobranças na sua conta do Google Cloud pelos recursos usados na arquitetura de referência, você poderá excluir o projeto ou removê-los manualmente.
Exclua o projeto
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
Remover recursos manualmente
No Cloud Shell, remova a infraestrutura:
gcloud container clusters delete gke-dev-us-central1 gcloud container clusters delete gke-staging-us-central1 gcloud container clusters delete gke-prod-us-central1 gcloud container clusters delete gke-prod-us-west1 gcloud beta builds triggers delete create-infra gcloud beta builds triggers delete add-team-files gcloud beta builds triggers delete create-app gcloud beta builds triggers delete tf-plan gcloud beta builds triggers delete tf-apply
A seguir
- Crie um novo aplicativo seguindo as etapas em CI/CD moderno com Anthos: como aplicar o fluxo de trabalho do desenvolvedor.
- Conheça as práticas recomendadas para configurar a federação de identidade.
Leia sobre o Kubernetes e os desafios da implantação contínua de software.
Confira arquiteturas de referência, diagramas, tutoriais e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.