Terraform #parte2 – Alterando sua infraestrutura de forma incremental

Terraform #parte2 – Alterando sua infraestrutura de forma incremental

Vimos no post anterior uma introdução ao Terraform e como criar de forma prática e simples uma máquina virtual na cloud da Google – GCP, porém não vimos como realizar modificações em recursos já existentes.
Conforme seu projeto de infraestrutura vai crescendo e seu código sendo alterado em recursos que já existem, é necessário algum tipo de “mecanismo” para que aplique apenas as novas alterações mantendo assim todo o restante. E o Terraform faz isto para nós, detectando quais são estas mudanças que aconteceram no projeto.
O Terraform ao ser executado grava o estado de sua infraestrutura localmente em um arquivo chamado terraform.tfstate em formato JSON. Este arquivo é gerado sempre no diretório que está sendo executado o Terraform e é por ele que os estados do que já existe em sua infraestrutura são mantidos.
Basicamente o Terraform irá ler o seu arquivo terraform.tfstate e verificar se estas informações ainda permanecem, caso isto não aconteça, o Terraform irá mostrar o que deve ser atualizado.

Então, continuando com a nossa infraestrutura anterior…

Vamos realizar pequenos ajustes na máquina virtual que foi provisionada na GCP.

Começando pequeno (sempre), iremos apenas adicionar labels para esta máquina que já existe, então o novo código fonte fica o seguinte:
resource "google_compute_instance" "default" {
  name         = "linux-vm-1"
  machine_type = "f1-micro"
  zone         = "us-central1-a"

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-9"
    }
  }

  labels = {
    environment = "development"
    distro      = "debian-9"
  }

  network_interface {
    network = "default"
  }
}
Faça o plano de execução para identificar o que irá acontecer com sua infraestrutura:
$ terraform plan
Abaixo está a saída do seu terminal, apenas iremos suprimir o restante do resultado que ficou o mesmo.
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

google_compute_instance.default: Refreshing state... [id=projects/projeto-1/zones/us-central1-a/instances/linux-vm-1]

------------------------------------------------------------------------

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # google_compute_instance.default will be updated in-place
  ~ resource "google_compute_instance" "default" {
        can_ip_forward       = false
        cpu_platform         = "Intel Haswell"
        deletion_protection  = false
        enable_display       = false
        guest_accelerator    = []
        id                   = "projects/projeto-1/zones/us-central1-a/instances/linux-vm-1"
        instance_id          = "3724819701104257360"
        label_fingerprint    = "42WmSpB8rSM="
      ~ labels               = {
          + "company"     = "4Linux"
          + "environment" = "development"
          + "os-system"   = "debian-9"
        }
        machine_type         = "f1-micro"
        metadata             = {}
        metadata_fingerprint = "b20jSyLni-U="
......
......
......
......
Plan: 0 to add, 1 to change, 0 to destroy.
......
......
......

O sumário final nos apresenta o que será criado, neste caso 0 recursos serão adicionados, 1 recurso será alterado e 0 recursos serão destruídos. Perceba que logo no início do output também é mostrado na saída do terminal que já existe esta máquina e em seguida o seguinte trecho de aviso:

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
~ update in-place

Ou seja, o Terraform está informando que todas modificações são mostradas com um ~ (sinal de til) no inicio da linha.

Em nosso caso o recurso da instância está sendo alterado mais precisamente onde adicionamos o novo código (labels).

Para prosseguir com a modificação, execute de fato o Terraform para aplicar o código.

$ terraform apply -auto-approve
Com o seguinte resultado:
google_compute_instance.default: Refreshing state... [id=projects/projeto-1/zones/us-central1-a/instances/linux-vm-1]
google_compute_instance.default: Modifying... [id=projects/projeto-1/zones/us-central1-a/instances/linux-vm-1]
google_compute_instance.default: Modifications complete after 8s [id=projects/projeto-1/zones/us-central1-a/instances/linux-vm-1]

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.

O procedimento para qualquer recurso é basicamente o mesmo para alterar de forma incremental.

    • Você cria o recurso inicial que precisa;
    • Faz o plano de execução;
    • Faz aplicação deste recurso;
    • Quando for necessário alterar qualquer atributo deste código, faça o plano de execução;
    • Verifique se a saída está de acordo;
    • Faça aplicação deste novo código.
Para o próximo artigo, iremos criar uma nova rede e utilizar em conjunto com esta nossa máquina virtual, assim iremos entender como funcionam as dependências entre os diferentes recursos no Terraform.
Anterior 4Linux atualiza seu curso "Python and Spark for Big Data e Machine Learning"
Próxima Por que a transformação digital das grandes corporações passa pela adoção de softwares Open Source?

About author

Você pode gostar também

Infraestrutura

Linux Bonding: Alta Disponibilidade em Interfaces de Rede

Quando falamos de infraestrutura, um dos pré-requisitos é se pensar em alta disponibilidade, seja ela de: Máquinas Virtuais Storages Máquinas Físicas Links de Internet E etc. Nesse post vou explicar

Desenvolvimento

JSON e BSON no MongoDB: para iniciantes

Dando continuidade na série de MongoDB, nesse post farei uma Introdução ao formato “Javascript Object Notation” (JSON), ao BSON e aos primeiros passos com o MongoDB. Compartilhe este post: Twitter

Desenvolvimento

Automatização de Infraestrutura – DevOps e Python

Automatização de Infraestrutura – DevOps e Python Hoje em dia os profissionais de TI estão olhando cada vez mais para DevOps e Python. Se você quer saber por que a