Recomendamos que você use uma infraestrutura declarativa para implantar sua base de maneira consistente e controlável. Essa abordagem permite uma governança consistente, aplicando controles de política sobre configurações aceitáveis de recursos nos seus pipelines. O blueprint é implantado usando um fluxo do GitOps, com o Terraform usado para definir a infraestrutura como código (IaC, na sigla em inglês), um repositório Git para controle de versões e aprovação de código, e o Cloud Build para automação de CI/CD no o pipeline de implantação. Para conferir uma introdução a esse conceito, consulte Gerenciar a infraestrutura como código com o Terraform, o Cloud Build e o GitOps.
As seções a seguir descrevem como o pipeline de implantação é usado para gerenciar recursos na sua organização.
Camadas do pipeline
Para separar as equipes e a pilha de tecnologia responsáveis por gerenciar diferentes camadas do ambiente, recomendamos um modelo que use pipelines diferentes e perfis responsáveis por cada camada da pilha.
No diagrama a seguir, apresentamos nosso modelo recomendado para separar um pipeline de fundação, um pipeline de infraestrutura e um pipeline de aplicativo.
O diagrama apresenta as camadas de pipeline neste modelo:
- O pipeline de base implanta os recursos básicos que são usados em toda a plataforma. Recomendamos que uma única equipe central seja responsável por gerenciar os recursos de base consumidos por várias unidades de negócios e cargas de trabalho.
- O pipeline de infraestrutura implanta projetos e infraestrutura que são usados por cargas de trabalho, como instâncias de VM ou bancos de dados. O blueprint configura um pipeline de infraestrutura separado para cada unidade de negócios. Você também pode preferir um único pipeline de infraestrutura usado por várias equipes.
- O pipeline do aplicativo implanta os artefatos para cada carga de trabalho, como contêineres ou imagens. É possível ter várias equipes de aplicativo diferentes com pipelines de aplicativos individuais.
As seções a seguir apresentam o uso de cada camada do pipeline.
O pipeline de base
O pipeline de base implanta os recursos básicos. Ele também configura o pipeline de infraestrutura usado para implantar a infraestrutura usada pelas cargas de trabalho.
Para criar o pipeline de base, primeiro clone ou bifurque
a base do Terraform-example para seu próprio repositório Git. Siga as etapas no
arquivo README 0-bootstrap para configurar a pasta e os recursos de inicialização.
| Etapa | Descrição |
|---|---|
Inicializa uma organização do Google Cloud. Esta etapa também configura um pipeline de CI/CD para o código de blueprint nos estágios subsequentes.
|
Depois de criar o pipeline de base no cenário 0-bootstrap, os estágios a seguir
implantam recursos nele. Revise as instruções README de cada etapa e implemente cada uma em sequência.
| Etapa | Descrição |
|---|---|
Configura as pastas compartilhadas de nível superior, projetos para serviços compartilhados, geração de registros no nível da organização e configurações de segurança de valor de referência por meio de políticas da organização. |
|
Configura os ambientes de desenvolvimento, de não produção e de produção na organização do Google Cloud que você criou. |
|
ou |
Configura as VPCs compartilhadas na topologia escolhida e nos recursos de rede associados. |
O pipeline de infraestrutura
O pipeline de infraestrutura implanta os projetos e a infraestrutura (por exemplo, as instâncias de VM e os bancos de dados) que são usados pelas cargas de trabalho. O pipeline de base implanta vários pipelines de infraestrutura. Essa separação entre o pipeline de base e o pipeline de infraestrutura permite separar recursos de toda a plataforma e recursos específicos da carga de trabalho.
No diagrama a seguir, descrevemos como o blueprint configura vários pipelines de infraestrutura destinados ao uso por equipes separadas.
O diagrama descreve os seguintes conceitos principais:
- Cada pipeline de infraestrutura é usado para gerenciar recursos de infraestrutura independentemente dos recursos de fundação.
- Cada unidade de negócios tem o próprio pipeline de infraestrutura, gerenciado em um projeto dedicado na pasta
common. - Cada um dos pipelines de infraestrutura tem uma conta de serviço com permissão para implantar recursos apenas em projetos associados a essa unidade de negócios. Essa estratégia cria uma separação de tarefas entre as contas de serviço privilegiadas usadas para o pipeline de fundação e aquelas usadas por cada pipeline de infraestrutura
Essa abordagem com vários pipelines de infraestrutura é recomendada quando há várias entidades dentro da organização com as habilidades e o apetite para gerenciar a infraestrutura separadamente, especialmente se elas tiverem requisitos diferentes, como tipos de validação de pipeline política que eles querem aplicar. Outra opção é ter um único pipeline de infraestrutura gerenciado por uma única equipe com políticas de validação consistentes.
Em terraform-example-foundation, o estágio 4 configura um pipeline de infraestrutura e o estágio 5 demonstra um exemplo de uso desse pipeline para implantar recursos de infraestrutura.
| Etapa | Descrição |
|---|---|
Configura uma estrutura de pastas, projetos e um pipeline de infraestrutura. |
|
|
Implanta projetos de carga de trabalho com uma instância do Compute Engine usando o pipeline de infraestrutura como exemplo. |
Pipeline do aplicativo
O pipeline do aplicativo é responsável por implantar artefatos de aplicativos para cada carga de trabalho individual, como imagens ou contêineres do Kubernetes que executam a lógica de negócios do aplicativo. Esses artefatos são implantados nos recursos de infraestrutura que foram implantados pelo pipeline de infraestrutura.
O blueprint de base da empresa configura o pipeline de fundação e o pipeline de infraestrutura, mas não implanta um pipeline de aplicativos. Para ver um exemplo de pipeline de aplicativos, consulte o Blueprint de aplicativos empresariais.
Como automatizar seu pipeline com o Cloud Build
O blueprint usa o Cloud Build para automatizar processos de CI/CD. Na tabela a seguir, descrevemos que os controles são incorporados ao pipeline de fundação e ao pipeline de infraestrutura implantados pelo repositório terraform-example-foundation. Se estiver desenvolvendo seus próprios pipelines usando outras ferramentas de automação de CI/CD, recomendamos que você aplique controles semelhantes.
| Controle | Descrição |
|---|---|
Configurações de build separadas para validar o código antes da implantação |
O blueprint usa dois arquivos de configuração do build do Cloud Build para
todo o pipeline, e cada repositório associado a um estágio tem dois
gatilhos do Cloud Build que são associados a esses arquivos de configuração de compilação. Quando o código é enviado por push para uma
ramificação de repositório, os arquivos de configuração do build são acionados para executar primeiro |
Verificações de política do Terraform | O blueprint inclui um conjunto de restrições do Open Policy Agent que são aplicadas pela validação de política na CLI do Google Cloud. Essas restrições definem as configurações de recursos aceitáveis que podem ser implantadas pelo pipeline. Se um build não atender à política na primeira configuração do build, a segunda não vai implantar nenhum recurso. As políticas
aplicadas no blueprint são ramificadas de |
Princípio de privilégio mínimo | O pipeline de base tem uma conta de serviço
diferente para cada estágio, com uma política de permissão que concede apenas os papéis mínimos do IAM
para esse estágio. Cada gatilho do Cloud Build é executado como a conta de serviço específica para esse estágio. O uso de contas diferentes ajuda a reduzir o risco
de que a modificação de um repositório possa afetar os recursos gerenciados por
outro. Para entender os papéis específicos do IAM aplicados a cada
conta de serviço, consulte o código |
Pools privados do Cloud Build | O blueprint usa pools particulares do Cloud Build. Com os pools particulares, você tem a opção de aplicar outros controles, como restringir o acesso a repositórios públicos ou executar o Cloud Build dentro de um perímetro do VPC Service Controls. |
Criadores personalizados do Cloud Build | O blueprint cria o próprio criador
personalizado para executar o Terraform. Para ver mais informações, consulte |
Aprovação da implantação | Também é possível adicionar um estágio de aprovação manual ao Cloud Build. Essa aprovação adiciona outro checkpoint após o build ser acionado, mas antes de ser executado, para que um usuário com privilégios possa aprová-lo manualmente. |
Estratégia de ramificação
Recomendamos uma estratégia de ramificação permanente para enviar código ao sistema Git e implantar recursos por meio do pipeline de base. O diagrama a seguir descreve a estratégia de ramificação permanente.
O diagrama descreve três ramificações persistentes no Git (desenvolvimento, não produção e produção) que refletem os ambientes correspondentes do Google Cloud. Há também várias ramificações de recursos temporárias que não correspondem aos recursos implantados nos ambientes do Google Cloud.
Recomendamos que você aplique um processo de solicitação de envio (PR, na sigla em inglês) ao sistema Git para que qualquer código mesclado a uma ramificação persistente tenha um PR aprovado.
Para desenvolver código com essa estratégia de ramificação persistente, siga estas etapas gerais:
- Quando você estiver desenvolvendo novos recursos ou trabalhando em uma correção de bug, crie uma nova
ramificação com base na ramificação de desenvolvimento. Use uma convenção de nomenclatura para a ramificação que inclua o tipo de alteração, um número de tíquete ou outro identificador e uma descrição legível, como
feature/123456-org-policies. - Ao concluir o trabalho na ramificação de recursos, abra um PR que segmente a ramificação de desenvolvimento.
- Quando você envia o PR, ele aciona o pipeline de fundação para executar
terraform planeterraform validatepara preparar e verificar as alterações. - Depois de validar as alterações no código, mescle o recurso ou a correção de bug na ramificação de desenvolvimento.
- O processo de mesclagem aciona o pipeline de base para executar
terraform applye implantar as alterações mais recentes na ramificação de desenvolvimento no ambiente de desenvolvimento. - Analise as alterações no ambiente de desenvolvimento usando revisões manuais, testes funcionais ou testes completos relevantes para seu caso de uso. Em seguida, promova as mudanças no ambiente de não produção abrindo um PR que segmenta a ramificação que não é de produção e mescle as alterações.
- Para implantar recursos no ambiente de produção, repita o mesmo processo da etapa 6: revisar e validar os recursos implantados, abrir um PR para a ramificação de produção e fazer a mesclagem.
A seguir
- Leia sobre as práticas recomendadas de operações (próximo documento desta série).