DEV Community: Rafael Dutra

IaC além do Terraform - Ansible para provisionamento e configuração

Rafael Dutra — Wed, 02 Sep 2026 09:30:44 +0000

1. Provisionar não é configurar

No artigo anterior desta série, vimos o OpenTofu como uma alternativa (ou substituto direto) ao Terraform para a tarefa de provisionar infraestrutura — criar VMs, redes, bancos de dados gerenciados, buckets. Mas provisionar um servidor é só o primeiro passo: depois que a VM existe, alguém precisa instalar pacotes, configurar usuários, aplicar hardening, subir a aplicação e manter tudo isso consistente ao longo do tempo. É nesse espaço que o Ansible entra — e é comum ver os dois trabalhando juntos no mesmo pipeline, não como concorrentes.

2. Onde o Terraform para e o Ansible começa

A distinção mais útil na prática é:

Terraform (e OpenTofu) são ferramentas de provisionamento: elas conversam com APIs de nuvem para criar, atualizar ou destruir recursos. O modelo mental é declarativo e orientado a estado desejado do recurso: "quero uma VM com esse tipo de instância, nessa rede, com esse disco".
Ansible é uma ferramenta de gerenciamento de configuração: ela conecta em máquinas já existentes (via SSH, sem precisar de agente instalado) e executa tarefas para deixá-las em um estado desejado: "quero o Nginx instalado, essa versão, esse arquivo de configuração, esse serviço rodando".

Não é incomum ver os dois no mesmo pipeline: o Terraform cria a VM e expõe o IP como output; o Ansible usa esse IP para conectar e configurar o que está dentro dela. Um cuida do "hardware" (ainda que virtual), o outro do "software".

3. Conceitos fundamentais do Ansible

Antes de ver exemplos reais, vale fixar o vocabulário:

Inventory: a lista de máquinas que o Ansible gerencia, agrupadas logicamente (por exemplo, webservers, databases). Pode ser um arquivo estático (INI ou YAML) ou gerado dinamicamente (ex.: a partir de tags de uma conta AWS).
Playbook: um arquivo YAML que descreve, em ordem, quais tarefas (tasks) devem ser executadas em quais grupos de máquinas do inventory.
Module: a unidade de trabalho executada por uma tarefa — existem módulos prontos para praticamente tudo (apt, yum, copy, service, user, template, módulos específicos de nuvem, etc.).
Role: uma forma de empacotar playbooks, variáveis, templates e arquivos relacionados a uma responsabilidade específica (ex.: uma role nginx que sabe instalar e configurar o Nginx), reutilizável entre projetos.
Idempotência: assim como o Terraform, o Ansible é projetado para que rodar o mesmo playbook várias vezes produza o mesmo resultado final, sem efeitos colaterais — se um pacote já está instalado, o módulo apt simplesmente não faz nada na segunda execução.
Agentless: ao contrário de ferramentas como Puppet ou Chef, o Ansible não exige instalar um agente permanente na máquina gerenciada — ele conecta via SSH (ou WinRM, no caso do Windows), copia os módulos necessários, executa e limpa depois. Isso simplifica bastante o setup inicial.

4. Inventory na prática

# inventory/hosts.ini
[webservers]
web1 ansible_host=10.0.1.10
web2 ansible_host=10.0.1.11

[databases]
db1 ansible_host=10.0.2.10

[webservers:vars]
ansible_user=deploy
ansible_ssh_private_key_file=~/.ssh/deploy_key

5. Um playbook real: configurando um servidor web após o provisionamento

Este exemplo assume que a VM já existe (criada por Terraform/OpenTofu) e foca só na parte de configuração: instalar Nginx, criar um usuário de deploy, copiar um arquivo de configuração e garantir que o firewall libere a porta certa.

# playbook-webserver.yml
- name: Configurar servidor web
  hosts: webservers
  become: true

  vars:
    app_port: 8080

  tasks:
    - name: Atualizar cache de pacotes
      apt:
        update_cache: true
        cache_valid_time: 3600

    - name: Instalar Nginx
      apt:
        name: nginx
        state: present

    - name: Criar usuário de deploy
      user:
        name: deploy
        shell: /bin/bash
        groups: www-data
        append: true

    - name: Copiar configuração customizada do Nginx
      template:
        src: templates/nginx-site.conf.j2
        dest: /etc/nginx/sites-available/app
        owner: root
        group: root
        mode: "0644"
      notify: Recarregar Nginx

    - name: Habilitar o site
      file:
        src: /etc/nginx/sites-available/app
        dest: /etc/nginx/sites-enabled/app
        state: link
      notify: Recarregar Nginx

    - name: Liberar porta HTTP no firewall (ufw)
      ufw:
        rule: allow
        port: "80"
        proto: tcp

    - name: Garantir que o Nginx está rodando e habilitado no boot
      service:
        name: nginx
        state: started
        enabled: true

  handlers:
    - name: Recarregar Nginx
      service:
        name: nginx
        state: reloaded

O template referenciado usa variáveis Jinja2, o mesmo motor de templates usado internamente pelo Ansible:

# templates/nginx-site.conf.j2
server {
    listen 80;
    server_name {{ inventory_hostname }};

    location / {
        proxy_pass http://127.0.0.1:{{ app_port }};
        proxy_set_header Host $host;
    }
}

Executando o playbook:

ansible-playbook -i inventory/hosts.ini playbook-webserver.yml

Note o uso de notify/handlers: a tarefa de copiar o template e a de habilitar o site notificam o handler Recarregar Nginx, que só roda uma vez ao final, mesmo que múltiplas tarefas o disparem — evitando reiniciar o serviço várias vezes desnecessariamente numa mesma execução.

6. Integrando Terraform e Ansible no mesmo fluxo

Uma forma comum de conectar as duas ferramentas é usar o output do Terraform para gerar o inventory do Ansible dinamicamente, em vez de manter os IPs hardcoded:

# outputs.tf
output "web_ips" {
  value = aws_instance.web[*].public_ip
}

# Gera o inventory a partir do output do Terraform
terraform output -json web_ips | jq -r '.[]' > inventory/hosts_dynamic.txt

ansible-playbook -i inventory/hosts_dynamic.txt playbook-webserver.yml

Em pipelines mais maduros, isso costuma virar um plugin de inventory dinâmico (o Ansible tem plugins oficiais para AWS EC2, Azure, GCP, etc.), eliminando esse passo manual de exportar e converter outputs.

7. O Ansible pode substituir o Terraform?

Tecnicamente, o Ansible tem módulos de cloud (amazon.aws.ec2_instance, azure.azcollection.azure_rm_virtualmachine, etc.) que conseguem criar recursos de infraestrutura, não só configurá-los. Na prática, isso é usado com menos frequência, por alguns motivos:

O Terraform mantém um state explícito e trata drift de forma mais robusta — ele sabe exatamente o que criou e detecta divergências. Módulos de cloud do Ansible tendem a ser mais imperativos, sem esse rastreamento nativo.
O ecossistema de providers do Terraform (e OpenTofu) para APIs de nuvem é mais completo e atualizado que os módulos de cloud do Ansible.
Misturar as responsabilidades — usar Ansible tanto para criar quanto para configurar — tende a deixar o pipeline mais difícil de raciocinar sobre "o que existe" versus "como está configurado".

Por isso, a combinação mais comum no mercado continua sendo: Terraform (ou OpenTofu) provisiona, Ansible configura.

8. Conclusão

O Ansible não compete com o Terraform — ele resolve um problema diferente e complementar: o que fazer depois que a infraestrutura já existe. Inventory, playbooks, módulos e idempotência são os blocos fundamentais para automatizar de forma confiável a configuração de servidores, e a integração com o output do Terraform fecha o ciclo completo de provisionamento + configuração. No próximo e último artigo desta série, mudamos de assunto: como testar código Terraform antes de rodar apply em produção, usando Terratest, checkov e tflint.

Imagem de capa: Logo oficial do Terraform — Wikimedia Commons

Referências:

IaC além do Terraform - OpenTofu, o fork que virou alternativa séria

Rafael Dutra — Tue, 01 Sep 2026 09:30:51 +0000

1. Uma nova série: o mundo além do Terraform

Na série anterior deste blog, exploramos em profundidade como combinar Terraform e YAML para gerenciar infraestrutura em múltiplos ambientes. O Terraform é, de longe, a ferramenta de Infraestrutura como Código (IaC) mais popular do mercado — mas está longe de ser a única peça relevante do ecossistema. Nesta nova série, vamos sair da bolha do Terraform puro e olhar para ferramentas que complementam (ou, em alguns casos, competem com) ele: OpenTofu, Ansible, e as ferramentas de teste que garantem que o código de infraestrutura realmente faz o que promete.

Começamos pelo caso mais próximo de casa: o OpenTofu, um fork direto do Terraform que nasceu de uma crise de licenciamento e hoje é um projeto da Linux Foundation com vida própria.

2. Por que um fork aconteceu

Em agosto de 2023, a HashiCorp anunciou que todos os seus produtos, incluindo o Terraform, deixariam de usar a licença Mozilla Public License 2.0 (MPL 2.0) — uma licença open source reconhecida pela OSI (Open Source Initiative) — e passariam a usar a Business Source License (BSL) 1.1.

Na prática, a BSL proíbe que terceiros usem o código da HashiCorp para criar produtos ou serviços que compitam diretamente com os produtos da própria HashiCorp. Isso pegou em cheio empresas que ofereciam plataformas de gerenciamento de estado, automação de pipelines e "Terraform as a Service" construídas sobre o código aberto do Terraform — de repente, seus modelos de negócio ficaram juridicamente incertos.

A reação da comunidade foi rápida. Em setembro de 2023, um grupo de empresas (incluindo Spacelift, Env0, Gruntwork, Harness e outras) anunciou a criação do OpenTF, um fork do último release do Terraform sob a MPL 2.0 original — congelando o código no ponto exato antes da mudança de licença. Pouco depois, o projeto foi doado para a Linux Foundation e renomeado para OpenTofu, ganhando governança neutra e um roadmap independente da HashiCorp. [1]

3. O que é o OpenTofu, na prática

OpenTofu não é um produto concorrente que reimplementa as ideias do Terraform do zero — é literalmente o mesmo código-fonte, mantido por uma comunidade aberta a partir do ponto em que divergiu. Isso significa que, para quem já usa Terraform, a curva de aprendizado para migrar é próxima de zero:

A sintaxe é HCL (HashiCorp Configuration Language), idêntica.
Os providers (AWS, GCP, Azure, Kubernetes, etc.) continuam funcionando — o OpenTofu consome o mesmo Terraform Registry por padrão, além de manter seu próprio registry espelhado.
O formato do arquivo de state é compatível.
Os comandos são praticamente os mesmos, trocando o binário terraform por tofu:

tofu init
tofu plan
tofu apply
tofu destroy

4. Diferenças práticas que já existem hoje

Apesar de compatível, o OpenTofu não ficou parado — o projeto já implementou funcionalidades que o Terraform ainda não tem (ou demorou mais para lançar):

Criptografia de state nativa (state encryption): o OpenTofu permite criptografar o arquivo de state em repouso e em trânsito usando chaves gerenciadas pelo usuário, sem depender de um backend que já faça isso (como um bucket S3 com criptografia server-side). Isso é configurado diretamente no bloco terraform:

terraform {
  encryption {
    key_provider "pbkdf2" "mykey" {
      passphrase = var.state_encryption_passphrase
    }

    method "aes_gcm" "example" {
      keys = key_provider.pbkdf2.mykey
    }

    state {
      method = method.aes_gcm.example
    }
  }
}

for_each em blocos provider: permite instanciar múltiplas configurações de um mesmo provider dinamicamente (por exemplo, uma credencial AWS por conta em uma lista), algo que no Terraform exige declarar cada alias manualmente.
Registry alternativo e distribuído: o OpenTofu Registry funciona de forma independente do Terraform Registry, reduzindo o risco de um único ponto de falha para quem depende de providers e módulos públicos.

No dia a dia de um módulo Terraform comum — recursos, variáveis, outputs, for_each, count, módulos aninhados — não há diferença perceptível.

5. Quando faz sentido migrar

Preocupação com o modelo de licenciamento: se sua empresa constrói produtos ou serviços sobre IaC (plataformas internas de self-service, ferramentas de automação) e quer evitar qualquer ambiguidade jurídica com a BSL, o OpenTofu remove essa preocupação por estar sob MPL 2.0.
Você já usa Terraform CLI puro, sem depender de recursos exclusivos do Terraform Cloud/Enterprise (como Sentinel para policy-as-code, ou Run Tasks). Nesse caso, a migração tende a ser praticamente transparente.
Você quer as features que só existem no OpenTofu, como a criptografia de state nativa mencionada acima.
Governança aberta é um critério de decisão para sua organização — times que valorizam projetos sob fundações neutras (como já acontece com Kubernetes na CNCF) tendem a preferir o modelo do OpenTofu.

6. Quando NÃO faz sentido migrar (ainda)

Dependência forte do Terraform Cloud/Enterprise: se sua equipe usa Sentinel, Run Tasks, ou outras integrações profundas com a plataforma paga da HashiCorp, migrar exige primeiro substituir essas peças por equivalentes (o OpenTofu tem parceiros como Spacelift, Env0 e Scalr oferecendo isso, mas é uma migração adicional).
Módulos ou providers de terceiros com licenciamento restritivo: raro, mas alguns módulos privados podem ter cláusulas específicas sobre qual runtime é permitido.
Zero atrito no momento: se o time está satisfeito com o Terraform atual e não há motivação de licenciamento, features ou governança, trocar de ferramenta só para trocar introduz risco operacional sem benefício claro. IaC não é o lugar para migrações por modismo.

7. Migrando sem drama

A migração de um projeto Terraform existente para OpenTofu costuma ser um processo de poucos passos, já que o formato de state é compatível:

# Instala o tofu (exemplo via script oficial)
curl -fsSL https://get.opentofu.org/install-opentofu.sh | sh -s -- --install-method standalone

# Dentro do diretório do projeto Terraform existente
tofu init

# Confirma que o plano bate com o que o terraform geraria
tofu plan

Na maioria dos casos, tofu init reconhece o state existente sem exigir nenhuma migração explícita — o formato é o mesmo. É recomendado rodar tofu plan logo após a troca e comparar com o último terraform plan para garantir que nenhuma mudança inesperada apareça antes de rodar apply.

8. Conclusão

O OpenTofu não é uma ferramenta radicalmente diferente do Terraform — e essa é exatamente a sua proposta de valor. Para quem já domina Terraform, migrar é uma decisão de baixo risco técnico e alto peso estratégico (licenciamento, governança, e algumas features exclusivas). Não é uma migração obrigatória para todo mundo, mas é uma alternativa madura o suficiente para estar na mesa de qualquer discussão sobre o futuro do seu stack de IaC. No próximo artigo desta série, saímos do território "provisionar infraestrutura" para entrar no de "configurar o que já foi provisionado": o Ansible.

Imagem de capa: Logo oficial do Terraform — Wikimedia Commons

Referências:

Fzf com Tmux - integração e pop-ups

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

1. Retomando: o que é o Fzf

Na primeira parte desta série vimos o que é o fzf, como instalá-lo e como usá-lo direto no shell com Ctrl+R, Ctrl+T e Alt+C. Quem também usa tmux no dia a dia ganha um segundo nível de integração: o fzf pode rodar dentro de janelas flutuantes (pop-ups) do próprio tmux, sem interferir no layout de painéis já aberto, e servir de seletor para operações do próprio tmux — trocar de sessão, de janela, de painel, matar processos em outro painel etc.

2. Por que integrar Fzf com Tmux

Sem integração, usar o fzf dentro de uma sessão tmux funciona normalmente, mas cada busca ocupa o painel inteiro: se o objetivo é só escolher um arquivo ou trocar de branch rapidamente, o conteúdo do painel (um editor, um servidor rodando) é temporariamente coberto e é preciso "voltar" depois. Além disso, o tmux tem sua própria lista de coisas que fazem sentido filtrar de forma fuzzy — sessões, janelas, painéis — e não há um binding nativo do tmux para isso.

O fzf-tmux, incluído na instalação do fzf, resolve o primeiro problema: roda o fzf em uma janela sobreposta (pop-up ou split temporário) que desaparece assim que a seleção é feita, sem afetar o conteúdo do painel original. Combinado com bindings customizados no tmux.conf, também resolve o segundo.

3. fzf-tmux: pop-ups nativos

fzf-tmux é um wrapper de shell em torno do fzf que aceita as mesmas opções, mais flags de posicionamento e tamanho da janela sobreposta:

# pop-up centralizado, 80% da largura e 60% da altura do terminal
fzf-tmux -p 80%,60%

# split na parte de baixo do painel atual, ocupando 40% da altura
fzf-tmux -d 40%

# split lateral à direita, ocupando 50% da largura
fzf-tmux -d 50% -r

A flag -p (disponível a partir do tmux 3.2, que suporta display-popup) é a mais usada hoje: cria uma janela verdadeiramente flutuante, sobreposta ao conteúdo do painel, que não reorganiza o layout existente — diferente do -d, que faz um split real e temporariamente redistribui o espaço entre painéis.

# substitui o Ctrl+T padrão (busca de arquivo) por um pop-up
vim $(fzf-tmux -p 80%,60%)

4. Configurando pop-ups no `~/.tmux.conf`

O ganho maior vem de amarrar fzf-tmux a atalhos do próprio tmux, para que buscas fiquem a uma tecla de distância independente do que está rodando no painel atual. Alguns bindings úteis para adicionar ao ~/.tmux.conf:

# trocar de sessão com busca fuzzy em pop-up
bind-key S display-popup -E "tmux list-sessions -F '#S' | fzf --reverse | xargs tmux switch-client -t"

# trocar de janela na sessão atual
bind-key W display-popup -E "tmux list-windows -F '#I: #W' | fzf --reverse | cut -d: -f1 | xargs tmux select-window -t"

# abrir um seletor de painéis de todas as sessões
bind-key P display-popup -E "tmux list-panes -a -F '#S:#I.#P #{pane_current_command}' | fzf --reverse | cut -d' ' -f1 | xargs tmux switch-client -t"

A flag -E do display-popup fecha o pop-up automaticamente assim que o comando termina — importante aqui, já que o próprio fzf já trata Esc como cancelamento e Enter como confirmação; sem -E, o pop-up ficaria aberto esperando mais um Enter para fechar.

Depois de editar o tmux.conf, recarregue a configuração sem precisar reiniciar as sessões:

Ctrl+b :source-file ~/.tmux.conf

5. Casos de uso práticos

Com os bindings acima, o fluxo de trabalho muda de forma sutil mas sensível: em vez de Ctrl+b s (lista de sessões nativa do tmux, sem busca) e navegar com as setas, Ctrl+b S abre o pop-up já filtrável — digitar duas ou três letras do nome do projeto já é suficiente. O mesmo vale para W (janelas) e P (painéis entre sessões, útil quando há muitas sessões abertas simultaneamente, cada uma com vários painéis).

Outro caso comum é buscar e matar um processo específico rodando em qualquer painel, sem precisar navegar até ele manualmente:

bind-key K display-popup -E "ps aux | fzf --reverse --header='Matar processo' | awk '{print \$2}' | xargs -r kill -9"

E, claro, os usos do artigo anterior (buscar arquivo, trocar de branch, navegar no histórico) continuam funcionando igual dentro do tmux — a diferença é que, com fzf-tmux -p, é possível trocar os bindings padrão do shell (Ctrl+T, Ctrl+R) para abrirem em pop-up em vez de ocupar o painel inteiro:

# no .bashrc/.zshrc, quando dentro de uma sessão tmux
export FZF_TMUX_OPTS="-p 80%,60%"

6. Plugins úteis: tmux-fzf

Para quem prefere não escrever os bindings à mão, o plugin tmux-fzf empacota menus fuzzy prontos para sessões, janelas, painéis e até comandos do próprio tmux (matar sessão, renomear janela, mover painel), instalável via TPM — o gerenciador de plugins citado na primeira parte desta série:

# no ~/.tmux.conf
set -g @plugin 'sainnhe/tmux-fzf'

Depois de instalar (Ctrl+b I para o TPM buscar os plugins), o atalho padrão do plugin (Ctrl+b F ou o prefixo configurado) abre um menu principal com todas as categorias — uma alternativa mais completa aos bindings manuais da seção anterior, ao custo de menos controle fino sobre o comportamento de cada um.

7. Conclusão

Com o fzf-tmux e os bindings de pop-up, a busca fuzzy deixa de ser algo que só acontece dentro do shell e passa a fazer parte da navegação do próprio tmux — trocar de sessão, janela ou painel vira tão rápido quanto digitar algumas letras, sem sair do teclado e sem perder de vista o que está rodando nos outros painéis. Combinados, os dois artigos desta série cobrem o suficiente para o fzf virar parte permanente do fluxo de trabalho no terminal, do shell puro até o multiplexador.

Referências:

Fzf - o que é, como instalar e onde usar no dia a dia

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

1. O problema que o Fzf resolve

Quem vive no terminal conhece a cena: Ctrl+R para buscar um comando no histórico, mas a busca é linear e só mostra um resultado por vez; cd para um diretório profundo, mas é preciso lembrar (ou digitar) o caminho inteiro; git checkout para uma branch, mas primeiro é necessário rodar git branch e copiar o nome exato. Em todos esses casos, o gargalo é o mesmo: escolher um item entre muitos, digitando cada vez mais texto até sobrar só um.

O fzf (fuzzy finder) resolve isso de um jeito genérico: ele pega qualquer lista de linhas — histórico de comandos, arquivos, branches, processos, o que for — e transforma essa lista em um filtro interativo, digitado em tempo real, onde não é preciso acertar a grafia exata nem a ordem das letras. Basta digitar pedaços do que se lembra e o fzf ordena os resultados por relevância.

2. O que é o Fzf

Fzf é um filtro de linha de comando escrito em Go, de código aberto, mantido por Junegunn Choi. Ele não sabe nada sobre arquivos, git ou processos — a única coisa que ele faz é ler linhas da entrada padrão (stdin) e devolver, na saída padrão (stdout), a linha (ou linhas) selecionada interativamente. Essa simplicidade é o que o torna tão versátil: qualquer comando que produza uma lista de texto pode ser "encanado" (|) para dentro do fzf.

# a ideia básica: qualquer lista vira um menu interativo
ls | fzf
history | fzf
git branch | fzf
ps aux | fzf

Na prática, o fzf raramente é usado sozinho dessa forma — o valor real aparece quando ele é integrado ao shell e a outras ferramentas, o que este artigo cobre a partir da próxima seção.

3. Instalando o Fzf

O fzf está disponível nos principais gerenciadores de pacote:

# Debian/Ubuntu
sudo apt install fzf

# Fedora
sudo dnf install fzf

# Arch Linux
sudo pacman -S fzf

# macOS (Homebrew)
brew install fzf

Também é possível instalar via git, o que traz um script auxiliar de configuração dos atalhos de shell (usados na próxima seção):

git clone --depth 1 https://github.com/junegunn/fzf.git ~/.fzf
~/.fzf/install

O instalador pergunta se deseja habilitar os atalhos de autocompletar e os bindings de tecla — vale responder "sim" às duas perguntas, é exatamente o que torna o fzf útil no dia a dia. Depois de instalado, confirme a versão:

fzf --version

4. Integração com o shell: os três atalhos essenciais

A maior parte do valor do fzf no terminal vem de três atalhos de teclado que ele registra no shell (bash, zsh ou fish) depois de configurado:

Atalho	Ação
`Ctrl+R`	Busca fuzzy no histórico de comandos
`Ctrl+T`	Insere o caminho de um arquivo/diretório selecionado na linha
`Alt+C`	Muda (`cd`) para um diretório selecionado, buscando abaixo do atual

Ctrl+R substitui a busca reversa padrão do shell (que já usa Ctrl+R, mas de forma linear e sem preview) por uma lista filtrável de todo o histórico, digitando qualquer parte do comando lembrado. Ctrl+T, no meio de qualquer comando, abre uma busca de arquivos a partir do diretório atual e insere o caminho escolhido na posição do cursor — útil para não precisar digitar caminhos longos por completo. Alt+C faz o mesmo, mas para navegar diretamente para dentro de um diretório.

Se a instalação via apt/dnf/pacman não habilitou esses atalhos automaticamente, adicione ao .bashrc ou .zshrc:

# bash
[ -f /usr/share/doc/fzf/examples/key-bindings.bash ] && \
  source /usr/share/doc/fzf/examples/key-bindings.bash
[ -f /usr/share/doc/fzf/examples/completion.bash ] && \
  source /usr/share/doc/fzf/examples/completion.bash

# zsh
source /usr/share/doc/fzf/examples/key-bindings.zsh
source /usr/share/doc/fzf/examples/completion.zsh

(O caminho exato dos exemplos varia por distribuição; ~/.fzf/install resolve isso automaticamente.)

5. Usos no dia a dia

Além dos três atalhos, o fzf combina bem com comandos que já fazem parte da rotina, encanando a saída deles para dentro do filtro:

# trocar de branch git interativamente
git checkout $(git branch --all | fzf | tr -d '* ')

# matar um processo escolhendo da lista
kill -9 $(ps aux | fzf | awk '{print $2}')

# abrir um arquivo no editor, buscando pelo nome
vim $(fzf)

# buscar e copiar um commit específico do log
git log --oneline | fzf

Esses exemplos funcionam porque $(comando | fzf) captura a linha selecionada e a devolve como argumento — o mesmo padrão se aplica a praticamente qualquer ferramenta de linha de comando que aceite um nome ou identificador como argumento.

6. Customizando o Fzf: comando padrão e preview

Por padrão, Ctrl+T e fzf sozinho usam find para listar arquivos, o que inclui diretórios como .git e node_modules e pode ser lento em projetos grandes. É comum substituir isso por uma ferramenta mais rápida, como fd ou rg --files, via a variável FZF_DEFAULT_COMMAND:

# no .bashrc/.zshrc
export FZF_DEFAULT_COMMAND='fd --type f --hidden --exclude .git'
export FZF_CTRL_T_COMMAND="$FZF_DEFAULT_COMMAND"

Outro recurso muito usado é o preview, que mostra o conteúdo do item selecionado em um painel lateral enquanto se navega pela lista:

# preview de arquivos com bat (syntax highlighting) ao usar Ctrl+T
export FZF_CTRL_T_OPTS="--preview 'bat --color=always --line-range :50 {}'"

# preview do diff ao buscar branches
git branch | fzf --preview 'git log --oneline --graph --color=always {1} | head -20'

7. Conclusão e próximos passos

Nesta primeira parte, vimos o problema que o fzf resolve, como instalá-lo, os três atalhos de shell que fazem a maior diferença no dia a dia (Ctrl+R, Ctrl+T, Alt+C) e como combiná-lo com outros comandos e personalizar seu comportamento. No próximo artigo, o foco é a integração do fzf com o tmux: como abrir buscas em pop-ups nativos, trocar de sessão ou painel sem sair do teclado, e os plugins que tornam esse combo ainda mais produtivo.

Referências:

Docker avançado - multi-stage builds, segurança e CI/CD

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

1. Retomando: da aplicação funcionando ao container pronto para produção

Esta série cobriu, até aqui, o suficiente para desenvolver com Docker no dia a dia: conceitos fundamentais, comandos essenciais, Dockerfiles eficientes, rede, volumes e Compose para orquestrar múltiplos serviços. Este último artigo fecha a lacuna entre "funciona no meu Compose local" e "pronto para rodar em produção": imagens menores via multi-stage builds, segurança básica e não negociável, e como tudo isso se integra a um pipeline de CI/CD.

2. O problema que multi-stage builds resolve

Compilar ou empacotar uma aplicação frequentemente exige ferramentas que a aplicação não precisa em tempo de execução: compiladores, headers de desenvolvimento, o próprio código-fonte antes de ser transpilado/buildado. Um Dockerfile ingênuo carrega tudo isso para a imagem final:

# Ruim: ferramentas de build viajam junto para produção
FROM node:20
WORKDIR /app
COPY . .
RUN npm install && npm run build
CMD ["node", "dist/server.js"]

Essa imagem inclui o npm, todo o node_modules (incluindo dependências de desenvolvimento), o código-fonte original e as ferramentas de build — frequentemente centenas de MBs de peso morto que nunca são usados depois que npm run build termina, e que ainda aumentam a superfície de ataque da imagem (mais binários, mais coisa que pode ter vulnerabilidade).

Multi-stage builds resolvem isso permitindo múltiplos blocos FROM no mesmo Dockerfile, onde estágios posteriores copiam seletivamente apenas o que precisam dos anteriores — o restante do estágio de build simplesmente não existe na imagem final:

# Estágio 1: build, com todas as ferramentas necessárias
FROM node:20 AS build
WORKDIR /app
COPY package*.json .
RUN npm ci
COPY . .
RUN npm run build

# Estágio 2: produção, só com o resultado do build
FROM node:20-slim
WORKDIR /app
COPY --from=build /app/dist ./dist
COPY --from=build /app/node_modules ./node_modules
COPY package*.json .
CMD ["node", "dist/server.js"]

A imagem final não contém o código-fonte original, nem as ferramentas de build do primeiro estágio — só o dist/ compilado e as dependências necessárias em runtime. A redução de tamanho costuma ser dramática: não é incomum cair de mais de 1 GB para menos de 150 MB na mesma aplicação.

3. Multi-stage com linguagens compiladas

O ganho é ainda mais evidente com linguagens compiladas, onde o binário final não precisa nem do compilador nem do código-fonte:

# Estágio 1: compila o binário
FROM golang:1.22 AS build
WORKDIR /app
COPY go.mod go.sum .
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -o servidor .

# Estágio 2: só o binário, em uma imagem praticamente vazia
FROM scratch
COPY --from=build /app/servidor /servidor
ENTRYPOINT ["/servidor"]

scratch é uma imagem literalmente vazia — sem shell, sem libc, sem utilitário algum. Um binário Go estaticamente linkado (CGO_ENABLED=0) não precisa de nada disso, resultando em uma imagem final de poucos MBs. Isso também é uma vantagem de segurança: uma imagem sem shell nem utilitários tem uma superfície de ataque drasticamente menor, já que não há ferramentas para um invasor usar mesmo que consiga executar algo dentro do container.

4. Segurança: nunca rodar como root

Por padrão, um container roda seus processos como root, a menos que a imagem base ou o Dockerfile digam o contrário. Isso é um risco real: se uma vulnerabilidade na aplicação permitir execução de código arbitrário dentro do container, esse código roda como root — e embora o isolamento de namespaces limite o dano ao host na maioria dos casos, root dentro do container ainda tem acesso irrestrito ao sistema de arquivos e processos daquele container, e certas vulnerabilidades de escape de container (historicamente raras, mas existentes) dependem exatamente de o processo estar rodando como root.

A correção é criar e usar um usuário sem privilégios no Dockerfile:

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

RUN useradd --create-home appuser
COPY --chown=appuser:appuser . .
USER appuser

CMD ["python3", "app.py"]

A instrução USER appuser garante que, a partir dali, todo comando do Dockerfile e todo processo do container em execução roda com esse usuário — não root. Muitas imagens oficiais já vêm com um usuário não-root pronto para uso (por exemplo, node tem o usuário node), bastando declarar USER node em vez de criar um novo.

5. Scan de vulnerabilidades

Mesmo com boas práticas de Dockerfile, a imagem base e as dependências instaladas podem conter vulnerabilidades conhecidas (CVEs) em bibliotecas do sistema. Ferramentas de scan verificam a imagem construída contra bancos de dados de vulnerabilidades conhecidas:

# Docker Scout, integrado ao Docker CLI
docker scout cves minha-app:1.0

# Trivy, alternativa open-source amplamente usada
trivy image minha-app:1.0

A saída lista pacotes com vulnerabilidades conhecidas, sua severidade (baixa, média, alta, crítica) e, quando disponível, a versão que corrige o problema — frequentemente resolvido apenas atualizando a imagem base ou uma dependência específica. Rodar esse scan como parte do pipeline de CI (a seguir) evita que uma imagem com vulnerabilidade crítica conhecida chegue a produção sem que ninguém tenha visto o alerta.

6. Docker em pipelines de CI/CD

O fluxo mais comum em CI é: build da imagem, rodar testes dentro dela (ou contra ela), scan de segurança, e — só se tudo passar — push para o registry e deploy. Um exemplo de pipeline (sintaxe do GitHub Actions, mas o fluxo é o mesmo em qualquer ferramenta de CI):

# .github/workflows/build.yml
name: build-and-push

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build da imagem
        run: docker build -t minha-app:${{ github.sha }} .

      - name: Scan de vulnerabilidades
        run: docker scout cves minha-app:${{ github.sha }} --exit-code --only-severity critical,high

      - name: Login no registry
        run: echo "${{ secrets.REGISTRY_TOKEN }}" | docker login registry.exemplo.com -u usuario --password-stdin

      - name: Push da imagem
        run: |
          docker tag minha-app:${{ github.sha }} registry.exemplo.com/minha-app:${{ github.sha }}
          docker push registry.exemplo.com/minha-app:${{ github.sha }}

Duas práticas valem destaque nesse pipeline:

Tag pela SHA do commit (${{ github.sha }}), não latest — cada build gera uma imagem rastreável a um commit exato, essencial para saber o que está rodando em produção e para reverter (rollback) para uma versão anterior com confiança.
--exit-code no scan — faz o comando retornar código de saída diferente de zero se encontrar vulnerabilidade crítica/alta, o que interrompe o pipeline automaticamente em vez de depender de alguém ler o relatório manualmente.

O cache de build (Artigo 3 desta série) também importa em CI: runners efêmeros normalmente começam sem cache local, então ferramentas como docker buildx com cache remoto (--cache-from/--cache-to apontando para o registry) evitam que cada execução do pipeline reconstrua tudo do zero.

7. Conclusão da série

Ao longo desses seis artigos, esta série foi do "o que é um container" até um pipeline de CI/CD publicando imagens seguras e enxutas: o problema que o Docker resolve e seus conceitos fundamentais, os comandos do dia a dia, como escrever Dockerfiles eficientes aproveitando cache de build, como containers se comunicam via rede e persistem dados via volumes, como Compose orquestra tudo isso localmente, e finalmente como levar isso a produção com multi-stage builds, containers não-root e scan de vulnerabilidades integrado ao pipeline. A partir daqui, a base está posta para explorar orquestração em escala (Kubernetes) e tópicos mais específicos de infraestrutura — mas o Docker isolado, bem usado, já resolve a enorme maioria dos casos do dia a dia de desenvolvimento e deploy de aplicações.

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

Referências:

Docker Compose - orquestrando múltiplos containers

Rafael Dutra — Sun, 16 Aug 2026 09:30:13 +0000

1. Retomando: do `docker run` repetido a um arquivo único

No artigo anterior, subir uma API e um Postgres conectados exigiu dois comandos docker run longos, com flags de rede, volume e variáveis de ambiente para lembrar (e digitar) toda vez. Em um projeto real, com mais serviços — cache, fila, worker em background — isso rapidamente vira inviável de manter na cabeça ou em um script solto. O Docker Compose resolve isso descrevendo toda a aplicação multi-container em um único arquivo declarativo, versionado junto com o código.

2. O arquivo `compose.yaml`

Compose lê um arquivo YAML (por convenção compose.yaml, ou o nome legado docker-compose.yml, ainda amplamente usado) descrevendo serviços (cada um vira um ou mais containers), redes e volumes:

# compose.yaml
services:
  api:
    build: .
    ports:
      - "8000:8000"
    environment:
      DATABASE_URL: postgresql://postgres:segredo@banco:5432/postgres
    depends_on:
      - banco

  banco:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: segredo
    volumes:
      - pg-dados:/var/lib/postgresql/data

volumes:
  pg-dados:

Isso substitui inteiramente os dois docker run do artigo anterior. Uma diferença importante já aparece aqui: por padrão, Compose cria uma rede própria para o projeto e conecta todos os serviços a ela automaticamente — não é preciso um docker network create manual, nem declarar --network em cada serviço. Cada serviço já é acessível pelos demais pelo nome declarado em services: (aqui, banco resolve para o container do Postgres), exatamente como as redes definidas pelo usuário do artigo anterior.

3. Comandos essenciais do Compose

docker compose up -d          # sobe todos os serviços em segundo plano
docker compose ps              # lista os containers do projeto e seu status
docker compose logs -f api     # segue os logs de um serviço específico
docker compose logs -f         # segue os logs de todos os serviços, intercalados
docker compose exec api bash   # abre um shell dentro do container de um serviço
docker compose stop            # para os containers sem removê-los
docker compose down            # para e remove containers e rede (volumes nomeados sobrevivem)
docker compose down -v         # remove também os volumes — cuidado, apaga dados

O padrão docker compose <comando> <serviço> se repete: a maioria dos comandos aceita opcionalmente o nome de um serviço específico (como em logs -f api) ou afeta o projeto inteiro se omitido.

4. `depends_on`: ordem de início, não prontidão

depends_on controla a ordem em que os containers são criados e iniciados — no exemplo acima, banco inicia antes de api. O que ele não garante é que o Postgres já esteja pronto para aceitar conexões nesse momento: o processo do Postgres pode levar alguns segundos para inicializar depois que o container começa a rodar, e uma API que tenta conectar imediatamente pode falhar nessa janela.

A forma correta de esperar prontidão de verdade é um healthcheck:

services:
  api:
    build: .
    depends_on:
      banco:
        condition: service_healthy

  banco:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: segredo
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 3s
      retries: 5

Com condition: service_healthy, o Compose só considera banco "pronto" (e só então inicia api) depois que o healthcheck passar — muito mais confiável do que assumir um tempo fixo de espera ou implementar retry manual na aplicação (embora ter retry na aplicação continue sendo uma boa prática defensiva, mesmo com healthcheck).

5. Variáveis de ambiente e o arquivo `.env`

Segredos e configuração que variam por ambiente (senha de banco, chaves de API) não deveriam ficar hardcoded no compose.yaml. Compose lê automaticamente um arquivo .env no mesmo diretório e substitui variáveis referenciadas com ${NOME}:

# .env
POSTGRES_PASSWORD=segredo-local
API_PORT=8000

services:
  api:
    build: .
    ports:
      - "${API_PORT}:8000"
  banco:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}

Isso permite versionar o compose.yaml normalmente enquanto o .env (que contém segredos reais) fica de fora do controle de versão via .gitignore — o mesmo princípio de nunca commitar credenciais, aplicado à configuração do Compose.

6. Um ambiente completo: app + banco + cache

Estendendo o exemplo para um cenário mais realista, com Redis como cache além da API e do Postgres:

services:
  api:
    build: .
    ports:
      - "8000:8000"
    environment:
      DATABASE_URL: postgresql://postgres:${POSTGRES_PASSWORD}@banco:5432/postgres
      REDIS_URL: redis://cache:6379
    depends_on:
      banco:
        condition: service_healthy
      cache:
        condition: service_started

  banco:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - pg-dados:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      retries: 5

  cache:
    image: redis:7-alpine
    volumes:
      - redis-dados:/data

volumes:
  pg-dados:
  redis-dados:

Um docker compose up -d sobe os três serviços, na ordem certa, já conectados entre si e com dados persistentes — o equivalente a uma infraestrutura local completa de desenvolvimento, reproduzível em qualquer máquina que tenha Docker instalado, sem instalar Postgres ou Redis diretamente no sistema.

7. Escalando um serviço

Para rodar múltiplas instâncias do mesmo serviço (por exemplo, vários workers processando uma fila em paralelo):

docker compose up -d --scale worker=3

Isso só funciona sem conflito para serviços que não publicam uma porta fixa do host (ports:) — três containers não podem, todos, mapear a porta 8000 do host simultaneamente. Serviços pensados para escalar dessa forma tipicamente não expõem porta ao host diretamente, sendo acessados por outro serviço (como um proxy reverso) através da rede interna do Compose.

8. Conclusão e próximos passos

Docker Compose transforma uma coleção de comandos docker run frágeis e difíceis de lembrar em um arquivo único, declarativo e versionável, que descreve toda a aplicação — serviços, rede, volumes, ordem de inicialização e variáveis de ambiente. No último artigo desta série, o assunto vai para práticas de nível de produção: multi-stage builds para reduzir drasticamente o tamanho final da imagem, segurança (rodar sem root, scan de vulnerabilidades) e como tudo isso se encaixa em um pipeline de CI/CD.

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

Referências:

Docker - redes e volumes na prática

Rafael Dutra — Sat, 15 Aug 2026 09:30:21 +0000

1. Retomando: de imagens bem construídas a containers que conversam entre si

Os artigos anteriores desta série cobriram como criar imagens eficientes e rodar containers isolados. Mas uma aplicação real raramente é um único container: normalmente há uma API, um banco de dados, um cache, talvez uma fila de mensagens — cada um em seu próprio container, precisando se comunicar. E containers, por padrão, são efêmeros: qualquer dado escrito dentro deles some quando são removidos. Este artigo cobre as duas peças que resolvem isso: redes (comunicação entre containers) e volumes (persistência de dados).

2. O problema do isolamento de rede por padrão

Cada container recebe seu próprio namespace de rede, isolado dos demais e do host. Isso é uma característica de segurança, não um bug — mas significa que dois containers rodados de forma independente não conseguem se encontrar automaticamente:

docker run -d --name api minha-api
docker run -d --name banco postgres

De dentro do container api, tentar acessar banco por esse nome simplesmente falha — cada container, isolado, só enxerga localhost como a si mesmo. A solução do Docker para isso é criar uma rede e conectar ambos os containers a ela.

3. Redes definidas pelo usuário (User-Defined Networks)

docker network create minha-rede

docker run -d --name banco --network minha-rede postgres
docker run -d --name api --network minha-rede minha-api

A partir daqui, dentro do container api, o hostname banco resolve automaticamente para o IP do container banco — o Docker roda um DNS interno para qualquer rede definida pelo usuário, resolvendo containers pelo nome (ou pelo alias definido com --network-alias, se houver mais de um). Isso é o motivo pelo qual strings de conexão em aplicações containerizadas costumam usar o nome do serviço em vez de um IP fixo:

DATABASE_URL=postgresql://usuario:senha@banco:5432/meudb

Comandos úteis para inspecionar redes:

docker network ls                  # lista todas as redes
docker network inspect minha-rede  # detalhes: containers conectados, subnet, gateway
docker network connect minha-rede outro-container   # conecta um container já em execução
docker network disconnect minha-rede outro-container

4. Os drivers de rede mais comuns

bridge (padrão): cada container recebe um IP interno numa sub-rede privada isolada; é o driver usado nos exemplos acima e o adequado para a grande maioria dos casos de uma única máquina.
host: o container compartilha diretamente a stack de rede do host, sem isolamento — usado quando a latência extra do NAT do bridge é inaceitável, ao custo de perder o isolamento de portas.
none: desabilita rede completamente — útil para containers que só processam dados locais e não devem ter acesso externo algum, por segurança.
overlay: conecta containers rodando em hosts diferentes, usado em clusters multi-máquina (Docker Swarm, e conceito similar ao que o Kubernetes resolve à sua própria maneira) — fora do escopo de uma única máquina, mas bom saber que existe.

Para a maioria dos projetos rodando em uma única máquina — o caso coberto por esta série — bridge com redes definidas pelo usuário é a resposta certa quase sempre.

5. Volumes: persistindo dados além da vida do container

Por padrão, tudo que um processo escreve dentro de um container vive na camada gravável dele — e essa camada é destruída junto com o container quando ele é removido (docker rm). Para um banco de dados, isso é inaceitável: perder todos os dados a cada docker rm banco não é uma opção. A solução são volumes, que existem fora do ciclo de vida de qualquer container específico.

docker volume create dados-banco

docker run -d --name banco \
  -v dados-banco:/var/lib/postgresql/data \
  postgres

Mesmo removendo e recriando o container banco, os dados em dados-banco sobrevivem — um novo container apontando para o mesmo volume enxerga exatamente os mesmos dados de antes:

docker stop banco && docker rm banco
docker run -d --name banco -v dados-banco:/var/lib/postgresql/data postgres
# os dados anteriores continuam lá

Comandos de gerenciamento:

docker volume ls                   # lista volumes
docker volume inspect dados-banco  # onde o volume vive no host, entre outros metadados
docker volume rm dados-banco       # remove (falha se algum container ainda o usa)
docker volume prune                # remove todos os volumes não usados por nenhum container

6. Volumes nomeados vs bind mounts

Existem duas formas de "montar" algo do host dentro de um container, e a diferença importa:

Volume nomeado (-v dados-banco:/caminho): gerenciado inteiramente pelo Docker, que decide onde no host os dados ficam de fato armazenados. É a opção certa para dados que uma aplicação gera e consome (bancos de dados, filas, caches persistentes) — portátil entre ambientes, porque não depende de um caminho específico do host.
Bind mount (-v /caminho/no/host:/caminho/no/container): aponta diretamente para um caminho existente do sistema de arquivos do host. É a opção certa para desenvolvimento local — montar o código-fonte do projeto dentro do container para ver mudanças refletidas sem rebuildar a imagem a cada alteração:

# Desenvolvimento: código do host refletido ao vivo dentro do container
docker run -d -v $(pwd)/src:/app/src -p 3000:3000 minha-app-dev

Bind mounts não são recomendados para dados de produção porque acoplam o container a um caminho específico do host, o que quebra a portabilidade que o Docker existe para garantir.

7. Um cenário completo: API + banco comunicando-se com dados persistentes

Juntando rede e volume no mesmo exemplo — uma API e um Postgres, isolados em rede própria, com dados que sobrevivem a reinicializações:

docker network create app-rede
docker volume create pg-dados

docker run -d --name banco \
  --network app-rede \
  -v pg-dados:/var/lib/postgresql/data \
  -e POSTGRES_PASSWORD=segredo \
  postgres:16

docker run -d --name api \
  --network app-rede \
  -p 8000:8000 \
  -e DATABASE_URL=postgresql://postgres:segredo@banco:5432/postgres \
  minha-api:1.0

Esse é exatamente o tipo de configuração que, no próximo artigo, o Docker Compose substitui por um único arquivo declarativo — em vez de dois comandos docker run longos para lembrar (e digitar) toda vez.

8. Conclusão e próximos passos

Redes definidas pelo usuário resolvem a comunicação entre containers via DNS interno pelo nome, e volumes resolvem a persistência de dados além do ciclo de vida de qualquer container individual — as duas peças que faltavam para modelar uma aplicação real com múltiplos serviços. No próximo artigo, o Docker Compose entra em cena para descrever tudo isso — rede, volumes e múltiplos containers — em um único arquivo declarativo, versionável junto com o código.

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

Referências:

Dockerfile na prática - camadas, cache de build e boas práticas

Rafael Dutra — Fri, 14 Aug 2026 09:30:11 +0000

1. Retomando: do Dockerfile mínimo a um Dockerfile de verdade

Na segunda parte desta série, um Dockerfile de poucas linhas já foi suficiente para empacotar uma aplicação Python. Isso funciona, mas um Dockerfile escrito sem pensar em camadas e cache de build gera imagens maiores do que precisam ser e builds que demoram muito mais do que deveriam a cada mudança pequena no código. Este artigo aprofunda como o Docker constrói uma imagem por dentro, e como escrever um Dockerfile que tira proveito disso.

2. Como funcionam as camadas (layers)

Cada instrução de um Dockerfile (FROM, RUN, COPY, ADD) que modifica o sistema de arquivos gera uma camada — um diff read-only armazenado separadamente e empilhado sobre as anteriores. A imagem final é simplesmente a soma de todas essas camadas, e o container em execução adiciona uma camada gravável no topo (union filesystem).

Container (camada gravável)
──────────────────────────
Camada 4: COPY . .
Camada 3: RUN pip install -r requirements.txt
Camada 2: COPY requirements.txt .
Camada 1: FROM python:3.12-slim

Duas consequências práticas importantes:

Camadas são reaproveitadas entre imagens. Se duas imagens diferentes compartilham as mesmas primeiras instruções (por exemplo, a mesma FROM e o mesmo RUN apt-get install), o Docker armazena essa camada uma única vez em disco, mesmo que várias imagens a usem.
Camadas são cacheadas entre builds. Ao rodar docker build de novo, o Docker verifica cada instrução, na ordem: se a instrução e seus arquivos de entrada não mudaram desde o último build, ele reaproveita a camada já construída em vez de refazer o trabalho. Isso é a base de todo o próximo tópico.

3. Cache de build: ordenar o Dockerfile por frequência de mudança

O cache de build é invalidado a partir do primeiro ponto de mudança: se a instrução N mudou (ou um arquivo que ela copia mudou), toda camada a partir de N é reconstruída — mesmo que as instruções seguintes sejam idênticas ao build anterior. Isso significa que a ordem das instruções no Dockerfile importa tanto quanto o conteúdo delas.

O erro mais comum é copiar todo o código-fonte antes de instalar dependências:

# Ruim: qualquer mudança no código invalida o cache do pip install
FROM python:3.12-slim
WORKDIR /app
COPY . .
RUN pip install --no-cache-dir -r requirements.txt
CMD ["python3", "app.py"]

Como COPY . . copia o código inteiro, qualquer alteração em qualquer arquivo — inclusive um README.md — muda o conteúdo dessa camada e invalida tudo que vem depois, incluindo o pip install, que normalmente é o passo mais lento do build.

A correção é separar o que muda com frequência (código) do que muda pouco (lista de dependências), copiando e instalando dependências primeiro:

# Bom: pip install só roda de novo se requirements.txt mudar
FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["python3", "app.py"]

Agora, alterar apenas o código da aplicação (o caso mais comum durante o desenvolvimento) reaproveita a camada do pip install do cache, e o build inteiro cai de dezenas de segundos (ou minutos, em projetos com muitas dependências) para menos de um segundo nessa etapa.

O mesmo princípio vale para qualquer gerenciador de pacotes — Node.js (package.json antes do código), Go (go.mod/go.sum antes do código), Ruby (Gemfile antes do código): copiar o manifesto de dependências, instalar, só então copiar o resto.

4. Minimizando o número e o tamanho das camadas

Cada RUN gera uma nova camada, e camadas nunca "encolhem" — se um RUN baixa um arquivo temporário e um RUN seguinte o apaga, o espaço ocupado por ele na camada anterior continua contando no tamanho final da imagem. Por isso, passos relacionados costumam ser combinados em um único RUN:

# Ruim: cache do apt fica preso numa camada, mesmo "removido" depois
RUN apt-get update
RUN apt-get install -y curl git
RUN rm -rf /var/lib/apt/lists/*

# Bom: um único RUN, uma única camada, sem sobra
RUN apt-get update && \
    apt-get install -y --no-install-recommends curl git && \
    rm -rf /var/lib/apt/lists/*

--no-install-recommends evita instalar pacotes "sugeridos" que o apt-get traria por padrão, mas que raramente são necessários dentro de um container — outra fonte comum de peso desnecessário na imagem.

5. Escolhendo a imagem base certa

A imagem base declarada em FROM é o maior fator isolado no tamanho final. Para a mesma linguagem, variantes existem com trade-offs diferentes:

Variante	Tamanho aproximado	Quando usar
`python:3.12`	~1 GB	Precisa de ferramentas de build completas
`python:3.12-slim`	~150 MB	Maioria dos casos — Debian mínimo
`python:3.12-alpine`	~50 MB	Tamanho é crítico; cuidado com compatibilidade

alpine usa musl em vez de glibc, o que ocasionalmente quebra dependências Python com extensões compiladas em C (como numpy ou psycopg2) — vale testar antes de adotar em produção, em vez de assumir que é sempre a melhor escolha só por ser a menor imagem.

6. `.dockerignore`: cortando o que não deveria nem chegar ao build

Antes de qualquer instrução rodar, o Docker envia todo o contexto de build (o diretório passado como argumento final de docker build, por exemplo .) para o daemon. Sem um .dockerignore, isso costuma incluir lixo irrelevante — e às vezes sensível:

# .dockerignore
.git
node_modules
__pycache__
*.pyc
.env
.venv
*.log

Além de acelerar o envio do contexto (relevante em projetos com dependências pesadas versionadas localmente, como node_modules), isso evita vazar segredos: um .env com credenciais copiado por acidente via COPY . . fica embutido permanentemente em uma camada da imagem, mesmo que um passo posterior o apague.

7. Conclusão e próximos passos

Entender camadas e cache de build muda a forma de escrever Dockerfiles: ordenar instruções da menos volátil para a mais volátil, combinar RUNs relacionados, escolher a imagem base certa para o caso de uso e manter um .dockerignore atualizado são hábitos que se pagam em builds mais rápidos e imagens menores desde o primeiro dia. No próximo artigo, o assunto muda de como as imagens são construídas para como os containers se comunicam: redes, volumes e persistência de dados.

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

Referências:

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:

DEV Community: Rafael Dutra

IaC além do Terraform - Ansible para provisionamento e configuração

1. Provisionar não é configurar

2. Onde o Terraform para e o Ansible começa

3. Conceitos fundamentais do Ansible

4. Inventory na prática

5. Um playbook real: configurando um servidor web após o provisionamento

6. Integrando Terraform e Ansible no mesmo fluxo

7. O Ansible pode substituir o Terraform?

8. Conclusão

IaC além do Terraform - OpenTofu, o fork que virou alternativa séria

1. Uma nova série: o mundo além do Terraform

2. Por que um fork aconteceu

3. O que é o OpenTofu, na prática

4. Diferenças práticas que já existem hoje

5. Quando faz sentido migrar

6. Quando NÃO faz sentido migrar (ainda)

7. Migrando sem drama

8. Conclusão

Fzf com Tmux - integração e pop-ups

1. Retomando: o que é o Fzf

2. Por que integrar Fzf com Tmux

3. fzf-tmux: pop-ups nativos

4. Configurando pop-ups no ~/.tmux.conf

5. Casos de uso práticos

6. Plugins úteis: tmux-fzf

7. Conclusão

Fzf - o que é, como instalar e onde usar no dia a dia

1. O problema que o Fzf resolve

2. O que é o Fzf

3. Instalando o Fzf

4. Integração com o shell: os três atalhos essenciais

5. Usos no dia a dia

6. Customizando o Fzf: comando padrão e preview

7. Conclusão e próximos passos

Docker avançado - multi-stage builds, segurança e CI/CD

1. Retomando: da aplicação funcionando ao container pronto para produção

2. O problema que multi-stage builds resolve

3. Multi-stage com linguagens compiladas

4. Segurança: nunca rodar como root

5. Scan de vulnerabilidades

6. Docker em pipelines de CI/CD

7. Conclusão da série

Docker Compose - orquestrando múltiplos containers

1. Retomando: do docker run repetido a um arquivo único

2. O arquivo compose.yaml

3. Comandos essenciais do Compose

4. depends_on: ordem de início, não prontidão

5. Variáveis de ambiente e o arquivo .env

6. Um ambiente completo: app + banco + cache

7. Escalando um serviço

8. Conclusão e próximos passos

Docker - redes e volumes na prática

1. Retomando: de imagens bem construídas a containers que conversam entre si

2. O problema do isolamento de rede por padrão

3. Redes definidas pelo usuário (User-Defined Networks)

4. Os drivers de rede mais comuns

5. Volumes: persistindo dados além da vida do container

6. Volumes nomeados vs bind mounts

7. Um cenário completo: API + banco comunicando-se com dados persistentes

8. Conclusão e próximos passos

Dockerfile na prática - camadas, cache de build e boas práticas

1. Retomando: do Dockerfile mínimo a um Dockerfile de verdade

2. Como funcionam as camadas (layers)

3. Cache de build: ordenar o Dockerfile por frequência de mudança

4. Minimizando o número e o tamanho das camadas

5. Escolhendo a imagem base certa

6. .dockerignore: cortando o que não deveria nem chegar ao build

7. Conclusão e próximos passos

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

4. Configurando pop-ups no `~/.tmux.conf`

1. Retomando: do `docker run` repetido a um arquivo único

2. O arquivo `compose.yaml`

4. `depends_on`: ordem de início, não prontidão

5. Variáveis de ambiente e o arquivo `.env`

6. `.dockerignore`: cortando o que não deveria nem chegar ao build

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