Terraform Providers
Olá pessoal, tudo em ordem? Vou começar uma série de posts sobre terraform utilizando AWS. Neste primeiro artigo vou discutir alguns pontos sobre o Provider AWS.
Vou começar com uma brevíssima descrição sobre AWS para dar sentido ao post, mas imagino que se você chegou até este artigo, provavelmente já tem algum conhecimento de AWS e busca como aprimorar seu uso utilizando Infra as Code (IaC). Então, para sintetizar nosso papo sobre Cloud Provider, AWS é um conjunto de recursos/serviços na nuvem que normalmente você paga pelo tempo de uso, alguns são completamente free e outros são free até determinado limite.
Se você tiver começando com AWS, você ainda pode aproveitar o free tier, onde alguns serviços podem ser utilizados gratuitamente por um ano, desde que respeitado seu tamanho (sempre é indicado na console) e quantidade de uso. Eu explico melhor sobre ele neste artigo ( https://yadax.com.br/aws/aws-free-tier/).
Entre os recursos disponíveis na AWS que usarei como exemplo, temos alguns de network, como VPC, subnet e route table. Já voltado para Infra as a Service (IaaS), temos as instâncias EC2 que são máquinas virtuais de uso geral. Para o lado de Platform as a Service (PaaS), o RDS é um banco de dados relacional prontinho para o uso.
O importante aqui é que tudo isso será tratado como Resource dentro de nossos scripts do Terraform.
Mas o que é Terraform? Ela é uma ferramenta open source criada pela HashiCorp que permite o provisionamento (criação) prático e reprodutível de sua infraestratura. Imagine que você tenha um blog e precisa de uma infra básica de redes, uma instância de processamento (EC2) e um banco de dados (RDS). Tudo isso pode ser criado e gerenciado a partir de arquivo textos, por isso o nome de Infrastructure as Code.
O Terraform tem uma linguagem simples e declarativa. Você só precisa escolher seu provider (provedor), seus recursos e apertar o play. Provider é qual tipo de Cloud você está usando. Você precisa indicar isso nos seus scripts e automaticamente o Terraform baixa um plugin que sabia conversar com ele. Providers mais comuns? São eles: AWS, GPC, Azure…
Olhando especificamente para o Terraform Provider – um arquivo de configuração que nos permite “conversar” com seu Cloud Provider – temos algumas informações obrigatórias e outras opcionais.
Uma importante é a região em que irá fazer o deploy, ela é obrigatória, e, alternativamente, pode ser passada via variável de ambiente. Outra é a versão do Provider, que talvez você não precise se preocupar caso sua infra não tenha coisas relacionadas a serviços lançados recentemente. Caso não informe, o terraform utilizará a mais recente.
Este é um exemplo bem simples de uma configuração de Cloud Provider: um arquivo provider.tf dentro de sua pasta de trabalho.
# AWS Provider
provider "aws" {
version = "~> 2.0"
region = "us-east-1"
}
As últimas informações necessárias estão relacionadas as credenciais que você utilizará para aplicar sua infra. Vou gastar um parágrafo chamando a atenção de um ponto crucial de segurança, pois neste ponto olhamos para a Access Key (AK) e Secret Access Key (SAK).
Para utilizar a console da AWS normalmente você usa usuário e senha, correto? Porém, se ao invés de dar cliques você preferir gerenciar seus recursos via AWS CLI, via API utilizando python ou via Terraform, por exemplo, como é feito esta autenticação? Através do AK e SAK. Então, pense assim: seu AK e SAK está ligado a um User, o que você consegue fazer via console com este User, você conseguirá fazer programaticamente. Por fim, se seu AK e ASK vazarem (o mais comum é commit inocente no GitHub), é o mesmo que ter seu User e Senha vazados, com o detalhe que programaticamente você consegue subir 100 instances EC2 em poucos segundos. Resumindo, jamais versione AK e SAK em repositório público. 🙂
Aqui entra uma combinação de fatores. Para o caso da AWS, temos quatro opções:
1 – Na estática, você passa sua AK e SAK na chamada do provider, desta forma:
provider "aws" {
region = "us-west-2"
access_key = "my-access-key"
secret_key = "my-secret-key"
} Novamente, olhando pelo ponto de vista que normalmente nosso código Terraform está versionado em algum lugar, como um github, este modelo não é recomendado, principalmente se o repositório for público. Acredite, se fizer isto em poucas horas a AWS bloqueia sua conta ou algum mal intencionado subirá tantas máquinas quanto sua conta permitir.
2 – A próxima opção é utilizar variáveis de ambiente para indicar suas keys: AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY. Também é possível indicar a região através da AWS_DEFAULT_REGION e, desta forma, seu provider pode ficar assim:
provider "aws" {}E para chamar o terraform você faz:
$ export AWS_ACCESS_KEY_ID="anaccesskey"
$ export AWS_SECRET_ACCESS_KEY="asecretkey"
$ export AWS_DEFAULT_REGION="sa-east-1"
$ terraform apply
3 – A terceira opção, e talvez a mais comum, é ter um arquivo de credentials compartilhado, com AccessKey e SecretKey separados por profiles (um profile para cada projeto).
Seu arquivo de credenciais (~/.aws/credentials) fica parecido com:
[accounting]
aws_access_key_id = AAWWVXXXXXXXOKAASS
aws_secret_access_key = abclkjiwjASJDFWskadfiw
[customer-xp]
aws_access_key_id = ASDFKJWIWKKKKKKKSOK
aws_secret_access_key = 123KJHGSUUwwsjisjiajsdkfj123KKKK
E ao declarar seu provider, você especifica o caminho deste arquivo e o profile a ser utilizado. Desta forma:
provider "aws" {
region = "sa-east-1"
shared_credentials_file = "~/.aws/credentials"
profile = "accounting"
}4 – E por último, você pode fazer a entrega de sua infra a partir de um resource AWS, como uma instância EC2, que pode ter attachado um Role que permite a criação de outros resources. Neste caso, no seu provider é necessário informar a Role a ser utilizada.
provider "aws" {
assume_role {
role_arn = "arn:aws:iam::ACCOUNT_ID:role/ROLE_NAME"
}
}Se quiser dar uma olhada na documentação, basta clicar aqui (https://www.terraform.io/docs/providers/aws/index.html).
No próximo artigo vamos começar organizar nosso código Terraform e iniciar os primeiros recourses. Se quiser ser notificado quando o artigo sair, basta se escrever na nossa newsletter. Até lá.
Tag:AWS, infra as code, terraform
Você também pode gostar
AWS Free Tier
15 setembro, 2019
AWS – Rodando DynamoDB local
3 maio, 2019
Deploy Cassandra AWS com Ansible
12 novembro, 2018
