Victor Ricardo

HCL é a sigla para HashiCorp Configuration Language. Teoricamente, uma linguagem cuja própria sintaxe foi concebida e estruturada de maneira a servir como uma espécie de base comum compartilhada (na prática, uma camada de configuração) entre o TERRAFORM e seus “irmãos” (demais produtos desenvolvidos pela empresa) Ainda na literatura, alguns autores chamam esse tipo de Domain Specific Language (ou DSL) Seria uma forma de agrupar todas as linguagens criadas por empresas para suas respectivas ferramentas de IaC (Infrastructure as Code) no contexto DevOps … Muito sopa de letrinhas para você? 🙁 Eu sei, eu sei, talvez para facilitar iremos de uns poucos, e ao mesmo tempo, bons exemplos:

Ansible	Chef	Puppet	Saltstack
YAML (Python)	Ruby	PuppetDSL	YAML (Python)

Dito isso, e retomando a HCL, podemos ir além e enxergá-la como um meio-termo da programação, chegando até mesmo ao ponto de afirmar que ela também é uma API. Isso porque ela foi desenhada para ser amigável em ambos os lados: humanos e máquinas. Resumidamente, aqui o estado desejado para uma determinada configuração pode ser obtido através de uma mistura de arquivos criados em sintaxe humana (inspirada por exemplo na UCL, ou Ruby) e arquivos gerados por máquinas (por exemplo, o formato JSON)

Anda logo Victor … Qual é a moral da história de hoje? 😐 Bom, o que quero dizer com tudo isso (na verdade, após tudo isso) é que como em qualquer outra linguagem de programação, a HCL igualmente suporta o uso de variáveis para valores mutáveis, e principalmente imutáveis (as famosas constantes) Poxa, e não poderia ter falado antes não, hein?! Claro que não, vocês já me conhecem bem! 😛

Portanto, sendo assim, vamos ao conteúdo do dia …

>_ DEFININDO UM VALOR PADRÃO

Dando continuidade as boas práticas da aula passada, ou seja, separando cada vez mais as coisas, crie um novo arquivo no VScode chamado vars.tf e adicione o seguinte:

variable "amis" {

    type = "map"

    default = {
        "us-east-1" = "ami-09cce346b3952cce3"
        "us-east-2" = "ami-045137e8d34668746"
    }
  
}

Aqui estamos criando uma variável chamada “AMIs”, do tipo “mapa”, que armazena dados no formato “chave:valor” (como se fosse um arquivo JSON, por exemplo) Por fim, salve e retorne ao main.tf para alterar as seguintes linhas:

resource "aws_instance" "dev5" {
  ami           = var.amis["us-east-2"]
  instance_type = "t2.micro"
  key_name      = "terraform-kali"
  tags = {
    Name = "dev5"
  }
  vpc_security_group_ids = [ "${aws_security_group.ssh-access.id}" ]
}

resource "aws_instance" "dev6" {
  provider      = aws.us-east-1
  ami           = var.amis["us-east-1"]
  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
  ]
}

Dessa forma, não precisamos mais decorar ou digitar sempre o mesmo código referente a “essa” ou “aquela” imagem específica. Basta colocar a chave para que o programa retorne o valor correspondente já definido em vars.tf

Agora sim, hora de testar com terraform plan Lembrando que a saída esperada aqui é a mensagem sem alterações, pois é como se estivéssemos trocando seis por meia dúzia. Ou seja, apenas uma outra maneira de escrever a mesma coisa! (de referenciar as mesmas imagens)

>_ DEFININDO UM NOVO TIPO: LISTA

Simplificamos a questão das imagens, então agora faremos o mesmo com os endereços ips, ou melhor, os blocos de acesso (CIDR) que estão liberados atualmente para as máquinas EC2. Por se tratarem de endereços dinâmicos, ou seja, que mudam de tempos em tempos, a cada vez que o provedor de internet mudar seu IP público, você terá dois trabalhos: modificar o arquivo security-groups.tf e também as linhas correspondentes no arquivo principal main.tf (o que convenhamos, não muito inteligente) Sendo assim, acompanhe comigo e repita os passos:

Abra o vars.tf e crie uma nova variável do tipo “lista” chamada “ips_remotos”. Em seguida, simule a necessidade de dois IPs distintos para cada filial ou cidade em que suas equipes estão trabalhando. Parênteses: aqui sugiro que você consulte seu IP vigente em https://www.whatismyip.com/ copie e cole o mesmo duas vezes nas variáveis, mas ao final do último edite o octeto para .XX (isso porque caso escolha um número aleatório, salve e siga em frente, a pessoa que também é cliente da mesma operadora com aquele segundo “inofensivo” IP que digitou terá acesso autorizado às instâncias que assim você definiu … então, depois não reclame … )

variable "ips_remotos" {

    type = list

    default = ["187.19.211.170/32","187.19.211.XX/32"]
  
}

Substitua as referências lá no security-group.tf pela nova variável

resource "aws_security_group" "ssh-access" {
  name        = "ssh-access"
  description = "Allow SSH inbound traffic"
  
  ingress {
    description      = "SSH from VPC"
    from_port        = 22
    to_port          = 22
    protocol         = "tcp"
    cidr_blocks      = var.ips_remotos
    #ipv6_cidr_blocks = [aws_vpc.main.ipv6_cidr_block]
  }

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"
  
  ingress {
    description      = "SSH from VPC"
    from_port        = 22
    to_port          = 22
    protocol         = "tcp"
    cidr_blocks      = var.ips_remotos
    #ipv6_cidr_blocks = [aws_vpc.main.ipv6_cidr_block]
  }

E confira se os novos endereços estarão dentro do planejamento sem nenhum erro terraform plan

Pequena errata: o TERRAFORM é inteligente o suficiente para reconhecer que um IP de final .XX não é um padrão esperado para blocos de acesso. Portanto, troque o primeiro octeto do 2º ip para atual+1, salve e ao terminar esse laboratório desligue a instância EC2 para não ser “ownado” conforme já explicado anteriormente. Ok?

>_ DEFININDO UM NOVO TIPO: STRING

Somente como um teste rápido, até porque não há tanto segredo quanto a esta. Na verdade, bastante simplória pra ser honesto. Repita comigo:

vars.tf

variable "key_name" {

    default = "terraform-kali"
  
}

main.tf

resource "aws_instance" "dev5" {
  ami           = var.amis["us-east-2"]
  instance_type = "t2.micro"
  key_name      = var.key_name
  tags = {
    Name = "dev5"
  }
  vpc_security_group_ids = [ "${aws_security_group.ssh-access.id}" ]
}

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

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

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

REFERÊNCIAS:

https://www.terraform.io/docs/glossary

https://github.com/hashicorp/hcl

https://www.redhat.com/pt-br/topics/automation/what-is-infrastructure-as-code-iac

https://www.edureka.co/blog/chef-vs-puppet-vs-ansible-vs-saltstack/