Como funciona a persistência de dados com Docker volumes?

Question

Accepted Answer

Por padrão, os dados em um contêiner são **efêmeros** — perdidos quando o contêiner é removido. **Volumes** (e bind mounts) fornecem **armazenamento persistente** que sobrevive aos contêineres, essencial para bancos de dados e qualquer dado que deva sobreviver a reinicializações/remoções de contêineres.

## O problema: contêineres são efêmeros

```text
A container's writable layer is DELETED when the container is removed:
  → data written inside the container (e.g. a database's files) is LOST
  → containers are meant to be disposable/replaceable → don't store important data in them
→ For persistent data, you need storage OUTSIDE the container's lifecycle.
```

## Volumes — armazenamento persistente gerenciado

```bash
# create and use a named volume (managed by Docker)
docker volume create mydata
docker run -v mydata:/var/lib/mysql mysql      # mount the volume into the container
# → data in /var/lib/mysql persists in the volume, surviving container removal

docker volume ls                 # list volumes
docker volume inspect mydata     # details
```

**Volumes** são armazenamento persistente gerenciado pelo Docker (armazenado no host, gerenciado pelo Docker) — a forma preferida de persistir dados. Os dados no caminho montado sobrevivem mesmo se o contêiner for removido.

## Bind mounts — mapear um diretório do host

```bash
# bind mount: map a specific HOST directory into the container
docker run -v /host/path:/app -p 3000:3000 myapp
docker run -v $(pwd):/app myapp   # mount the current directory (great for development)
# → changes on the host are reflected in the container (and vice versa)
```

**Bind mounts** mapeiam um diretório do host para dentro do contêiner — útil para desenvolvimento (editar código no host, ver mudanças ao vivo no contêiner).

## Volumes vs bind mounts

```text
VOLUMES      → Docker-managed, portable, the preferred choice for PERSISTENT DATA
               (databases, uploads) — decoupled from the host's filesystem layout
BIND MOUNTS  → map a specific host path; great for DEVELOPMENT (live code reload)
               and sharing host files; tied to the host's filesystem
tmpfs        → in-memory (non-persistent), for sensitive/temporary data
```

## Por que isso importa

Entender a persistência de dados com volumes é essencial para usar Docker corretamente com qualquer aplicação que tenha dados, portanto é um conhecimento prático importante.

A questão fundamental — **contêineres são efêmeros**, com sua camada gravável deletada na remoção, significando que **dados escritos dentro de um contêiner são perdidos** — é um conceito crítico: contêineres são projetados para serem descartáveis, então armazenar dados importantes dentro deles (como os arquivos de um banco de dados) causa perda de dados quando o contêiner é substituído. **Volumes** resolvem isso fornecendo **armazenamento persistente gerenciado pelo Docker** que vive fora do ciclo de vida do contêiner, então dados (bancos de dados, uploads, qualquer estado) sobrevivem à remoção e substituição do contêiner — essencial para aplicações com estado.

Entender **bind mounts** (mapeando um diretório do host para dentro do contêiner) é importante para **desenvolvimento** (editar código no host e ver mudanças ao vivo no contêiner, um fluxo de trabalho de desenvolvimento muito comum) e para compartilhar arquivos do host.

Conhecer a **distinção** — volumes (gerenciados pelo Docker, portáveis, a escolha preferida para dados persistentes de aplicações como bancos de dados) versus bind mounts (específicos do caminho do host, ótimos para desenvolvimento) — guia a escolha da abordagem correta.

Com contêineres sendo efêmeros por design e a maioria das aplicações reais tendo dados que devem persistir (bancos de dados especialmente), e com volumes sendo o mecanismo essencial para armazenamento persistente (com bind mounts sendo importantes para desenvolvimento), entender a persistência de dados do Docker — o problema do contêiner efêmero, volumes para dados persistentes, bind mounts para desenvolvimento, e quando usar cada um — é um conhecimento Docker essencial e praticamente relevante, necessário para executar aplicações com estado corretamente e evitar o erro grave de perder dados armazenados dentro de contêineres descartáveis.