Práticas recomendadas para o controlo de versões

Este documento fornece práticas recomendadas de controlo de versões a considerar quando usar o Terraform para Trusted Cloud.

Tal como acontece com outras formas de código, armazene o código de infraestrutura no controlo de versões para preservar o histórico e permitir reversões fáceis.

Este guia não é uma introdução ao Terraform. Para uma introdução à utilização do Terraform com o Trusted Cloud by S3NS, consulte o artigo Comece a usar o Terraform.

Use uma estratégia de ramificação predefinida

Para todos os repositórios que contêm código Terraform, use a seguinte estratégia por predefinição:

  • O ramo main é o ramo de desenvolvimento principal e representa o código aprovado mais recente. O ramo main está protegido.
  • O desenvolvimento ocorre em ramificações de funcionalidades e de correções de erros que se ramificam a partir da ramificação main.
    • Nomeie os ramos de funcionalidades feature/$feature_name.
    • Dê nomes às ramificações de correção de erros fix/$bugfix_name.
  • Quando uma funcionalidade ou uma correção de erro estiver concluída, faça a união novamente no ramo main com um pedido de envio.
  • Para evitar conflitos de união, rebase os ramos antes de os unir.

Use ramificações de ambiente para configurações raiz

Para repositórios que incluem configurações de raiz implementadas diretamente no Trusted Cloud, é necessária uma estratégia de implementação segura. Recomendamos que tenha um ramo separado para cada ambiente. Assim, as alterações à configuração do Terraform podem ser promovidas através da união das alterações entre os diferentes ramos.

Ramo separado para cada ambiente

Permitir visibilidade ampla

Tornar o código-fonte e os repositórios do Terraform amplamente visíveis e acessíveis em todas as organizações de engenharia, para os proprietários de infraestruturas (por exemplo, SREs) e as partes interessadas em infraestruturas (por exemplo, programadores). Isto garante que os intervenientes da infraestrutura podem ter uma melhor compreensão da infraestrutura da qual dependem.

Incentive os intervenientes da infraestrutura a enviar pedidos de união como parte do processo de pedido de alteração.

Nunca confirme secrets

Nunca comprometa Secrets com o controlo de origem, incluindo na configuração do Terraform. Em alternativa, carregue-os para um sistema como o Secret Manager e faça referência aos mesmos através de origens de dados.

Tenha em atenção que esses valores confidenciais podem acabar no ficheiro de estado e também podem ser expostos como resultados.

Organize repositórios com base nos limites da equipa

Embora possa usar diretórios separados para gerir limites lógicos entre recursos, os limites organizacionais e a logística determinam a estrutura do repositório. Em geral, use o princípio de design de que as configurações com requisitos de aprovação e gestão diferentes são separadas em repositórios de controlo de origem diferentes. Para ilustrar este princípio, seguem-se algumas configurações possíveis do repositório:

  • Um repositório central: neste modelo, todo o código do Terraform é gerido centralmente por uma única equipa de plataforma. Este modelo funciona melhor quando existe uma equipa de infraestrutura dedicada responsável por toda a gestão da nuvem e aprova quaisquer alterações pedidas por outras equipas.

  • Repositórios de equipa: neste modelo, cada equipa é responsável pelo seu próprio repositório do Terraform, onde gere tudo o que está relacionado com a infraestrutura que detém. Por exemplo, a equipa de segurança pode ter um repositório onde todos os controlos de segurança são geridos, e as equipas de aplicações têm cada uma o seu próprio repositório do Terraform para implementar e gerir a respetiva aplicação.

    A organização dos repositórios ao longo dos limites das equipas é a melhor estrutura para a maioria dos cenários empresariais.

  • Repositórios separados: neste modelo, cada componente lógico do Terraform é dividido no seu próprio repositório. Por exemplo, a rede pode ter um repositório dedicado e pode existir um repositório de fábrica de projetos separado para a criação e gestão de projetos. Esta opção funciona melhor em ambientes altamente descentralizados, onde as responsabilidades mudam frequentemente entre equipas.

Estrutura do repositório de exemplo

Pode combinar estes princípios para dividir a configuração do Terraform em diferentes tipos de repositórios:

  • Fundacional
  • Específico da aplicação e da equipa

Repositório fundamental

Um repositório fundamental que contém os principais componentes centrais, como pastas ou IAM da organização. Este repositório pode ser gerido pela equipa central da nuvem.

  • Neste repositório, inclua um diretório para cada componente principal (por exemplo, pastas, redes, etc.).
  • Nos diretórios de componentes, inclua uma pasta separada para cada ambiente (refletindo as orientações da estrutura de diretórios mencionadas anteriormente).

Estrutura de repositório fundamental

Repositórios específicos da aplicação e da equipa

Implemente repositórios específicos da aplicação e da equipa separadamente para cada equipa gerir a respetiva configuração do Terraform exclusiva específica da aplicação.

Estrutura de repositório específica da aplicação e da equipa

O que se segue?