Também estou em um estado de migração da infraestrutura existente da AWS para o Terraform, então terei como objetivo atualizar a resposta à medida que desenvolvo.
Tenho confiado muito nos exemplos oficiais do Terraform e em várias tentativas e erros para detalhar áreas nas quais não tenho certeza.
.tfstate
arquivos
A configuração do Terraform pode ser usada para provisionar muitas caixas em diferentes infraestruturas, cada uma delas com um estado diferente. Como também pode ser executado por várias pessoas, esse estado deve estar em um local centralizado (como S3), mas não git.
Isso pode ser confirmado olhando para o Terraform .gitignore
.
Controle do desenvolvedor
Nosso objetivo é fornecer mais controle da infraestrutura aos desenvolvedores, mantendo uma auditoria completa (git log) e a capacidade de verificar a integridade das alterações (solicitações pull). Com isso em mente, o novo fluxo de trabalho de infraestrutura que pretendo é:
- Base básica de AMIs comuns que incluem módulos reutilizáveis, por exemplo, fantoches.
- Infraestrutura central provisionada pelo DevOps usando Terraform.
- Os desenvolvedores alteram a configuração do Terraform no Git conforme necessário (número de instâncias; novo VPC; adição de região / zona de disponibilidade etc.).
- A configuração Git foi enviada por push e uma solicitação de pull foi enviada para ser verificada por um membro do esquadrão DevOps.
- Se aprovado, chama webhook para CI para construir e implantar (sem saber como particionar vários ambientes neste momento)
Edição 1 - Atualização do estado atual
Desde que comecei esta resposta, escrevi muito código TF e me sinto mais confortável em nosso estado de coisas. Encontramos bugs e restrições ao longo do caminho, mas eu aceito que essa é uma característica de usar um software novo que muda rapidamente.
Layout
Temos uma infraestrutura AWS complicada com vários VPCs, cada um com várias sub-redes. A chave para gerenciar isso facilmente foi definir uma taxonomia flexível que engloba região, ambiente, serviço e proprietário, que podemos usar para organizar nosso código de infraestrutura (terraform e fantoche).
Módulos
O próximo passo foi criar um único repositório git para armazenar nossos módulos de terraform. Nossa estrutura de diretório de nível superior para os módulos se parece com isto:
tree -L 1 .
Resultado:
├── README.md
├── aws-asg
├── aws-ec2
├── aws-elb
├── aws-rds
├── aws-sg
├── aws-vpc
└── templates
Cada um define alguns padrões lógicos, mas os expõe como variáveis que podem ser substituídas por nossa "cola".
Cola
Temos um segundo repositório com o nosso glue
que faz uso dos módulos mencionados acima. Ele é apresentado de acordo com nosso documento de taxonomia:
.
├── README.md
├── clientA
│ ├── eu-west-1
│ │ └── dev
│ └── us-east-1
│ └── dev
├── clientB
│ ├── eu-west-1
│ │ ├── dev
│ │ ├── ec2-keys.tf
│ │ ├── prod
│ │ └── terraform.tfstate
│ ├── iam.tf
│ ├── terraform.tfstate
│ └── terraform.tfstate.backup
└── clientC
├── eu-west-1
│ ├── aws.tf
│ ├── dev
│ ├── iam-roles.tf
│ ├── ec2-keys.tf
│ ├── prod
│ ├── stg
│ └── terraform.tfstate
└── iam.tf
Dentro do nível do cliente, temos .tf
arquivos específicos da conta da AWS que provisionam recursos globais (como funções de IAM); a seguir está o nível de região com as chaves públicas SSH EC2; Finalmente, em nosso ambiente ( dev
, stg
, prod
etc) são a nossa setups VPC, a criação da instância e olhando conexões etc, são armazenados.
Nota lateral: Como você pode ver, estou indo contra meu próprio conselho acima de manter o terraform.tfstate
git. Esta é uma medida temporária até que eu mude para o S3, mas é adequado para mim, pois sou atualmente o único desenvolvedor.
Próximos passos
Este ainda é um processo manual e não está no Jenkins, mas estamos portando uma infraestrutura bastante grande e complicada e até agora tudo bem. Como eu disse, poucos bugs mas indo bem!
Editar 2 - Mudanças
Já se passou quase um ano desde que escrevi esta resposta inicial e o estado do Terraform e de mim mudou significativamente. Agora estou em uma nova posição usando o Terraform para gerenciar um cluster do Azure e o Terraform está agora v0.10.7
.
Estado
As pessoas me disseram repetidamente que o estado não deve ser usado no Git - e estão corretas. Usamos isso como uma medida provisória com uma equipe de duas pessoas que dependia da comunicação e disciplina do desenvolvedor. Com uma equipe maior e distribuída, agora estamos aproveitando totalmente o estado remoto no S3 com bloqueio fornecido pelo DynamoDB. Idealmente, isso será migrado para o cônsul agora que é v1.0 para cortar provedores de nuvem cruzada.
Módulos
Anteriormente, criamos e usamos módulos internos. Esse ainda é o caso, mas com o advento e crescimento do registro Terraform , tentamos usá-lo como pelo menos uma base.
Estrutura de arquivo
A nova posição tem uma taxonomia muito mais simples com apenas dois ambientes infx - dev
e prod
. Cada um tem suas próprias variáveis e saídas, reutilizando nossos módulos criados acima. O remote_state
provedor também ajuda no compartilhamento de saídas de recursos criados entre ambientes. Nosso cenário é de subdomínios em diferentes grupos de recursos do Azure para um TLD gerenciado globalmente.
├── main.tf
├── dev
│ ├── main.tf
│ ├── output.tf
│ └── variables.tf
└── prod
├── main.tf
├── output.tf
└── variables.tf
Planejamento
Novamente com os desafios extras de uma equipe distribuída, agora sempre salvamos nossa saída do terraform plan
comando. Podemos inspecionar e saber o que será executado sem o risco de algumas alterações entre o estágio plan
e apply
(embora o bloqueio ajude nisso). Lembre-se de excluir este arquivo de plano, pois ele pode conter variáveis "secretas" de texto simples.
No geral, estamos muito felizes com o Terraform e continuamos a aprender e melhorar com os novos recursos adicionados.