Comment partager des volumes sur plusieurs hôtes en mode Swarm Engine?
Pouvons-nous partager un volume nommé/unique commun entre plusieurs hôtes en mode Swarm Engine, quelle est la façon la plus simple de le faire?
Si vous avez une configuration de serveur NFS, vous pouvez utiliser certains dossiers nfs en tant que volume de docker, composez comme ceci:
volumes:
grafana:
driver: local
driver_opts:
type: nfs
o: addr=192.168.xxx.xx,rw
device: ":/PathOnServer"
À partir de zéro, Docker ne prend pas cela en charge. Vous devez utiliser des composants supplémentaires, soit un plugin docker qui vous fournirait un nouveau type de couche pour vos volumes, ou un outil de synchronisation directement sur votre FS qui synchronisera les données pour vous.
De mon point de vue, la solution la plus simple est rsync ou plus précisément lsyncdn la version démon de rsync. Mais je ne l’ai jamais essayé pour les volumes de menu fixe, je ne peux donc pas dire s’il le gère bien . D'autres solutions sont proposées avec Infinit.sh . Il fait fondamentalement la même chose que lsyncd. C'est une synchronisation à sens unique. Donc, si votre conteneur docker contient des volumes RW, il ne correspondra pas à vos attentes. J'ai essayé cette solution et elle fonctionne plutôt bien pour les opérations RO. Et pas en production. C'est toujours une version alpha. Infinit est également sur le point de fournir un pilote de menu fixe. Pas encore sorti. Donc je n'ai même pas essayé. Trop risqué.
D'autres solutions que j'ai trouvées mais que je n'ai pas pu installer (et donc essayer) sont flocker et glusterFS. Les deux sont conçus pour créer un volume FS basé sur plusieurs disques durs de plusieurs machines. Mais aucun de leurs référentiels ne fonctionnait ces dernières semaines.
Désolé de ne vous avoir donné que des solutions faibles, mais je suis confronté au même problème et je n’ai pas encore trouvé de solution parfaite.
A bientôt, Olivier
Dans le grand schéma des choses
Les autres réponses sont certainement correctes. Si vous sentez qu'il vous manque encore quelque chose ou si vous en venez à la conclusion que les choses ne s'amélioreront jamais vraiment dans cet espace, vous voudrez peut-être reconsidérer l'utilisation de l'abstraction typique du système de fichiers hiérarchique de type POSIX. Toutes les applications n'en ont pas vraiment besoin (j'irais même jusqu'à dire que peu le font). Peut-être que le vôtre non plus.
En défense des systèmes de fichiers
Il est encore très courant dans de nombreux milieux, mais généralement, ces personnes connaissent très bien leurs systèmes de fichiers distants/distribués et savent comment les configurer et les exploiter correctement (et ce sont peut-être aussi de très bons systèmes, bien que souvent pas avec les pilotes de volume Docker existants. ). Parfois, c'est aussi en partie parce qu'ils sont simplement obligés de le faire (des bases de code qui ne peuvent ou ne doivent pas être réécrites pour prendre en charge d'autres systèmes de stockage). Utiliser, configurer ou même écrire des pilotes de volume Docker arbitraires serait une préoccupation secondaire.
Des alternatives
Si toutefois vous en avez la possibilité, évaluez d’autres solutions de persistance pour vos applications. De nombreuses implémentations n'utilisent pas d'interfaces système de fichiers POSIX, mais d'interfaces réseau, ce qui ne pose pas de problèmes particuliers au niveau de l'infrastructure dans des grappes telles que Docker Swarm.
Solutions gérées par des tiers (tels que des fournisseurs de cloud computing)
Si vous parvenez à supprimer toutes les dépendances des systèmes de fichiers pour les données persistantes et partagées (cela reste correct pour transitoire état local), vous pouvez alors prétendre avoir des applications totalement "sans état". Bien sûr, il y a souvent toujours un état persistant quelque part encore, mais l'idée est que vous ne le manipulez pas vous-même. De nombreux fournisseurs de cloud (si c'est là que vous hébergez des choses) proposeront des solutions entièrement gérées pour gérer les états persistants, de sorte que vous n'ayez plus à vous en soucier. Si vous choisissez cette voie, envisagez les services gérés qui utilisent des API compatibles avec les implémentations que vous pouvez utiliser localement pour les tests (par exemple, en exécutant un conteneur Docker basé sur une image pour cette implémentation fournie par un tiers ou qui vous pouvez vous maintenir).
Solutions de bricolage
Si vous souhaitez gérer vous-même l'état persistant au sein d'un cluster Docker Swarm, l'abstraction du système de fichiers est souvent inévitable (et vous auriez probablement plus de difficultés à cibler directement les périphériques en mode bloc). Vous voudrez jouer avec les contraintes de nœud et de service pour vous assurer que les exigences de tout ce que vous utilisez pour conserver les données sont satisfaites. Pour certaines choses, comme un serveur de SGBD central, cela pourrait être facile ("exécutez toujours la tâche sur ce nœud spécifique uniquement"), pour d'autres, cela pourrait être beaucoup plus complexe.
La tâche de configuration, de dimensionnement et de surveillance d’une telle configuration n’est certainement pas triviale. C’est pourquoi de nombreux développeurs d’applications sont heureux de laisser quelqu'un d'autre (par exemple, des fournisseurs de cloud computing) le faire. C'est quand même un endroit très cool à explorer. Cependant, étant donné que vous avez dû poser cette question, il est probable que vous ne devriez pas vous concentrer dessus si vous respectez une échéance.
Conclusion
Comme toujours, utilisez la bonne abstraction pour le travail et prenez une pause pour réfléchir à vos forces et à l'endroit où vous utiliserez vos ressources.