Infraestrutura como código, gerenciamento de configuração e ambientes

Do zero

Imagine montar um servidor clicando em telas: escolher o sistema, a memória, a rede, instalar programas, ajustar configurações. Na segunda vez, alguém esquece um passo. Na décima, ninguém sabe mais por que um servidor é diferente do outro.

A infraestrutura como código (IaC) troca os cliques por uma receita escrita: um arquivo de texto que descreve servidores, redes e bancos. Uma ferramenta lê a receita e monta tudo, sempre igual. Como é texto, a receita vai para o Git: tem histórico, revisão e volta atrás, como qualquer código.

O gerenciamento de configuração cuida do que fica dentro dos servidores: pacotes instalados, arquivos de configuração, serviços ligados. A ferramenta confere cada servidor e corrige o que estiver fora da receita.

E os ambientes são como uma cozinha de restaurante:

• Desenvolvimento: a cozinha de testes, onde o cozinheiro inventa e erra à vontade.
• Homologação: a degustação. O prato é servido num salão igual ao de verdade, para o cliente aprovar antes da estreia.
• Produção: o restaurante aberto ao público. Ali não se experimenta.

Frase para guardar: IaC é a infraestrutura descrita em código versionado; aplicar a mesma receita duas vezes não muda nada (idempotência); o mesmo artefato passa de desenvolvimento a homologação e a produção.

Em 1 minuto

• Declarativo × imperativo: no declarativo, descreve-se o estado desejado (“quero dois servidores web”), e a ferramenta calcula o que fazer (Terraform, CloudFormation, manifestos do Kubernetes). No imperativo, descrevem-se os passos (“crie um servidor, depois outro”), como num script.
• Idempotência: aplicar a mesma configuração várias vezes dá sempre o mesmo resultado; na segunda vez, nada muda.
• Terraform: arquivos em HCL, providers para cada nuvem, ciclo init (prepara), plan (mostra o que vai mudar), apply (aplica) e destroy (remove). O arquivo de estado registra o que existe; deve ficar num armazenamento remoto, com bloqueio e protegido, porque pode conter dados sensíveis.
• Gerenciamento de configuração: Ansible (sem agente, conecta por SSH, playbooks em YAML, modelo push), Puppet e Chef (com agente instalado, que busca a configuração, modelo pull).
• Deriva de configuração (drift): mudança feita à mão, fora do código, que deixa a infraestrutura diferente da receita. O plan a revela.
• Infraestrutura imutável: em vez de alterar servidores em funcionamento, cria-se um novo a partir de uma imagem atualizada e descarta-se o antigo.
• Ambientes: paridade (homologação o mais parecida possível com produção), configuração e segredos fora do código (variáveis de ambiente, cofre de segredos), o mesmo artefato promovido entre ambientes e dados reais só com mascaramento fora da produção.

Exemplo concreto: o portal em homologação e em produção

A infraestrutura, em Terraform. O mesmo código serve aos dois ambientes: muda a variável, e cada ambiente tem o seu próprio arquivo de estado (um workspace ou um backend por ambiente). Sem estados separados, aplicar com ambiente=producao alteraria a máquina de homologação em vez de criar outra.

variable "ambiente" { type = string }            # "homologacao" ou "producao"

resource "aws_instance" "portal" {
  ami           = "ami-0abc1234"                  # imagem aprovada pela equipe
  instance_type = var.ambiente == "producao" ? "m5.large" : "t3.small"
  tags = { Name = "portal-${var.ambiente}" }   # "Name" é a etiqueta que a AWS mostra como nome
}

terraform init                                    # baixa o provider
terraform workspace select -or-create homologacao # estado separado para homologação
terraform plan  -var="ambiente=homologacao"      # mostra o que será criado ou alterado
terraform apply -var="ambiente=homologacao"      # aplica, depois de revisar o plano

A configuração dos servidores, em Ansible:

- name: Configura os servidores web
  hosts: web
  become: true
  tasks:
    - name: Instala o nginx
      ansible.builtin.apt:
        name: nginx
        state: present        # estado desejado: instalado
    - name: Mantém o nginx ligado
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true

Na primeira execução, o Ansible instala e liga o nginx (“changed”). Na segunda, encontra tudo como pedido e não faz nada (“ok”): é a idempotência.

O caminho de uma versão: o pipeline gera uma imagem do portal, versão 2.3.0. Ela vai para homologação, onde os usuários aprovam. A mesma imagem, sem recompilar, vai para produção; o que muda é só a configuração de cada ambiente (endereço do banco, nível de log) e os segredos, lidos do cofre.

Comparação: abordagens, ferramentas e ambientes

Como a FCC cobra

• Ferramentas: Terraform (provisionamento) × Ansible, Puppet e Chef (configuração).
• Comandos e arquivo de estado do Terraform.
• Deriva de configuração e infraestrutura imutável.
• Boas práticas entre ambientes: paridade, mesmo artefato, segredos fora do código.

Pegadinhas

Explique com suas palavras

Explique a um gestor por que descrever a infraestrutura em código evita que os servidores de homologação e de produção fiquem diferentes, e por que a mesma versão deve passar pelos dois.

1. Escreva sem olhar a lição, com frases curtas e um exemplo seu.
2. Onde travar ou precisar de jargão, há uma lacuna: releia só essa parte.
3. Compare com a explicação-modelo e reescreva o que faltou.

Sua explicação

Fica salva neste navegador.

Comparar com uma explicação-modelo

Quando os servidores são montados à mão, cada um sai um pouco diferente: alguém esquece um ajuste aqui, faz uma correção às pressas ali. Com a infraestrutura descrita em código, homologação e produção são montadas pela mesma receita, e a única diferença é o que a gente escolhe de propósito, como o tamanho da máquina. Se alguém mexer à mão, a ferramenta mostra a diferença na próxima conferência.

A homologação só serve para alguma coisa se testa exatamente o que vai para a produção. Por isso a versão aprovada em homologação é a mesma que sobe para produção, sem ser montada de novo. Se fosse refeita, poderia sair diferente, e o teste não valeria mais.

Teste-se

Mais duas questões deste tópico estão em Questões.

Flashcards gerados

Ligação com o estudo de caso

Num caso de padronização de servidores ou de implantação de sistema, proponha: infraestrutura em Terraform e configuração em Ansible, ambos no Git e revisados por pull request; arquivo de estado remoto e protegido; três ambientes com paridade; um único artefato promovido de homologação para produção; segredos num cofre; e dados de produção mascarados antes de qualquer uso fora dela.

Fontes da lição

• Edital nº 01/2026, Anexo II, DevOps, Plataforma de Desenvolvimento e Engenharia de Entrega (fontes/edital-01-2026.txt).
• Kief Morris, Infrastructure as Code (declarativo, idempotência, deriva e infraestrutura imutável).
• Documentação do Terraform e do Ansible.
• The Twelve-Factor App (configuração no ambiente e paridade entre ambientes).