Voltar ao blog Self-hosting

Os dados da sua aplicação sobreviverão à reconstrução de um contêiner? Um checklist de persistência no Docker

Um contêiner parado e um contêiner substituído não são o mesmo teste. Mapeie onde sua aplicação armazena dados e configurações, confira as instruções de implantação e verifique a persistência com uma substituição controlada.

Checklist para rastrear os dados da aplicação e testar a persistência durante a substituição de um contêiner Docker

Por que a substituição do contêiner importa

Um contêiner pode ser parado e iniciado novamente ou removido e substituído durante uma alteração na implantação. Esses são eventos diferentes do ciclo de vida, portanto, uma reinicialização bem-sucedida não comprova que dados importantes da aplicação sobreviverão à substituição. A documentação introdutória do Docker trata a persistência de dados como um conceito distinto ([documentação do Docker](https://docs.docker.com/get-started/docker-concepts/running-containers/persisting-container-data/)).

A camada gravável de um contêiner parado continua disponível até que o contêiner seja removido; iniciar o mesmo contêiner faz com que ela volte a ficar disponível ([Dash0, «Como preservar dados quando um contêiner Docker é encerrado»](https://www.dash0.com/faq/how-to-preserve-data-when-a-docker-container-exits)). Isso não determina o que acontece com os dados durante a remoção e a substituição. Teste o evento do ciclo de vida que realmente importa para você.

  • Defina a alteração que deseja testar: reinicialização, atualização, remoção e recriação ou outra ação gerenciada pelo provedor.
  • Para um teste inicial, use um ambiente que não seja de produção ou dados que possam ser perdidos com segurança.
  • Se não conseguir determinar se uma alteração reutiliza ou substitui o contêiner, pergunte a quem gerencia a implantação.
Por que a substituição do contêiner importa

Mapeie os dados, as configurações e os locais de armazenamento

Faça um inventário breve do que a aplicação cria ou utiliza, como dados relacionados ao banco de dados, arquivos enviados por usuários, configurações, arquivos gerados ou registros de log. Essas são categorias a investigar, não uma afirmação de que todas as aplicações armazenam esses itens da mesma maneira.

Para cada item, anote onde a aplicação ou a implantação informa que ele fica: dentro do contêiner, em um ponto de montagem configurado, em outro serviço ou nas configurações da implantação. Marque como desconhecido tudo o que não conseguir verificar. É preciso consultar a documentação de implantação da própria aplicação para confirmar os caminhos específicos e o comportamento de inicialização.

Para cada ponto de montagem configurado, registre o tipo, a origem e o destino conforme aparecem na implantação, a finalidade prevista e o comportamento documentado durante o procedimento de substituição. O nome de um ponto de montagem, por si só, não indica o que ele contém nem se o procedimento o preserva.

  • Dado ou configuração: o que é e qual seria o impacto se desaparecesse?
  • Local e evidências: onde a aplicação ou a implantação informa que esse item fica, e quais instruções ou configurações sustentam essa informação?
  • Ciclo de vida: o que se espera que aconteça com esse local durante a alteração que você pretende testar?
  • Dúvidas: o que precisa ser confirmado antes de uma alteração em produção?
Mapeie os dados, as configurações e os locais de armazenamento

Confira as instruções de implantação antes de testar

Consulte a documentação oficial de implantação do fornecedor da aplicação para identificar os caminhos de dados necessários, as entradas de configuração e o comportamento na primeira execução ou durante a inicialização. Compare essas instruções com a definição real da implantação; não copie um caminho de outra instalação nem suponha que um contêiner novo lidará como esperado com dados já existentes.

Se um caminho necessário não estiver configurado, uma etapa de inicialização não estiver clara ou a implantação não corresponder às instruções, interrompa o processo e peça esclarecimentos antes de testar com dados importantes. Registre a documentação e as configurações que consultou para que suas expectativas correspondam à implantação que você realmente está usando.

  • Quais caminhos documentados contêm estado ou dados de usuários, e a implantação define armazenamento para eles?
  • O que a documentação da aplicação informa sobre o comportamento na primeira execução ou sobre um caminho que já contém dados?
  • De acordo com a documentação, como a configuração é fornecida neste ambiente?
  • Quais configurações ou detalhes do ciclo de vida ainda não foram verificados?

Execute um teste de persistência controlado

Teste o evento exato do ciclo de vida que preocupa você, usando dados que possam ser perdidos com segurança. Prefira um ambiente que não seja de produção. Se for necessário testar um serviço ativo, obtenha aprovação e use um item de baixo risco que possa ser identificado e removido depois.

Crie um item de teste com um nome claro usando a aplicação e anote como reconhecê-lo. Siga o procedimento documentado de substituição — não se limite a parar e iniciar o contêiner se sua preocupação for a remoção e a recriação. Depois, confira se o item está presente e pode ser usado e verifique separadamente os outros dados importantes que você inventariou.

Registre o resultado e quaisquer premissas que tenham mudado. Um teste bem-sucedido se aplica àquela implantação e àquele procedimento; não determina como cada categoria de dados ou outro cenário de recuperação vai se comportar.

  • Antes: registre a aplicação, a implantação, o item de teste e a ação do ciclo de vida.
  • Depois: confira o item de teste e quaisquer outras categorias de dados importantes.
  • Documente: anote o procedimento, o resultado, os dados ausentes ou alterados e as dúvidas que ainda restam.
  • Limpeza: remova o item de teste, se for apropriado, e confirme que a aplicação está no estado previsto.

Mantenha a persistência, os backups e as responsabilidades separados

Persistência e backup respondem a perguntas diferentes. O fato de um local continuar disponível após um procedimento de substituição não comprova que seja possível recuperar os dados em caso de perda ou erro. Documente separadamente o que precisa de backup, o que cada backup cobre, como funciona a recuperação e quem é responsável por cada etapa.

Também determine quem pode acessar a aplicação, a configuração de armazenamento e qualquer mecanismo de recuperação. Não suponha que o tipo de hospedagem determine quais dados estão cobertos, por quanto tempo são mantidos ou quem pode restaurá-los.

A Airbip oferece backups configuráveis diários, semanais e mensais. As informações disponíveis sobre o produto não especificam quais dados de cada aplicação estão incluídos em cada backup nem o procedimento de recuperação; portanto, confirme esses detalhes de acordo com suas necessidades.

  • Identifique os dados que precisam ser recuperáveis e quem confirma a cobertura dos backups.
  • Pergunte o que os backups incluem e excluem, e como a recuperação é solicitada e realizada.
  • Confirme quem pode acessar ou administrar os dados da aplicação e as configurações da implantação.
  • Mantenha as expectativas sobre backup e recuperação separadas do resultado do teste de persistência.

Perguntas para fazer a um provedor de hospedagem gerenciada

Peça respostas vinculadas à implantação da sua aplicação e ao evento específico do ciclo de vida que importa para você, em vez de depender de garantias genéricas. Use as respostas para decidir se o modelo gerenciado atende aos seus requisitos de dados, acesso e governança.

A Airbip executa instâncias de aplicações como cargas de trabalho Docker em seus servidores na nuvem e oferece gerenciamento do ciclo de vida do serviço. Ela automatiza o roteamento e os certificados TLS por meio do Traefik e do Let’s Encrypt, além de oferecer backups configuráveis diários, semanais e mensais. Essas capacidades, por si só, não especificam quais caminhos da aplicação persistem após uma substituição nem o que um backup inclui.

Se um provedor não conseguir esclarecer os detalhes da implantação que você precisa controlar, ou se o serviço não atender aos seus requisitos de governança, avalie um modelo de implantação que ofereça o controle necessário.

  • Qual ação específica conta como substituição de um contêiner na minha instância, e quais locais de dados e configurações são mantidos durante esse processo?
  • O que sustenta essa resposta e onde posso consultar as configurações de armazenamento específicas da aplicação?
  • O que os backups incluem, como funciona a recuperação e quem é responsável por cada etapa?
  • Quais controles de acesso se aplicam e quais alterações ou ações continuam sob minha responsabilidade?

Perguntas frequentes

Os dados de um contêiner Docker parado desaparecem imediatamente?

Não. A camada gravável de um contêiner parado continua disponível até que ele seja removido, e iniciar o mesmo contêiner faz com que ela volte a ficar disponível. Isso não determina o que acontece quando o contêiner é removido e substituído.

Reiniciar um contêiner é um teste válido de persistência?

Esse teste verifica a reinicialização do mesmo contêiner, mas não necessariamente sua remoção e substituição. Se você precisa entender o que acontece durante a substituição, siga o procedimento documentado em um ambiente seguro.

Volumes nomeados e montagens bind são automaticamente seguros para os dados da minha aplicação?

Não suponha que sejam. Confira as instruções de implantação da aplicação e as configurações reais da implantação para determinar quais caminhos estão montados, o que contêm e o que acontece durante a alteração que você pretende testar.

O que devo perguntar a um provedor de hospedagem gerenciada sobre persistência?

Pergunte quais locais de dados e configurações são mantidos durante o procedimento específico de substituição, o que os backups incluem, como funciona a recuperação e quais responsabilidades continuam sendo suas.

Fontes e leituras adicionais

  1. Persisting container data — Docker
  2. How to Preserve Data When a Docker Container Exits — Dash0