Où une application auto-hébergée doit-elle stocker ses fichiers ? Un cadre de décision pour les volumes persistants et le stockage d’objets

Le stockage des fichiers est une décision architecturale

Une application auto-hébergée stocke généralement son état durable à plusieurs emplacements. La base de données peut contenir les enregistrements, les autorisations et les métadonnées, tandis que les fichiers tels que les téléversements, documents, images et rapports générés résident sur disque ou dans un magasin d’objets. Restaurer uniquement la base de données peut donc créer des enregistrements qui pointent vers des fichiers qui n’existent plus.

Dans les déploiements Docker, les données écrites uniquement dans la couche inscriptible d’un conteneur disparaissent lorsque ce conteneur est détruit. Les fichiers applicatifs durables doivent être placés dans un emplacement explicitement persistant, pris en charge par l’application. Le bon choix n’est pas automatiquement le stockage d’objets : c’est le modèle de stockage correspondant au mode d’accès aux fichiers de l’application, aux exigences de restauration et à la capacité opérationnelle de l’équipe.

• Considérez chaque emplacement de fichiers comme faisant partie du modèle de données de l’application.
• Concevez les sauvegardes et les restaurations autour de la base de données et des fichiers auxquels elle fait référence.
• Documentez l’emplacement de stockage prévu plutôt que de vous appuyer sur une image de conteneur ou un chemin hôte non documenté.

Commencez par un inventaire des fichiers

Avant de choisir un stockage, identifiez chaque catégorie de données que l’application crée ou consomme. Consultez la documentation officielle de déploiement et de sauvegarde de l’application, inspectez les chemins et paramètres configurés, puis réalisez un téléversement ou un export de test dans un environnement hors production. L’objectif est de déterminer ce qui fait autorité, ce qui peut être régénéré et ce qui doit être conservé.

Ne supposez pas qu’un répertoire nommé uploads constitue toute la réponse. Une application peut conserver les fichiers originaux, les miniatures, les pièces jointes privées, les ressources de plugins, les index de recherche, les charges utiles de tâches en file d’attente ou les archives d’export dans différents emplacements.

• Téléversements et pièces jointes des utilisateurs : fichiers originaux fournis par les utilisateurs ou le personnel.
• Médias et fichiers dérivés générés : images, aperçus, miniatures ou documents transformés.
• Exports générés : rapports, fichiers CSV, factures ou téléchargements d’archives.
• Ressources gérées par l’application : fichiers créés via une interface d’administration.
• Caches, sessions et fichiers de travail temporaires : souvent supprimables, mais à confirmer dans la documentation de l’éditeur.
• Journaux et fichiers de diagnostic : utiles sur le plan opérationnel, mais généralement régis séparément de la restauration de l’application.

Comprendre les trois modèles de stockage courants

Les volumes persistants locaux stockent les fichiers indépendamment du cycle de vie d’un conteneur individuel. Les volumes Docker sont gérés par Docker et demeurent lorsque le conteneur qui les utilise est supprimé. Dans Kubernetes, les PersistentVolumes ont de la même façon un cycle de vie indépendant de celui d’un Pod individuel. Ce modèle convient souvent à une instance unique de l’application dont le logiciel attend un accès classique au système de fichiers.

Le stockage d’objets conserve les données sous forme d’objets dans des buckets, adressés par des clés d’objet. Il n’est approprié que lorsque l’application prend explicitement en charge un service de stockage d’objets ou fournit une intégration prise en charge. Par exemple, Active Storage de Rails prend en charge à la fois un service de disque local et des services de stockage cloud, ce qui illustre que le choix du stockage relève souvent de la configuration de l’application plutôt que d’un remplacement transparent de l’infrastructure.

Un système de fichiers géré de manière externe peut fournir un accès partagé au système de fichiers à des charges de travail. Il peut convenir lorsque l’application en a réellement besoin et que l’implémentation de stockage choisie prend en charge le modèle d’accès requis. Il ajoute un système supplémentaire à exploiter, sécuriser, sauvegarder et tester.

• Volume persistant : sémantique simple de système de fichiers pour une conception prise en charge à hôte ou nœud unique.
• Stockage d’objets : accès aux objets piloté par l’application, potentiellement séparé de l’hôte de calcul.
• Système de fichiers géré : sémantique de système de fichiers partagé lorsqu’elle est justifiée par les exigences de l’application.

Utilisez une matrice de décision plutôt qu’un choix par défaut

Choisissez le stockage par catégorie de fichiers, et pas nécessairement une seule fois pour toute l’application. Une charge de travail de gestion documentaire peut nécessiter un stockage durable des pièces jointes, tandis que son répertoire temporaire de conversion doit rester non persistant. Une application de reporting peut conserver les documents sources tout en régénérant les exports après une restauration.

Une architecture de stockage est défendable lorsqu’elle apporte des réponses claires sur la durabilité, la compatibilité applicative, la restauration, la portabilité, le contrôle des accès et la maintenance courante.

• Durabilité : que se passe-t-il si le conteneur, l’hôte ou le nœud est remplacé ?
• Compatibilité : l’application prend-elle officiellement en charge ce backend de stockage et sa configuration ?
• Complexité de restauration : l’équipe peut-elle restaurer les fichiers et les données de la base de données à un point connu comme compatible ?
• Portabilité de migration : les données peuvent-elles être exportées, copiées et validées sans hypothèses non documentées ?
• Limites d’accès : quelle identité de service peut lire, écrire ou supprimer les fichiers ?
• Charge opérationnelle : qui gère les identifiants, le suivi de capacité, les règles de rétention et les tests de restauration ?
• Modèle de montée en charge : plusieurs processus applicatifs devront-ils écrire dans les mêmes fichiers, et cela est-il pris en charge ?

Restaurez les bases de données et les fichiers comme un système lié

La question essentielle est de savoir si la base de données contient des références aux fichiers ou si les fichiers sont nécessaires pour interpréter les enregistrements de la base de données. Si un enregistrement de pièce jointe fait référence à un chemin ou à une clé d’objet, le stockage des pièces jointes et la base de données doivent être planifiés ensemble pour la restauration. Une restauration combinant une base de données plus récente avec des fichiers plus anciens, ou l’inverse, peut entraîner des pièces jointes manquantes ou des fichiers sans référence.

L’ordre exact d’une restauration sûre dépend de l’application. Certains produits offrent un mode de maintenance, une commande de sauvegarde ou une procédure de restauration documentés ; utilisez-les lorsqu’ils sont disponibles. Lorsqu’une application ne fournit aucun mécanisme de cohérence documenté, définissez une courte fenêtre de maintenance ou une autre méthode contrôlée afin de réduire les écritures pendant la réalisation des sauvegardes de la base de données et des fichiers.

• Identifiez le système de référence pour chaque catégorie de fichiers.
• Consignez si la base de données stocke des chemins, des clés d’objet, des sommes de contrôle ou des métadonnées de pièce jointe.
• Définissez un point de récupération acceptable à la fois pour la base de données et les fichiers.
• Testez ce que les utilisateurs doivent voir après restauration : téléversements récents, anciennes pièces jointes, autorisations et téléchargements.

Quand les volumes persistants locaux sont le bon choix

Un volume persistant local est souvent le choix le plus clair pour un petit déploiement lorsque l’application est conçue pour un stockage sur système de fichiers local, s’exécute sous la forme d’une instance active unique et que l’équipe peut sauvegarder et restaurer le volume sous-jacent. Il évite d’ajouter une intégration de stockage d’objets uniquement parce qu’elle semble plus évolutive.

Cette simplicité n’est réelle que si les détails opérationnels sont explicites. Un volume Docker est géré par l’hôte, et un nom de volume local est propre à son hôte. Déplacer l’application vers un autre hôte nécessite un processus délibéré de transfert et de vérification des données. Docker documente une méthode permettant d’archiver le contenu d’un volume à l’aide d’un conteneur temporaire et de restaurer cette archive dans un volume, ce qui peut prendre en charge un flux de migration ou de récupération contrôlé.

• Montez le volume durable au chemin de données documenté de l’application.
• Ne confondez pas un chemin du système de fichiers du conteneur avec un stockage persistant.
• Consignez le nom du volume, la destination de montage, les attentes relatives à la propriété et la méthode de sauvegarde.
• Vérifiez le comportement du montage pendant le déploiement : monter un volume non vide masque les fichiers préexistants de l’image à cette destination ; un volume vide peut être rempli à partir du répertoire de l’image, sauf si la copie est désactivée.
• Séparez les données temporaires lorsque c’est possible ; un montage tmpfs ne convient qu’aux données destinées à disparaître à l’arrêt, au redémarrage ou au redémarrage de l’hôte.

Quand le stockage d’objets convient

Le stockage d’objets est une option solide lorsqu’une application le prend en charge nativement et que la charge de travail bénéficie de la séparation des objets fichiers et de l’hôte applicatif. Ne déduisez pas la compatibilité du seul fait qu’une application s’exécute dans Docker. Confirmez le backend pris en charge, les identifiants requis, l’organisation du bucket, le comportement de nommage des objets, les paramètres de diffusion par URL et toute procédure de migration dans la documentation propre à l’application.

Le stockage d’objets modifie le modèle opérationnel plutôt que de l’éliminer. Vous devez toujours décider qui peut accéder au bucket, comment les suppressions accidentelles sont traitées, comment les versions conservées influencent la récupération, et si les règles de cycle de vie correspondent aux obligations de rétention de l’organisation. Dans Amazon S3, par exemple, les buckets versionnés et non versionnés ont des comportements de suppression différents, et les règles de cycle de vie peuvent transférer ou supprimer des objets.

• Utilisez un bucket dédié ou un préfixe clairement isolé lorsque la conception de l’application le permet.
• Accordez à l’application uniquement les autorisations dont elle a besoin ; séparez les identifiants de service de l’administration humaine.
• Documentez comment les originaux, fichiers dérivés et téléversements abandonnés sont conservés ou supprimés.
• Testez la récupération avec la même configuration de bucket et le même modèle d’accès que ceux prévus en production.
• Assurez-vous qu’une politique de cycle de vie ne peut pas supprimer des données dont l’application ou ses utilisateurs ont encore besoin.

Ne faites pas d’un système de fichiers réseau partagé le choix par défaut

Un système de fichiers réseau partagé peut sembler être une solution simple lorsque plusieurs conteneurs ou nœuds sont concernés, mais il doit répondre à une exigence de l’application, et non la précéder. Plusieurs écrivains soulèvent des questions de verrouillage, de modifications concurrentes, d’autorisations et de comportement en cas de défaillance auxquelles les applications ne sont pas forcément conçues pour répondre.

Les modes d’accès au stockage de Kubernetes ne remplacent pas non plus la coordination au niveau de l’application. ReadWriteOnce signifie un montage en lecture-écriture par un seul nœud, et non nécessairement par un seul Pod. La prise en charge de ReadWriteMany dépend du plugin sous-jacent ou du pilote CSI, et les modes d’accès courants n’appliquent pas eux-mêmes une protection en écriture après le montage. Validez à la fois le comportement de la plateforme de stockage et la conception multi-instance documentée de l’application.

• Utilisez un stockage de système de fichiers partagé uniquement lorsque l’application prend en charge le modèle d’accès dont elle a besoin.
• Vérifiez si plusieurs instances peuvent écrire en toute sécurité dans les mêmes fichiers.
• Spécifiez l’implémentation de stockage sous-jacente, et pas seulement une étiquette de mode d’accès Kubernetes.
• Examinez le comportement de récupération avant de provisionner du stockage dynamique ; une StorageClass peut supprimer le stockage sous-jacent avec une politique de récupération Delete.