Pour les applications qui partagent des fichiers entre plusieurs paliers — serveurs d’application lisant des téléversements, répartiteurs servant des assets statiques, pipelines de build récupérant des artéfacts — il est plus simple de centraliser ces données dans un seul conteneur que de les dupliquer sur chaque nœud. La plateforme expose ce patron comme conteneur de stockage partagé : un conteneur système optimisé pour le stockage de données, avec l’espace disque, la surface d’exports et le modèle de permissions nécessaires pour servir de source unique aux fichiers partagés.
Quand utiliser un conteneur de stockage dédié
Un conteneur de stockage partagé convient lorsque vous avez l’un des besoins suivants :
- Le même jeu de données servi en lecture seule à un palier applicatif multi-nœuds et en lecture/écriture à un palier d’admin ou de build.
- Des fichiers de configuration communs utilisés par des nœuds sur des paliers ou des environnements différents du même compte.
- Des dumps de base de données produits par une tâche de sauvegarde planifiée, conservés sur un hôte séparé du conteneur de base de données.
- Une zone de transit pour des assets livrés à plusieurs environnements (dev, staging, prod) sous le même compte.
Ce que vous obtenez
Placer les données partagées dans un conteneur dédié, plutôt que de faire porter les deux rôles par un de vos nœuds applicatifs, présente plusieurs avantages concrets.
- Isolation de charge. Si quelque chose sur le conteneur de stockage — un export lourd, une tâche de synchronisation — fait grimper les I/O, cela ne se voit pas dans le temps de réponse de votre application. Les deux charges tournent sur des conteneurs distincts.
- Isolation de cycle de vie. Vous pouvez redéployer, mettre à l’échelle ou reconstruire votre palier applicatif sans toucher aux données. Le conteneur de stockage conserve son disque, ses exports et ses permissions de point de montage à travers les redéploiements des paliers qu’il sert.
- Hygiène d’environnements. Plusieurs environnements — dev, test, prod — peuvent monter le même jeu de données sous leurs propres règles de permissions. Le nommage de domaines, les chemins de montage et le contrôle d’accès restent cohérents.
- Sauvegarde hors hôte. Monter le dossier de sauvegarde de la base de données sur le conteneur de stockage partagé déporte les sauvegardes hors de l’hôte de la base. Les dumps planifiés atterrissent sur un autre disque sur un autre conteneur, ce qui les fait survivre à un redéploiement de la base.
Exports NFS externes
Un conteneur de stockage partagé peut aussi servir de serveur NFS externe. Si vous attachez une IP publique, configurez /etc/exports et ouvrez les ports NFS dans le pare-feu, le conteneur devient joignable depuis des clients hors du compte. C’est la brique de base pour partager des données entre installations PaaS ou avec des services externes qui parlent déjà NFS.
Le cas externe demande une configuration explicite des deux côtés — vous configurez l’export sur le conteneur de stockage, puis vous le montez sur chaque client externe. La plateforme ne lie pas les deux automatiquement parce que le côté client est, par définition, hors de son contrôle.
Pour le partage interne — clients et serveur dans le même compte — la plateforme prend en charge la seconde moitié automatiquement. Configurez l’export sur le conteneur de stockage et le point de montage correspondant apparaît sur le nœud cible sans configuration manuelle.
La suite
- Exports de stockage — partager un répertoire de votre conteneur de stockage vers d’autres nœuds du compte.
- Points de montage — monter un répertoire distant sur un conteneur client.
- Configuration d’un serveur NFS externe — transformer le conteneur de stockage en serveur NFS joignable de l’extérieur.
- Stockage NFS externe — connecter un serveur NFS hors plateforme.