Data Persistence with Docker Volumes

A Natureza dos Dados de um Banco de Dados

Primeiro, vamos contextualizar o problema. Aplicações podem ser categorizadas como stateless (sem estado) ou stateful (com estado).

• Stateless: Uma API web é um exemplo clássico. Você pode criar ou destruir várias instâncias dela sem perder informações, pois o estado (os dados) é armazenado em outro lugar.
• Stateful: Um banco de dados (como PostgreSQL, SQL Server ou MySQL) é o exemplo por excelência. Os dados que ele gerencia são o estado. A perda desses dados é, na maioria dos casos, catastrófica.

Como os contêineres são efêmeros por padrão, garantir a persistência e a integridade dos dados de um banco de dados é uma prioridade máxima.

Volumes vs. Bind Mounts: A Justificativa Técnica

Embora tanto volumes quanto bind mounts possam tecnicamente persistir dados, a escolha correta para um banco de dados é, inequivocamente, o volume nomeado (named volume). Vamos analisar o porquê com base em quatro critérios essenciais.

Para uma excelente visão geral que aborda essa decisão, leia o seguinte artigo. Ele oferece uma árvore de decisão clara e cenários do mundo real.

Com base no que você leu e em nosso conhecimento prévio, vamos estruturar a justificativa:

1. Gerenciamento e Portabilidade

• Volumes: São gerenciados pelo Docker Engine. O Docker armazena os dados em uma área específica no sistema de arquivos do host (ex: /var/lib/docker/volumes/ no Linux), mas você, como usuário, não precisa saber ou interagir com esse caminho. Você gerencia tudo via comandos Docker (docker volume create, inspect, ls). Isso desacopla os dados do ambiente do host.
• Bind Mounts: Mapeiam um caminho específico do host para o contêiner. Isso cria um acoplamento forte. Se você configurar um contêiner para usar um bind mount em C:\dev\db_data, essa configuração não funcionará em outra máquina sem esse caminho exato.

Justificativa para Bancos de Dados: A portabilidade é crucial. Você precisa que sua configuração de banco de dados funcione de forma consistente na sua máquina, na de seus colegas e nos ambientes de staging e produção. Os volumes garantem essa independência de localização.

2. Desempenho

• Volumes: Oferecem desempenho próximo ao nativo em todas as plataformas. No Windows e macOS, onde o Docker é executado dentro de uma VM Linux, o Docker otimizou o sistema de arquivos para operações de I/O de alto desempenho dentro dessa VM, onde os volumes residem.
• Bind Mounts: Embora rápidos no Linux, eles podem sofrer uma penalidade de desempenho significativa no Windows e macOS. Isso ocorre porque o compartilhamento de arquivos entre o sistema operacional do host (Windows/macOS) e a VM Docker envolve uma camada de tradução que pode ser lenta para operações de I/O intensivas, como as de um banco de dados (muitas leituras e escritas pequenas).

Justificativa para Bancos de Dados: O desempenho do banco de dados é crítico para a performance da aplicação. A degradação de I/O causada por bind mounts no Windows/macOS torna-os inadequados para essa tarefa. Os volumes oferecem um desempenho consistente e otimizado em todas as plataformas.

3. Segurança e Isolamento

• Volumes: Os dados são isolados dentro da área de gerenciamento do Docker. Isso protege os arquivos do banco de dados de serem modificados ou excluídos acidentalmente por outros processos no sistema do host.
• Bind Mounts: Expõem uma parte do sistema de arquivos do host diretamente ao contêiner. Um contêiner comprometido poderia, teoricamente, afetar o host. Mais importante, qualquer processo no host pode acessar e modificar os arquivos do banco de dados, contornando o motor do banco de dados, o que é uma receita para a corrupção de dados.

Justificativa para Bancos de Dados: Os arquivos de dados de um banco de dados são altamente estruturados e não devem ser tocados por nada além do próprio processo do banco de dados. Os volumes fornecem o isolamento necessário para garantir a integridade dos dados.

4. Recursos Avançados e Ecossistema

• Volumes: Suportam drivers de volume. Isso permite que o Docker armazene dados em sistemas de armazenamento externos, como compartilhamentos NFS ou armazenamento em nuvem (Amazon EBS, Azure Disk). Além disso, os volumes podem ser pré-populados com dados de uma imagem na primeira vez que um contêiner é iniciado.
• Bind Mounts: São um mapeamento simples e não possuem um modelo de driver extensível.

Justificativa para Bancos de Dados: Para cenários de produção, a capacidade de usar drivers de volume para conectar-se a soluções de armazenamento gerenciadas, replicadas e de alta disponibilidade é fundamental. Os volumes são a porta de entrada para essa funcionalidade.

Demonstração Prática: Persistindo Dados do PostgreSQL

Agora, vamos ver como aplicar isso na prática com o PostgreSQL, um banco de dados que você usará mais adiante no curso.

O vídeo a seguir demonstra o processo completo com MySQL, mas os conceitos e comandos são idênticos para qualquer banco de dados. Ele mostra visualmente por que a persistência funciona.

Inspirados pelo vídeo, aqui estão os comandos para fazer o mesmo com o PostgreSQL:

1. Crie um volume nomeado:

   docker volume create postgres-data
   

2. Execute um contêiner PostgreSQL usando o volume:
   O diretório padrão de dados do PostgreSQL na imagem oficial é /var/lib/postgresql/data.

   docker run --name some-postgres -d \
     --mount type=volume,source=postgres-data,target=/var/lib/postgresql/data \
     -e POSTGRES_PASSWORD=mysecretpassword \
     postgres:16
   

   • --mount type=volume,source=postgres-data,target=/var/lib/postgresql/data: Mapeia nosso volume postgres-data para o diretório de dados dentro do contêiner.

3. Simule um desastre: Pare e remova o contêiner.

   docker stop some-postgres
   docker rm some-postgres
   

4. Verifique se os dados (o volume) ainda existem:

   docker volume ls
   

   Você verá postgres-data na lista. Seus dados estão seguros.

5. Inicie um novo contêiner conectado ao volume existente:

   docker run --name new-postgres -d \
     --mount type=volume,source=postgres-data,target=/var/lib/postgresql/data \
     -e POSTGRES_PASSWORD=mysecretpassword \
     postgres:16
   

   Este novo contêiner carregará e servirá os dados existentes do volume postgres-data, como se nada tivesse acontecido.

Este artigo do dev.to reforça essa prática com exemplos e dicas valiosas.

Conclusão

Parabéns por concluir este módulo sobre redes e armazenamento! Hoje, você solidificou um dos conceitos mais importantes para executar aplicações robustas no Docker.

Principais Pontos:

• Para aplicações com estado (stateful), como bancos de dados, a escolha padrão e correta para persistir dados é um volume nomeado (named volume).
• A justificativa se baseia em quatro pilares: portabilidade (desacoplamento do host), desempenho (otimizado em todas as plataformas), segurança (isolamento dos dados) e funcionalidades (suporte a drivers).
• Bind mounts são inadequados para bancos de dados devido ao acoplamento com o host, possíveis problemas de desempenho e riscos à integridade dos dados.

Até agora, gerenciamos nossos contêineres individualmente. No entanto, aplicações reais, como uma API .NET com um banco de dados PostgreSQL, são compostas por múltiplos serviços que precisam se comunicar. Na próxima lição, daremos um grande passo em frente e entraremos no Módulo 4: Aplicações Multi-Contêiner com Docker Compose. Você aprenderá a definir e gerenciar toda a sua stack de aplicação em um único arquivo de configuração, tornando o desenvolvimento e a orquestração muito mais simples.