Quando começamos a usar Docker, é comum pensar nele como “uma ferramenta para rodar containers”. Isso não está errado, mas é uma visão superficial. Por trás de um simples docker run, existe uma arquitetura bem definida, com responsabilidades claras e um fluxo previsível.

Como o Docker funcionaFonte: ByteByteGo

Os três elementos básicos do Docker

Antes de falar de comandos, é importante entender os três pilares do Docker:

  • Docker Client
  • Docker Host
  • Docker Registry

Eles estão sempre envolvidos, direta ou indiretamente, sempre que você trabalha com Docker.

Docker Client: onde tudo começa

O Docker Client é a interface que você usa no dia a dia. Normalmente, é o terminal com comandos como:

docker build
docker pull
docker run
docker push

Um ponto importante:

  • o client não executa containers.

Ele apenas envia instruções para o Docker Daemon, usando uma API (geralmente via socket Unix ou HTTP).

Sempre que você roda um comando Docker, o fluxo é basicamente:

Cliente, fale com o daemon e peça para ele fazer isso por mim.

Docker Daemon: o cérebro da operação

O Docker Daemon (dockerd) é quem realmente faz o trabalho pesado. Ele roda no Docker Host e é responsável por:

  • Criar imagens
  • Baixar imagens
  • Criar containers
  • Iniciar e parar containers
  • Gerenciar redes e volumes

Na imagem, ele aparece como um bloco central conectando tudo: client, imagens, containers e registry. Isso não é à toa, nada acontece sem o daemon.

Docker Host: onde os containers vivem

O Docker Host é a máquina (local ou remota) onde o daemon está rodando. Pode ser:

  • Seu notebook
  • Um servidor
  • Uma VM na nuvem

É no host que ficam:

  • As imagens Docker
  • Os containers em execução
  • As redes
  • Os volumes

Quando um container é criado, ele não é uma VM. Ele é apenas um processo isolado, rodando no kernel do host, usando recursos como:

  • namespaces (isolamento)
  • cgroups (limites de CPU, memória, etc.)

Docker Registry: o repositório de imagens

O Docker Registry é onde as imagens ficam armazenadas. O mais famoso é o Docker Hub, mas o conceito é genérico.

Exemplos comuns:

  • Docker Hub
  • GitHub Container Registry
  • AWS ECR
  • GitLab Registry

Na imagem, você vê várias imagens conhecidas:

  • Ubuntu
  • Redis
  • Node.js
  • Nginx
  • Postgres
  • Prometheus

Essas imagens não “vivem” no host por padrão. Elas só aparecem localmente depois de um pull ou build.

O fluxo real dos comandos Docker

Agora vamos conectar tudo isso aos comandos mostrados na imagem.

docker build: criando uma imagem

Quando você executa:

docker build -t minha-imagem .

O que acontece:

  1. O Docker Client envia o comando para o daemon
  2. O Docker Daemon lê o Dockerfile
  3. Cada instrução gera uma layer
  4. A imagem final é armazenada localmente no Docker Host

Nada vai para o registry automaticamente. A imagem ainda é local.

docker pull: baixando uma imagem

Quando você executa:

docker pull nginx

O fluxo é:

  1. Client → Daemon
  2. Daemon verifica se a imagem já existe localmente
  3. Se não existir, ele busca no Docker Registry
  4. As layers são baixadas e salvas no host

Esse passo acontece automaticamente se você rodar um docker run sem ter a imagem local.

docker run: criando e iniciando um container

Esse é o comando mais importante para entender o Docker:

docker run nginx

Aqui o Docker faz várias coisas de uma vez:

  1. Verifica se a imagem existe localmente
    • Se não existir → faz pull
  2. Cria um container a partir da imagem
  3. Adiciona uma camada de escrita (RW layer)
  4. Configura rede, volumes e variáveis
  5. Inicia o processo principal do container

Ou seja:

Container é uma instância em execução de uma imagem.

Na imagem, isso aparece como vários containers rodando a partir das mesmas imagens.

docker push: enviando uma imagem para o registry

Quando você executa:

docker push minha-imagem

O fluxo é o inverso do pull:

  1. Client → Daemon
  2. Daemon pega a imagem local
  3. Envia as layers para o Docker Registry
  4. A imagem fica disponível para outros hosts

Isso é essencial para CI/CD e ambientes distribuídos.

Imagens x Containers: a distinção fundamental

Um erro comum de quem está começando é confundir os dois:

  • Imagem É um artefato imutável, um template

  • Container É a execução viva dessa imagem

Você pode:

  • Criar vários containers a partir da mesma imagem
  • Parar e remover containers sem afetar a imagem
  • Atualizar a imagem e recriar containers

A imagem deixa isso visualmente claro ao separar os blocos de Images e Containers.

Conclusão

O Docker funciona como um ecossistema bem organizado:

  • O Client apenas envia comandos
  • O Daemon orquestra tudo
  • O Host fornece recursos
  • O Registry armazena e distribui imagens

Entender esse fluxo muda completamente a forma como você usa Docker. Em vez de decorar comandos, você passa a prever o comportamento da ferramenta, o que é essencial para ambientes profissionais, debugging e arquitetura.