Instalar Docker num VPS Ubuntu 24.04/22.04: o método oficial

Antes de começar: um VPS KVM, um Ubuntu suportado e um utilizador com sudo

O Docker Engine não traz o seu próprio kernel. Cada contentor partilha o kernel do host e depende de namespaces do Linux, cgroups e netfilter, portanto o daemon precisa de um VPS onde o kernel seja seu. É isso que um VPS KVM (virtualização completa) oferece. Em planos baseados em contentores, construídos sobre OpenVZ ou LXC, o kernel pertence ao fornecedor e o Docker ou se recusa a arrancar ou só funciona se o host tiver ativado o nesting. Verifique antes de instalar seja o que for:

systemd-detect-virt                          # expect: kvm
. /etc/os-release && echo "$VERSION_CODENAME"   # noble (24.04) or jammy (22.04)
uname -m                                     # x86_64 or aarch64

O Docker publica pacotes para o Ubuntu 24.04 LTS (noble) e 22.04 LTS (jammy) de 64 bits, em x86_64 e arm64. Também precisa de um utilizador com direitos sudo; as secções sobre o grupo docker e o modo rootless abaixo pressupõem uma conta normal e não o root.

Instalar o Docker Engine a partir do repositório apt oficial

Há quatro formas comuns de instalar o Docker no Ubuntu, e só uma é o método que o Docker documenta e suporta para servidores:

Passo 1: remover pacotes em conflito

Se a imagem do VPS já contiver o docker.io do Ubuntu, um docker-compose antigo ou o podman-docker, remova-os para que as duas builds não disputem o /usr/bin/docker. Este ciclo vem da documentação do Docker e é inofensivo num sistema limpo; deixa o /var/lib/docker intacto:

for pkg in docker.io docker-doc docker-compose docker-compose-v2 podman-docker containerd runc; do
  sudo apt-get remove $pkg
done

Passo 2: adicionar a chave GPG e a fonte apt do Docker

A chave vai para /etc/apt/keyrings/ e é referenciada com signed-by=, o que a limita a este repositório em vez de a tornar globalmente confiável através do obsoleto apt-key. O codename é lido de /etc/os-release, por isso o mesmo bloco funciona no 24.04 e no 22.04:

sudo apt-get update
sudo apt-get install -y 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

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt-get update

Um erro de assinatura nesse último apt-get update significa quase sempre que o ficheiro da chave está ilegível; volte a executar a linha do chmod.

Passo 3: instalar o engine e os seus plugins

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

docker-ce é o daemon, docker-ce-cli o cliente, containerd.io o runtime por baixo, e os dois plugins fornecem o docker buildx e o docker compose. No Ubuntu, o script de pós-instalação do pacote arranca o docker.service imediatamente e ativa-o no arranque.

Passo 4: verificar com o hello-world

sudo docker run hello-world
docker --version
sudo docker info | head -n 20

hello-world é o teste definitivo: o cliente fala com o daemon, o daemon descarrega uma imagem minúscula do Docker Hub, cria um contentor, executa-o e devolve o resultado. Se vir "Hello from Docker!", todas as camadas funcionam. Numa instalação saudável de 24.04 ou 22.04, o docker info reporta Storage Driver: overlay2 e Cgroup Version: 2.

Usar o Docker sem sudo: o grupo docker

O daemon escuta no socket Unix /var/run/docker.sock, pertencente a root:docker, por isso os membros do grupo docker podem usar a CLI sem sudo:

sudo groupadd docker          # usually exists already; harmless if it does
sudo usermod -aG docker $USER
newgrp docker                 # or log out and back in
docker run hello-world

Perceba o que acabou de conceder. Quem conseguir chegar a esse socket pode executar docker run -v /:/host --privileged ... e ler ou reescrever qualquer ficheiro do VPS, o que torna a pertença ao grupo docker equivalente a root, sem pedido de palavra-passe e sem registo no log do sudo. Trate-a exatamente como acesso sudo; o nosso guia sobre mudar de utilizador e escalar privilégios no Ubuntu explica por que essa distinção importa numa máquina multiutilizador.

Plugin Docker Compose

O pacote docker-compose-plugin fornece o Compose v2 como subcomando docker compose (com espaço). O antigo binário Python docker-compose chegou ao fim de vida e não deve ser instalado ao lado dele. Verifique a versão e depois teste com um compose.yaml mínimo:

docker compose version

mkdir -p ~/web && cd ~/web
cat > compose.yaml <<'EOF'
services:
  web:
    image: nginx:alpine
    ports:
      - "127.0.0.1:8080:80"
    restart: unless-stopped
EOF

docker compose up -d
docker compose ps
curl -I http://127.0.0.1:8080
docker compose down

Dois detalhes são deliberados: restart: unless-stopped repõe o contentor depois de um reboot, e a porta é associada a 127.0.0.1 em vez de a todas as interfaces, por razões que a secção da firewall explica.

Modo rootless: um daemon que não é root

O modo rootless executa o daemon e os contentores dentro de um user namespace, por isso uma fuga de contentor cai numa conta sem privilégios em vez de root. É a escolha certa quando várias pessoas partilham um VPS. Os pré-requisitos são intervalos de UID/GID subordinados (o Ubuntu cria-os para utilizadores normais em /etc/subuid e /etc/subgid), as ferramentas uidmap, uma sessão D-Bus de utilizador e os extras rootless do Docker:

sudo apt-get install -y uidmap dbus-user-session docker-ce-rootless-extras
grep "^$USER:" /etc/subuid /etc/subgid   # each should show a range of 65536 IDs

# optional: stop the system-wide daemon if you only want rootless
sudo systemctl disable --now docker.service docker.socket

dockerd-rootless-setuptool.sh install

A ferramenta de configuração cria uma unidade systemd por utilizador e imprime as duas variáveis de que a sua shell precisa. Adicione-as ao ~/.bashrc e faça com que o daemon do utilizador arranque no boot sem login:

export PATH=/usr/bin:$PATH
export DOCKER_HOST=unix:///run/user/$(id -u)/docker.sock

systemctl --user enable docker
sudo loginctl enable-linger $(whoami)

O modo rootless tem limites reais: não é possível publicar portas abaixo de 1024 a menos que execute sudo setcap cap_net_bind_service=ep $(which rootlesskit) e reinicie o daemon do utilizador, as redes overlay não estão disponíveis, e os dados ficam em ~/.local/share/docker. No Ubuntu 24.04, o AppArmor restringe os user namespaces sem privilégios; os pacotes deb incluem o perfil de que o rootlesskit precisa, mas uma instalação por binário estático exige adicioná-lo à mão, como descrito na documentação do modo rootless.

Comportamento no arranque, armazenamento e rotação de logs

São duas coisas distintas que determinam se os seus contentores ficam ativos depois de um reboot: o daemon tem de estar ativado e cada contentor precisa de uma política de restart. Os pacotes do Ubuntu ativam o serviço por si; confirme, e se os estados da unidade lhe parecerem estranhos, a nossa referência sobre listar serviços com o systemctl explica todas as colunas:

systemctl is-enabled docker.service containerd.service
sudo systemctl enable docker.service containerd.service   # only if the line above said disabled

Os contentores iniciados sem --restart ficam desligados após um reboot; use --restart unless-stopped na linha de comandos ou restart: unless-stopped no Compose para tudo o que for permanente.

Tudo o que o Docker guarda (camadas de imagem, sistemas de ficheiros dos contentores, volumes, logs) fica em /var/lib/docker, e num VPS pequeno é este o diretório que enche o disco. Vigie-o com docker system df, recupere camadas órfãs com docker system prune e leia o aviso antes de acrescentar -a, que também apaga todas as imagens não usadas por um contentor em execução. Se o VPS tiver um segundo disco, aponte o data-root para ele em /etc/docker/daemon.json antes de descarregar algo grande.

Os logs merecem um aviso específico. O driver por omissão json-file escreve cada linha do stdout do contentor em /var/lib/docker/containers/<id>/<id>-json.log e não faz qualquer rotação a menos que a configure. Um contentor tagarela pode devorar o disco inteiro numa semana. Defina limites ao nível do daemon logo no primeiro dia:

sudo tee /etc/docker/daemon.json > /dev/null <<'EOF'
{
  "log-driver": "json-file",
  "log-opts": { "max-size": "10m", "max-file": "3" },
  "live-restore": true
}
EOF
sudo systemctl restart docker

As opções de log aplicam-se aos contentores criados depois do restart, por isso recrie uma vez os que estão em execução prolongada. O live-restore permite reiniciar o daemon para atualizações sem matar os contentores em execução.

Docker e ufw: as portas publicadas contornam a sua firewall

Esta é a parte que apanha a maioria das pessoas num VPS público. O Docker gere as suas próprias regras iptables: quando publica uma porta com -p 8080:80, o daemon insere uma regra DNAT na cadeia PREROUTING da tabela nat e uma regra de aceitação em FORWARD. As regras do ufw vivem em INPUT, que o tráfego encaminhado nunca atravessa. Por isso ufw deny 8080 não tem efeito, e um contentor de base de dados publicado em 0.0.0.0:5432 fica acessível a partir de toda a internet enquanto o ufw reporta a porta como bloqueada. Procure 0.0.0.0: na coluna PORTS do docker ps, ou execute ss -tlnp; o nosso guia sobre verificar portas abertas no Linux mostra como ler esse resultado e confirmar a exposição a partir do exterior.

Duas correções limpas, por ordem de preferência:

1. Associe as portas publicadas ao loopback. -p 127.0.0.1:8080:80 mantém o serviço acessível apenas a partir do próprio VPS, normalmente por trás de um proxy inverso como o nginx ou o Caddy que expõe deliberadamente. Contentores que só falam entre si não precisam de -p nenhum.
2. Filtre na cadeia DOCKER-USER. O Docker avalia esta cadeia antes das suas próprias regras FORWARD e nunca a reescreve. Como o DNAT já aconteceu quando um pacote lá chega, faça a correspondência da porta original com o conntrack:

sudo iptables -I DOCKER-USER -i eth0 ! -s 203.0.113.10 -p tcp \
  -m conntrack --ctorigdstport 8080 --ctdir ORIGINAL -j DROP

Substitua eth0 pela sua interface pública e 203.0.113.10 pelo endereço autorizado. Estas regras não são persistentes; guarde-as com o pacote iptables-persistent. Definir "iptables": false no daemon.json quebra a rede dos contentores de formas difíceis de depurar; não lhe toque.

Desinstalar completamente o Docker

Faça primeiro o purge dos pacotes e depois apague os diretórios de dados, que o apt deixa no lugar de propósito:

sudo apt-get purge -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin docker-ce-rootless-extras
sudo rm -rf /var/lib/docker /var/lib/containerd
sudo rm -f /etc/apt/sources.list.d/docker.list /etc/apt/keyrings/docker.asc
sudo apt-get autoremove -y

Numa configuração rootless, execute primeiro dockerd-rootless-setuptool.sh uninstall como utilizador e apague depois ~/.local/share/docker.

Tudo isto pressupõe um servidor onde tem root, controla o kernel e pode reescrever o iptables sem pedir autorização a ninguém. Se ainda precisa dessa máquina, o VPS Linux KVM com acesso root total da rdp.monster vem com Ubuntu 24.04 ou 22.04, CPU e RAM dedicados, largura de banda ilimitada (fair-use), sem KYC, com criptomoedas aceites, a partir de $8.99/mês, e é entregue cerca de 10 segundos após a confirmação do pagamento, para que possa correr o teste hello-world acima no seu próprio servidor logo a seguir à compra.

Perguntas frequentes

Que versão do Docker é que o apt instala no Ubuntu, e como a atualizo?

O repositório instala a versão estável mais recente do Docker Engine, e o apt upgrade mantém-na atualizada.

Com o repositório apt do Docker configurado, apt-get install docker-ce instala a versão estável mais recente disponível para o codename do seu Ubuntu, e cada sudo apt-get update && sudo apt-get upgrade posterior faz-lhe avançar. Execute docker version para ver as versões do cliente e do servidor. Para fixar uma versão específica, liste os candidatos com apt-cache madison docker-ce e instale docker-ce=<version> juntamente com o docker-ce-cli correspondente, depois faça apt-mark hold a ambos os pacotes.

Porque recebo "permission denied while trying to connect to the Docker daemon socket"?

O seu utilizador não consegue ler o /var/run/docker.sock; entre no grupo docker ou use sudo.

O socket do daemon pertence a root:docker, por isso um utilizador comum recebe permission denied. Ou prefixe os comandos com sudo, ou adicione-se com sudo usermod -aG docker $USER e inicie uma nova sessão (ou execute newgrp docker), porque as alterações de grupo só se aplicam a sessões novas. Se o erro persistir, verifique groups para confirmar a pertença, confirme que o daemon está a correr com systemctl status docker e certifique-se de que DOCKER_HOST não aponta para um socket rootless inexistente.

Devo instalar o Docker com snap ou com apt no Ubuntu Server?

Use o apt com o repositório do Docker; o snap traz manias de confinamento sem vantagem num servidor.

Prefira o apt a partir do repositório do próprio Docker. O snap é estritamente confinado: não consegue ler ficheiros fora do seu diretório pessoal sem ligações de interface adicionais, usa caminhos diferentes para o daemon.json e para os dados, e a sua cadência de atualização é controlada pelo snapd e não por si. Essas manias aparecem como misteriosos permission denied e falhas de bind-mount. Os pacotes apt seguem as convenções normais do Ubuntu, integram-se com o systemd de forma natural e recebem as atualizações upstream pelo mesmo apt upgrade que já executa.

Quanta RAM e disco precisa um VPS para Docker?

O engine em si é leve; dimensione o VPS para os contentores e as suas imagens.

O Docker Engine em repouso consome algumas dezenas de megabytes de RAM, por isso o orçamento real é a sua carga de trabalho. Uma pequena aplicação web com base de dados corre confortavelmente em 2 GB; stacks mais pesadas ou vários projetos pedem 4 GB ou mais. O disco importa mais do que se pensa: imagens, cache de build e logs vão todos parar a /var/lib/docker, e 20 GB enchem depressa sem docker system prune e rotação de logs. Prefira CPU e RAM dedicados a fatias burstable, já que as builds provocam picos fortes e os contentores não lidam bem com swap.