Hoje vamos dar os primeiros passos no mundo da Infraestrutura como um Código, a.k.a. IaC, fazendo a instalação local do Terraform, autenticando no Azure via cli e criando o primeiro objeto no Azure.
O Terraform faz uso do HCL (Hashicorp Configuration Language) e a sua sintaxe foi muito baseada na libucl.
Para falar sobre o Terraform (como funciona, detalhes, componentes, divisões, etc), eu poderia criar uma série apenas para isso, mas não é a ideia aqui. Vamos colocar a mão na massa direto.
Passo 1: Instalando o Chocolatey & Terraform
Para instalar o Terraform no Windows, antes, precisamos instalar o Chocolatey antes (que é um gerenciador de pacotes do windows). Você pode rodar tudo em uma linha (lembre-se de executar como administrador, senão vai dar erro), mas se quiser, rode os 3 comandos separadamente:
|
1 2 3 |
Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1')) |
Instalado o Chocolatey, vamos instalar o Terraform:
|
1 |
choco install terraform |
Uma recomendação… Coloquem o Terraform no Path, para não precisarem ficar copiando o executável a cada novo projeto.
Passo 2: Instalação do Azure CLI
Pelo print acima, vocês devem ter notado que eu já estava com o CLI habilitado, mas o que vocês devem rodar no terminal (mais uma vez, como administrador):
|
1 2 3 |
Invoke-WebRequest -Uri https://aka.ms/installazurecliwindows -OutFile .\AzureCLI.msi; Start-Process msiexec.exe -Wait -ArgumentList '/I AzureCLI.msi /quiet'; rm .\AzureCLI.msi |
O que essa linha fará:
- Baixar o instalador do AZ CLI
- Executar em modo silencioso
- Remover o instalador
Passo 3: Autenticar no Azure
Para se autenticar no Azure, você deve executar o comando:
|
1 |
az login |
(Caso dê erro, feche o terminal, abra novamente e reexecute o comando)
Ao digitar o az login uma página abrirá para você se autenticar no Azure… Coloque seu usuário, sua senha e o retorno será de um json com os dados das assinaturas que a conta tem acesso. Algo mais ou menos assim:
Caso apareça várias subscriptions e você queira se conectar em alguma em específico, use o seguinte comando:
|
1 |
az account set --subscription "123ABC-SubscriptionID" |
Não vai ser nesse post que eu vou falar sobre a criação de um Service Principal específico para o Terraform e como configurar as variáveis de ambiente para fazer uso dele… Isso vai ficar para um outro momento, mas tenham isso em mente quando forem desenvolver, fechado?
Passo 4: Criar o Resource Group
Feita toda a função… chegou a hora de brincarmos com o HCL!
Aqui, nós temos duas opções…
- Criar um único arquivo e fazer o deploy. (Meh)
- Organizar em alguns arquivos e fazer um deploy “diferente”
É óbvio que vamos para a segunda opção… 😉
Vamos criar os seguintes arquivos:
- providers.tf
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
terraform{ required_version = ">=1.1.0" required_providers { azurerm = { source = "hashicorp/azurerm" version = "~>3.10.0" } } } provider "azurerm"{ features {} } |
Com a opção required_version, é possível determinar uma versão mínima para o funcionamento do Terraform. No meu caso, coloquei a versão 1.1.0. Veja o que acontece se, ao invés de ‘>=1.1.0‘, eu tivesse colocado um ‘=1.1.0‘ (informando que eu só posso executar o script com esta versão em especial:
Com o required_providers, eu informo quais o providers eu vou utilizar no projeto. Neste caso, será o azurerm e a versão última versão a partir da 3.10.0 (para mais informações, veja sobre version-constraints)
No bloco provider eu determino as configurações de cada provider que eu vou utilizar. Neste caso, eu vou usar o provider azurerm e vou utilizar as opções padrão.
- variables.tf
A ideia aqui é mostrar a possibilidade de criarmos algumas opções caso se queira aproveitar alguma informação mais adiante, como por exemplo, um prefixo ou então a localização que iremos colocar o nosso ambiente:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
variable "rg_prefixo" { default = "rg" description = "Prefixo para os Resource Groups criados" } variable "ambiente" { default = "dev" description = "Ambiente que estamos utilizando" } variable "rg_localizacao"{ default = "eastus" description = "Localização do RG" } |
- main.tf
Aqui é onde vamos criar os recursos propriamente ditos.
|
1 2 3 4 5 6 7 8 |
resource "random_pet" "nome-rg"{ prefix = "${var.rg_prefixo}-${var.ambiente}" } resource "azurerm_resource_group" "rg" { name = random_pet.rg-name.id location = var.rg_localizacao } |
Talvez você esteja se perguntando de onde saiu esse random_pet né? Dê uma olhada aqui.
A ideia é que, usando o provider random, você possa construir recursos usando nomes aleatórios, crie senhas, número inteiros, uuids, etc.
Em resumo: Primeiro determinamos o nome do nosso recurso (que aqui ficará como rg-dev) e, em seguida, a gente consiga criar o Resource Group usando as informações acima.
- output.tf
Vamos criar agora um arquivo apenas para podermos validar como os dados ficaram, no final.
|
1 2 3 |
output "nome_do_rg" { value = azurerm_resource_group.rg.name } |
Passo 5: Executando o Terraform
Ufa! Agora, vamos para a parte massa… Vamos ver a coisa toda rodando.
Primeiro, devemos inicializar o projeto:
|
1 |
terraform init |
Agora, devemos validar se está tudo de acordo e planejar:
|
1 |
terraform validate |
|
1 |
terraform plan |
Veja que o plan criou um passo a passo do que será feito, avisando sobre a criação dos recursos e informando que alguns dos nomes serão conhecidos apenas no momento da criação, pois será criado dinamicamente.
E por último (mas não menos importante):
|
1 |
terraform apply |
Apenas como observação… Notem que é preciso realizar uma confirmação para realizar o processo e, logo em seguida, ele já retorna o valor do Resource Group criado.
Vamos ver se deu certo? Vamos no Portal do Azure e ver os Resources Groups:
E voi lá, temos o nosso primeiro objeto criado usando IaC.
Caso queira destruir o que fez, ainda via Terraform, basta rodar um terraform destroy e confirmar a operação. Levou pouco mais de um minuto para mim nos testes. Eu não vou rodar, pois quero usar esse mesmo RG para os próximos passos.
Próximos passos:
- Criar novos objetos.
- Configurar o Service Principal
- Colocar no git ou no DevOps para pensar em CI/CD
- …
Caso queira acompanhar as evoluções, estou colocando as alterações no meu github:
Mas claro que toda nova manutenção, informarei em um novo post por aqui (saindo a primeira série de 2022?).
[]’s!!
Muito bom esse artigo..
Opa! Fico feliz que tenha gostado Anderson.
Espero conseguir dar andamento e fazer a série envolvendo algumas clouds e outros recursos. 🙂