Entendendo os módulos do Terraform

No reino da infraestrutura como código (IaC), um módulo é um bloco de código independente que é isolado e empacotado para reutilização. O conceito de módulos é um aspecto inevitável do desenvolvimento do Terraform. Para obter mais informações, consulte Módulos na documentação do Terraform. AWS CloudFormation também suporta módulos. Para obter mais informações, consulte Introdução aos AWS CloudFormation módulos no blog de operações e migrações na AWS nuvem.

A principal diferença entre os módulos no Terraform CloudFormation é que os CloudFormation módulos são importados usando um tipo de recurso especial (AWS::CloudFormation::ModuleVersion). No Terraform, cada configuração tem pelo menos um módulo, conhecido como módulo raiz. Os recursos do Terraform que estão no arquivo main.tf ou arquivos em um arquivo de configuração do Terraform são considerados como estando no módulo raiz. O módulo raiz pode então chamar outros módulos para inclusão na pilha. O exemplo a seguir mostra um módulo raiz provisionando um cluster do Amazon Elastic Kubernetes Service (Amazon EKS) usando o módulo eks de código aberto.

terraform {
  required_providers {
    helm = {
      source  = "hashicorp/helm"
      version = "2.12.1"
    }
  }
  required_version = ">= 1.2.0"
}

module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  version = "20.2.1"
  vpc_id  = var.vpc_id
}

provider "helm" {
  kubernetes {
    host                   = module.eks.cluster_endpoint
    cluster_ca_certificate = base64decode(module.eks.cluster_certificate_authority_data)
  }
}

Você deve ter notado que o arquivo de configuração acima não inclui o AWS provedor. Isso porque os módulos são independentes e podem incluir seus próprios fornecedores. Como os provedores do Terraform são globais, os provedores de um módulo filho podem ser usados no módulo raiz. No entanto, isso não é verdade para todos os valores do módulo. Outros valores internos em um módulo têm como escopo definido, por padrão, somente esse módulo e precisam ser declarados como saídas para serem acessíveis no módulo raiz. Você pode aproveitar os módulos de código aberto para simplificar a criação de recursos em sua pilha. Por exemplo, o módulo eks faz mais do que provisionar um cluster EKS — ele provisiona um ambiente Kubernetes totalmente funcional. Usá-lo pode evitar que você escreva dezenas de linhas extras de código, desde que a configuração do módulo eks atenda às suas necessidades.

Módulos de chamada

Dois dos principais comandos da CLI do Terraform que você executa durante a implantação do Terraform são terraform init e terraform apply. Uma das etapas padrão que o terraform init comando executa é localizar todos os módulos secundários e importá-los como dependências para o .terraform/modules diretório. Durante o desenvolvimento, sempre que você adiciona um novo módulo de origem externa, é necessário reinicializar antes de usar o comando. apply Quando você ouve uma referência a um módulo do Terraform, ela está se referindo aos pacotes nesse diretório. Estritamente falando, o módulo que você declara em seu código é o módulo de chamada, então, na prática, a palavra-chave module chama o módulo real, que é armazenado como uma dependência.

Dessa forma, o módulo de chamada serve como um representante mais sucinto do módulo completo a ser substituído quando a implantação ocorrer. Você pode aproveitar essa ideia criando seus próprios módulos em suas pilhas para impor separações lógicas de recursos usando os critérios que desejar. Lembre-se de que o objetivo final de fazer isso deve ser reduzir a complexidade da pilha. Como o compartilhamento de dados entre módulos exige que você produza esses dados de dentro do módulo, às vezes confiar demais nos módulos pode complicar demais as coisas.

O módulo raiz

Como cada configuração do Terraform tem pelo menos um módulo, pode ser útil examinar as propriedades do módulo com o qual você mais lidará: o módulo raiz. Sempre que você estiver trabalhando em um projeto do Terraform, o módulo raiz consiste em todos os .tf (ou.tf.json) arquivos em seu diretório de nível superior. Quando você executa terraform apply nesse diretório de nível superior, o Terraform tenta executar todos os .tf arquivos que encontra lá. Todos os arquivos nos subdiretórios são ignorados, a menos que sejam chamados em um desses arquivos de configuração de nível superior.

Isso fornece alguma flexibilidade na forma como você estrutura seu código. Também é por isso que é mais preciso se referir à implantação do Terraform como um módulo do que como um arquivo, pois vários arquivos podem estar envolvidos em um único processo. Há uma estrutura de módulo padrão que o Terraform recomenda para as melhores práticas. No entanto, se você colocasse qualquer .tf arquivo em seu diretório de nível superior, ele será executado junto com o resto dos arquivos. Na verdade, todos os .tf arquivos de nível superior em um módulo são implantados quando você executa. terraform apply Então, qual arquivo o Terraform executa primeiro? A resposta a essa pergunta é muito importante.

Há uma série de etapas que o Terraform executa após a inicialização e antes da implantação da pilha. Primeiro, as configurações existentes são analisadas e, em seguida, um gráfico de dependências é criado. O gráfico de dependências determina quais recursos são necessários e em que ordem eles devem ser tratados. Recursos que contêm propriedades referenciadas em outros recursos, por exemplo, seriam tratados antes dos recursos dependentes. Da mesma forma, os recursos que declaram explicitamente a dependência usando o depends_on parâmetro seriam tratados após os recursos que eles especificam. Quando possível, o Terraform pode implementar paralelismo e lidar com recursos não dependentes simultaneamente. Você pode ver o gráfico de dependências antes da implantação usando o comando terraform graph.

Depois que o gráfico de dependências é criado, o Terraform determina o que precisa ser feito durante a implantação. Ele compara o gráfico de dependências com o arquivo de estado mais recente. O resultado desse processo é chamado de plano e é muito parecido com um conjunto de CloudFormation mudanças. Você pode ver o plano atual usando o comando terraform plan.

Como prática recomendada, é recomendável ficar o mais próximo possível da estrutura padrão do módulo. Nos casos em que seus arquivos de configuração estão ficando muito longos para serem gerenciados com eficiência e as separações lógicas podem simplificar o gerenciamento, você pode distribuir seu código em vários arquivos. Lembre-se de como o gráfico de dependências e o processo de planejamento funcionam para que suas pilhas funcionem da forma mais eficiente possível.