DEV Community: Rafael Dutra

Docker no dia a dia - comandos essenciais e primeiros containers reais

Rafael Dutra — Thu, 13 Aug 2026 00:23:30 +0000

1. Retomando: de imagens a containers em execução

Na primeira parte desta série vimos o que é o Docker, o problema que ele resolve e os três conceitos fundamentais — imagens, containers e registries. Agora que a base teórica está posta, o foco deste artigo é prático: os comandos que efetivamente viram hábito no uso diário — run, exec, logs, ps, build — aplicados a containers reais, não só ao hello-world.

2. `docker run` além do básico

O artigo anterior já usou docker run para subir um Nginx. Vale conhecer as flags que aparecem o tempo todo:

# Modo interativo, útil para explorar uma imagem manualmente
docker run -it ubuntu bash

# Variáveis de ambiente
docker run -e POSTGRES_PASSWORD=segredo -d postgres

# Montar um diretório do host dentro do container (volume bind mount)
docker run -v $(pwd)/dados:/dados -d minha-imagem

# Remover o container automaticamente quando ele parar
docker run --rm -it python:3.12 python3

# Limitar recursos
docker run --memory=512m --cpus=1 minha-imagem

-it combina -i (interativo, mantém STDIN aberto) com -t (aloca um pseudo-terminal) — é o par de flags para "entrar" em um container e usar um shell como se fosse uma máquina normal.
--rm evita acumular containers parados no disco depois de testes rápidos e descartáveis — sem ela, cada docker run deixa um container parado para trás até ser removido manualmente.
-e define variáveis de ambiente; imagens oficiais como a do Postgres costumam documentar quais variáveis elas esperam (usuário, senha, nome do banco inicial).

3. Inspecionando o que está rodando

O comando mais usado para ter uma visão geral do que o Docker está gerenciando na máquina:

docker ps              # containers em execução
docker ps -a            # todos, incluindo parados
docker ps -q            # só os ids (útil em scripts)

Para investigar um container específico mais a fundo:

docker inspect meu-container      # todos os metadados em JSON: rede, volumes, config
docker top meu-container          # processos rodando dentro do container
docker stats                      # uso de CPU/memória em tempo real de todos os containers

docker stats é particularmente útil para detectar um container consumindo memória ou CPU muito acima do esperado, sem precisar entrar nele.

4. Logs: a primeira ferramenta de debug

Containers geralmente não têm um arquivo de log tradicional acessível de fora — a convenção do Docker é que a aplicação escreva na saída padrão (stdout/stderr), e o Docker captura isso automaticamente:

docker logs meu-container          # todo o log acumulado
docker logs -f meu-container        # segue o log em tempo real (como tail -f)
docker logs --tail 100 meu-container  # só as últimas 100 linhas
docker logs --since 10m meu-container # só os últimos 10 minutos

Na prática, docker logs -f nome-do-container costuma ser o primeiro comando rodado ao investigar um container que não está se comportando como esperado — antes até de entrar nele.

5. `docker exec`: entrando em um container já rodando

Diferente de docker run (que cria um novo container), docker exec executa um comando dentro de um container que já está rodando:

# Abrir um shell dentro de um container em execução
docker exec -it meu-container bash

# Rodar um comando pontual sem abrir shell interativo
docker exec meu-container ls /app

# Útil para inspecionar o banco de um container Postgres
docker exec -it meu-postgres psql -U postgres

Esse é o comando do dia a dia para depurar um container em produção (ou em homologação) sem reiniciá-lo: verificar se um arquivo de configuração chegou certo, olhar o conteúdo de um diretório, testar conectividade de rede com curl de dentro do container, etc.

6. `docker build`: da aplicação à imagem

Todos os exemplos até aqui usaram imagens prontas do Docker Hub. Para empacotar uma aplicação própria, o ponto de partida é um Dockerfile (o Artigo 3 desta série é inteiramente dedicado a escrevê-los bem) — por agora, um exemplo mínimo para uma aplicação Python:

# Dockerfile
FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["python3", "app.py"]

Construir a imagem a partir desse arquivo:

docker build -t minha-app:1.0 .

-t minha-app:1.0 — dá um nome (minha-app) e uma tag (1.0) à imagem resultante. Sem tag explícita, o Docker usa latest por padrão — algo a evitar em ambientes reais, porque latest não diz nada sobre qual versão do código está de fato empacotada ali.
. — o contexto de build: o diretório cujo conteúdo fica disponível para os comandos COPY/ADD do Dockerfile. Tudo dentro dele é enviado ao Docker daemon antes do build começar, então diretórios grandes e irrelevantes (como .git, node_modules) devem ser excluídos com um arquivo .dockerignore.

Depois de construída, a imagem já pode ser rodada como qualquer outra:

docker run -d --name minha-app-container minha-app:1.0

7. Limpando o ambiente

Containers parados, imagens não usadas e volumes órfãos se acumulam rápido durante o desenvolvimento. Comandos úteis de limpeza:

docker container prune    # remove todos os containers parados
docker image prune         # remove imagens "dangling" (sem tag, órfãs de build)
docker image prune -a      # remove também imagens não usadas por nenhum container
docker system prune        # limpeza geral: containers parados, redes e imagens não usadas

Vale rodar docker system df antes, para ter uma ideia de quanto espaço em disco está sendo ocupado por cada categoria (imagens, containers, volumes, cache de build) antes de decidir o que limpar.

8. Conclusão e próximos passos

Com run, ps, logs, exec e build, já é possível cobrir o ciclo completo do dia a dia: subir containers, inspecionar o que está rodando, depurar problemas e empacotar uma aplicação própria em imagem. No próximo artigo, o foco entra a fundo no Dockerfile: como as camadas funcionam, como aproveitar o cache de build para acelerar builds repetidos, e boas práticas para escrever um Dockerfile enxuto e eficiente.

Imagem de capa: Logo oficial do Docker — Wikimedia Commons, fonte: docker.com/company/newsroom/media-resources

Referências:

Docker - O Que É, Para Que Serve e Conceitos Iniciais

Rafael Dutra — Wed, 12 Aug 2026 09:30:09 +0000

1. O Problema que o Docker Resolve

"Na minha máquina funciona." Poucas frases resumem tão bem um problema que atormentou (e ainda atormenta) times de desenvolvimento: um código que roda perfeitamente no notebook do desenvolvedor, mas quebra no servidor de produção — porque a versão do Python é outra, uma biblioteca do sistema está faltando, uma variável de ambiente não foi configurada, ou o sistema operacional simplesmente se comporta de forma diferente.

O Docker resolve exatamente isso: ele empacota uma aplicação junto com tudo que ela precisa para rodar — código, dependências, bibliotecas do sistema, variáveis de ambiente, configuração — em uma unidade isolada e portátil chamada container. Essa unidade roda da mesma forma em qualquer lugar que tenha o Docker instalado: no notebook do desenvolvedor, no servidor de CI, ou em produção. Esta é a primeira parte de uma série que vai do zero ao avançado em Docker: hoje o foco é entender o problema que ele resolve, os conceitos fundamentais e como eles se encaixam.

2. Containers vs Máquinas Virtuais

A comparação mais comum ao explicar Docker é com máquinas virtuais (VMs), porque ambos resolvem um problema parecido — isolar e empacotar aplicações — mas de formas muito diferentes.

Uma máquina virtual virtualiza o hardware inteiro: cada VM roda seu próprio sistema operacional completo (kernel incluso), gerenciado por um hypervisor. Isso garante isolamento forte, mas tem um custo alto: cada VM consome centenas de MBs a alguns GBs de disco e memória só para o SO, e leva de dezenas de segundos a minutos para inicializar.

Um container, por outro lado, virtualiza no nível do sistema operacional: todos os containers em uma máquina compartilham o mesmo kernel do host, mas cada um enxerga seu próprio sistema de arquivos, processos e rede isolados — usando recursos do kernel Linux como namespaces (isolamento de visão) e cgroups (limites de CPU/memória). O resultado é que containers são muito mais leves: alguns MBs a poucas centenas de MBs, com inicialização em milissegundos a poucos segundos.

┌─────────────────────────┐        ┌─────────────────────────┐
│   VM 1    │    VM 2      │        │  Container 1│Container 2│
│  ┌─────┐  │   ┌─────┐    │        │  ┌───────┐  │ ┌───────┐ │
│  │ App │  │   │ App │    │        │  │  App  │  │ │  App  │ │
│  ├─────┤  │   ├─────┤    │        │  ├───────┤  │ ├───────┤ │
│  │ SO   │  │   │ SO  │    │        │  │ Libs  │  │ │ Libs  │ │
│  └─────┘  │   └─────┘    │        │  └───────┘  │ └───────┘ │
├───────────┴──────────────┤        ├─────────────┴───────────┤
│        Hypervisor        │        │      Docker Engine       │
├───────────────────────────┤        ├───────────────────────────┤
│     SO Host + Hardware    │        │     SO Host + Hardware    │
└───────────────────────────┘        └───────────────────────────┘

Isso não significa que containers substituem VMs em todo cenário — VMs continuam sendo a escolha certa quando o isolamento precisa ser total (por exemplo, rodar cargas de múltiplos clientes não confiáveis na mesma máquina física) ou quando se precisa de um kernel diferente do host. Mas para o caso mais comum — empacotar e distribuir aplicações de forma consistente — containers ganham em leveza, velocidade de inicialização e densidade (quantas cargas cabem na mesma máquina).

3. Os Três Conceitos Fundamentais: Imagens, Containers e Registries

Todo o modelo mental do Docker gira em torno de três peças:

Imagem (image): um pacote read-only com tudo que uma aplicação precisa para rodar — sistema de arquivos, binários, bibliotecas, código da aplicação e metadados (como qual comando executar ao iniciar). É construída a partir de um Dockerfile (assunto do Artigo 3 desta série) e organizada em camadas (layers) empilhadas, o que permite reaproveitar partes já construídas entre builds diferentes.
Container: uma instância em execução de uma imagem. Se a imagem é a "planta" (como uma classe em programação orientada a objetos), o container é o "objeto" instanciado a partir dela — com um processo rodando, um sistema de arquivos gravável em cima da imagem read-only, e seu próprio espaço de rede isolado. É possível rodar múltiplos containers a partir da mesma imagem, cada um independente dos outros.
Registry: um repositório para armazenar e distribuir imagens. O Docker Hub é o registry público padrão (onde vivem imagens oficiais como python, postgres, nginx), mas existem registries privados (AWS ECR, Google Artifact Registry, GitHub Container Registry) para imagens internas de uma empresa.

O fluxo típico conecta essas três peças: escreve-se um Dockerfile, constrói-se uma imagem a partir dele, essa imagem é enviada (push) para um registry, e em qualquer máquina com Docker instalado é possível baixá-la (pull) e rodar um ou mais containers a partir dela.

Dockerfile → (build) → Imagem → (push) → Registry
                                              │
                                          (pull)
                                              │
                                              ▼
                                        Imagem local → (run) → Container

4. Instalando o Docker

O Docker está disponível para Linux, macOS e Windows. Em distribuições Linux, o pacote oficial (não o docker.io genérico de alguns repositórios, que costuma ficar desatualizado) é instalado assim:

# Debian/Ubuntu — script oficial de conveniência
curl -fsSL https://get.docker.com | sh

# Depois, para rodar docker sem sudo (requer novo login/logout):
sudo usermod -aG docker $USER

Em macOS e Windows, a forma mais comum é instalar o Docker Desktop, que empacota o engine, uma VM Linux leve (necessária porque o Docker depende de recursos do kernel Linux) e uma interface gráfica.

Depois de instalado, confirme que está funcionando:

docker --version
docker run hello-world

O segundo comando baixa uma imagem mínima do Docker Hub, roda um container a partir dela (que imprime uma mensagem de confirmação e termina) — é o "hello world" oficial do ecossistema Docker, útil para validar que o engine está rodando e tem permissão para baixar imagens.

5. Um Primeiro Container na Prática

Para sair da teoria, um exemplo real: rodar um servidor web Nginx sem instalar nada além do Docker na máquina.

docker run -d -p 8080:80 --name meu-nginx nginx

Decompondo o comando:

docker run — cria e inicia um container a partir de uma imagem.
-d (detached) — roda o container em segundo plano, devolvendo o terminal imediatamente.
-p 8080:80 — mapeia a porta 8080 da máquina host para a porta 80 dentro do container (onde o Nginx escuta por padrão).
--name meu-nginx — dá um nome fácil de referenciar ao container, em vez de um id gerado automaticamente.
nginx — a imagem a usar. Como não existe localmente ainda, o Docker automaticamente faz pull dela do Docker Hub antes de rodar.

Acessar http://localhost:8080 no navegador já mostra a página padrão do Nginx. Para conferir que o container está rodando e depois removê-lo:

docker ps                    # lista containers em execução
docker stop meu-nginx        # para o container
docker rm meu-nginx          # remove o container (já parado)

Note que docker stop e docker rm são passos separados — parar um container não o remove, apenas encerra o processo dentro dele. Isso é proposital: permite inspecionar o estado final de um container que falhou antes de descartá-lo. Os comandos do dia a dia como esses (run, exec, logs, ps, build) são o assunto completo do próximo artigo.

6. Conclusão e Próximos Passos

Nesta primeira parte, vimos o problema real que o Docker resolve ("funciona na minha máquina"), como containers se diferenciam de máquinas virtuais em leveza e velocidade, os três conceitos que sustentam todo o ecossistema — imagens, containers e registries — e rodamos o primeiro container de ponta a ponta. No próximo artigo, o foco vai para os comandos que realmente viram hábito no dia a dia: run, exec, logs, ps e build, com exemplos de containers reais além do "hello world".

Imagem de capa: Logo oficial do Docker — Wikimedia Commons, fonte: docker.com/company/newsroom/media-resources

Referências:

Tmux Avançado - Exemplos Reais e Configurações para Produtividade

Rafael Dutra — Wed, 05 Aug 2026 09:30:51 +0000

tmuxinator em ação — tmuxinator/tmuxinator, licença MIT

1. Fechando a Série

Nas três primeiras partes desta série, cobrimos o que é o tmux, os comandos de navegação entre sessões/janelas/painéis e a personalização via ~/.tmux.conf e plugins. Este último artigo é sobre uso avançado: como automatizar a criação de layouts complexos, integrar o tmux com fluxos de trabalho remotos, sincronizar comandos entre múltiplos servidores e ajustar detalhes de configuração que fazem diferença no uso intenso do dia a dia.

2. Automatizando Sessões com Scripts

Montar manualmente o mesmo layout (editor, servidor, logs) toda vez que um projeto é retomado é repetitivo. A própria CLI do tmux permite montar uma sessão inteira via script, sem interação manual:

#!/bin/bash
# start-project.sh — monta a sessão de trabalho do projeto "blog"

SESSION="blog"

tmux new-session -d -s "$SESSION" -c ~/projects/blog

# Janela 0: editor
tmux rename-window -t "$SESSION:0" "editor"
tmux send-keys -t "$SESSION:editor" "nvim ." C-m

# Janela 1: servidor + logs, dividida em dois painéis
tmux new-window -t "$SESSION" -n "server" -c ~/projects/blog
tmux send-keys -t "$SESSION:server" "npm run dev" C-m
tmux split-window -t "$SESSION:server" -v -c ~/projects/blog
tmux send-keys -t "$SESSION:server" "tail -f logs/app.log" C-m

# Janela 2: terminal solto, sem comando automático
tmux new-window -t "$SESSION" -n "shell" -c ~/projects/blog

tmux select-window -t "$SESSION:editor"
tmux attach -t "$SESSION"

Rodar ./start-project.sh recria o layout inteiro em segundos. Para projetos com estrutura parecida, ferramentas como o tmuxinator ou o tmuxp fazem o mesmo a partir de um arquivo YAML declarativo, o que fica mais legível quando há muitas janelas e painéis envolvidos:

# .tmuxp.yaml
session_name: blog
start_directory: ~/projects/blog
windows:
  - window_name: editor
    panes:
      - nvim .
  - window_name: server
    layout: even-vertical
    panes:
      - npm run dev
      - tail -f logs/app.log
  - window_name: shell
    panes:
      - ""

tmuxp load .tmuxp.yaml

3. Persistência de Sessões em Servidores Remotos

O caso de uso mais comum em produção é abrir uma sessão nomeada logo após conectar via SSH, sempre reaproveitando a mesma se já existir:

ssh usuario@servidor -t 'tmux new-session -A -s trabalho'

A flag -A faz o tmux anexar à sessão trabalho se ela já existir, ou criá-la se ainda não existir — elimina a necessidade de lembrar se já havia uma sessão aberta antes. Combinado com tmux-resurrect e tmux-continuum (vistos na parte anterior), até uma reinicialização do servidor não é motivo para perder o layout: basta reconectar e rodar prefix + Ctrl+r para restaurar.

4. Sincronizando Painéis Entre Múltiplos Hosts

tmux-resurrect — screencast completo no Vimeo, tmux-plugins/tmux-resurrect, licença MIT

Quando o mesmo comando precisa rodar em vários servidores ao mesmo tempo (por exemplo, checar a versão de um pacote em todos os nós de um cluster), o tmux permite espelhar a digitação em todos os painéis abertos de uma janela:

# Uma janela com um painel por servidor, cada um já conectado via SSH
tmux new-window -n "cluster"
tmux send-keys -t "cluster.0" "ssh node1" C-m
tmux split-window -t "cluster"
tmux send-keys -t "cluster.1" "ssh node2" C-m
tmux split-window -t "cluster"
tmux send-keys -t "cluster.2" "ssh node3" C-m
tmux select-layout -t "cluster" tiled

# Ativa a sincronização: tudo que for digitado vai para todos os painéis
tmux setw synchronize-panes on

Com synchronize-panes on, qualquer comando digitado é replicado em tempo real em todos os painéis da janela — útil para operações repetitivas em múltiplos hosts, mas vale lembrar de desativar (synchronize-panes off) antes de rodar algo destrutivo em apenas um deles por engano.

5. Tmux Dentro de Tmux (Sessões Aninhadas)

Ao conectar via SSH a um servidor remoto que também roda tmux, de dentro de uma sessão tmux local, o prefixo do teclado passa a ser interpretado pela sessão mais externa (a local), não pela remota. A solução mais comum é alternar temporariamente o destino do prefixo com Ctrl+x Ctrl+x (pressionar o prefixo duas vezes envia o segundo diretamente para a sessão interna), ou configurar um prefixo alternativo específico para uso remoto:

# No .tmux.conf da sessão externa (local), o segundo Ctrl+x repassa para a interna
bind-key -n C-x send-prefix

Uma alternativa mais simples no dia a dia é usar Ctrl+b d para desanexar a sessão remota antes de mexer na local, evitando a ambiguidade por completo.

6. Ajustes Finos de Configuração

Alguns parâmetros que fazem diferença perceptível no uso intenso, para adicionar ao ~/.tmux.conf:

# Reduz o delay entre pressionar Esc e o terminal reconhecer (importante para vim/neovim)
set -sg escape-time 0

# Histórico de scroll maior (padrão é só 2000 linhas)
set -g history-limit 50000

# Renumera as janelas automaticamente ao fechar uma no meio
set -g renumber-windows on

# Evita que o tmux renomeie janelas automaticamente com base no comando em execução
set-option -g allow-rename off

# Notificação visual (não sonora) quando outra janela tem atividade
setw -g monitor-activity on
set -g visual-activity on

escape-time 0 em particular resolve um sintoma clássico de quem usa Vim/Neovim dentro do tmux: um pequeno atraso perceptível ao sair do modo de inserção com Esc, causado pelo tmux esperando para diferenciar a tecla Esc isolada de sequências de escape de teclas especiais.

7. Conclusão da Série

Ao longo destes quatro artigos, o tmux saiu de "o que é isso e por que alguém usaria" até scripts de automação de sessão, persistência em servidores remotos e sincronização entre múltiplos hosts. A curva de aprendizado inicial (decorar o prefixo, os atalhos de painel) se paga rápido assim que uma conexão cai no meio de um trabalho importante e tudo continua exatamente de pé ao reconectar. Vale começar pequeno — um .tmux.conf com poucas linhas e um ou dois plugins — e ir incorporando o restante conforme o próprio fluxo de trabalho pedir.

Imagem de capa: Logo do tmux, por Jason Long — Wikimedia Commons

Referências:

Tmux Personalizado - Cores, Status Bar e Plugins Úteis

Rafael Dutra — Tue, 04 Aug 2026 09:30:57 +0000

Catppuccin Frappé — catppuccin/tmux, licença MIT

1. Onde Mora a Configuração do Tmux

Nas duas primeiras partes desta série, vimos os conceitos do tmux e os comandos para navegar entre sessões, janelas e painéis. Tudo isso funciona com os padrões de fábrica — mas o tmux só realmente "gruda" no fluxo de trabalho quando é ajustado ao gosto de quem usa: prefixo mais confortável, atalhos no estilo vi, status bar informativa e plugins que resolvem problemas recorrentes. Em vez de montar um exemplo genérico, este artigo usa como base uma configuração real, em uso diário, com tema Catppuccin e integração com Docker e Git direto na status bar.

Toda essa personalização mora em um único arquivo: ~/.tmux.conf. Ele é lido quando o servidor tmux inicia; para aplicar mudanças em uma sessão já em execução, sem reiniciar tudo, recarrega-se manualmente:

tmux source-file ~/.tmux.conf

Mapear isso para uma combinação de teclas dentro do próprio .tmux.conf evita ter que digitar o comando inteiro toda vez que uma linha é ajustada:

unbind r
bind r source-file ~/.tmux.conf

2. Prefixo, Atalhos e Popups

O prefixo padrão Ctrl+b é uma escolha histórica (evitar conflito com o Ctrl+a do GNU Screen), mas boa parte da comunidade prefere algo mais perto do canto do teclado. Aqui a escolha caiu sobre Ctrl+x:

# Alterar a tecla Leader (Prefix) de Ctrl+b para Ctrl+x
set -g prefix C-x
unbind C-b
bind C-x send-prefix

Divisão de painéis mantendo o diretório atual, navegação estilo vi e redimensionamento com shift+direção:

# Split mantendo o diretório atual
bind '"' split-window -v -c "#{pane_current_path}"
bind '%' split-window -h -c "#{pane_current_path}"

# Navegação entre painéis (estilo vim)
bind h select-pane -L
bind j select-pane -D
bind k select-pane -U
bind l select-pane -R

# Redimensionar painéis com shift+seta
bind -r H resize-pane -L 5
bind -r J resize-pane -D 5
bind -r K resize-pane -U 5
bind -r L resize-pane -R 5

# Copy mode com vi keys
setw -g mode-keys vi
bind -T copy-mode-vi v send -X begin-selection
bind -T copy-mode-vi y send -X copy-selection-and-cancel

O -r nos binds de resize permite repetir o atalho várias vezes seguidas sem apertar o prefixo de novo a cada aperto — útil quando um painel precisa crescer bem mais que 5 colunas/linhas de uma vez.

Um recurso menos comum: display-popup, que abre uma janela flutuante por cima da sessão sem criar um painel novo — ótimo para uma checagem rápida sem bagunçar o layout atual:

bind D display-popup -w 80% -h 80% -E "docker stats"
bind P display-popup -w 80% -h 80% -b rounded -s "fg=black" -S "fg=cyan" -E "zsh"

-E roda o comando e fecha o popup assim que ele termina; P abre um shell solto (zsh) num popup com borda arredondada, útil para rodar algo pontual sem sair da janela atual nem abrir um painel permanente.

3. Cores e Status Bar com Catppuccin

Catppuccin Mocha, outro flavor do mesmo tema — catppuccin/tmux, licença MIT

Escrever cada cor da status bar manualmente (como status-style bg=colour235,fg=colour250) funciona, mas dá trabalho para manter consistente em todos os elementos — painéis, mensagens, janela ativa. O plugin catppuccin/tmux resolve isso fornecendo uma paleta e um conjunto de módulos prontos:

set -g @catppuccin_flavor "frappe"
set -g @catppuccin_window_status_style "rounded"
set -g @catppuccin_window_text "#H"
set -g @catppuccin_window_current_text "#W"
set -g @catppuccin_session_text " #I:#S"

O flavor frappe é uma das quatro variações de paleta do Catppuccin (as outras são latte, macchiato e mocha) — trocar essa única linha muda o esquema de cores inteiro, sem tocar em mais nada. As cores de base do frappe aparecem depois no arquivo, para uso em outros elementos que o módulo do Catppuccin não cobre diretamente:

set -g @ctp_bg "#303446"        # Base
set -g @ctp_surface_1 "#51576d" # Surface1
set -g @ctp_fg "#c6d0f5"        # Text
set -g @ctp_mauve "#ca9ee6"     # Mauve
set -g @ctp_crust "#232634"     # Crust

Um detalhe que vale a pena copiar: detecção de sessão SSH via diretiva condicional do próprio tmux, deixando a status bar visivelmente diferente (laranja) sempre que a sessão está numa máquina remota — um lembrete visual de "cuidado, você não está local":

%if "#{SSH_CLIENT}"
set -g status-style "bg=#fe640b,fg=#ffffff"
set -g message-style "bg=#e64553,fg=#ffffff"
%else
set -g status-style "bg=#e78284,fg=#232634"
set -g message-style "bg=#ea999c,fg=#232634"
%endif

%if/%else/%endif são avaliados quando o tmux lê o arquivo, com base em uma variável de formato — aqui, #{SSH_CLIENT} só é diferente de vazio quando a conexão veio via SSH.

A composição da status bar é feita concatenando pedaços com -a (append), em vez de escrever uma string gigante numa linha só:

set-option -g status-position top
set -g status-left-length 100
set -g status-right-length 100
set -g status-left ""
set -g window-status-format ""
set -g window-status-current-format ""

# Sessão + hostname
set -gF status-left "#[fg=#babbf1]   ##H "
set -ag status-left "#{E:@catppuccin_status_session}"

# Badge de SSH, aparece só quando conectado remotamente
set -ag status-left '#([ -n "$SSH_CLIENT" ] && echo "#[fg=#ffffff bg=#fe640b bold] SSH #[default]") '

# Containers Docker rodando / parados, CPU e memória agregadas
set -ag status-left "#[fg=#a6d189,bold] #(docker ps -q 2>/dev/null | wc -l | tr -d ' ')#[fg=#626880]/#[fg=#e78284]#(docker ps -aq --filter status=exited 2>/dev/null | wc -l | tr -d ' ') "
set -ag status-left "#[fg=#ef9f76] #(docker stats --no-stream --format '{{.CPUPerc}}' 2>/dev/null | sed 's/[^0-9.]//g' | awk '{sum+=$1} END {print int(sum*10)/10}')%% "
set -ag status-left "#[fg=#85c1dc] #(docker stats --no-stream --format '{{.MemUsage}}' 2>/dev/null | awk -F'/' 'NR==1{print $1}' | tr -d ' ') "

# Aplicação atual, uptime e métricas do host (plugins, seção 5)
set -g status-right "#{E:@catppuccin_status_application}"
set -ag status-right "#{E:@catppuccin_status_uptime}"
set -agF status-right "#{E:@catppuccin_status_cpu}"
set -agF status-right "#{E:@catppuccin_status_ram}"
set -agF status-right "#{E:@catppuccin_status_load}"
set -agF status-right "#{E:@catppuccin_status_battery}"

#(comando) roda um shell command e injeta a saída direto na status bar — é assim que os containers Docker ativos e o uso de CPU/memória aparecem atualizados a cada status-interval (60 segundos, por padrão, para não pesar rodando docker stats toda hora):

set -g status-interval 60

Por fim, os painéis também ganham borda colorida e um cabeçalho informativo, mostrando o comando rodando, a branch git do diretório atual (via #(cd #{pane_current_path} && git branch --show-current)) e o horário:

set -g pane-border-lines single
set -g pane-border-status top
set -g pane-active-border-style "fg=#e5c890,bold"
set -g pane-border-style "fg=#006b6b"
set -g pane-border-format " #{?pane_active,#[fg=#a6d189 bold]▶ #[fg=#85c1dc bold],#[fg=#626880]}#{pane_current_command} #[align=right]#[fg=#ca9ee6]#(cd #{pane_current_path} && git branch --show-current 2>/dev/null | sed '/^$/d; s/^/  /; s/$/ /') #[fg=#626880]· #[fg=#00ffff]%H:%M #[fg=#626880]· #[fg=#a6d189]#P "

#{?pane_active,X,Y} é um condicional de formato: mostra X se o painel estiver ativo, Y caso contrário — é assim que só o painel focado ganha a seta ▶ destacada.

4. Tmux Plugin Manager (TPM)

O TPM (Tmux Plugin Manager) é o método padrão da comunidade para instalar e gerenciar plugins, de forma parecida com o vim-plug no Vim:

git clone https://github.com/tmux-plugins/tpm ~/.tmux/plugins/tpm

No ~/.tmux.conf, plugins são declarados com set -g @plugin, e a linha que inicializa o TPM precisa ficar sempre por último no arquivo:

set -g @plugin 'tmux-plugins/tpm'
set -g @plugin 'tmux-plugins/tmux-resurrect'
set -g @plugin 'jimeh/tmuxifier'
set -g @plugin 'tmux-plugins/tmux-battery'
set -g @plugin 'tmux-plugins/tmux-cpu'
set -g @plugin 'tmux-plugins/tmux-prefix-highlight'
set -g @plugin 'tmux-plugins/tmux-online-status'
set -g @plugin 'tmux-plugins/tmux-yank'
set -g @plugin 'tmux-plugins/tmux-continuum'

run -b '~/.tmux/plugins/tpm/tpm'

O Catppuccin, nesta configuração, não está na lista @plugin — foi clonado manualmente e carregado com um run direto, apontando pro caminho do repositório:

git clone https://github.com/catppuccin/tmux.git ~/.config/tmux/plugins/catppuccin/tmux

run ~/.config/tmux/plugins/catppuccin/tmux/catppuccin.tmux

As duas formas funcionam — @plugin 'catppuccin/tmux' via TPM também seria válido — mas o run direto evita que uma atualização do TPM (prefix + U) mexa acidentalmente na versão do tema enquanto ele ainda está sendo ajustado.

Depois de salvar o arquivo e recarregar (prefix + r), os plugins da lista @plugin são instalados de dentro do próprio tmux com prefix + I (maiúsculo). Para atualizar todos: prefix + U. Para remover os que foram tirados da lista: prefix + alt + u.

5. Plugins que Realmente Valem a Pena

tmux-resurrect: salva o estado completo de sessões, janelas e painéis em disco (prefix + Ctrl+s) e restaura tudo depois (prefix + Ctrl+r). Com @resurrect-strategy-vim/@resurrect-strategy-nvim setados como session, ele delega a restauração do buffer do editor para a própria sessão de Vim/Neovim salva, em vez de só reabrir os arquivos:

  set -g @resurrect-capture-pane-contents 'on'
  set -g @resurrect-strategy-nvim 'session'
  set -g @resurrect-strategy-vim 'session'

tmux-continuum: complementa o tmux-resurrect salvando o estado automaticamente a cada alguns minutos, sem precisar lembrar de acionar o atalho manualmente:

  set -g @continuum-restore 'on'
  set -g @continuum-save-interval '15'

tmuxifier: gerencia layouts de sessão pré-definidos por projeto (o equivalente, dentro do ecossistema de plugins do TPM, ao que ferramentas como tmuxinator/tmuxp fazem via script — assunto da próxima parte desta série).
tmux-battery / tmux-cpu: expõem #{battery_percentage} e #{cpu_percentage} como variáveis de formato, usadas pelos módulos @catppuccin_status_battery e @catppuccin_status_cpu na status bar.
tmux-prefix-highlight: mostra um indicador visual assim que o prefixo é pressionado — útil para confirmar que o tmux "ouviu" o Ctrl+x antes de digitar o atalho seguinte, especialmente relevante quando o prefixo foi trocado do padrão.
tmux-online-status: expõe #{online_status}, para exibir se a máquina tem conectividade de rede direto na status bar.
tmux-yank: melhora a integração do copy mode com a área de transferência do sistema operacional (útil especialmente sobre SSH ou em WSL, onde essa integração não funciona por padrão).

6. Exemplo de `.tmux.conf` Completo

Juntando o conteúdo das seções anteriores num arquivo funcional (a configuração real usada no dia a dia, com o tema Catppuccin Frappe):

# ~/.tmux.conf

# Prefixo
set -g prefix C-x
unbind C-b
bind C-x send-prefix

# Reload
unbind r
bind r source-file ~/.tmux.conf

# Popups úteis
bind D display-popup -w 80% -h 80% -E "docker stats"
bind P display-popup -w 80% -h 80% -b rounded -s "fg=black" -S "fg=cyan" -E "zsh"

# Comportamento
set -g mouse on
set-option -g allow-rename off
set-option -g automatic-rename-format '#{b:pane_current_path}'
set -g default-terminal "tmux-256color"
set -g base-index 1
set -g pane-base-index 1
set -g renumber-windows on
set -g history-limit 50000
set -sg escape-time 10
set -g focus-events on
set -g display-time 2000

# Painéis e navegação
bind '"' split-window -v -c "#{pane_current_path}"
bind '%' split-window -h -c "#{pane_current_path}"
bind h select-pane -L
bind j select-pane -D
bind k select-pane -U
bind l select-pane -R
bind -r H resize-pane -L 5
bind -r J resize-pane -D 5
bind -r K resize-pane -U 5
bind -r L resize-pane -R 5
setw -g mode-keys vi
bind -T copy-mode-vi v send -X begin-selection
bind -T copy-mode-vi y send -X copy-selection-and-cancel

# SSH: status bar laranja quando conectado remotamente
%if "#{SSH_CLIENT}"
set -g status-style "bg=#fe640b,fg=#ffffff"
set -g message-style "bg=#e64553,fg=#ffffff"
%else
set -g status-style "bg=#e78284,fg=#232634"
set -g message-style "bg=#ea999c,fg=#232634"
%endif
set-option -g status-position top
set -g status-interval 60

# Catppuccin
set -g @catppuccin_flavor "frappe"
set -g @catppuccin_window_status_style "rounded"
set -g @catppuccin_window_text "#H"
set -g @catppuccin_window_current_text "#W"
set -g @catppuccin_session_text " #I:#S"

# Plugins (TPM)
set -g @plugin 'tmux-plugins/tpm'
set -g @plugin 'tmux-plugins/tmux-resurrect'
set -g @resurrect-capture-pane-contents 'on'
set -g @resurrect-strategy-nvim 'session'
set -g @resurrect-strategy-vim 'session'
set -g @plugin 'jimeh/tmuxifier'
set -g @plugin 'tmux-plugins/tmux-battery'
set -g @plugin 'tmux-plugins/tmux-cpu'
set -g @plugin 'tmux-plugins/tmux-prefix-highlight'
set -g @plugin 'tmux-plugins/tmux-online-status'
set -g @plugin 'tmux-plugins/tmux-yank'
set -g @plugin 'tmux-plugins/tmux-continuum'
set -g @continuum-restore 'on'
set -g @continuum-save-interval '15'

run ~/.config/tmux/plugins/catppuccin/tmux/catppuccin.tmux

# Status bar
set -g status-left-length 100
set -g status-right-length 100
set -g status-left ""
set -g window-status-format ""
set -g window-status-current-format ""
set -gF status-left "#[fg=#babbf1]   ##H "
set -ag status-left "#{E:@catppuccin_status_session}"
set -ag status-left '#([ -n "$SSH_CLIENT" ] && echo "#[fg=#ffffff bg=#fe640b bold] SSH #[default]") '
set -ag status-left "#[fg=#a6d189,bold] #(docker ps -q 2>/dev/null | wc -l | tr -d ' ')#[fg=#626880]/#[fg=#e78284]#(docker ps -aq --filter status=exited 2>/dev/null | wc -l | tr -d ' ') "
set -ag status-left "#[fg=#ef9f76] #(docker stats --no-stream --format '{{.CPUPerc}}' 2>/dev/null | sed 's/[^0-9.]//g' | awk '{sum+=$1} END {print int(sum*10)/10}')%% "
set -ag status-left "#[fg=#85c1dc] #(docker stats --no-stream --format '{{.MemUsage}}' 2>/dev/null | awk -F'/' 'NR==1{print $1}' | tr -d ' ') "
set -g status-right "#{E:@catppuccin_status_application}"
set -ag status-right "#{E:@catppuccin_status_uptime}"
set -agF status-right "#{E:@catppuccin_status_cpu}"
set -agF status-right "#{E:@catppuccin_status_ram}"
set -agF status-right "#{E:@catppuccin_status_load}"
set -agF status-right "#{E:@catppuccin_status_battery}"

# Painéis: borda com comando atual, branch git e horário
setw -g monitor-activity on
set -g visual-activity off
setw -g monitor-silence 0
set -g pane-border-lines single
set -g pane-border-status top
set -g pane-active-border-style "fg=#e5c890,bold"
set -g pane-border-style "fg=#006b6b"
set -g pane-border-format " #{?pane_active,#[fg=#a6d189 bold]▶ #[fg=#85c1dc bold],#[fg=#626880]}#{pane_current_command} #[align=right]#[fg=#ca9ee6]#(cd #{pane_current_path} && git branch --show-current 2>/dev/null | sed '/^$/d; s/^/  /; s/$/ /') #[fg=#626880]· #[fg=#00ffff]%H:%M #[fg=#626880]· #[fg=#a6d189]#P "
set -g window-active-style "bg=default"
set -g window-style "bg=default"

run -b '~/.tmux/plugins/tpm/tpm'

7. Conclusão e Próximos Passos

Com prefixo ajustado, tema Catppuccin aplicado e a status bar mostrando o que realmente importa no dia a dia — containers Docker, uso de CPU/memória, branch git do painel ativo, indicador de SSH — o tmux deixa de ser apenas funcional e passa a se adaptar ao fluxo de quem usa. No último artigo desta série, o assunto são exemplos reais de uso avançado: scripts de sessão automatizados, layouts fixos para desenvolvimento, sincronização de painéis entre múltiplos servidores e ajustes finos de performance.

Imagem de capa: Logo do tmux, por Jason Long — Wikimedia Commons

Referências:

Tmux na Prática - Navegação, Painéis e Organização de Layout

Rafael Dutra — Mon, 03 Aug 2026 09:30:40 +0000

Maximizando um painel — gpakosz/.tmux, licença MIT (repassado via wsrv.nl -- cloud.githubusercontent.com direto é instável no proxy do Dev.to)

1. Retomando: Sessões, Janelas e Painéis

Na primeira parte desta série vimos o que é o tmux, o modelo cliente-servidor por trás dele e os comandos básicos para criar, desanexar e reconectar a uma sessão. Agora que a sessão já existe e está rodando, o foco deste artigo é o que acontece dentro dela: como navegar entre janelas, dividir a tela em painéis, reorganizar esse layout e mover conteúdo entre eles — o conjunto de comandos que efetivamente vira hábito no dia a dia.

Todos os atalhos abaixo partem do prefixo padrão Ctrl+b: pressiona-se e solta-se essa combinação, depois a tecla do comando.

2. Trabalhando com Janelas

Cada sessão pode ter várias janelas, numeradas a partir de 0. Os comandos mais usados:

Ação	Atalho
Criar nova janela	`Ctrl+b` `c`
Ir para a próxima janela	`Ctrl+b` `n`
Ir para a janela anterior	`Ctrl+b` `p`
Ir direto para a janela N	`Ctrl+b` `N`
Listar janelas e escolher interativamente	`Ctrl+b` `w`
Renomear a janela atual	`Ctrl+b` `,`
Fechar a janela atual	`Ctrl+b` `&`

Nomear janelas (Ctrl+b ,) compensa rápido: em vez de lembrar que "janela 2" é o servidor de desenvolvimento, a barra de status já mostra o nome que você escolheu, tipo dev, logs ou db.

3. Dividindo a Tela em Painéis

Painéis (panes) dividem uma janela em múltiplas áreas visíveis simultaneamente, cada uma com seu próprio shell:

Ação	Atalho
Dividir painel na horizontal (um em cima do outro)	`Ctrl+b` `"`
Dividir painel na vertical (lado a lado)	`Ctrl+b` `%`
Mover para o próximo painel	`Ctrl+b` `o`
Mover para o painel em uma direção	`Ctrl+b` + seta
Fechar o painel atual	`Ctrl+b` `x`
Mostrar números dos painéis (para pular direto)	`Ctrl+b` `q`

Um layout comum de desenvolvimento — editor à esquerda, servidor e logs à direita, um em cima do outro — é montado assim, partindo de uma janela única:

Ctrl+b %      # divide na vertical: editor | direita
Ctrl+b o      # move para o painel da direita
Ctrl+b "      # divide esse painel na horizontal: servidor / logs

Resultando em:

+------------------+------------------+
|                  |     servidor      |
|                  +------------------+
|      editor      |       logs       |
|                  |                  |
+------------------+------------------+

4. Redimensionando e Reorganizando o Layout

Oh My Tmux! em ação — gpakosz/.tmux, licença MIT (repassado via wsrv.nl -- cloud.githubusercontent.com direto falhava no proxy do Dev.to)

Depois de dividir os painéis, redimensioná-los é feito segurando o prefixo e usando as setas repetidamente, ou de forma mais previsível com resize-pane:

# dentro do tmux, dá pra digitar comandos completos após Ctrl+b :
Ctrl+b :resize-pane -D 10   # move a borda 10 linhas para baixo
Ctrl+b :resize-pane -U 10   # 10 linhas para cima
Ctrl+b :resize-pane -L 10   # 10 colunas para a esquerda
Ctrl+b :resize-pane -R 10   # 10 colunas para a direita

O tmux também vem com layouts pré-definidos que reorganizam todos os painéis de uma janela de uma vez, alternados com Ctrl+b Espaço, ou escolhidos diretamente:

Ctrl+b :select-layout even-horizontal
Ctrl+b :select-layout even-vertical
Ctrl+b :select-layout main-vertical    # um painel grande + coluna com o resto
Ctrl+b :select-layout tiled            # distribui igualmente em grade

main-vertical é particularmente útil para o layout de desenvolvimento citado acima: o editor ocupa a área grande à esquerda, e os demais painéis (servidor, logs, terminal solto) se acomodam em uma coluna à direita.

5. Modo de Cópia: Rolar, Selecionar e Copiar Texto

Diferente de um terminal comum, dentro do tmux o scroll do mouse (ou das setas) não funciona por padrão sem entrar em um modo específico, o copy mode:

Ctrl+b [        # entra no modo de cópia
setas ou PgUp/PgDn   # navega pelo histórico
Espaço          # inicia seleção (com emulação vi habilitada)
Enter           # copia a seleção e sai do modo
Ctrl+b ]        # cola o que foi copiado
q               # sai do modo de cópia sem copiar nada

Para usar as teclas de movimentação no estilo vi (h, j, k, l, v para selecionar, y para copiar) dentro do copy mode, é preciso habilitar isso na configuração — assunto do próximo artigo desta série, que trata de personalização.

6. Comandos Úteis do Dia a Dia (Resumo)

Categoria	Atalho	Ação
Sessão	`Ctrl+b d`	Desanexar
Sessão	`Ctrl+b s`	Listar/trocar de sessão
Janela	`Ctrl+b c`	Nova janela
Janela	`Ctrl+b n` / `p`	Próxima / anterior
Painel	`Ctrl+b %`	Dividir vertical
Painel	`Ctrl+b "`	Dividir horizontal
Painel	`Ctrl+b o`	Alternar painel
Painel	`Ctrl+b x`	Fechar painel
Cópia	`Ctrl+b [`	Entrar em copy mode

Vale imprimir (ou fixar em algum lugar visível) essa tabela nas primeiras semanas de uso — depois de algumas sessões, os atalhos mais usados viram automáticos.

7. Conclusão e Próximos Passos

Com sessões, janelas e painéis sob controle, o tmux já substitui boa parte da necessidade de múltiplas janelas do emulador de terminal. No próximo artigo, o foco muda para deixar tudo isso com a cara que você quiser: personalização de cores, status bar e os plugins mais úteis para o dia a dia, incluindo o gerenciador de plugins do tmux (TPM).

Imagem de capa: Logo do tmux, por Jason Long — Wikimedia Commons

Referências:

Tmux - O Que É, Para Que Serve e Primeiros Passos

Rafael Dutra — Sun, 02 Aug 2026 09:30:43 +0000

1. O Problema que o Tmux Resolve

Quem trabalha com terminal no dia a dia esbarra cedo ou tarde no mesmo incômodo: uma conexão SSH cai e todo o trabalho em andamento — um build rodando, um editor aberto, logs sendo acompanhados — vai junto com ela. Ou então é preciso alternar constantemente entre vários comandos de longa duração (um servidor de desenvolvimento, um watcher de testes, um tail -f de log) e cada um exige sua própria janela de terminal, ocupando espaço e exigindo troca manual entre elas.

O tmux (Terminal Multiplexer) resolve exatamente isso: ele permite criar, organizar e — o mais importante — manter vivas múltiplas sessões de terminal, independentemente da conexão que as originou. Esta é a primeira parte de uma série que vai do básico ao avançado: hoje o foco é entender o que é o tmux, por que ele existe e como dar os primeiros passos.

2. O Que é um Terminal Multiplexer

Um multiplexador de terminal é um programa que roda como um processo único no servidor (ou máquina local) e, dentro dele, gerencia múltiplos "terminais virtuais" simultaneamente. A parte crucial é que esse processo continua rodando mesmo que o cliente que está olhando para ele feche a conexão. Isso é possível porque o tmux funciona em modelo cliente-servidor:

O servidor tmux roda em segundo plano, mantendo todas as sessões, janelas e painéis vivos, com todo o estado (histórico de scroll, processos em execução, variáveis de ambiente) preservado.
Um ou mais clientes tmux apenas se conectam a esse servidor para visualizar e interagir com as sessões — como uma "tela" que pode ser ligada e desligada sem afetar o que está sendo exibido.

Isso quer dizer que é possível abrir uma sessão, desconectar (detach), desligar o notebook, ir para outro lugar, abrir outro computador, reconectar (attach) na mesma sessão e encontrar tudo exatamente como estava — inclusive processos que continuaram rodando o tempo todo.

3. Conceitos Fundamentais: Sessões, Janelas e Painéis

O tmux organiza tudo em três níveis, do mais amplo para o mais específico:

Sessão (session): um agrupamento independente de trabalho, geralmente associado a um projeto ou contexto (ex.: uma sessão deploy, outra blog). Cada sessão sobrevive independentemente das demais.
Janela (window): dentro de uma sessão, equivalente a uma aba de terminal. Uma sessão pode ter várias janelas, cada uma ocupando a tela inteira quando ativa.
Painel (pane): uma janela pode ser dividida em múltiplos painéis lado a lado ou empilhados, cada um rodando seu próprio shell ou comando, visíveis ao mesmo tempo na tela.

Sessão "blog"
├── Janela 0: editor
│   ├── Painel 0: vim
│   └── Painel 1: git status
└── Janela 1: servidor
    └── Painel 0: npm run dev

Essa hierarquia é o que permite organizar um fluxo de trabalho complexo sem depender de várias janelas separadas do emulador de terminal.

4. Instalando o Tmux

O tmux está disponível nos repositórios padrão da maioria das distribuições e gerenciadores de pacote:

# Debian/Ubuntu
sudo apt update && sudo apt install tmux

# Fedora
sudo dnf install tmux

# Arch Linux
sudo pacman -S tmux

# macOS (Homebrew)
brew install tmux

Depois de instalado, confirme a versão:

tmux -V

Versões mais recentes (3.x) trazem suporte a mais recursos de layout e integração com o mouse, usados nas próximas partes desta série — vale atualizar se a versão empacotada pela distribuição for muito antiga (2.x).

5. Primeiros Comandos: Criar, Sair, Desanexar e Reconectar

O comando mais simples possível é iniciar uma sessão sem nome:

tmux

Isso abre uma nova sessão e já entra nela. Mas o ideal, desde o início, é nomear as sessões — facilita muito reconectar depois:

tmux new -s blog

Dentro do tmux, praticamente todo comando é acionado por uma combinação de teclas chamada de prefixo, cujo padrão é Ctrl+b. Ou seja: solta-se Ctrl+b, depois pressiona-se a tecla do comando. Os primeiros comandos essenciais:

Ação	Atalho
Desanexar da sessão (detach)	`Ctrl+b` `d`
Listar sessões	`Ctrl+b` `s`
Sair do painel/shell atual	`exit` ou `Ctrl+d`

Fora do tmux, para ver e gerenciar sessões existentes:

# Listar todas as sessões ativas
tmux ls

# Reconectar à sessão "blog"
tmux attach -t blog

# Encerrar uma sessão sem entrar nela
tmux kill-session -t blog

O fluxo típico de uso, então, é: tmux new -s blog para começar, trabalhar normalmente, Ctrl+b d para desanexar quando for preciso sair, e tmux attach -t blog para voltar exatamente de onde parou — de qualquer terminal, em qualquer máquina que tenha acesso à mesma sessão.

6. Por Que Isso Importa no Dia a Dia

Sessão de tmux — Wikimedia Commons

O caso de uso mais citado é o de servidores remotos via SSH: iniciar uma sessão tmux logo após conectar, rodar tudo dentro dela, e se a conexão cair (rede instável, notebook fechado, VPN caindo), o trabalho continua intacto no servidor — basta reconectar e dar tmux attach. Processos de longa duração (deploys, migrações de banco, treinamentos de modelos) não são interrompidos por uma queda de conexão.

Mas o benefício vai além do SSH: mesmo localmente, o tmux permite manter um layout de painéis organizado (editor, logs, testes rodando) sem depender de múltiplas janelas do emulador de terminal, e alternar entre diferentes contextos de projeto trocando de sessão com um comando.

7. Conclusão e Próximos Passos

Nesta primeira parte, vimos o problema que o tmux resolve, o modelo cliente-servidor por trás dele, os três níveis de organização (sessões, janelas, painéis) e os comandos mínimos para criar, desanexar e reconectar a uma sessão. No próximo artigo, entramos na prática do dia a dia: navegação entre janelas e painéis, divisão e reorganização de layout, e os atalhos que realmente valem a pena decorar.

Imagem de capa: Logo do tmux, por Jason Long — Wikimedia Commons

Referências:

Terraform e YAML - Implementação Prática em Projetos de CI/CD

Rafael Dutra — Sun, 26 Jul 2026 09:31:01 +0000

1. Introdução: Conectando IaC e Automação

Nos artigos anteriores desta série, exploramos a poderosa combinação de Terraform e YAML para gerenciar configurações de infraestrutura em múltiplos ambientes, desde os conceitos básicos até padrões avançados de deep merge e modularização. No entanto, a verdadeira força da Infraestrutura como Código (IaC) se manifesta quando integrada a um pipeline de Integração Contínua e Entrega Contínua (CI/CD). É no CI/CD que a promessa de provisionamento automatizado, consistente e seguro da infraestrutura se torna realidade.

Este artigo se aprofundará na implementação prática desses conceitos em um projeto real de CI/CD. Abordaremos a estrutura ideal do repositório, as etapas essenciais de um pipeline, estratégias de branching, considerações de segurança e as melhores práticas para garantir que sua infraestrutura seja implantada de forma eficiente e confiável.

2. Estrutura do Repositório para CI/CD Eficaz

Uma estrutura de repositório bem definida é crucial para a organização e automação em um ambiente de CI/CD. Ela deve refletir a separação entre código Terraform e dados YAML, além de acomodar múltiplos ambientes e serviços.

. (root do repositório)
├── README.md
├── .github/workflows/ # Ou .gitlab-ci/, .azure-pipelines/, etc.
│   └── terraform.yml
├── terraform/ # Código Terraform genérico e módulos
│   ├── main.tf
│   ├── variables.tf
│   ├── outputs.tf
│   └── modules/
│       ├── vpc/
│       │   ├── main.tf
│       │   └── variables.tf
│       └── webserver/
│           ├── main.tf
│           └── variables.tf
└── config/ # Dados de configuração YAML por ambiente/serviço
    ├── global.yaml
    ├── environments/
    │   ├── dev/
    │   │   ├── base.yaml
    │   │   └── services/
    │   │       ├── webapp.yaml
    │   │       └── database.yaml
    │   ├── staging/
    │   │   ├── base.yaml
    │   │   └── services/
    │   │       ├── webapp.yaml
    │   │       └── database.yaml
    │   └── prod/
    │       ├── base.yaml
    │       └── services/
    │           ├── webapp.yaml
    │           └── database.yaml
    └── services/
        ├── defaults/
        │   ├── webapp.yaml
        │   └── database.yaml
        └── overrides/
            ├── webapp-prod.yaml
            └── database-dev.yaml

Explicação da Estrutura:

terraform/: Contém todo o código HCL (HashiCorp Configuration Language) que define a infraestrutura. Este código deve ser o mais genérico possível, utilizando variáveis para aceitar as configurações dos arquivos YAML. Os módulos (modules/) encapsulam recursos reutilizáveis.
config/: Armazena todos os arquivos YAML que contêm os dados de configuração específicos. A organização hierárquica (global, environments, services) permite uma gestão granular e a aplicação de deep merge, conforme discutido no Artigo 3.
.github/workflows/: Contém as definições do pipeline de CI/CD (neste exemplo, usando GitHub Actions). O arquivo terraform.yml orquestrará as etapas de validação, planejamento e aplicação do Terraform.

3. O Pipeline de CI/CD: Etapas Essenciais

Um pipeline de CI/CD robusto para Terraform deve incluir etapas que garantam a qualidade, segurança e consistência das implantações. Vamos detalhar as etapas cruciais, usando GitHub Actions como exemplo, mas os princípios se aplicam a qualquer plataforma de CI/CD.

3.1. Definição do Pipeline (`.github/workflows/terraform.yml`)

name: Terraform Infrastructure Deployment

on:
  push:
    branches:
      - main
      - develop
      - feature/*
  pull_request:
    branches:
      - main
      - develop

env:
  TF_VAR_aws_region: us-east-1 # Variável de ambiente padrão para a região AWS

jobs:
  terraform:
    runs-on: ubuntu-latest
    environment: # Define ambientes para proteção e segredos
      name: ${{ github.ref == 'refs/heads/main' && 'production' || (github.ref == 'refs/heads/develop' && 'staging' || 'development') }}
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ env.TF_VAR_aws_region }}

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v3
        with:
          terraform_version: 1.x.x

      - name: Determine Environment
        id: set_env
        run: |
          if [[ "${{ github.ref }}" == "refs/heads/main" ]]; then
            echo "ENVIRONMENT=prod" >> "$GITHUB_OUTPUT"
          elif [[ "${{ github.ref }}" == "refs/heads/develop" ]]; then
            echo "ENVIRONMENT=staging" >> "$GITHUB_OUTPUT"
          else
            echo "ENVIRONMENT=dev" >> "$GITHUB_OUTPUT"
          fi

      - name: Terraform Init
        id: init
        run: terraform init -backend-config="bucket=${{ secrets.TF_STATE_BUCKET }}" -backend-config="key=${{ steps.set_env.outputs.ENVIRONMENT }}/terraform.tfstate" -backend-config="region=${{ env.TF_VAR_aws_region }}"

      - name: Terraform Validate
        id: validate
        run: terraform validate

      - name: Terraform Plan
        id: plan
        run: terraform plan -var="environment=${{ steps.set_env.outputs.ENVIRONMENT }}" -out=tfplan
        continue-on-error: true # Permite que o pipeline continue para exibir o plano mesmo com erros

      - name: Show Terraform Plan
        run: terraform show -no-color tfplan

      - name: Terraform Apply (Auto-approve for main branch)
        if: success() && github.ref == 'refs/heads/main'
        run: terraform apply -auto-approve tfplan

      - name: Terraform Apply (Manual approval for develop/feature branches)
        if: success() && github.ref != 'refs/heads/main'
        run: |
          echo "Para aplicar as mudanças no ambiente ${{ steps.set_env.outputs.ENVIRONMENT }}, execute manualmente:"
          echo "terraform apply tfplan"
          # Em um pipeline real, você usaria um passo de aprovação manual ou um ambiente de revisão aqui

      - name: Post-deployment Tests (Optional)
        if: success()
        run: |
          echo "Executando testes pós-implantação..."
          # Ex: InSpec, Terratest, ou scripts de validação de API

3.2. Detalhamento das Etapas do Pipeline

Checkout code: Clona o repositório para o ambiente do executor do pipeline.
Configure AWS Credentials: Configura as credenciais para o provedor de nuvem (AWS neste caso) usando segredos do CI/CD. É crucial que essas credenciais tenham as permissões mínimas necessárias para o ambiente alvo. [1]
Setup Terraform: Instala a versão específica do Terraform CLI no executor.
Determine Environment: Esta etapa é fundamental. Ela define qual ambiente (dev, staging, prod) será alvo da implantação com base na branch atual. Por exemplo, main para produção, develop para staging e branches de feature/* para desenvolvimento. O output ENVIRONMENT será usado nas etapas subsequentes.
Terraform Init: Inicializa o diretório de trabalho do Terraform. Aqui, configuramos o backend remoto (ex: S3) para armazenar o estado do Terraform. O key do backend é dinamicamente definido para isolar os estados por ambiente (${{ steps.set_env.outputs.ENVIRONMENT }}/terraform.tfstate). Isso garante que cada ambiente tenha seu próprio arquivo de estado, evitando conflitos. [2]
Terraform Validate: Verifica a sintaxe dos arquivos de configuração e a validade dos argumentos. É uma verificação rápida e essencial para pegar erros básicos antes de prosseguir.
Terraform Plan: Gera um plano de execução, mostrando quais recursos serão adicionados, modificados ou destruídos. O -var="environment=..." garante que o plano seja gerado com base nas configurações YAML do ambiente correto. O -out=tfplan salva o plano para ser usado na etapa de apply. É uma boa prática que esta etapa seja sempre executada, mesmo que o apply exija aprovação manual. [3]
Show Terraform Plan: Exibe o conteúdo do plano gerado. Isso é útil para revisões de código e para que os desenvolvedores e operadores possam entender as mudanças propostas antes da aplicação.
Terraform Apply (Auto-approve for main branch): Aplica o plano gerado. Para a branch main (produção), pode-se configurar para ser auto-approve após a revisão do plano, ou, mais comumente, exigir uma aprovação manual para maior segurança. A condição if: success() && github.ref == 'refs/heads/main' garante que o apply automático só ocorra na branch principal e apenas se as etapas anteriores foram bem-sucedidas.
Terraform Apply (Manual approval for develop/feature branches): Para branches de desenvolvimento ou staging, o apply pode ser manual ou condicionado a um processo de revisão. Em ambientes de CI/CD mais avançados, esta etapa pode ser substituída por um ambiente de revisão efêmero ou um passo de aprovação manual explícito.
Post-deployment Tests (Optional): Após a implantação, é crucial executar testes automatizados para validar a funcionalidade da infraestrutura. Ferramentas como InSpec, Terratest ou scripts personalizados podem verificar se os recursos foram provisionados corretamente e estão operacionais. [4]

4. Estratégias de Branching e Fluxo de Trabalho

A escolha da estratégia de branching impacta diretamente como o CI/CD interage com seus ambientes. As mais comuns são:

GitFlow: Utiliza branches main (produção), develop (staging) e feature/* (desenvolvimento). Cada merge para develop aciona a implantação em staging, e merges para main acionam a implantação em produção. Exige um gerenciamento de branches mais rigoroso.
Trunk-Based Development: Foca em uma única branch principal (main) com commits frequentes e pequenos. Ambientes são diferenciados por tags ou variáveis. Mais ágil, mas exige alta confiança nos testes automatizados.

Para a abordagem de Terraform com YAML, o GitFlow (ou uma variação dele) é frequentemente preferido, pois mapeia naturalmente as branches aos ambientes, simplificando a lógica de seleção de ambiente no pipeline.

5. Considerações de Segurança no Pipeline de CI/CD

A segurança é primordial ao automatizar a implantação de infraestrutura.

Princípio do Menor Privilégio: As credenciais de nuvem usadas pelo pipeline devem ter apenas as permissões mínimas necessárias para provisionar e gerenciar os recursos do ambiente alvo. Nunca use credenciais de administrador.
Segredos do CI/CD: Armazene todas as informações sensíveis (chaves de API, segredos de nuvem, tokens) como segredos no seu sistema de CI/CD (ex: GitHub Secrets, GitLab CI/CD Variables, Azure Key Vault). Nunca as coloque diretamente nos arquivos do repositório.
State Locking e Backend Remoto: Utilize um backend remoto (ex: AWS S3 com DynamoDB, Azure Storage Account, HashiCorp Consul) para armazenar o estado do Terraform. Configure o state locking para evitar que múltiplas execuções do Terraform corrompam o estado simultaneamente. [5]
Revisão de Código e Planos: Implemente revisões de código (Pull Requests/Merge Requests) para todas as mudanças no código Terraform e nos arquivos YAML. Exija que o plano do Terraform seja revisado antes de ser aplicado, especialmente em ambientes de produção.
Ferramentas de Análise Estática: Integre ferramentas como terraform validate, tflint, checkov ou terrascan ao seu pipeline para identificar problemas de sintaxe, segurança e conformidade antes da implantação. [6]

6. Boas Práticas e Dicas Adicionais

Idempotência: Garanta que suas configurações Terraform sejam idempotentes, ou seja, que a aplicação repetida do mesmo plano resulte no mesmo estado da infraestrutura, sem efeitos colaterais indesejados.
Rollback: Tenha uma estratégia clara de rollback. Em caso de falha na implantação, como você reverte para um estado anterior estável? O Terraform Cloud e outras ferramentas oferecem funcionalidades de rollback, mas é importante entender como elas funcionam com seu pipeline.
Monitoramento e Alerta: Configure monitoramento e alertas para a infraestrutura provisionada. Isso ajuda a identificar problemas rapidamente após uma implantação.
Documentação: Mantenha a documentação atualizada sobre a estrutura do repositório, o funcionamento do pipeline e as convenções de configuração YAML.
Testes de Infraestrutura: Além dos testes pós-implantação, considere testes de unidade e integração para seus módulos Terraform usando ferramentas como Terratest. [4]

7. Conclusão

A integração de Terraform com arquivos YAML em um pipeline de CI/CD é uma prática fundamental para qualquer equipe que busca excelência em DevOps. Ao estruturar seu repositório de forma inteligente, definir um pipeline robusto com etapas claras, adotar estratégias de branching adequadas e priorizar a segurança, você pode automatizar o provisionamento de infraestrutura de forma consistente, escalável e confiável. Esta abordagem não apenas acelera o ciclo de entrega, mas também eleva a qualidade e a resiliência de seus ambientes, permitindo que as equipes se concentrem na inovação em vez de tarefas manuais repetitivas.

Imagem de capa: Logo oficial do Terraform — Wikimedia Commons

Referências:

Terraform e YAML - Padrões Avançados e Escalabilidade

Rafael Dutra — Sat, 25 Jul 2026 09:30:09 +0000

1. Introdução: Rumo à Infraestrutura como Código de Nível Empresarial

Nos artigos anteriores desta série, estabelecemos os fundamentos da separação de código e dados no Terraform com YAML (Artigo 1) e exploramos técnicas intermediárias de modularização e provisionamento dinâmico (Artigo 2). Agora, no terceiro e último artigo, mergulharemos em padrões avançados que são essenciais para gerenciar infraestruturas complexas e escaláveis em ambientes corporativos. O foco será em como lidar com hierarquias de configuração intrincadas, mesclar dados de forma inteligente e integrar essa abordagem em fluxos de trabalho de CI/CD.

À medida que a infraestrutura cresce, a necessidade de abstração e automação se torna ainda mais crítica. Este artigo abordará:

Deep Merge de Configurações: Como combinar dados de múltiplos arquivos YAML de forma hierárquica, onde configurações mais específicas sobrescrevem as mais genéricas.
Gerenciamento de Múltiplos Arquivos YAML: Estratégias para organizar e carregar configurações de diferentes escopos (global, ambiente, serviço, região).
Integração com CI/CD: Como automatizar o processo de implantação de infraestrutura usando essa abordagem em pipelines de integração contínua e entrega contínua.

2. Deep Merge de Configurações: Mesclando Dados Hierarquicamente

Um dos maiores desafios ao gerenciar configurações em múltiplos níveis (global, ambiente, serviço) é a necessidade de mesclar mapas de formaprofunda, onde valores de níveis mais baixos (mais específicos) sobrescrevem ou complementam valores de níveis mais altos (mais genéricos ou padrões). A função merge nativa do Terraform realiza uma mesclagem superficial, o que significa que ela apenas mescla o primeiro nível de chaves, e se uma chave existir em ambos os mapas, o valor do segundo mapa prevalece. Para mapas aninhados, isso não é suficiente. [1]

2.1. O Desafio do `merge` Superficial

Considere a seguinte estrutura de configuração:

config/global.yaml:

webserver:
  instance_type: t2.micro
  min_size: 1
  max_size: 5
  tags:
    Project: MyWebApp
    ManagedBy: Terraform
database:
  engine: postgres
  version: "13"
  storage: 50

config/environments/prod.yaml:

webserver:
  instance_type: m5.large
  max_size: 10
  tags:
    Environment: Production

Se aplicarmos um merge superficial diretamente:

locals {
  global_config = yamldecode(file("${path.module}/config/global.yaml"))
  prod_config   = yamldecode(file("${path.module}/config/environments/prod.yaml"))

  # Mesclagem superficial
  merged_config_shallow = merge(local.global_config, local.prod_config)
}

output "shallow_merged_webserver_tags" {
  # Isso resultaria apenas em { Environment = "Production" }, perdendo Project e ManagedBy
  value = local.merged_config_shallow.webserver.tags
}

O resultado de merged_config_shallow.webserver.tags seria apenas { Environment = "Production" }, pois o mapa tags do prod_config sobrescreveria completamente o mapa tags do global_config. Os valores Project e ManagedBy seriam perdidos. Isso não é o comportamento desejado para umdeep merge.

2.2. Implementando um Deep Merge

Para realizar um deep merge, precisamos de uma lógica que itere recursivamente sobre os mapas aninhados, aplicando a mesclagem em cada nível. O Terraform não possui uma função deep_merge nativa, mas a comunidade desenvolveu módulos que abstraem essa complexidade ou podemos construir uma lógica manual para casos específicos. [2]

Uma abordagem comum é usar um módulo auxiliar ou construir a lógica de mesclagem manualmente para cada nível aninhado que precisa de um deep merge. Por exemplo, para as tags do webserver:

locals {
  global_config = yamldecode(file("${path.module}/config/global.yaml"))
  env_config    = yamldecode(file("${path.module}/config/environments/${var.environment}.yaml"))

  # Mesclagem profunda para as tags do webserver
  merged_webserver_tags = merge(
    lookup(local.global_config.webserver, "tags", {}),
    lookup(local.env_config.webserver, "tags", {})
  )

  # Mesclagem profunda para o bloco webserver
  merged_webserver_config = merge(
    local.global_config.webserver,
    lookup(local.env_config, "webserver", {}),
    {
      tags = local.merged_webserver_tags
    }
  )

  # Configuração final, aplicando deep merge onde necessário
  final_config = merge(
    local.global_config,
    local.env_config,
    {
      webserver = local.merged_webserver_config
    }
  )
}

output "deep_merged_webserver_tags" {
  value = local.final_config.webserver.tags
  # Resultado esperado: { Project = "MyWebApp", ManagedBy = "Terraform", Environment = "Production" }
}

output "deep_merged_webserver_instance_type" {
  value = local.final_config.webserver.instance_type
  # Resultado esperado para prod: m5.large
}

output "deep_merged_database_storage" {
  value = local.final_config.database.storage
  # Resultado esperado para prod: 50 (não sobrescrito no prod.yaml)
}

Neste exemplo, usamos lookup para garantir que, se um bloco como webserver ou tags não existir no env_config, um mapa vazio seja usado para evitar erros. Em seguida, aplicamos merge sequencialmente para construir a configuração final, garantindo que as tags sejam mescladas profundamente.

Para um deep merge mais genérico e reutilizável, especialmente em estruturas de dados muito aninhadas, é altamente recomendável utilizar módulos da comunidade. O módulo cloudposse/config/yaml [3] é um exemplo popular que oferece funcionalidades de deep merge para arquivos YAML, simplificando significativamente a lógica no seu main.tf.

3. Gerenciamento de Múltiplos Arquivos YAML para Hierarquias Complexas

Em projetos grandes, ter um único arquivo YAML por ambiente pode se tornar impraticável. É comum dividir as configurações em múltiplos arquivos, organizados por escopo (global, ambiente, serviço, região, etc.). Isso melhora a organização, a legibilidade e a colaboração.

3.1. Estrutura de Diretórios Hierárquica

Considere a seguinte estrutura de diretórios para gerenciar configurações de forma mais granular:

. (root)
├── main.tf
├── config/
│   ├── global.yaml
│   ├── environments/
│   │   ├── dev/
│   │   │   ├── base.yaml
│   │   │   └── services/
│   │   │       ├── webapp.yaml
│   │   │       └── database.yaml
│   │   └── prod/
│   │       ├── base.yaml
│   │       └── services/
│   │           ├── webapp.yaml
│   │           └── database.yaml
│   └── services/
│       ├── defaults/
│       │   ├── webapp.yaml
│       │   └── database.yaml
│       └── overrides/
│           ├── webapp-prod.yaml
│           └── database-dev.yaml

Nesta estrutura, podemos ter:

global.yaml: Configurações que se aplicam a todos os ambientes e serviços.
environments/<env>/base.yaml: Configurações base para um ambiente específico, que podem sobrescrever o global.yaml.
environments/<env>/services/*.yaml: Configurações específicas de serviço dentro de um ambiente, que sobrescrevem as configurações base do ambiente e as globais.
services/defaults/*.yaml: Padrões para serviços que podem ser usados como base.
services/overrides/*.yaml: Sobrescritas pontuais para serviços em ambientes específicos, com a maior precedência.

3.2. Carregando e Mesclando Múltiplos Arquivos YAML

Para carregar e mesclar esses múltiplos arquivos de forma hierárquica, você precisará de uma lógica mais elaborada no seu main.tf (ou em um locals.tf dedicado). Isso geralmente envolve:

Identificar todos os arquivos YAML relevantes para o ambiente atual.
Ler o conteúdo de cada arquivo usando file() e yamldecode().
Aplicar uma sequência de merge (ou um deep merge mais sofisticado) para combinar os mapas, respeitando a precedência (do mais genérico para o mais específico).

Um exemplo simplificado de como você poderia carregar e mesclar arquivos para um ambiente específico:

variable "environment" {
  description = "O ambiente alvo."
  type        = string
  default     = "dev"
}

locals {
  # 1. Carrega a configuração global
  global_config = yamldecode(file("${path.module}/config/global.yaml"))

  # 2. Carrega a configuração base do ambiente
  env_base_path   = "${path.module}/config/environments/${var.environment}/base.yaml"
  env_base_config = fileexists(local.env_base_path) ? yamldecode(file(local.env_base_path)) : {}

  # 3. Carrega configurações de serviço específicas do ambiente
  env_service_configs = {
    for f in fileset("${path.module}/config/environments/${var.environment}/services", "*.yaml") :
    basename(f, ".yaml") => yamldecode(file("${path.module}/config/environments/${var.environment}/services/${f}"))
  }

  # Mesclagem inicial: global + base do ambiente
  merged_base_config = merge(local.global_config, local.env_base_config)

  # Mesclagem final: base mesclada + configurações de serviço (deep merge seria necessário aqui)
  # Esta é uma mesclagem superficial para fins de demonstração.
  # Para um deep merge completo de todos os serviços, a lógica seria mais complexa.
  final_env_config = merge(local.merged_base_config, local.env_service_configs)
}

output "final_config_example" {
  value = local.final_env_config
}

Neste exemplo, fileset é usado para encontrar todos os arquivos YAML dentro do diretório de serviços do ambiente, e um for expression os carrega em um mapa. A mesclagem final ainda precisaria de uma lógica de deep merge para lidar com mapas aninhados dentro das configurações de serviço. Módulos como o cloudposse/config/yaml são projetados para lidar com essa complexidade de forma mais elegante e robusta, permitindo que você especifique uma ordem de precedência para os arquivos YAML e ele se encarregue do deep merge. [3]

4. Integração com CI/CD: Automatizando Implantações Multi-Ambiente

A verdadeira força da separação de código e dados com YAML se manifesta quando integrada a um pipeline de Integração Contínua/Entrega Contínua (CI/CD). Isso permite automatizar o provisionamento e a atualização da infraestrutura para diferentes ambientes de forma segura e consistente.

4.1. Fluxo de Trabalho Típico em CI/CD

Um pipeline de CI/CD para Terraform com configurações YAML pode seguir os seguintes passos:

Trigger: Um push para o repositório Git (ou um merge request) aciona o pipeline.
Checkout: O código Terraform e os arquivos YAML são clonados.
Seleção de Ambiente: O pipeline determina o ambiente alvo (ex: dev, staging, prod) com base no branch, tag, ou uma variável de pipeline.
Inicialização do Terraform: terraform init é executado para baixar provedores e módulos.
Validação: terraform validate verifica a sintaxe e a consistência do código.
Planejamento: terraform plan -var="environment=<ambiente>" (ou -var-file) é executado para gerar um plano de execução. Este plano pode ser revisado manualmente (em ambientes de produção) ou automaticamente aprovado.
Aplicação: terraform apply -var="environment=<ambiente>" (ou -var-file) é executado para aplicar as mudanças na infraestrutura.
Testes Pós-Implantação: Testes automatizados podem ser executados para verificar a funcionalidade da infraestrutura provisionada.

4.2. Exemplo de Pipeline (GitHub Actions)

name: Terraform Multi-Environment Deployment

on:
  push:
    branches:
      - main
      - develop

env:
  AWS_REGION: us-east-1 # Região padrão, pode ser sobrescrita pelo YAML

jobs:
  terraform:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ env.AWS_REGION }}

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v3
        with:
          terraform_version: 1.x.x

      - name: Determine Environment
        id: set_env
        run: |
          if [[ "${{ github.ref }}" == "refs/heads/main" ]]; then
            echo "ENVIRONMENT=prod" >> "$GITHUB_OUTPUT"
          elif [[ "${{ github.ref }}" == "refs/heads/develop" ]]; then
            echo "ENVIRONMENT=dev" >> "$GITHUB_OUTPUT"
          else
            echo "ENVIRONMENT=staging" >> "$GITHUB_OUTPUT"
          fi

      - name: Terraform Init
        run: terraform init

      - name: Terraform Validate
        run: terraform validate

      - name: Terraform Plan
        id: plan
        run: terraform plan -var="environment=${{ steps.set_env.outputs.ENVIRONMENT }}" -out=tfplan
        continue-on-error: true

      - name: Terraform Apply
        if: success() && github.ref == 'refs/heads/main' # Auto-apply apenas para main (produção)
        run: terraform apply -auto-approve tfplan

      - name: Terraform Apply (Manual Approval for other environments)
        if: success() && github.ref != 'refs/heads/main'
        run: |
          echo "Para aplicar as mudanças no ambiente ${{ steps.set_env.outputs.ENVIRONMENT }}, execute manualmente:"
          echo "terraform apply tfplan"
          # Em um pipeline real, você usaria um passo de aprovação manual aqui

Considerações para CI/CD:

Segurança: Utilize segredos do CI/CD (GitHub Secrets, GitLab CI/CD Variables) para armazenar credenciais sensíveis (chaves AWS, etc.). Nunca as exponha diretamente nos arquivos de configuração ou no código.
Aprovações Manuais: Para ambientes de produção, é uma boa prática exigir aprovação manual antes de executar o terraform apply.
State Locking: Certifique-se de que seu backend Terraform (ex: S3 com DynamoDB) esteja configurado para state locking para evitar conflitos em execuções concorrentes.
Testes: Integre testes de infraestrutura (ex: Terratest, InSpec) ao seu pipeline para validar a infraestrutura provisionada após o apply.

5. Boas Práticas e Considerações Finais

Validação de Esquema YAML: Para configurações complexas, considere usar ferramentas externas (ex: yamllint, json-schema com yq) ou scripts personalizados para validar o esquema dos seus arquivos YAML. Isso pode pegar erros de digitação ou estrutura antes mesmo do Terraform ser executado.
Segurança de Segredos: Reforçando, nunca armazene informações sensíveis diretamente em arquivos YAML versionados. Utilize soluções como AWS Secrets Manager, HashiCorp Vault, Azure Key Vault ou variáveis de ambiente para gerenciar segredos de forma segura. O YAML deve conter apenas referências ou metadados para esses segredos.
Modularização Agressiva: Quanto mais genéricos e reutilizáveis forem seus módulos Terraform, mais eficaz será a sua estratégia de configuração baseada em YAML. Pense em seus módulos como blocos de construção que são configurados pelos dados YAML.
Nomenclatura Consistente: Adote uma convenção de nomenclatura clara para seus arquivos e diretórios de configuração YAML (ex: global.yaml, dev.yaml, prod.yaml, service-a.yaml).
Documentação: Mantenha uma documentação clara sobre a estrutura dos seus arquivos YAML e como as configurações são mescladas e aplicadas.

6. Conclusão da Série

Esta série de artigos demonstrou como o Terraform, em conjunto com arquivos YAML, oferece uma abordagem poderosa e flexível para gerenciar infraestruturas como código em múltiplos ambientes. Desde os conceitos introdutórios de yamldecode até padrões avançados como deep merge, gerenciamento de múltiplos arquivos e integração com CI/CD, a externalização de configurações permite construir sistemas mais manuteníveis, escaláveis e alinhados com as melhores práticas de DevOps. Ao dominar essas técnicas, você estará apto a projetar e implementar arquiteturas de infraestrutura robustas que se adaptam às crescentes demandas de qualquer organização.

Imagem de capa: Logo oficial do Terraform — Wikimedia Commons

Referências:

Terraform e YAML - Modularização e Configurações Dinâmicas

Rafael Dutra — Fri, 24 Jul 2026 21:18:33 +0000

1. Introdução: Elevando a Abstração no Terraform

No Artigo 1 desta série, exploramos os fundamentos da separação de código e dados no Terraform utilizando arquivos YAML e a função yamldecode. Aprendemos a carregar configurações básicas por ambiente, o que já representa um avanço significativo na organização de projetos de Infraestrutura como Código (IaC). No entanto, à medida que a infraestrutura se torna mais complexa, a simples leitura de um arquivo YAML pode não ser suficiente para manter a modularidade e evitar a duplicação de código.

Este segundo artigo aprofundará nas técnicas intermediárias, focando em como combinar a flexibilidade do YAML com os poderosos recursos de modularização do Terraform. Abordaremos a passagem de configurações YAML para módulos, o uso do meta-argumento for_each para provisionamento dinâmico de recursos e módulos, e a aplicação de funções como lookup e condicionais para lidar com a variabilidade e opcionalidade dos dados de configuração.

2. Modularização com Dados YAML

A modularização é um pilar fundamental para a construção de infraestruturas escaláveis e manuteníveis no Terraform. Módulos permitem encapsular um conjunto de recursos relacionados, tornando-os reutilizáveis em diferentes partes do seu projeto ou em outros projetos. Ao combinar módulos com dados YAML, podemos criar componentes de infraestrutura altamente configuráveis.

2.1. Estrutura de Projeto com Módulos

Vamos expandir a estrutura de diretórios do Artigo 1 para incluir um módulo de exemplo:

. (root do projeto)
├── main.tf
├── variables.tf
├── outputs.tf
├── environments/
│   ├── dev.yaml
│   ├── staging.yaml
│   └── prod.yaml
└── modules/
    └── webserver/
        ├── main.tf
        ├── variables.tf
        └── outputs.tf

2.2. Definindo o Módulo `webserver`

O módulo webserver será responsável por provisionar uma instância de servidor web (por exemplo, uma instância AWS EC2). Ele receberá suas configurações como variáveis de entrada.

modules/webserver/variables.tf:

variable "instance_type" {
  description = "O tipo de instância EC2 para o servidor web."
  type        = string
}

variable "ami_id" {
  description = "O ID da AMI para o servidor web."
  type        = string
}

variable "server_name_prefix" {
  description = "Prefixo para o nome do servidor."
  type        = string
}

variable "instance_count" {
  description = "Número de instâncias a serem provisionadas."
  type        = number
  default     = 1
}

variable "tags" {
  description = "Tags adicionais para o servidor web."
  type        = map(string)
  default     = {}
}

modules/webserver/main.tf:

resource "aws_instance" "web" {
  count         = var.instance_count
  ami           = var.ami_id
  instance_type = var.instance_type

  tags = merge(
    var.tags,
    {
      Name = "${var.server_name_prefix}-${count.index + 1}"
    }
  )

  # Para este exemplo, assumimos que o provedor AWS está configurado no root
  # provider = aws
}

modules/webserver/outputs.tf:

output "instance_ids" {
  value       = aws_instance.web[*].id
  description = "IDs das instâncias EC2 provisionadas pelo módulo."
}

output "public_ips" {
  value       = aws_instance.web[*].public_ip
  description = "IPs públicos das instâncias EC2 provisionadas pelo módulo."
}

2.3. Integrando o Módulo com Configurações YAML

Agora, no main.tf principal, podemos chamar o módulo webserver e passar as configurações carregadas do YAML como variáveis para o módulo.

main.tf** (atualizado):**

variable "environment" {
  description = "O ambiente para o qual a infraestrutura será provisionada."
  type        = string
  default     = "dev"
}

locals {
  env_config = yamldecode(file("${path.module}/environments/${var.environment}.yaml"))
}

module "webserver_instance" {
  source             = "./modules/webserver"
  instance_type      = local.env_config.instance_type
  ami_id             = local.env_config.ami_id
  server_name_prefix = local.env_config.server_name_prefix
  instance_count     = local.env_config.instance_count
  tags               = local.env_config.tags
}

output "webserver_public_ips" {
  value = module.webserver_instance.public_ips
}

Com esta abordagem, o módulo webserver é genérico e reutilizável, e suas configurações são totalmente externalizadas para os arquivos YAML, permitindo que o mesmo módulo seja usado em diferentes ambientes com parâmetros distintos.

3. Provisionamento Dinâmico com `for_each` e YAML

O meta-argumento for_each é uma ferramenta poderosa para criar múltiplos recursos ou módulos a partir de um mapa ou conjunto de strings. Quando combinado com dados estruturados de um arquivo YAML, ele permite provisionar infraestruturas dinâmicas e escaláveis, evitando a repetição de blocos de código Terraform. [2]

3.1. Cenário: Múltiplos Buckets S3 com Configurações Variáveis

Imagine a necessidade de criar vários buckets S3, cada um com configurações específicas (ACL, versionamento, tags, etc.), que variam por ambiente ou por finalidade. O for_each é ideal para isso.

environments/dev.yaml** (adicionando configuração de S3):**

region: us-east-1
instance_type: t2.micro
ami_id: ami-0abcdef1234567890
server_name_prefix: dev-web
instance_count: 1
tags:
  Environment: Development
  Project: MyWebApp
  Owner: DevTeam

s3_buckets:
  app-logs:
    name: myapp-dev-logs-bucket
    acl: private
    versioning: true
    tags:
      Purpose: Logs
  app-assets:
    name: myapp-dev-assets-bucket
    acl: public-read
    versioning: false
    website_enabled: true
    tags:
      Purpose: Assets

3.2. Utilizando `for_each` no `main.tf`

# ... (variáveis e locals existentes)

resource "aws_s3_bucket" "app_buckets" {
  for_each = local.env_config.s3_buckets

  bucket = each.value.name
  acl    = each.value.acl

  versioning {
    enabled = lookup(each.value, "versioning", false)
  }

  # Bloco dinâmico para configuração de website, se presente
  dynamic "website" {
    for_each = lookup(each.value, "website_enabled", false) ? [1] : []
    content {
      index_document = "index.html"
      error_document = "error.html"
    }
  }

  tags = each.value.tags
}

output "s3_bucket_names" {
  value = [for bucket in aws_s3_bucket.app_buckets : bucket.id]
}

Explicação:

for_each = local.env_config.s3_buckets: O Terraform iterará sobre o mapa s3_buckets definido no YAML. Para cada chave (ex: app-logs, app-assets), um recurso aws_s3_bucket será criado.
each.value: Dentro do bloco resource, each.value refere-se ao mapa de configurações para o bucket atual (ex: { name: myapp-dev-logs-bucket, acl: private, ... }).

4. Lidando com Opcionalidade e Valores Padrão: `lookup` e Condicionais

Nem todas as configurações em YAML serão obrigatórias para todos os recursos ou módulos. Para lidar com atributos opcionais e fornecer valores padrão, o Terraform oferece funções como lookup e expressões condicionais.

4.1. A Função `lookup`

A função lookup(map, key, default) permite acessar um valor em um mapa. Se a key não existir, ela retorna o default fornecido, evitando erros. [3]

No exemplo do S3 acima, lookup(each.value, "versioning", false) garante que, se versioning não estiver definido no YAML para um bucket, o valor padrão false será usado, em vez de causar um erro.

4.2. Expressões Condicionais (`? :`)

Expressões condicionais (condition ? true_val : false_val) são úteis para decidir qual valor usar com base em uma condição. [4]

No bloco dynamic "website" do exemplo do S3, lookup(each.value, "website_enabled", false) ? [1] : [] é uma expressão condicional. Se website_enabled for true (ou não estiver presente e o lookup retornar false), o for_each do bloco dynamic receberá uma lista com um elemento ([1]), fazendo com que o bloco website seja criado. Caso contrário, receberá uma lista vazia ([]), e o bloco website não será criado. Isso permite que a configuração do website seja opcional no YAML.

5. Conclusão do Nível Intermediário

Neste segundo artigo, avançamos na utilização de Terraform com YAML, explorando como a modularização e o provisionamento dinâmico podem ser aprimorados. A combinação de módulos, for_each, lookup e expressões condicionais permite criar infraestruturas mais flexíveis, reutilizáveis e adaptáveis a diferentes cenários e ambientes. Com essas técnicas, você pode reduzir significativamente a duplicação de código e gerenciar configurações complexas de forma mais eficiente.

No próximo e último artigo desta série, mergulharemos em padrões avançados, como o deep merge de configurações, a gestão de múltiplos arquivos YAML para hierarquias complexas e a integração com fluxos de CI/CD, para construir arquiteturas de IaC verdadeiramente escaláveis.

Imagem de capa: Logo oficial do Terraform — Wikimedia Commons

Referências:

Terraform e YAML - Introdução e Configuração Básica por Ambiente

Rafael Dutra — Fri, 24 Jul 2026 02:22:00 +0000

1. Desafio Multi-Ambiente

A Infraestrutura como Código (IaC) revolucionou a forma como gerenciamos e provisionamos recursos de TI. Ferramentas como o Terraform permitem descrever a infraestrutura desejada em arquivos de configuração, que podem ser versionados, revisados e implantados de forma automatizada e consistente. Essa abordagem traz inúmeros benefícios, como a redução de erros manuais, a aceleração do provisionamento e a garantia de que o ambiente de produção seja idêntico ao de desenvolvimento.

No entanto, um desafio comum em projetos de IaC é a gestão de configurações que variam entre diferentes ambientes, como desenvolvimento (dev), homologação (staging) e produção (prod). Cada ambiente pode exigir tipos de instâncias diferentes, tamanhos de disco, regiões da nuvem, ou tags específicas. Manter essas diferenças sem duplicar excessivamente o código da infraestrutura é crucial para a manutenibilidade e escalabilidade do projeto.

Este artigo, o primeiro de uma série, apresentará os conceitos fundamentais de como desacoplar o código Terraform dos dados de configuração, utilizando arquivos YAML. Abordaremos a estrutura básica do projeto, a criação de arquivos YAML específicos por ambiente e o uso da função yamldecode do Terraform para carregar e interpretar esses dados.

2. Por Que Separar Código e Dados?

Separar o código da infraestrutura dos seus dados de configuração oferece vantagens significativas:

Reusabilidade: O mesmo código Terraform pode ser usado para provisionar infraestrutura em múltiplos ambientes, apenas alterando o arquivo de dados de entrada.
Manutenibilidade: Alterações em configurações específicas de um ambiente não exigem modificações no código principal do Terraform, reduzindo o risco de introduzir bugs.
Clareza: Os arquivos de configuração YAML são geralmente mais legíveis para não-desenvolvedores ou para quem precisa apenas entender os parâmetros de um ambiente, sem se aprofundar na lógica do Terraform.
Princípio DRY (Don't Repeat Yourself): Evita a duplicação de blocos de código Terraform que seriam idênticos, exceto pelos valores de suas variáveis.

3. Pré-requisitos

Para acompanhar este tutorial, você precisará de:

Terraform CLI: Versão 0.13 ou superior, pois a função yamldecode foi introduzida nesta versão. [1]
Conhecimento Básico: Familiaridade com os conceitos de Terraform (recursos, variáveis, outputs) e a sintaxe YAML.

4. Estrutura de Projeto Básica

Uma estrutura de diretórios bem organizada é o primeiro passo para uma gestão eficaz. Para este nível introdutório, sugerimos a seguinte organização:

. (root do projeto)
├── main.tf
├── variables.tf
├── outputs.tf
└── environments/
    ├── dev.yaml
    ├── staging.yaml
    └── prod.yaml

main.tf: Contém a lógica principal do Terraform, incluindo a leitura dos arquivos YAML e a definição dos recursos.
variables.tf: Declaração de variáveis globais, como a variável que selecionará o ambiente.
outputs.tf: Define os valores que serão exibidos após a aplicação do Terraform.
environments/: Um diretório dedicado para armazenar os arquivos YAML, um para cada ambiente.

5. Definindo Configurações por Ambiente com YAML

Vamos criar arquivos YAML simples para representar as configurações de três ambientes: dev, staging e prod. Estes arquivos conterão pares chave-valor que o Terraform utilizará.

`environments/dev.yaml`

Este arquivo define as configurações para o ambiente de desenvolvimento. Geralmente, são recursos menores e mais econômicos.

region: us-east-1
instance_type: t2.micro
ami_id: ami-0abcdef1234567890 # Exemplo de AMI ID
server_name_prefix: dev-web
instance_count: 1
tags:
  Environment: Development
  Project: MyWebApp
  Owner: DevTeam

`environments/staging.yaml`

Para o ambiente de homologação, podemos ter recursos um pouco mais robustos, mas ainda não em escala de produção.

region: us-west-2
instance_type: t2.medium
ami_id: ami-0fedcba9876543210 # Exemplo de AMI ID
server_name_prefix: staging-web
instance_count: 2
tags:
  Environment: Staging
  Project: MyWebApp
  Owner: QAteam

`environments/prod.yaml`

O ambiente de produção terá as configurações mais robustas e otimizadas para desempenho e alta disponibilidade.

region: eu-west-1
instance_type: m5.large
ami_id: ami-0123456789abcdef0 # Exemplo de AMI ID
server_name_prefix: prod-web
instance_count: 3
tags:
  Environment: Production
  Project: MyWebApp
  Owner: OpsTeam

6. Carregando e Utilizando Configurações YAML no Terraform

Agora, vamos integrar esses arquivos YAML ao nosso código Terraform. O main.tf será responsável por ler o arquivo YAML do ambiente selecionado e disponibilizar seus dados para uso.

`variables.tf`

Primeiro, definimos uma variável para selecionar o ambiente. É uma boa prática fornecer um valor padrão.

variable "environment" {
  description = "O ambiente para o qual a infraestrutura será provisionada (dev, staging, prod)"
  type        = string
  default     = "dev" # Valor padrão para desenvolvimento
  validation {
    condition     = contains(["dev", "staging", "prod"], var.environment)
    error_message = "O ambiente deve ser 'dev', 'staging' ou 'prod'."
  }
}

`main.tf`

Neste arquivo, usaremos yamldecode e file() para carregar as configurações e um bloco resource de exemplo para demonstrar seu uso.

# Carrega o conteúdo do arquivo YAML do ambiente selecionado
locals {
  env_config = yamldecode(file("${path.module}/environments/${var.environment}.yaml"))
}

# Exemplo de um recurso AWS EC2 utilizando as configurações do YAML
resource "aws_instance" "web_server" {
  count         = local.env_config.instance_count # Número de instâncias do YAML
  ami           = local.env_config.ami_id
  instance_type = local.env_config.instance_type

  tags = merge(
    local.env_config.tags,
    {
      Name = "${local.env_config.server_name_prefix}-${count.index + 1}"
    }
  )

  # Para este exemplo, assumimos que o provedor AWS está configurado
  # provider = aws
}

Explicação:

O bloco locals é usado para definir env_config, que armazena o mapa resultante da decodificação do YAML. path.module garante que o caminho para o diretório environments seja relativo ao main.tf.
O recurso aws_instance utiliza local.env_config.instance_count para o meta-argumento count, local.env_config.ami_id e local.env_config.instance_type para configurar as instâncias.
As tags são mescladas: as tags definidas no YAML (local.env_config.tags) são combinadas com uma tag Name gerada dinamicamente, que inclui o prefixo do servidor e um índice para cada instância.

`outputs.tf`

Para verificar se as configurações foram aplicadas corretamente, podemos definir alguns outputs.

output "current_environment" {
  value       = var.environment
  description = "O ambiente atual provisionado."
}

output "provisioned_instance_ids" {
  value       = aws_instance.web_server[*].id
  description = "IDs das instâncias EC2 provisionadas."
}

output "provisioned_instance_types" {
  value       = aws_instance.web_server[*].instance_type
  description = "Tipos das instâncias EC2 provisionadas."
}

output "provisioned_instance_tags" {
  value       = aws_instance.web_server[*].tags
  description = "Tags das instâncias EC2 provisionadas."
}

7. Executando o Terraform com Diferentes Ambientes

Para aplicar as configurações de um ambiente específico, você pode passar a variável environment ao Terraform de algumas maneiras:

Via Linha de Comando (`-var`)

Esta é a forma mais direta para testes ou implantações pontuais:

# Para o ambiente de desenvolvimento
terraform plan -var="environment=dev"
terraform apply -var="environment=dev"

# Para o ambiente de homologação
terraform plan -var="environment=staging"
terraform apply -var="environment=staging"

# Para o ambiente de produção
terraform plan -var="environment=prod"
terraform apply -var="environment=prod"

Via Arquivo de Variáveis (`-var-file`)

Para um fluxo de trabalho mais estruturado, você pode criar arquivos .tfvars específicos para cada ambiente. Por exemplo, crie dev.tfvars, staging.tfvars e prod.tfvars na raiz do projeto.

dev.tfvars:

environment = "dev"

staging.tfvars:

environment = "staging"

prod.tfvars:

environment = "prod"

Então, execute o Terraform apontando para o arquivo de variáveis desejado:

# Para o ambiente de desenvolvimento
terraform plan -var-file="dev.tfvars"
terraform apply -var-file="dev.tfvars"

# Para o ambiente de homologação
terraform plan -var-file="staging.tfvars"
terraform apply -var-file="staging.tfvars"

# Para o ambiente de produção
terraform plan -var-file="prod.tfvars"
terraform apply -var-file="prod.tfvars"

8. Conclusão do Nível Introdutório

Neste primeiro artigo, estabelecemos a base para a separação de código e dados no Terraform usando arquivos YAML. Aprendemos a estruturar o projeto, definir configurações específicas por ambiente em YAML e carregá-las no Terraform usando yamldecode. Esta abordagem inicial já proporciona uma melhor organização e flexibilidade em comparação com a codificação rígida de valores. No próximo artigo, exploraremos técnicas intermediárias para modularizar ainda mais a infraestrutura e lidar com cenários mais dinâmicos.

Imagem de capa: Logo oficial do Terraform — Wikimedia Commons

Referências:

yamldecode - Functions - Configuration Language | Terraform by HashiCorp

DEV Community: Rafael Dutra

Docker no dia a dia - comandos essenciais e primeiros containers reais

1. Retomando: de imagens a containers em execução

2. docker run além do básico

3. Inspecionando o que está rodando

4. Logs: a primeira ferramenta de debug

5. docker exec: entrando em um container já rodando

6. docker build: da aplicação à imagem

7. Limpando o ambiente

8. Conclusão e próximos passos

Docker - O Que É, Para Que Serve e Conceitos Iniciais

1. O Problema que o Docker Resolve

2. Containers vs Máquinas Virtuais

3. Os Três Conceitos Fundamentais: Imagens, Containers e Registries

4. Instalando o Docker

5. Um Primeiro Container na Prática

6. Conclusão e Próximos Passos

Tmux Avançado - Exemplos Reais e Configurações para Produtividade

1. Fechando a Série

2. Automatizando Sessões com Scripts

3. Persistência de Sessões em Servidores Remotos

4. Sincronizando Painéis Entre Múltiplos Hosts

5. Tmux Dentro de Tmux (Sessões Aninhadas)

6. Ajustes Finos de Configuração

7. Conclusão da Série

Tmux Personalizado - Cores, Status Bar e Plugins Úteis

1. Onde Mora a Configuração do Tmux

2. Prefixo, Atalhos e Popups

3. Cores e Status Bar com Catppuccin

4. Tmux Plugin Manager (TPM)

5. Plugins que Realmente Valem a Pena

6. Exemplo de .tmux.conf Completo

7. Conclusão e Próximos Passos

Tmux na Prática - Navegação, Painéis e Organização de Layout

1. Retomando: Sessões, Janelas e Painéis

2. Trabalhando com Janelas

3. Dividindo a Tela em Painéis

4. Redimensionando e Reorganizando o Layout

5. Modo de Cópia: Rolar, Selecionar e Copiar Texto

6. Comandos Úteis do Dia a Dia (Resumo)

7. Conclusão e Próximos Passos

Tmux - O Que É, Para Que Serve e Primeiros Passos

1. O Problema que o Tmux Resolve

2. O Que é um Terminal Multiplexer

3. Conceitos Fundamentais: Sessões, Janelas e Painéis

4. Instalando o Tmux

5. Primeiros Comandos: Criar, Sair, Desanexar e Reconectar

6. Por Que Isso Importa no Dia a Dia

7. Conclusão e Próximos Passos

Terraform e YAML - Implementação Prática em Projetos de CI/CD

1. Introdução: Conectando IaC e Automação

2. Estrutura do Repositório para CI/CD Eficaz

3. O Pipeline de CI/CD: Etapas Essenciais

3.1. Definição do Pipeline (.github/workflows/terraform.yml)

3.2. Detalhamento das Etapas do Pipeline

4. Estratégias de Branching e Fluxo de Trabalho

5. Considerações de Segurança no Pipeline de CI/CD

6. Boas Práticas e Dicas Adicionais

7. Conclusão

Terraform e YAML - Padrões Avançados e Escalabilidade

1. Introdução: Rumo à Infraestrutura como Código de Nível Empresarial

2. Deep Merge de Configurações: Mesclando Dados Hierarquicamente

2.1. O Desafio do merge Superficial

2.2. Implementando um Deep Merge

3. Gerenciamento de Múltiplos Arquivos YAML para Hierarquias Complexas

3.1. Estrutura de Diretórios Hierárquica

3.2. Carregando e Mesclando Múltiplos Arquivos YAML

4. Integração com CI/CD: Automatizando Implantações Multi-Ambiente

4.1. Fluxo de Trabalho Típico em CI/CD

4.2. Exemplo de Pipeline (GitHub Actions)

5. Boas Práticas e Considerações Finais

6. Conclusão da Série

Terraform e YAML - Modularização e Configurações Dinâmicas

1. Introdução: Elevando a Abstração no Terraform

2. Modularização com Dados YAML

2.1. Estrutura de Projeto com Módulos

2.2. Definindo o Módulo webserver

2.3. Integrando o Módulo com Configurações YAML

3. Provisionamento Dinâmico com for_each e YAML

3.1. Cenário: Múltiplos Buckets S3 com Configurações Variáveis

2. `docker run` além do básico

5. `docker exec`: entrando em um container já rodando

6. `docker build`: da aplicação à imagem

6. Exemplo de `.tmux.conf` Completo

3.1. Definição do Pipeline (`.github/workflows/terraform.yml`)

2.1. O Desafio do `merge` Superficial

2.2. Definindo o Módulo `webserver`

3. Provisionamento Dinâmico com `for_each` e YAML

3.2. Utilizando `for_each` no `main.tf`

4. Lidando com Opcionalidade e Valores Padrão: `lookup` e Condicionais

4.1. A Função `lookup`

4.2. Expressões Condicionais (`? :`)

`environments/dev.yaml`

`environments/staging.yaml`

`environments/prod.yaml`

`variables.tf`

`main.tf`

`outputs.tf`

Via Linha de Comando (`-var`)

Via Arquivo de Variáveis (`-var-file`)