Victor Ricardo

Analogamente ao que acontece nas ROLES em Ansible, manifestos e scripts pensados para Terraform seguem uma recomendação: pequenas partes que irão compor um todo. Em outras palavras, seria aquela velha máxima de “dividir para conquistar” … Ou seja, ao invés de escrevermos tudo num único arquivo de configuração (HCL), de agora em diante vamos começar a separar as coisas. Estabelecendo um padrão e seguindo as boas práticas, daqui pra frente recursos que possam ser considerados como “secundários” serão escritos em outro(s) arquivos(s), contudo preservando sempre a extensão .tf (terraform) para todos, incluindo o main. Ok? Eu sei, eu sei, você deve estar pensando … Mas Victor, o que considero como principal talvez seja secundário para você, e vice-versa. Exatamente meu caro e minha cara, e por isso que cá entre nós fica combinado assim: instâncias, buckets, banco de dados, estão em primeiro plano. Ademais, security-groups, VPCs e variáveis são coadjuvantes e portanto, secundários. Tudo bem? Alguma objeção? Maravilha! Mãos-a-obra então 😉

COMO SEPARAR CONFIGS NO TERRAFORM?

Talvez essa seja a melhor parte: automaticamente. Sim, você não leu errado. Pelo contrário. O Terraform interpretará tal divisão nativamente. Basta que você crie os novos arquivos nomeando-os com a extensão certa, que neste caso é a .tf E pronto! A única ressalva é que tudo precisa estar sob o mesmo diretório para funcionar corretamente. Vamos ao nosso exemplo:

Selecione o trecho correspondente às configurações do security-group, em seguida copie o mesmo, depois cole em um novo arquivo chamado security-group.tf, para finalmente executar mais uma vez o comando terraform plan

https://raw.githubusercontent.com/vicrlda/terraform-aws/master/security-group.tf

resource "aws_security_group" "ssh-access" {
  name        = "ssh-access"
  description = "Allow SSH inbound traffic"
  #vpc_id      = aws_vpc.main.id

  ingress {
    description      = "SSH from VPC"
    from_port        = 22
    to_port          = 22
    protocol         = "tcp"
    cidr_blocks      = ["187.19.208.26/32"]
    #ipv6_cidr_blocks = [aws_vpc.main.ipv6_cidr_block]
  }

  egress {
    from_port        = 0
    to_port          = 0
    protocol         = "-1"
    cidr_blocks      = ["0.0.0.0/0"]
    #ipv6_cidr_blocks = ["::/0"]
  }

  tags = {
    Name = "ssh-access"
  }
}

Viram só? Não é magia, é tecnologia! 🙂 Claro que existem outras formas de boas práticas, por exemplo, criar um arquivo TERRAFORM somente para instâncias, outro exclusivo para bancos de dados, um terceiro apenas para S3 … Enfim, ficaria mais ou menos assim: instances.tf / databases.tf / buckets.tf

ALIAS = NOVOS RECURSOS + REGIÕES DIFERENTES

Até aqui a maioria dos itens estavam basicamente na mesma região, a us-east-2, ou simplesmente Ohio, nos Estados Unidos. Mas nós sabemos muito bem que nem sempre é assim no mundo real, afinal seus clientes em potencial podem estar em qualquer lugar do mundo. Além disso, é provável que em conversas com alguns clientes, certos casos levem a seguinte exigência:

– “Não, tenho ciência que as coisas são mais baratas em Ohio e Virgínia do Norte, mas eu quero latência mínima, quase zero. Gostaria que cada serviço estivesse o mais próximo de mim possível, e estou disposto a pagar”

E então? Como prosseguir? 😐 A resposta é um recurso denominado alias

A princípio, devemos copiar o segundo bloco do arquivo main.tf, identificado como provider “aws” { e colá-lo imediatamente abaixo, criando assim um bloco gêmeo mas escrito da seguinte maneira:

OHIO

provider "aws" {
  profile = "default"
  region  = "us-east-2"
}

NORTH VIRGINIA

provider "aws" {
  alias = "us-east-1"
  profile = "default"
  region  = "us-east-1"
}

Na sequência, vamos supor a necessidade de uma sexta máquina para a reforçar a nossa infra atual, sendo internamente provisionado um banco de dados. Copie baseado na dev5, cole imediatamente após, e edite na “nova” dev6 os parâmetros: ami, security-group

OHIO

resource "aws_security_group" "ssh-access" {
  name        = "ssh-access"
  description = "Allow SSH inbound traffic"
  #vpc_id      = aws_vpc.main.id

  ingress {
    description      = "SSH from VPC"
    from_port        = 22
    to_port          = 22
    protocol         = "tcp"
    cidr_blocks      = ["187.19.208.98/32"]
    #ipv6_cidr_blocks = [aws_vpc.main.ipv6_cidr_block]
  }

  egress {
    from_port        = 0
    to_port          = 0
    protocol         = "-1"
    cidr_blocks      = ["0.0.0.0/0"]
    #ipv6_cidr_blocks = ["::/0"]
  }

  tags = {
    Name = "ssh-access"
  }
}

NORTH VIRGINIA

resource "aws_security_group" "ssh-access-us-east-1" {
  provider = aws.us-east-1
  name        = "ssh-access-us-east-1"
  description = "Allow SSH inbound traffic"
  #vpc_id      = aws_vpc.main.id

  ingress {
    description      = "SSH from VPC"
    from_port        = 22
    to_port          = 22
    protocol         = "tcp"
    cidr_blocks      = ["187.19.208.98/32"]
    #ipv6_cidr_blocks = [aws_vpc.main.ipv6_cidr_block]
  }

  egress {
    from_port        = 0
    to_port          = 0
    protocol         = "-1"
    cidr_blocks      = ["0.0.0.0/0"]
    #ipv6_cidr_blocks = ["::/0"]
  }

  tags = {
    Name = "ssh-access-us-east-1"
  }
}

OHIO

resource "aws_instance" "dev5" {
  ami           = "ami-045137e8d34668746"
  instance_type = "t2.micro"
  key_name      = "terraform-kali"
  tags = {
    Name = "dev5"
  }
  vpc_security_group_ids = [ "${aws_security_group.ssh-access.id}" ]
}

NORTH VIRGINIA

resource "aws_instance" "dev6" {
  provider      = "aws.us-east-1"
  ami           = "ami-09cce346b3952cce3"
  instance_type = "t2.micro"
  key_name      = "terraform-kali"
  tags = {
    Name = "dev6"
  }
  vpc_security_group_ids = [ "${aws_security_group.ssh-access-us-east-1.id}" ]
}

Por fim, e antes de criarmos efetivamente o banco de dados na nova máquina, uma pausa para validar se todas essas mudanças propostas de fato não irão apresentar nenhum erro quando aplicadas em PRODUÇÃO . . .

terraform plan

Perfeito! Aparentemente tudo será criado/modificado sem erros. Portanto, faltam apenas dois detalhes: (a) transmitir a chave SSH para a nova região; (b) criar o banco de dados na máquina seis.

Passo um: importar a chave em N.Virginia via console

Passo dois: criar o banco em N.Virginia via terraform

resource "aws_instance" "dev6" {
  provider      = aws.us-east-1
  ami           = "ami-09cce346b3952cce3"
  instance_type = "t2.micro"
  key_name      = "terraform-kali"
  tags = {
    Name = "dev6"
  }
  vpc_security_group_ids = [ "${aws_security_group.ssh-access-us-east-1.id}" ]
  depends_on = [
    aws_dynamodb_table.HOMOLOG-dynamodb
  ]
}

resource "aws_dynamodb_table" "HOMOLOG-dynamodb" {
  provider = aws.us-east-1
  name           = "GameScores"
  billing_mode   = "PAY_PER_REQUEST"
  #read_capacity  = 20
  #write_capacity = 20
  hash_key       = "UserId"
  range_key      = "GameTitle"

  attribute {
    name = "UserId"
    type = "S"
  }

  attribute {
    name = "GameTitle"
    type = "S"
  }
}

terraform plan

terraform apply

Teste final “A”

Teste final “B”

Teste final “C”

REFERÊNCIAS:

https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/dynamodb_table#example-usage

https://cloud-images.ubuntu.com/locator/ec2/