Fonte: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/small-terraform
Este exemplo contém código como um exemplo de estruturação de configurações do Terraform para uma infraestrutura de pequeno porte, onde nenhuma dependência externa é utilizada.
Perfeito para começar e refatorar à medida que avança
Perfeito para pequenos módulos de recursos
Bom para módulos de infraestrutura pequenos e lineares (ex, terraform-aws-atlantis)
Bom para um número pequeno de recursos (menos de 20-30)
Um arquivo de estado único para todos os recursos pode tornar o processo de trabalho com o Terraform lento, se o número de recursos estiver crescendo (considere utilizar o argumento -target para limitar o número de recursos)
Esses exemplos estão mostrando o provedor da AWS, mas a maioria dos princípios mostrados nos exemplos pode ser aplicada a outros provedores de núvem pública, bem como a outros tipos de provedores (DNS, DB, Monitoring, etc).
| Tipo | Descrição | Disponibilidade |
|---|---|---|
| Tipo | Descrição | Disponibilidade |
|---|---|---|
Poucos recursos, sem dependências externas. Conta única da AWS. Região única. Ambiente único.
Sim
Diversas contas e ambientes na AWS, módulos de infraestrutura prontos para o uso utilizando o Terraform.
Sim
Muitas contas na AWS, muitas regiões, necessidade urgente de reduzir copiar e colar, módulos de infraestrutura personalizados, uso intenso de composições. Utilizando o Terraform.
Trabalho em progresso
muito grande (nível Enterprise)
Diversos provedores (AWS, GCP, Azure). Implementações em diversas nuvens. Utilizando o Terraform.
Não
médio
Diversas contas e ambientes na AWS, módulos de infraestrutura prontos para o uso utilizando o Terragrunt.
Não
grande
Muitas contas na AWS, muitas regiões, necessidade urgente de reduzir copiar e colar, módulos de infraestrutura personalizados, uso intenso de composições. Utilizando o Terragrunt.
Não
muito grande (nível Enterprise)
Diversos provedores (AWS, GCP, Azure). Implementações em diversas nuvens. Utilizando o Terragrunt.
Não
Fonte: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/large-terraform
Este exemplo contém código como um exemplo de estruturação de configurações do Terraform para uma infraestrutura de médio porte, que utiliza:
2 contas na AWS
2 regiões (ap-southeast-2 e us-west-1, por exemplo)
2 ambientes separados (prod e stage que não compartilham nada entre eles). Cada ambiente está em uma conta separada na AWS.
Cada ambiente utiliza uma versão diferente do módulo de infraestrutura pronto para uso (alb) originado do Terraform Registry
Cada ambiente utiliza a mesma versão de módulos/rede de um módulo interno, pois é originado de um diretório local.
Em um grande projeto como o descrito aqui, os benefócios do uso do Terragrunt se tornam muito visíveis. Veja Estruturas de código de exemplos com o Terragrunt.
Perfeito para projetos em que a infraestrutura é separada logicamente (contas AWS separadas)
Bom para quando não há necessidade de modificar recursos compartilhados entre contas da AWS (um ambiente = uma conta da AWS = um arquivo de estado)
Bom para quando não há necessidade na orquestração de mudanças entre os ambientes
Bom para quando os recursos de infraestrutura são diferentes por ambiente de propósito e não podem ser generalizados (por exemplo, alguns recursos estão ausentes em um ambiente ou em algumas regiões)
À medida que o projeto cresce, será mais difícil manter esses ambientes atualizados entre sí. Considere o uso de módulos de infraestrutura (já prontos ou internos) para tarefas repetíveis.
Fonte: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/medium-terraform
Este exemplo contém código como um exemplo de estruturação de configurações do Terraform para uma infraestrutura de médio porte, que utiliza:
2 contas na AWS
2 ambientes separados (prod e stage que não compartilham nada entre eles). Cada ambiente está em uma conta separada na AWS.
Cada ambiente utiliza uma versão diferente do módulo de infraestrutura pronto para uso (alb) originado do Terraform Registry
Cada ambiente utiliza a mesma versão de módulos/rede de um módulo interno, pois é originado de um diretório local.
Perfeito para projetos em que a infraestrutura é separada logicamente (contas AWS separadas)
Bom para quando não há necessidade de modificar recursos compartilhados entre contas da AWS (um ambiente = uma conta da AWS = um arquivo de estado)
Bom para quando não há necessidade na orquestração de mudanças entre os ambientes
Bom para quando os recursos de infraestrutura são diferentes por ambiente de propósito e não podem ser generalizados (por exemplo, alguns recursos estão ausentes em um ambiente ou em algumas regiões)
À medida que o projeto cresce, será mais difícil manter esses ambientes atualizados entre sí. Considere o uso de módulos de infraestrutura (já prontos ou internos) para tarefas repetíveis.