Docker na Prática 2026: Guia para Devs

Você já percebeu que quase toda vaga de dev pede Docker, mas quando chega a entrevista dá aquele medo de descobrirem que você só rodou docker compose up seguindo tutorial? Relaxa. Muita gente está nessa, inclusive devs bons, porque Docker parece simples por fora, mas vira um labirinto quando entra em imagem, volume, rede, cache, CI/CD e produção.

Docker na Prática 2026: Guia para Devs#

Docker continua sendo uma das habilidades mais úteis para quem quer crescer como dev em 2026.

Não porque “todo mundo usa”, mas porque ele resolve problemas bem reais: ambiente quebrado, dependência diferente entre máquinas, deploy sofrido, testes que só passam no notebook de uma pessoa e onboarding que leva dias.

Se você está mirando vagas em empresas como Itaú, Nubank, Stone, iFood, Magalu ou Globo, Docker aparece com frequência em descrições de vagas para backend, full stack, plataforma, DevOps, dados e QA automation.

E sim, ele pode impactar salário.

Uma pessoa backend pleno que entende Docker, CI/CD e cloud pode ver vagas entre R$ 9k e R$ 15k no Brasil. Em posições sênior, especialmente com Kubernetes, AWS ou GCP, não é raro encontrar faixas de R$ 18k a R$ 28k. Para remoto internacional, vagas em USD podem pagar $60k a $120k por ano, dependendo do nível e do inglês.

A ideia aqui é te dar um guia prático, com foco em carreira, entrevista e uso real no dia a dia.

Sem papo bonito demais. Vamos direto ao que você precisa saber.

O que é Docker, explicado sem enrolação#

Docker é uma forma de empacotar sua aplicação com tudo que ela precisa para rodar.

Você coloca código, runtime, dependências, variáveis, configurações e comandos dentro de uma imagem. Depois, executa essa imagem como um container.

Pensa assim:

• Imagem: a receita pronta da aplicação.
• Container: a aplicação rodando a partir dessa receita.
• Dockerfile: o arquivo que ensina como criar a imagem.
• Docker Compose: o arquivo que sobe vários serviços juntos, como app, banco e cache.
• Volume: uma forma de persistir dados fora do container.
• Network: a rede interna para containers conversarem.

O ponto que pega muita gente é este: container não é uma máquina virtual tradicional.

Ele é mais leve, sobe rápido e compartilha o kernel do sistema operacional. Por isso Docker virou padrão em muitos times, principalmente onde deploy e escala importam.

Por que empresas cobram Docker em vagas?

Porque Docker reduz aquela frase clássica: “na minha máquina funciona”.

Em empresas grandes, você pode ter dezenas ou centenas de devs mexendo no mesmo sistema. Se cada um instala Node, Java, Python, Postgres e Redis de um jeito, o caos chega rápido.

Com Docker, o time consegue:

1. Padronizar ambiente local.
2. Rodar testes com mais previsibilidade.
3. Criar pipelines de CI/CD.
4. Fazer deploy com menos surpresa.
5. Documentar dependências de forma clara.
6. Facilitar onboarding de novas pessoas.

Imagine entrar no iFood como backend e precisar rodar 8 serviços locais. Sem Docker, você talvez perca dois dias instalando coisa. Com Docker Compose bem feito, você roda um comando e começa a trabalhar.

Isso tem valor real para o negócio.

O mínimo de Docker que você precisa saber para entrevistas#

Você não precisa decorar todos os comandos do Docker para passar em entrevista. Mas precisa mostrar que entende os conceitos e sabe usar no fluxo real de desenvolvimento.

Se você souber explicar bem os pontos abaixo, já fica na frente de muita gente.

1. Diferença entre imagem e container

Essa é pergunta básica, mas derruba candidato.

Uma imagem é imutável, como um pacote com tudo que a aplicação precisa. Um container é uma instância em execução dessa imagem.

Exemplo simples:

docker build -t minha-api .
docker run -p 3000:3000 minha-api

No primeiro comando, você cria a imagem. No segundo, você cria e executa um container.

Se você rodar o segundo comando várias vezes, pode ter vários containers baseados na mesma imagem.

2. Para que serve o Dockerfile

O Dockerfile descreve como montar sua imagem.

Exemplo para uma aplicação Node.js:

FROM node:20-alpine

WORKDIR /app

COPY package*.json ./
RUN npm ci

COPY . .

EXPOSE 3000

CMD ["npm", "start"]

O que acontece aqui:

• Usa uma imagem base do Node.
• Define /app como pasta de trabalho.
• Copia os arquivos de dependência.
• Instala dependências.
• Copia o restante do projeto.
• Expõe a porta 3000.
• Define o comando para iniciar.

Na entrevista, vale comentar sobre cache.

Copiar primeiro package*.json e só depois o restante do código ajuda o Docker a reaproveitar camadas. Assim, se você muda só um arquivo da aplicação, ele não precisa reinstalar todas as dependências.

Isso mostra maturidade.

3. Para que serve o Docker Compose

Docker Compose ajuda a subir múltiplos containers com um arquivo docker-compose.yml.

Exemplo com app e Postgres:

services:
  app:
    build: .
    ports:
      - "3000:3000"
    environment:
      DATABASE_URL: postgres://user:pass@db:5432/appdb
    depends_on:
      - db

  db:
    image: postgres:16
    environment:
      POSTGRES_USER: user
      POSTGRES_PASSWORD: pass
      POSTGRES_DB: appdb
    ports:
      - "5432:5432"
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:

Com isso, você roda:

docker compose up

E sobe app mais banco.

Esse é o tipo de coisa que você pode colocar no GitHub para mostrar serviço.

4. Volumes e persistência

Container pode ser apagado a qualquer momento. Se você guardar dados só dentro dele, perde tudo quando remover.

Volume resolve isso.

No exemplo anterior:

volumes:
  - pgdata:/var/lib/postgresql/data

O volume pgdata guarda os dados do Postgres fora do ciclo de vida do container.

Em entrevista, você pode dizer:

“Eu uso volumes quando preciso persistir dados, como banco local, uploads ou cache entre execuções. Para código em desenvolvimento, também posso usar bind mount.”

Boa resposta, simples e prática.

5. Redes entre containers

Dentro do Docker Compose, os serviços se comunicam pelo nome.

Então sua aplicação acessa o Postgres em db, não em localhost.

Isso é uma pegadinha comum.

Dentro do container da aplicação, localhost é o próprio container da aplicação. Para falar com outro container, use o nome do serviço.

Exemplo:

DATABASE_HOST=db

Saber isso evita muita dor de cabeça.

Docker na rotina de um dev em 2026#

A melhor forma de aprender Docker é usar em um projeto real.

Não precisa inventar um sistema gigante. Pode ser uma API com autenticação, banco, cache e testes. O importante é simular um ambiente que pareça com trabalho de verdade.

Um projeto bom para portfólio

Se você quer chamar atenção em vagas, crie algo como:

API de controle financeiro pessoal, com:

• Node.js, Java, Python ou Go.
• PostgreSQL.
• Redis para cache.
• Dockerfile.
• Docker Compose.
• Testes automatizados.
• README explicando como rodar.
• Pipeline no GitHub Actions.
• Variáveis de ambiente com .env.example.

Isso já te dá assunto para entrevista.

Você pode dizer:

“Eu criei uma API com Postgres e Redis usando Docker Compose para facilitar o ambiente local. Também configurei o Dockerfile com cache de dependências e um workflow de CI para rodar testes a cada pull request.”

Isso soa muito melhor do que “sei Docker básico”.

Como escrever um README que vende sua habilidade

Muita gente faz projeto bom e estraga no README.

Um recrutador técnico ou tech lead pode entrar no seu GitHub e decidir em 40 segundos se vale chamar você para conversa.

Use algo assim:

## Como rodar com Docker

1. Copie as variáveis de ambiente:

cp .env.example .env

2. Suba os containers:

docker compose up --build

3. Rode as migrações:

docker compose exec app npm run migrate

4. Execute os testes:

docker compose exec app npm test

Depois explique:

• Quais serviços existem.
• Quais portas são usadas.
• Como resetar o banco.
• Como rodar testes.
• Como gerar build de produção.

Isso mostra que você pensa em quem vai usar o projeto.

E isso é exatamente o que empresas valorizam.

Comandos Docker que você deve saber de cabeça#

Você não precisa decorar tudo, mas alguns comandos são do dia a dia.

Para imagens

docker build -t nome-da-imagem .
docker images
docker rmi nome-da-imagem

Use para criar, listar e remover imagens.

Para containers

docker ps
docker ps -a
docker run nome-da-imagem
docker stop id-ou-nome
docker rm id-ou-nome
docker logs id-ou-nome
docker exec -it id-ou-nome sh

Esses comandos aparecem o tempo todo.

O docker exec é especialmente útil para entrar no container e investigar problema.

Para Compose

docker compose up
docker compose up --build
docker compose down
docker compose logs -f
docker compose exec app sh

Uma dica: quando algo estranho acontece, rode:

docker compose down -v

Isso remove containers, redes e volumes.

Cuidado, porque apaga dados persistidos em volumes daquele Compose. Em ambiente local pode ser útil para resetar tudo.

Para limpeza

docker system prune
docker volume prune

Esses comandos limpam recursos não usados.

Use com atenção. Em notebook com pouco espaço, Docker pode comer dezenas de GB sem você perceber.

Erros comuns que fazem você parecer iniciante#

Alguns erros são normais enquanto aprende. O problema é levar esses erros para produção ou entrevista sem perceber.

Usar imagem pesada sem necessidade

Exemplo ruim:

FROM node:20

Pode funcionar, mas muitas vezes você pode usar:

FROM node:20-alpine

Imagens menores baixam mais rápido e reduzem superfície de ataque.

Nem sempre Alpine é a melhor escolha, porque algumas libs nativas podem dar trabalho. Mas saber discutir esse trade-off é sinal de maturidade.

Rodar aplicação como root

Muitos Dockerfiles deixam a aplicação rodando como root dentro do container.

Em produção, isso pode ser um risco.

Em Node, por exemplo, você pode usar usuário não root:

FROM node:20-alpine

WORKDIR /app

COPY package*.json ./
RUN npm ci --omit=dev

COPY . .

USER node

CMD ["npm", "start"]

Dependendo da estrutura, talvez precise ajustar permissões antes.

Você não precisa virar especialista em segurança para vaga dev, mas precisa saber que existe esse cuidado.

Colocar segredo dentro da imagem

Nunca coloque senha, token ou chave dentro do Dockerfile.

Errado:

ENV API_KEY=minha-chave-secreta

Prefira passar por variável de ambiente no runtime, secret manager ou configuração da plataforma.

Empresas como Nubank, Itaú e Stone levam segurança muito a sério. Falar que você evita segredos em imagem conta ponto.

Ignorar .dockerignore

Sem .dockerignore, você pode mandar arquivos desnecessários para o build.

Exemplo:

node_modules
.git
.env
coverage
dist
README.md

Isso acelera build e evita vazar arquivo sensível.

É um detalhe pequeno que passa impressão boa.

Não diferenciar desenvolvimento e produção

Em desenvolvimento, você quer hot reload e bind mount.

Em produção, você quer imagem limpa, menor, previsível e sem dependências desnecessárias.

Um Compose de desenvolvimento pode ter:

volumes:
  - .:/app

Mas em produção isso geralmente não faz sentido.

Se a entrevista tocar nesse ponto, diga que você separa configs por ambiente e evita levar atalhos de dev para prod.

Docker e salário: onde isso entra na sua carreira#

Docker sozinho talvez não dobre seu salário. Mas Docker combinado com backend, cloud, CI/CD e observabilidade aumenta muito sua empregabilidade.

Uma vaga backend pleno em São Paulo pode pedir:

• Java ou Node.js.
• Docker.
• AWS.
• Testes automatizados.
• Banco relacional.
• Mensageria com Kafka ou RabbitMQ.
• Experiência com CI/CD.

Se você só sabe a linguagem, concorre com muita gente.

Se você sabe entregar uma aplicação empacotada, testada e pronta para deploy, você conversa em outro nível.

Exemplos de faixas salariais realistas

No Brasil, em 2026, você pode encontrar algo próximo de:

• Dev júnior com Docker básico: R$ 4k a R$ 7k.
• Dev pleno backend/full stack: R$ 8k a R$ 15k.
• Dev sênior com cloud e containers: R$ 16k a R$ 28k.
• Platform engineer ou DevOps sênior: R$ 20k a R$ 35k.
• Remoto internacional pleno/sênior: $60k a $130k por ano.

Claro que varia por empresa, inglês, cidade, stack e negociação.

Mas uma coisa é certa: Docker ajuda você a sair do “só codar feature” e entrar no grupo de devs que entendem entrega.

Isso pesa em promoção.

Docker em CI/CD: o que você precisa entender#

Em muitas empresas, Docker aparece no pipeline.

Você faz push no GitHub, GitLab ou Bitbucket. O pipeline roda testes, cria imagem, envia para um registry e dispara deploy.

Um fluxo típico:

1. Dev abre pull request.
2. Pipeline roda lint e testes.
3. Merge na branch principal.
4. Pipeline faz build da imagem.
5. Imagem é enviada para registry.
6. Ambiente de staging recebe a nova versão.
7. Depois vai para produção.

Registries comuns:

• Docker Hub.
• GitHub Container Registry.
• AWS ECR.
• Google Artifact Registry.
• Azure Container Registry.

Se você entende esse ciclo, consegue conversar melhor com times de plataforma e DevOps.

Exemplo de GitHub Actions simples

name: CI

on:
  pull_request:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest

    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_USER: user
          POSTGRES_PASSWORD: pass
          POSTGRES_DB: appdb
        ports:
          - 5432:5432

    steps:
      - uses: actions/checkout@v4

      - name: Build app
        run: docker build -t minha-api .

      - name: Run tests
        run: docker run --network host minha-api npm test

Esse exemplo é simples e talvez precise ajustes no seu projeto, mas já mostra o conceito.

Para portfólio, é excelente.

Docker e Kubernetes: preciso aprender os dois?#

Depende do seu objetivo.

Para a maioria das vagas dev júnior e pleno, Docker é mais importante no começo. Kubernetes costuma aparecer mais em vagas sênior, plataforma, SRE ou DevOps.

Mas entender a relação ajuda:

• Docker empacota e roda containers.
• Kubernetes orquestra containers em escala.

Ou seja, Docker resolve “como minha aplicação vira container”. Kubernetes resolve “como eu rodo muitos containers em cluster, com escala, rede, deploy e recuperação”.

Se você está começando, siga esta ordem:

1. Docker básico.
2. Docker Compose.
3. Dockerfile bem feito.
4. CI/CD com imagem.
5. Conceitos básicos de Kubernetes.
6. Deploy simples em cloud.

Não pule direto para Kubernetes sem saber montar uma imagem decente.

É como querer correr maratona sem conseguir correr 5 km.

Como estudar Docker em 30 dias#

Se você quer sair do zero e chegar num nível bom para entrevistas, dá para fazer um plano simples.

Semana 1: fundamentos

Aprenda:

• O que é imagem.
• O que é container.
• Como usar docker run.
• Como ver logs.
• Como entrar no container.
• Como expor porta.

Prática:

• Rode Nginx.
• Rode Postgres.
• Rode Redis.
• Rode uma API simples.

Meta: entender o ciclo básico.

Semana 2: Dockerfile

Aprenda:

• FROM.
• WORKDIR.
• COPY.
• RUN.
• CMD.
• EXPOSE.
• Cache de camadas.
• .dockerignore.

Prática:

• Crie Dockerfile para uma API.
• Reduza tamanho da imagem.
• Remova dependências desnecessárias.
• Teste build local.

Meta: conseguir empacotar sua aplicação sozinho.

Semana 3: Docker Compose

Aprenda:

• Services.
• Ports.
• Environment.
• Volumes.
• Networks.
• depends_on.

Prática:

• Suba app + Postgres.
• Adicione Redis.
• Rode migrations.
• Rode testes dentro do container.

Meta: criar ambiente local completo.

Semana 4: carreira e entrega

Aprenda:

• CI/CD básico.
• Registry.
• Variáveis por ambiente.
• Boas práticas de segurança.
• Como explicar Docker em entrevista.

Prática:

• Publique projeto no GitHub.
• Escreva README bom.
• Configure GitHub Actions.
• Grave um vídeo curto mostrando o projeto, se quiser.

Meta: transformar estudo em evidência para vaga.

Perguntas comuns de entrevista sobre Docker#

Aqui vão perguntas que podem aparecer em entrevistas técnicas.

“Qual a diferença entre container e máquina virtual?”

Container compartilha o kernel do host e costuma ser mais leve. Máquina virtual emula um sistema operacional completo, com mais isolamento e maior consumo de recursos.

Docker é ótimo para empacotar e rodar aplicações de forma consistente.

“Por que usar Docker no desenvolvimento?”

Para padronizar ambiente, reduzir problemas de instalação, facilitar onboarding e aproximar desenvolvimento do ambiente de produção.

Também ajuda a rodar bancos, filas e caches sem instalar tudo direto na máquina.

“O que é um volume?”

É um recurso para persistir dados fora do container.

Se o container for removido, o volume pode continuar existindo.

“Como containers se comunicam no Docker Compose?”

Pelo nome do serviço na rede criada pelo Compose.

Se o serviço do banco chama db, a aplicação acessa db:5432.

“O que você faria para reduzir o tamanho de uma imagem?”

Eu analisaria a imagem base, usaria .dockerignore, evitaria copiar arquivos desnecessários, instalaria só dependências necessárias e consideraria multi-stage build quando fizer sentido.

“O que é multi-stage build?”

É uma técnica para usar múltiplas etapas no Dockerfile.

Você pode compilar a aplicação em uma etapa e copiar só o resultado final para uma imagem menor.

Exemplo com Go:

FROM golang:1.22 AS builder

WORKDIR /app
COPY . .
RUN go build -o server .

FROM alpine:3.20

WORKDIR /app
COPY --from=builder /app/server .

CMD ["./server"]

A imagem final não precisa ter o compilador Go inteiro.

Isso reduz tamanho e melhora a distribuição.

Como colocar Docker no currículo sem parecer genérico#

Não escreva apenas:

• “Conhecimento em Docker”
• “Docker básico”
• “Experiência com containers”

Isso diz pouco.

Prefira frases com contexto e impacto:

• “Containerização de APIs Node.js com Docker e Docker Compose, incluindo Postgres e Redis para ambiente local.”
• “Criação de Dockerfiles com otimização de cache, .dockerignore e separação entre ambiente de desenvolvimento e produção.”
• “Configuração de pipeline CI com build de imagem Docker e execução de testes automatizados.”
• “Padronização de ambiente local para reduzir erros de setup em time de desenvolvimento.”

Se você trabalhou em empresa, melhor ainda:

• “Ajudei a reduzir o tempo de setup local de 1 dia para menos de 30 minutos usando Docker Compose.”

Número chama atenção.

Mesmo que seja projeto pessoal, você pode escrever:

• “Projeto pessoal com API REST, PostgreSQL, Redis, Docker Compose e CI no GitHub Actions.”

Isso já melhora bastante seu currículo.

Como falar de Docker em entrevista sem exagerar#

Você não precisa fingir que é especialista.

Na verdade, entrevistador bom percebe rápido quando alguém floreia demais.

Você pode dizer algo como:

“Eu uso Docker principalmente para padronizar ambiente de desenvolvimento e empacotar aplicações. Já criei Dockerfiles para APIs, usei Compose para subir app com Postgres e Redis, configurei volumes para persistência local e entendo o fluxo básico de build de imagem em CI. Ainda estou aprofundando Kubernetes, mas já entendo como Docker entra no processo de entrega.”

Isso é honesto e forte.

Se a vaga for sênior, aí esperam mais profundidade em produção, segurança, observabilidade, deploy, registry e talvez Kubernetes.

Mas para júnior e pleno, essa resposta já passa segurança.

Checklist prático para você aplicar hoje#

Se você quer sair deste artigo com ação concreta, faça isso:

1. Pegue um projeto seu.
2. Crie um Dockerfile.
3. Crie um .dockerignore.
4. Suba banco com Docker Compose.
5. Configure variáveis no .env.example.
6. Escreva comandos no README.
7. Rode testes dentro do container.
8. Coloque o projeto no GitHub.
9. Adicione uma linha boa no currículo.
10. Treine explicar o projeto em 60 segundos.

Essa sequência já te coloca na frente de muita gente que só assistiu aula.

Conclusão: Docker não é detalhe, é sinal de maturidade#

Docker virou parte do kit básico de dev profissional.

Não significa que você precisa saber tudo sobre infraestrutura. Mas significa que você precisa conseguir rodar, empacotar, testar e explicar sua aplicação sem depender de mágica.

Em 2026, empresas querem devs que entregam com menos atrito.

Se você mostra que sabe usar Docker no dia a dia, entende Compose, cuida de variáveis, evita segredos, escreve README bom e conecta isso com CI/CD, você passa uma mensagem clara: “eu não só escrevo código, eu ajudo esse código a chegar em produção”.

E isso vale dinheiro.

Pode ser a diferença entre uma vaga júnior de R$ 5k e uma pleno de R$ 11k. Ou entre ficar travado em entrevistas e começar a conversar com empresas maiores como Nubank, Itaú, Stone, Magalu, iFood e Globo.

Agora faz o próximo passo com carinho: ajuste seu currículo para mostrar essas habilidades do jeito certo.

Antes de se candidatar, teste se seu currículo passa pelos filtros automáticos de recrutamento. Use o verificador gratuito da JobRise aqui: https://jobrise.io/pt/free-ats-checker/