Instalar Docker no Ubuntu com segurança

Para instalar Docker no Ubuntu com segurança, use uma versão suportada, configure o repositório apt oficial e instale Engine, CLI, containerd e o plugin Compose. Verifique tudo com sudo. Trate pacotes conflitantes, grupo docker, firewall, atualização e remoção como decisões separadas, nunca como atalhos automáticos.

Antes de instalar, confirme sistema e arquitetura

O repositório oficial aceita Ubuntu 26.04 LTS, 25.10, 24.04 LTS e 22.04 LTS em 64 bits na data desta revisão. Versão aceita não é recomendação de vida útil. A Canonical orienta usar LTS em produção; versões intermediárias recebem apenas nove meses de atualizações.

Para uma máquina nova, prefira 26.04 LTS ou 24.04 LTS. O 22.04 LTS ainda tem manutenção padrão até maio de 2027, mas seu horizonte já é curto para um projeto que começa agora. Confira a máquina real, não apenas o nome da imagem escolhido no painel do provedor:

. /etc/os-release
printf 'Sistema: %s %s\nCodename: %s\nArquitetura: ' "$NAME" "$VERSION_ID" "${UBUNTU_CODENAME:-$VERSION_CODENAME}"
dpkg --print-architecture

Pare se o sistema for derivado de Ubuntu, estiver fora da lista oficial ou usar uma arquitetura que sua aplicação não suporta. Linux Mint e outras derivações podem funcionar, mas não estão dentro da garantia documental desse procedimento.

Em um VPS da DigitalOcean, Hetzner, OVHcloud ou Vultr, confirme também se existe console de recuperação. Uma instalação de pacotes raramente derruba SSH, mas contar com raramente não é um plano de retorno.

Pacotes conflitantes exigem inventário, não remoção cega

O Ubuntu oferece pacotes como docker.io e containerd. O repositório do Docker fornece docker-ce e seu próprio containerd.io. Misturar essas origens pode criar conflitos de dependência e versões.

Inventário vem antes da remoção. Primeiro veja o que está instalado:

dpkg --get-selections docker.io docker-compose docker-compose-v2 docker-doc podman-docker containerd runc 2>/dev/null
sudo systemctl --no-pager --type=service --state=running | grep -E 'docker|containerd|podman' || true

Se houver um Docker funcional, registre contêineres, imagens, volumes e arquivos Compose antes de tocar nos pacotes. Faça backup dos dados com o procedimento da aplicação e teste a restauração. A pasta do Docker continuar no disco não prova que uma troca de runtime será compatível.

Somente depois do inventário, e apenas se a decisão for substituir os pacotes da distribuição pelos oficiais, remova os conflitos listados pela documentação:

sudo apt remove docker.io docker-compose docker-compose-v2 docker-doc podman-docker containerd runc

Leia o resumo do apt antes de confirmar. O comando remove pacotes e dependências resolvidas pelo gerenciador; ele não é uma promessa de preservar um serviço em execução. Não use purge nem autoremove nesta etapa. Imagens, contêineres, volumes e redes em /var/lib/docker não são apagados automaticamente, mas isso tampouco os transforma em backup.

Configure a chave e o repositório apt oficial

Atualize o índice, instale os utilitários mínimos e grave a chave em um keyring dedicado:

sudo apt update
sudo apt install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

Aqui curl baixa apenas a chave pública para um caminho explícito. Ele não entrega o conteúdo direto a um shell com privilégios. O instalador de conveniência do Docker é útil em testes, mas a própria documentação não o recomenda como caminho principal de produção.

Crie a fonte deb822 usando o codename informado pelo próprio sistema:

sudo tee /etc/apt/sources.list.d/docker.sources >/dev/null <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF

sudo apt update
apt-cache policy docker-ce | sed -n '1,20p'

Falha de assinatura é uma parada, não um aviso decorativo. Pare se apt update acusar assinatura inválida, repositório sem Release ou codename inexistente. Não marque o repositório como confiável para silenciar a falha. Corrija relógio, versão, proxy ou arquivo de origem antes de continuar.

Instale Engine, CLI, containerd, Buildx e Compose

O conjunto oficial separa o daemon, o cliente, o runtime e os plugins:

sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Registre o que entrou na máquina. Confira a lista e a origem dos pacotes na tela do apt. Em automação, fixe versões testadas; em uma sessão manual, ao menos registre o que foi instalado:

dpkg-query -W -f='${Package}\t${Version}\n' \
  docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Não instale o binário antigo docker-compose separadamente. O pacote docker-compose-plugin fornece o subcomando atual docker compose, com espaço.

Verifique serviço, cliente e execução real

No Ubuntu, o serviço costuma iniciar durante a instalação. Confirme sem depender dessa expectativa:

sudo systemctl status docker --no-pager
sudo docker version
sudo docker compose version
sudo docker run --rm hello-world

O status comprova que a unidade está ativa; docker version verifica a conversa entre cliente e daemon; docker compose version confirma o plugin; hello-world testa download, criação e execução de um contêiner. hello-world não certifica produção. Nenhum desses passos valida backup, firewall, DNS ou a sua aplicação.

Se o serviço não estiver ativo, leia o log antes de reiniciar repetidamente:

sudo journalctl -u docker --since '-15 minutes' --no-pager

Erros sobre armazenamento, iptables, configuração do daemon ou containerd precisam ser entendidos. Reiniciar até funcionar esconde a primeira causa e costuma alongar a indisponibilidade.

Use sudo por padrão; grupo docker equivale a root

O daemon roda com privilégios e expõe um socket Unix. Por padrão, outros usuários acessam esse socket por sudo. Isso deixa a elevação visível no histórico e sujeita à política de sudo da máquina.

Grupo docker não é acesso limitado. A documentação alerta que esse grupo concede privilégios de nível root: quem controla o daemon pode montar diretórios do host e iniciar contêineres com acesso amplo.

Mantenha sudo, especialmente em servidor compartilhado. Se uma equipe decidir conscientemente aceitar o risco, a alteração é:

sudo usermod -aG docker "$USER"

É necessário sair e entrar novamente para recarregar os grupos. Registre quem recebeu acesso e revise essa lista. Para uma fronteira realmente sem root, avalie o modo rootless como outro desenho operacional; ele não é consequência automática de entrar no grupo docker.

Portas publicadas podem contornar o UFW

UFW não garante o bloqueio de uma porta publicada. Ao publicar uma porta, o Docker cria regras para encaminhar o tráfego ao contêiner. Segundo a documentação oficial, esse tráfego pode ser desviado na tabela nat antes das cadeias usadas pelo UFW. Uma regra deny no UFW não garante que a porta publicada esteja fechada.

Veja os listeners do host e as portas que o Docker publicou:

sudo ss -lntup
sudo docker ps --format 'table {{.Names}}\t{{.Ports}}'
sudo ufw status verbose

Quando um serviço só precisa atender ao proxy local, limite o bind no Compose ou em docker run. Por exemplo, 127.0.0.1:8080:80 publica a porta apenas no loopback, enquanto 8080:80 normalmente a expõe em todos os endereços do host.

Para acesso externo, combine bind deliberado, firewall do provedor e política na cadeia DOCKER-USER quando usar o backend compatível. Não desligue a manipulação de iptables do Docker como correção rápida: a própria documentação avisa que isso tende a quebrar a rede dos contêineres.

Antes de publicar, faça três perguntas:

• o serviço precisa ser alcançado pela internet ou apenas por outro processo local;
• o bind está limitado ao endereço correto;
• o acesso foi testado de uma rede externa, e não somente de dentro do VPS.

Atualize com versão conhecida e janela de retorno

Liste versões disponíveis antes de mudar o daemon:

apt list --all-versions docker-ce
apt list --all-versions docker-ce-cli

Antes de atualizar, registre a versão atual, confira notas de versão, faça backup dos dados e verifique se a aplicação tolera reinício. Instale Engine e CLI na mesma versão escolhida:

VERSION_STRING='substitua-pela-versao-exata-listada-pelo-apt'
sudo apt install docker-ce="$VERSION_STRING" docker-ce-cli="$VERSION_STRING" \
  containerd.io docker-buildx-plugin docker-compose-plugin

Downgrade de pacote não é rollback comprovado. O mesmo mecanismo consegue selecionar uma versão anterior disponível, mas estado interno, rede, plugins e imagens podem não ser retrocompatíveis. O retorno confiável parte de snapshot ou backup testado e de uma janela em que a versão anterior foi validada.

Depois da mudança, repita as quatro verificações e teste a aplicação de fora do servidor. Um contêiner em estado running ainda pode responder errado ou não alcançar o banco.

Remova pacotes sem confundir isso com apagar dados

Para retirar os componentes oficiais, a documentação usa:

sudo apt purge docker-ce docker-ce-cli containerd.io docker-buildx-plugin \
  docker-compose-plugin docker-ce-rootless-extras

Pacote removido não significa dado apagado. O purge remove pacotes e suas configurações gerenciadas, mas não apaga automaticamente imagens, contêineres, volumes nem toda configuração personalizada. Os dados podem continuar em /var/lib/docker e /var/lib/containerd. Isso é uma fronteira de segurança contra exclusão acidental, não um plano de retenção.

Não incluo um comando recursivo de exclusão porque ele é irreversível. Se a intenção for desativar a máquina, primeiro exporte o que precisa permanecer, valide a restauração em outro host, confirme os mounts fora dessas pastas e só então aprove uma limpeza com caminho e escopo revisados por outra pessoa.

Instalação concluída é o começo da operação

Docker fica pronto quando o repositório é verificável, os pacotes têm origem e versão conhecidas, o serviço responde e um contêiner executa. O servidor fica pronto quando acesso, portas, dados, logs, atualização e recuperação também têm responsáveis. A diferença aparece justamente no dia em que algo falha.