Onde uma aplicação auto-hospedada deve armazenar os seus ficheiros? Um quadro de decisão para volumes persistentes e armazenamento de objetos

O armazenamento de ficheiros é uma decisão arquitetural

Uma aplicação auto-hospedada normalmente armazena o seu estado duradouro em mais de um local. A base de dados pode conter registos, permissões e metadados, enquanto ficheiros como carregamentos, documentos, imagens e relatórios gerados ficam no disco ou num armazenamento de objetos. Por isso, restaurar apenas a base de dados pode produzir registos que apontam para ficheiros que já não existem.

Em implementações com Docker, os dados gravados apenas na camada gravável de um contentor desaparecem quando esse contentor é destruído. Os ficheiros duradouros da aplicação têm de ser colocados numa localização explicitamente persistente e suportada pela aplicação. A escolha certa não é automaticamente o armazenamento de objetos: é o padrão de armazenamento que corresponde ao modelo de acesso a ficheiros da aplicação, aos requisitos de recuperação e à capacidade operacional da equipa.

• Trate cada localização de ficheiros como parte do modelo de dados da aplicação.
• Conceba cópias de segurança e restauros em torno da base de dados e dos ficheiros a que esta faz referência.
• Documente a localização de armazenamento prevista, em vez de depender de uma imagem de contentor ou de um caminho de anfitrião não documentado.

Comece por um inventário de ficheiros

Antes de escolher o armazenamento, identifique todas as categorias de dados que a aplicação cria ou consome. Leia a documentação oficial de implementação e cópias de segurança da aplicação, inspecione os caminhos e definições configurados e faça um carregamento ou exportação de teste num ambiente que não seja de produção. O objetivo é compreender o que é autoritativo, o que pode ser regenerado e o que tem de ser preservado.

Não assuma que um diretório chamado uploads é toda a resposta. Uma aplicação pode manter ficheiros originais, miniaturas, anexos privados, recursos de extensões, índices de pesquisa, cargas úteis de tarefas em fila ou arquivos de exportação em localizações diferentes.

• Carregamentos e anexos de utilizadores: originais fornecidos por utilizadores ou colaboradores.
• Multimédia e derivados gerados: imagens, pré-visualizações, miniaturas ou documentos transformados.
• Exportações geradas: relatórios, ficheiros CSV, faturas ou transferências de arquivos.
• Recursos geridos pela aplicação: ficheiros criados através de uma interface administrativa.
• Caches, sessões e ficheiros de trabalho temporários: frequentemente descartáveis, mas confirme-o na documentação do fornecedor.
• Registos e ficheiros de diagnóstico: úteis operacionalmente, mas normalmente geridos separadamente da recuperação da aplicação.

Compreenda os três padrões comuns de armazenamento

Os volumes persistentes locais armazenam ficheiros fora do ciclo de vida de um contentor individual. Os volumes Docker são geridos pelo Docker e permanecem quando o contentor que os utiliza é removido. No Kubernetes, os PersistentVolumes têm igualmente um ciclo de vida independente de um Pod individual. Este padrão é frequentemente adequado a uma única instância da aplicação cujo software espera acesso normal ao sistema de ficheiros.

O armazenamento de objetos guarda dados como objetos em buckets, identificados por chaves de objeto. Só é apropriado quando a aplicação suporta explicitamente um serviço de armazenamento de objetos ou fornece uma integração suportada. Por exemplo, o Active Storage do Rails suporta tanto um serviço de disco local como serviços de armazenamento na cloud, ilustrando que a escolha do armazenamento é frequentemente uma decisão de configuração da aplicação, e não uma substituição transparente de infraestrutura.

Um sistema de ficheiros gerido externamente pode disponibilizar acesso a um sistema de ficheiros partilhado às cargas de trabalho. Pode ser apropriado quando a aplicação realmente o exige e a implementação de armazenamento selecionada suporta o padrão de acesso necessário. Acrescenta mais um sistema para operar, proteger, salvaguardar e testar.

• Volume persistente: semântica simples de sistema de ficheiros para uma arquitetura suportada de anfitrião único ou nó único.
• Armazenamento de objetos: acesso a objetos orientado pela aplicação, potencialmente separado do anfitrião de computação.
• Sistema de ficheiros gerido: semântica de sistema de ficheiros partilhado quando justificada pelos requisitos da aplicação.

Utilize uma matriz de decisão em vez de uma predefinição

Escolha o armazenamento por categoria de ficheiro, não necessariamente uma única vez para toda a aplicação. Uma carga de trabalho de gestão documental pode precisar de armazenamento duradouro para anexos, enquanto o respetivo diretório temporário de conversão deve permanecer não persistente. Uma aplicação de relatórios pode reter documentos de origem, mas regenerar exportações após um restauro.

Uma arquitetura de armazenamento é defensável quando tem respostas claras para durabilidade, compatibilidade com a aplicação, recuperação, portabilidade, controlo de acesso e manutenção de rotina.

• Durabilidade: O que acontece se o contentor, anfitrião ou nó for substituído?
• Compatibilidade: A aplicação suporta oficialmente este backend de armazenamento e a sua configuração?
• Complexidade de restauro: A equipa consegue restaurar ficheiros e dados da base de dados para um ponto conhecido e compatível?
• Portabilidade da migração: Os dados podem ser exportados, copiados e validados sem pressupostos não documentados?
• Limites de acesso: Que identidade de serviço pode ler, escrever ou eliminar os ficheiros?
• Sobrecarga operacional: Quem é responsável pelas credenciais, monitorização de capacidade, regras de retenção e testes de restauro?
• Modelo de escala: Mais de um processo da aplicação precisará de escrever nos mesmos ficheiros, e isso é suportado?

Restaure bases de dados e ficheiros como um sistema relacionado

A questão fundamental é saber se a base de dados contém referências a ficheiros ou se os ficheiros são necessários para interpretar os registos da base de dados. Se um registo de anexo fizer referência a um caminho ou a uma chave de objeto, o armazenamento de anexos e a base de dados precisam de planeamento de recuperação conjunto. Um restauro que combina uma base de dados mais recente com ficheiros mais antigos, ou o inverso, pode deixar anexos em falta ou ficheiros sem referência.

A ordem exata de restauro segura depende da aplicação. Alguns produtos oferecem um modo de manutenção, comando de cópia de segurança ou procedimento de restauro documentados; utilize-os quando estiverem disponíveis. Quando a aplicação não possui um mecanismo de consistência documentado, defina uma janela de manutenção curta ou outro método controlado para reduzir escritas enquanto são efetuadas cópias de segurança da base de dados e dos ficheiros.

• Identifique o sistema de registo para cada categoria de ficheiro.
• Registe se a base de dados armazena caminhos, chaves de objeto, somas de verificação ou metadados de anexos.
• Defina um ponto de recuperação aceitável para a base de dados e para os ficheiros.
• Teste o que os utilizadores devem ver após o restauro: carregamentos recentes, anexos antigos, permissões e transferências.

Quando os volumes persistentes locais são a resposta certa

Um volume persistente local é frequentemente a escolha mais clara para uma pequena implementação quando a aplicação foi concebida para armazenamento em sistema de ficheiros local, é executada como uma instância ativa e a equipa consegue fazer cópias de segurança e restaurar o volume subjacente. Evita adicionar uma integração de armazenamento de objetos apenas porque parece mais escalável.

A simplicidade só é real se os detalhes operacionais forem explícitos. Um volume Docker é gerido pelo anfitrião, e o nome de um volume local é único nesse anfitrião. Mover a aplicação para outro anfitrião requer um processo deliberado de transferência e verificação dos dados. O Docker documenta um método para arquivar o conteúdo de volumes através de um contentor temporário e restaurar esse arquivo num volume, o que pode suportar um fluxo de trabalho controlado de migração ou recuperação.

• Monte o volume duradouro no caminho de dados documentado da aplicação.
• Não confunda um caminho do sistema de ficheiros do contentor com armazenamento persistente.
• Registe o nome do volume, destino de montagem, expectativas de propriedade e método de cópia de segurança.
• Verifique o comportamento de montagem durante a implementação: montar um volume não vazio oculta ficheiros da imagem que já existiam nesse destino; um volume vazio pode ser preenchido a partir do diretório da imagem, exceto se a cópia estiver desativada.
• Mantenha os dados temporários separados sempre que possível; uma montagem tmpfs é adequada apenas para dados destinados a desaparecer ao parar, reiniciar ou reinicializar o anfitrião.

Quando o armazenamento de objetos é adequado

O armazenamento de objetos é uma opção forte quando uma aplicação o suporta nativamente e a carga de trabalho beneficia de separar os objetos de ficheiro do anfitrião da aplicação. Não deduza a compatibilidade a partir do facto de uma aplicação ser executada no Docker. Confirme o backend suportado, as credenciais necessárias, a organização do bucket, o comportamento de nomenclatura de objetos, as definições de entrega por URL e qualquer procedimento de migração na documentação da própria aplicação.

O armazenamento de objetos altera o modelo operacional, em vez de o eliminar. Continua a ser necessário decidir quem pode aceder ao bucket, como é tratada a eliminação acidental, de que forma as versões retidas afetam a recuperação e se as regras de ciclo de vida correspondem às obrigações de retenção da organização. No Amazon S3, por exemplo, buckets com e sem versionamento têm comportamentos de eliminação diferentes, e as regras de ciclo de vida podem fazer a transição ou eliminar objetos.

• Utilize um bucket dedicado ou um prefixo claramente isolado quando a arquitetura da aplicação o suportar.
• Conceda à aplicação apenas as permissões de que necessita; mantenha as credenciais de serviço separadas da administração humana.
• Documente como os originais, derivados e carregamentos abandonados são retidos ou removidos.
• Teste a recuperação utilizando a mesma configuração de bucket e o mesmo modelo de acesso esperados em produção.
• Certifique-se de que uma política de ciclo de vida não elimina dados de que a aplicação ou os seus utilizadores ainda necessitam.

Não faça de um sistema de ficheiros de rede partilhado a predefinição

Um sistema de ficheiros de rede partilhado pode parecer uma resposta fácil quando há vários contentores ou nós envolvidos, mas deve resultar de um requisito da aplicação, e não antecedê-lo. Vários escritores introduzem questões de bloqueio, alterações concorrentes, permissões e comportamento em caso de falha, que as aplicações podem não estar preparadas para tratar.

Os modos de acesso ao armazenamento do Kubernetes também não substituem a coordenação ao nível da aplicação. ReadWriteOnce significa montagem de leitura e escrita por um nó, não necessariamente por um único Pod. O suporte de ReadWriteMany depende do plugin subjacente ou do controlador CSI, e os modos de acesso comuns não impõem, por si só, proteção contra escrita após a montagem. Valide tanto o comportamento da plataforma de armazenamento como a arquitetura documentada da aplicação para várias instâncias.

• Utilize armazenamento em sistema de ficheiros partilhado apenas quando a aplicação suportar o padrão de acesso exigido.
• Confirme se várias instâncias podem escrever com segurança nos mesmos ficheiros.
• Especifique a implementação de armazenamento subjacente, não apenas uma etiqueta de modo de acesso do Kubernetes.
• Analise o comportamento de recuperação antes de aprovisionar armazenamento dinâmico; uma StorageClass pode eliminar o armazenamento subjacente com uma política de recuperação Delete.