Gerador de Comando docker run

docker run em profundidade: flags, rede, volumes e limites de recursos

O docker run é o cavalo de batalha de todo workflow de containers — cria um container novo a partir de uma imagem e o inicia em uma única chamada. Por baixo dos panos é a composição de docker create + docker start, aplicando dezenas de opções de namespaces, cgroups e seccomp, montando volumes, ligando redes e expondo portas. A forma geral é docker run [OPTIONS] IMAGE [COMMAND] [ARG...], e mesmo que a maioria dos containers em produção sejam disparados por Compose, Kubernetes ou Nomad, a primitiva que cada orquestrador embrulha por baixo é sempre essa.

Ciclo de vida e flags de processo

• -d — detach: roda em background e imprime o ID do container.
• -i — interactive: mantém STDIN aberto mesmo sem attach.
• -t — aloca um TTY (pseudo-terminal).
• -it — combo canônico para shell interativo: docker run -it alpine sh.
• --rm — remove o container automaticamente ao sair (ideal para ferramentas one-shot).
• --name web — atribui um nome estável no lugar do adjetivo_substantivo aleatório.
• --restart unless-stopped — políticas: no (padrão), always, unless-stopped, on-failure[:N].

Portas, volumes, variáveis e redes

É aqui que mora a fiação de verdade:

-p 8080:80           publica a :80 do container na :8080 do host
-p 127.0.0.1:8080:80 só no localhost (não expõe publicamente)
-P                   publica todas as portas EXPOSE em portas aleatórias do host
-v /host:/container  bind mount de um caminho do host
-v data:/var/lib/db  volume nomeado (portável, gerenciado pelo Docker)
--mount type=bind,...  sintaxe moderna, mais explícita
-e CHAVE=valor       define uma env var
--env-file .env      carrega um arquivo inteiro de CHAVE=valor
--network host       compartilha o namespace de rede do host (só Linux)
--network app-net    entra em uma bridge user-defined (DNS entre containers)

Volumes nomeados são quase sempre preferíveis a bind mounts: sobrevivem à remoção do container, são gerenciados pelo Docker e fáceis de fazer backup. Bind mounts fazem sentido em desenvolvimento local quando você quer hot reload do código.

Limites de recursos e segurança

• --memory 512m --memory-swap 512m — teto rígido de RAM, sem swap.
• --cpus 1.5 — fração de CPU (tempo equivalente a 1,5 cores).
• --pids-limit 200 — defesa contra fork bombs.
• -u 1000:1000 — roda como UID/GID não-root dentro do container.
• -w /app — define o working directory.
• --read-only — root filesystem somente leitura (combine com --tmpfs /tmp).
• --cap-drop ALL --cap-add NET_BIND_SERVICE — derruba toda capability do Linux e adiciona só o necessário.
• --security-opt no-new-privileges — bloqueia escalada por setuid.
• --gpus all — expõe GPUs NVIDIA (requer nvidia-container-toolkit).
• --privileged — dá ao container acesso quase total ao host; evite, a menos que seja Docker-in-Docker ou um serviço de sistema que realmente precise.

Exemplos comentados e comandos relacionados

# Shell interativo rápido, com limpeza automática
docker run --rm -it alpine sh

# Nginx na porta 8080 do host, nomeado, com auto-restart
docker run -d --name web --restart unless-stopped \
  -p 8080:80 nginx:1.27-alpine

# Postgres com volume nomeado, limites e segredos via env-file
docker run -d --name pg \
  -v pgdata:/var/lib/postgresql/data \
  --env-file ./pg.env \
  --memory 1g --cpus 1 \
  -p 5432:5432 postgres:16

# Entrar em um container rodando
docker exec -it web sh

# Acompanhar logs, parar, remover
docker logs -f web
docker stop web && docker rm web

Boas práticas e alternativas

Fixe a tag da imagem — :latest é convenção, não contrato, e um upgrade silencioso pode quebrar produção da noite para o dia. Sempre defina --memory e --cpus: um container sem limites pode sufocar todos os vizinhos no host. Evite --privileged; se precisa de uma capability, adicione com --cap-add. Inclua um HEALTHCHECK no Dockerfile (ou --health-cmd em runtime) para que orquestradores detectem processos zumbis.

Para apps multi-container use docker compose up em vez de costurar docker run — o Compose v2 já vem como plugin nativo do Docker. Podman é alternativa compatível drop-in que roda rootless por padrão; nerdctl é o CLI nativo do containerd; para orquestração em produção você acaba caindo em Kubernetes ou Nomad.

FAQ

Qual a diferença entre docker stop e docker kill? O stop manda SIGTERM, espera dez segundos (ajustável com -t) e depois SIGKILL. O kill vai direto no SIGKILL. Prefira sempre stop para o processo conseguir fechar limpo.

O container morre quando o processo principal sai? Sim — o container vive enquanto o PID 1 viver. Se o PID 1 sair para background, o container morre imediatamente. Use um entrypoint em foreground ou um init como tini (já embutido via --init).

Volume nomeado ou bind mount? Volume nomeado para estado que você quer que o Docker gerencie e faça backup (bancos, dados de app). Bind mount para código-fonte em desenvolvimento e arquivos de configuração que você edita no host.

Como ter aceleração de GPU? Instale o nvidia-container-toolkit no host e passe --gpus all (ou --gpus '"device=0,1"' para placas específicas). Verifique com docker run --gpus all nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi.

Preciso rebuildar a imagem depois de mudar o código? Sim para imagens de produção — docker build -t app:v2 . e depois docker run app:v2. Em desenvolvimento, bind-monte o código com -v $(pwd):/app para o container rodando refletir as edições ao vivo.