Recomendamos que use uma infraestrutura declarativa para implementar a sua base de forma consistente e controlável. Esta abordagem ajuda a ativar uma gestão consistente, aplicando controlos de políticas sobre configurações de recursos aceitáveis nos seus pipelines. O projeto é implementado através de um fluxo GitOps, com o Terraform usado para definir a infraestrutura como código (IaC), um repositório Git para o controlo de versões e a aprovação de código, e o Cloud Build para a automatização de CI/CD no pipeline de implementação. Para uma introdução a este conceito, consulte o artigo Faça a gestão da infraestrutura como código com o Terraform, o Cloud Build e o GitOps.
As secções seguintes descrevem como o pipeline de implementação é usado para gerir recursos na sua organização.
Camadas de pipeline
Para separar as equipas e a pilha tecnológica responsáveis pela gestão de diferentes camadas do seu ambiente, recomendamos um modelo que use diferentes pipelines e diferentes perfis responsáveis por cada camada da pilha.
O diagrama seguinte apresenta o nosso modelo recomendado para separar um pipeline de base, um pipeline de infraestrutura e um pipeline de aplicações.
O diagrama apresenta as camadas do pipeline neste modelo:
- O pipeline de base implementa os recursos de base que são usados na plataforma. Recomendamos que uma única equipa central seja responsável pela gestão dos recursos básicos que são consumidos por várias unidades de negócio e cargas de trabalho.
- O pipeline de infraestrutura implementa projetos e infraestrutura que são usados por cargas de trabalho, como instâncias de VM ou bases de dados. O esquema configura um pipeline de infraestrutura separado para cada unidade de negócio, ou pode preferir um pipeline de infraestrutura único usado por várias equipas.
- O pipeline de aplicação implementa os artefactos para cada carga de trabalho, como contentores ou imagens. Pode ter muitas equipas de aplicações diferentes com pipelines de aplicações individuais.
As secções seguintes apresentam a utilização de cada camada do pipeline.
O pipeline de base
O pipeline de base implementa os recursos de base. Também configura o pipeline de infraestrutura usado para implementar a infraestrutura usada por cargas de trabalho.
Para criar o pipeline de base, primeiro clone ou bifurque o
terraform-example-foundation para o seu próprio repositório Git. Siga os passos no ficheiro
0-bootstrap README
para configurar a pasta e os recursos de arranque.
| Fase | Descrição |
|---|---|
Inicializa uma Google Cloud organização. Este passo também configura um pipeline de CI/CD para o código do projeto nas fases subsequentes.
|
Depois de criar o pipeline base na fase 0-bootstrap, as fases seguintes implementam recursos no pipeline base. Reveja as instruções do ficheiro README para cada fase e implemente cada fase sequencialmente.
| Fase | Descrição |
|---|---|
Configura pastas partilhadas de nível superior, projetos para serviços partilhados, registo ao nível da organização e definições de segurança de base através de políticas da organização. |
|
Configura ambientes de desenvolvimento, não produção e produção na Google Cloud organização que criou. |
|
ou |
Configura VPCs partilhadas na topologia escolhida e os recursos de rede associados. |
A pipeline de infraestrutura
O pipeline de infraestrutura implementa os projetos e a infraestrutura (por exemplo, as instâncias de VM e as bases de dados) que são usados pelas cargas de trabalho. O pipeline de base implementa vários pipelines de infraestrutura. Esta separação entre o pipeline de base e o pipeline de infraestrutura permite uma separação entre recursos ao nível da plataforma e recursos específicos da carga de trabalho.
O diagrama seguinte descreve como o projeto configura vários pipelines de infraestrutura destinados a serem usados por equipas separadas.
O diagrama descreve os seguintes conceitos principais:
- Cada pipeline de infraestrutura é usado para gerir recursos de infraestrutura independentemente dos recursos básicos.
- Cada unidade de negócio tem o seu próprio pipeline de infraestrutura, gerido num projeto dedicado na pasta
common. - Cada um dos pipelines de infraestrutura tem uma conta de serviço com autorização para implementar recursos apenas nos projetos associados a essa unidade empresarial. Esta estratégia cria uma separação de funções entre as contas de serviço privilegiadas usadas para o pipeline de base e as usadas por cada pipeline de infraestrutura
Esta abordagem com várias pipelines de infraestrutura é recomendada quando tem várias entidades na sua organização com as competências e o interesse em gerir a respetiva infraestrutura separadamente, especialmente se tiverem requisitos diferentes, como os tipos de política de validação de pipelines que querem aplicar. Em alternativa, pode preferir ter um pipeline de infraestrutura único gerido por uma única equipa com políticas de validação consistentes.
No terraform-example-foundation, a fase 4 configura um pipeline de infraestrutura e a fase 5 demonstra um exemplo de utilização desse pipeline para implementar recursos de infraestrutura.
| Fase | Descrição |
|---|---|
Configura uma estrutura de pastas, projetos e um pipeline de infraestrutura. |
|
|
Implementa projetos de carga de trabalho com uma instância do Compute Engine usando o pipeline de infraestrutura como exemplo. |
O pipeline de candidaturas
O pipeline de aplicações é responsável pela implementação de artefactos de aplicações para cada carga de trabalho individual, como imagens ou contentores do Kubernetes que executam a lógica de negócio da sua aplicação. Estes artefactos são implementados em recursos de infraestrutura que foram implementados pelo seu pipeline de infraestrutura.
O esquema detalhado da base empresarial configura o pipeline da base e o pipeline de infraestrutura, mas não implementa um pipeline de aplicação. Para ver um exemplo de um pipeline de aplicações, consulte o projeto de aplicação empresarial.
Automatizar o pipeline com o Cloud Build
O projeto usa o Cloud Build para automatizar os processos de CI/CD. A tabela seguinte descreve os controlos incorporados no pipeline de base e no pipeline de infraestrutura implementados pelo repositório terraform-example-foundation. Se estiver a desenvolver os seus próprios pipelines com outras ferramentas de automatização de CI/CD, recomendamos que aplique controlos semelhantes.
| Controlo | Descrição |
|---|---|
Separe as configurações de compilação para validar o código antes da implementação |
O projeto usa dois ficheiros de configuração de compilação do Cloud Build para todo o pipeline, e cada repositório associado a uma fase tem dois acionadores do Cloud Build associados a esses ficheiros de configuração de compilação. Quando o código é enviado para um ramo do repositório, os ficheiros de configuração de compilação são acionados para executar primeiro |
Verificações de políticas do Terraform | O projeto inclui um conjunto de restrições do Open Policy Agent que são aplicadas pela validação de políticas na CLI do Google Cloud. Estas restrições definem as configurações de recursos aceitáveis que podem ser implementadas pelo seu pipeline. Se uma compilação não cumprir a política na configuração da primeira compilação, a configuração da segunda compilação não implementa recursos. As políticas aplicadas no projeto são ramificadas a partir de |
Princípio do menor privilégio | O pipeline de base tem uma conta de serviço diferente para cada fase com uma política de autorização que concede apenas as funções do IAM mínimas para essa fase. Cada acionador do Cloud Build é executado como a conta de serviço específica dessa fase. A utilização de contas diferentes ajuda a mitigar o risco de que a modificação de um repositório possa afetar os recursos geridos por outro repositório. Para compreender as funções IAM específicas aplicadas a cada conta de serviço, consulte o código Terraform na fase de arranque. |
Grupos privados do Cloud Build | O projeto usa pools privados do Cloud Build. As pools privadas permitem-lhe aplicar opcionalmente controlos adicionais, como restringir o acesso a repositórios públicos ou executar o Cloud Build num perímetro do VPC Service Controls. |
Construtores personalizados do Cloud Build | O projeto cria o seu próprio criador
personalizado para executar o Terraform. Para mais informações, consulte |
Aprovação da implementação | Opcionalmente, pode adicionar uma fase de aprovação manual ao Cloud Build. Esta aprovação adiciona um ponto de verificação adicional depois de a compilação ser acionada, mas antes de ser executada, para que um utilizador privilegiado possa aprovar manualmente a compilação. |
Estratégia de ramificação
Recomendamos uma estratégia de ramificação persistente para enviar código para o seu sistema Git e implementar recursos através do pipeline de base. O diagrama seguinte descreve a estratégia de ramificação persistente.
O diagrama descreve três ramificações persistentes no Git (desenvolvimento, não produção e produção) que refletem osGoogle Cloud ambientes correspondentes. Também existem vários ramos de funcionalidades efémeras que não correspondem a recursos implementados nos seus Google Cloud ambientes.
Recomendamos que aplique um processo de pedido de envio (PR) no seu sistema Git para que qualquer código que seja unido a um ramo persistente tenha um PR aprovado.
Para desenvolver código com esta estratégia de ramificação persistente, siga estes passos gerais:
- Quando estiver a desenvolver novas capacidades ou a trabalhar na correção de um erro, crie um novo ramo com base no ramo de desenvolvimento. Use uma convenção de nomenclatura para a sua ramificação que inclua o tipo de alteração, um número de pedido ou outro identificador e uma descrição legível, como
feature/123456-org-policies. - Quando concluir o trabalho no ramo de funcionalidades, abra um PR que tenha como destino o ramo de desenvolvimento.
- Quando envia o PR, este aciona o pipeline de base para executar
terraform planeterraform validatepara preparar e validar as alterações. - Depois de validar as alterações ao código, junte a funcionalidade ou a correção de erros ao ramo de desenvolvimento.
- O processo de união aciona a execução do pipeline de base
terraform applypara implementar as alterações mais recentes no ramo de programação no ambiente de programação. - Reveja as alterações no ambiente de desenvolvimento através de revisões manuais, testes funcionais ou testes completos relevantes para o seu exemplo de utilização. Em seguida, promova as alterações para o ambiente de não produção abrindo um PR que segmente o ramo de não produção e junte as suas alterações.
- Para implementar recursos no ambiente de produção, repita o mesmo processo do passo 6: reveja e valide os recursos implementados, abra um PR para a ramificação de produção e faça a união.
O que se segue?
- Leia sobre as práticas recomendadas de operações (documento seguinte nesta série).