Como atualizar container Docker com Compose sem perder dados: fixar versões, fazer backup, recriar e voltar atrás se a nova versão falhar.

Para que serve

Para atualizar container Docker, não basta um comando como em um pacote: você baixa uma imagem nova e recria o container a partir dela, mantendo os dados em volumes. Feito de qualquer jeito, isso pode trazer uma versão com mudança incompatível de banco de dados, quebrar a aplicação ou apagar dados que estavam dentro do container. Este artigo mostra um processo seguro, com backup e caminho de volta.

Pré-requisitos

  • Aplicações rodando com Docker Compose (compose.yaml). Se você usa docker run solto, vale converter para Compose: fica documentado e repetível.
  • Dados persistentes em volumes ou bind mounts. Tudo que está só na camada do container é perdido ao recriá-lo.
  • Espaço em disco para a imagem nova e para o backup.

Regra de ouro: fixe as versões

Evite image: app:latest em produção. Com latest, você não sabe qual versão está rodando, e um pull pode saltar uma versão maior sem aviso. Prefira tags específicas e atualize de forma deliberada:

services:
  db:
    image: postgres:16.6
  app:
    image: ghcr.io/empresa/app:2.4.1

Antes de mudar a tag, leia as notas de versão (release notes) da aplicação, principalmente em saltos de versão maior. Bancos de dados como PostgreSQL e MySQL não migram os dados sozinhos entre versões maiores (16 → 17): isso exige dump/restore ou pg_upgrade.

Passo a passo para atualizar container Docker

  1. Anote o estado atual (para saber para onde voltar): 
    cd ~/apps/meuprojeto
docker compose images
cp compose.yaml compose.yaml.$(date +%F)
  2. Faça backup dos dados. Para bancos, prefira o dump lógico: 
    docker compose exec -T db pg_dumpall -U postgres > backup-$(date +%F).sql
# MySQL/MariaDB:
# docker compose exec -T db mariadb-dump -u root -p"$SENHA" --all-databases > backup-$(date +%F).sql
    Para volumes de arquivos, pare o serviço e copie o volume com um container temporário: 
    docker compose stop app
docker run --rm -v meuprojeto_dados:/origem:ro -v "$PWD":/destino alpine \
  tar czf /destino/dados-$(date +%F).tar.gz -C /origem .
    Se o projeto roda numa VM do Proxmox, um snapshot ou backup da VM (vzdump) antes da atualização é a forma mais rápida de voltar atrás.
  3. Altere a tag no compose.yaml (ou mantenha a mesma, se for só uma correção publicada na mesma tag).
  4. Baixe as imagens novas sem derrubar nada ainda: 
    docker compose pull
  5. Recrie os containers: 
    docker compose up -d
    O Compose só recria os serviços cuja imagem ou configuração mudou. A indisponibilidade costuma ser de segundos.
  6. Acompanhe os logs na primeira inicialização (migrações de banco aparecem aqui): 
    docker compose logs -f --tail=100
  7. Limpe imagens antigas depois de confirmar que está tudo bem (não antes: elas são seu rollback rápido): 
    docker image prune

Como voltar atrás

  1. Restaure a tag anterior no compose.yaml (ou use a cópia que você fez).
  2. Rode docker compose up -d. Se a imagem antiga ainda estiver no servidor, a volta é imediata.
  3. Se a versão nova já alterou o esquema do banco, a imagem antiga pode não abrir os dados. Nesse caso restaure o backup do passo 2 (ou o snapshot da VM).

Atualização automática: vale a pena?

Para serviços críticos, a recomendação é ser avisado de que há versão nova e atualizar manualmente:

  • Diun (Docker Image Update Notifier): monitora os registries e envia aviso por e-mail, Telegram, webhook e outros canais quando sai uma imagem nova. Não altera nada no servidor.
  • What's Up Docker (WUD): painel que mostra quais containers têm atualização disponível e pode, opcionalmente, disparar a atualização.

O Watchtower original (containrrr/watchtower), muito citado em tutoriais, foi arquivado em dezembro de 2025 e não recebe mais manutenção. Existem forks da comunidade, mas avalie com cuidado antes de dar a uma ferramenta de terceiros acesso ao socket do Docker. Se usar atualização automática, restrinja a containers sem estado (proxy, ferramentas) e mantenha backups.

Não esqueça o próprio Docker

O Docker Engine vem do repositório oficial e é atualizado pelo apt upgrade. Atualizar o pacote docker-ce ou containerd.io reinicia o daemon e, com ele, os containers. Faça isso numa janela de manutenção. Se preferir controlar o momento, use apt-mark hold docker-ce containerd.io e libere quando for atualizar.

Como saber se funcionou

  • docker compose ps: todos os serviços running (ou healthy, se houver healthcheck).
  • docker compose images: mostra as tags novas.
  • A aplicação responde normalmente e não há erros novos em docker compose logs.

Problemas comuns

  • Dados sumiram após atualizar: o dado estava dentro do container, não num volume. Confira os caminhos de dados na documentação da imagem e mapeie volumes antes da próxima atualização.
  • "pull access denied" ou limite de downloads: o Docker Hub limita downloads anônimos. Faça docker login com uma conta (mesmo gratuita) para aumentar o limite.
  • Container reinicia em loop: veja docker compose logs NOME. Quase sempre é migração de configuração exigida pela versão nova ou incompatibilidade de dados; volte para a tag anterior enquanto investiga.
  • Disco cheio: docker system df mostra o uso; imagens antigas acumuladas são a causa mais frequente.

Perguntas frequentes

Atualizar um container apaga os dados?

Não, desde que os dados estejam em volumes ou bind mounts. O que está apenas na camada do container é perdido quando ele é recriado com a imagem nova.

Qual comando atualiza todos os containers de um projeto Compose?

docker compose pull seguido de docker compose up -d. O Compose recria somente os serviços cuja imagem ou configuração mudou.

Ainda vale a pena usar o Watchtower?

O Watchtower original foi arquivado em dezembro de 2025 e não recebe manutenção. Para serviços críticos, prefira ser avisado (Diun ou WUD) e atualizar manualmente.

Como fazer backup do banco antes de atualizar?

Use um dump lógico de dentro do container, como mostrado no passo 2. Veja também os artigos «Backup de PostgreSQL com pg_dump e pg_basebackup (inclusive incremental no PostgreSQL 17+)» e «Backup de MySQL e MariaDB: mariadb-dump, mysqldump, mariadb-backup e XtraBackup».

Leitura complementar

Precisa de ajuda? Abra um ticket ou fale com o suporte pelo WhatsApp.

Esta resposta lhe foi útil? 0 Usuários acharam útil (0 Votos)

Leia também