Quelles sont les raisons pour lesquelles Docker ne doit pas être utilisé pour les bases de données?

J'ai une discussion avec un ami sur les cas d'utilisation de Docker . Un gars de l'équipe veut utiliser Docker pour tout - comme une sorte de wrapper de processus Unix universel. L'autre pense que Docker ne devrait être utilisé que pour les applications sans état comme les microservices et les applications de style AWS Lambda .

Nous avons conçu des preuves de concepts pour les deux. Sur notre cluster Docker, nous avons un lecteur partagé qui est monté lorsque l'hôte Docker est monté, et si une base de données dans un conteneur est montée, il monte simplement un volume sur le lecteur partagé.

Mon ami reste fidèle à sa position, malgré la preuve contraire. (Il fait également valoir que Docker ajoute des risques inutiles en ajoutant de la complexité à la pile.)

J'essaie d'écouter et de comprendre son point de vue, à la fois dans un acte d'empathie, mais aussi pour mieux raisonner avec lui. (Nous nous entendons tous très bien - c'est donc un mélange de plaisanteries et de discussions sérieuses).

Le type de question derrière la question est: les bases de données sont-elles des bovins ? Ce commentaire suggère qu'une bonne stratégie de sauvegarde et de récupération automatisée pour votre base de données est impossible à distinguer d'un serveur de bovins.

Ma question est: quelles sont les raisons pour lesquelles Docker ne doit pas être utilisé pour les bases de données?

EDIT: Les gens m'ont demandé de clarifier ma terminologie. Je supposais que l'application de base de données se trouvait dans le conteneur et que le stockage était dans le volume. Ce que je voulais dire, c'est que le SGBDR est dans le conteneur et le stockage de la base de données est dans le volume.

Certains commentateurs ont suggéré que les pilotes de volume docker ne fonctionneraient pas très bien avec les écritures de base de données. (Ou quelque chose à cet effet). Pourriez-vous développer cela?

Lorsque les gens parlent de l'exécution d'une base de données dans Docker, ils ne veulent pas stocker les données dans un conteneur; ils parlent d'avoir une image docker avec le logiciel DB et de monter les données en tant que volume (un volume de liaison, pas un volume de conteneur).

Les volumes sont une partie essentielle de Docker, et ne sont pas quelque chose de floconneux ou simplement collé. Docker n'est pas uniquement conçu pour les (micro) services sans état.

Quel que soit mon souhait, je ne trouve pas de raison technique de ne pas exécuter une base de données dans un Docker, donc je vais malheureusement choisir l'autre côté de l'argument et donc ne vous donnerai peut-être pas la réponse que vous recherchez.

(J'utilise Oracle comme exemple parce que je le connais, à la fois en métal nu et en dockerized, et parce que c'est une bête bien connue pour être juste un peu banale à utiliser si vous dépassez les paramètres par défaut.)

• Empaqueter le logiciel DB lui-même dans un conteneur vous offre les avantages habituels - avoir la même version partout, éviter les problèmes de dépendance / bibliothèque partagée, pouvoir faire tourner la même base de données exacte sur les ordinateurs portables des développeurs ou partout où vous en avez besoin.
• C'est un jeu d' enfant de le faire fonctionner n'importe où; la mise à jour est triviale, etc. Tous les avantages Docker s'appliquent. Il y a une image Oracle sur Dockerhub qui vous permet de faire tourner une base de données fonctionnelle en une minute ou trois (et pour les autres aussi, bien sûr).
• Les gens ont fait des tests de performances et n'ont trouvé aucune différence d'E / S entre les volumes et le métal nu ( https://www.percona.com/blog/2016/02/11/measuring-docker-io-overhead/ , https: // stackoverflow .com / questions / 21889053 / what-is-the-runtime-performance-cost-of-a-docker-container ).
• Sous le capot, ce n'est pas comme si Docker intercepte en quelque sorte toutes les E / S, de toute façon. Il devient juste créatif avec les outils Linux standard (dans ce cas, liez les montages, manipulez les tables internes du noyau qui rendent le Docker-fu possible).
• Évidemment, cela ne signifie pas que vous pouvez exécuter deux instances de la base de données et les faire simplement travailler sur les mêmes fichiers, mais personne ne l'implique. Docker ne vous donne pas un accès automatique, simultané et sans course aux volumes, et n'a jamais prétendu le faire. Les autres avantages s'appliquent toujours. Si votre base de données elle-même ne détecte pas de conflits comme celui-ci, il vaut mieux fournir un script CMD à l'image qui refuse de faire tourner un deuxième conteneur lorsque le volume est déjà utilisé.
• Vous devez être un peu plus prudent en tournant / fermant le conteneur (tout comme vous ne feriez pas simplement éteindre un serveur DB bare metal), mais cela devrait être tout à fait gérable.

Maintenant, selon les circonstances, il peut y avoir de légères raisons de ne pas le faire:

• Oracle (la société), par exemple, ne vous supportera certainement pas si vous exécutez leur SGBDR dans un conteneur Docker. Mais peut-être que vous utilisez des images RDBMS Oracle dockées uniquement pour vos développeurs et l'environnement de test, où vous n'auriez en aucun cas besoin de leur support, le réservant à un serveur de production nu. (Mais n'oubliez pas de payer vos licences ...).
• Si les opérateurs ne connaissent pas Docker, il pourrait être un peu plus facile de tout tuer accidentellement, de détruire vos fichiers de données, etc.
• Si vous avez de grandes machines à DB métallique dédié déjà, avec de grandes quantités de stockage SAN très rapide dédié, et rien en cours d' exécution d' autre de toute façon, alors il serait tout simplement inutile d'utiliser Docker conteneuriser ceux que vous ne vient tourner un autre serveur quand il sont des centaines de Go ou même des To de données. Après tout, pour la production, un SGBDR comme Oracle est très, très avancé dans tous les aspects de la réplication, de l'intégrité des données, du basculement sans interruption, etc. Notez que cet argument dit simplement "vous n'avez pas besoin de conteneuriser votre SGBDR". Il ne dit pas "vous ne devriez pas le faire" - peut-être que vous voulez le faire parce que vous souhaitez déployer des mises à niveau logicielles de base de données via des conteneurs ou pour toute autre raison que vous pourriez imaginer.

Alors voilà. Par tous les moyens , dockez votre base de données, au moins pour vos développeurs (qui seront éternellement reconnaissants) et vos environnements de test. Sur la production, cela dépendra du goût, et là au moins, je préférerais également la solution qui convient le mieux aux DBA / Ops spécialisés - s'ils ont des décennies d'expérience de travail sur des serveurs DB bare metal, alors faites-leur confiance de continuer ainsi. Mais si vous êtes une startup qui a de toute façon tout l'informatique dans le cloud, un conteneur Docker ne serait qu'un morceau d'oignon supplémentaire dans l'ensemble.

J'ai écrit à ce sujet en profondeur, mais voici le résumé:

• La prévention du split brain (élection de plus d'un nœud maître) doit être résolue. Ne pas le faire peut être catastrophique

• Il n'y a pas de solutions de stockage partagé prêtes pour la production permettant aux bases de données d'être arrêtées sur une instance et remontées sur une autre sans perdre toutes vos données.

Lorsque vous dites que les données sont montées dans un conteneur Docker, ne serait-il pas plus correct de dire que la "base de données" est montée dans le conteneur Docker? Si vous conservez vos données en dehors du conteneur, vous faites la chose "correcte" de ne pas mettre votre base de données dans un conteneur.

Bien sûr, allez en ville en mettant un SGBD dans un conteneur pour le laisser gérer les données que vous stockez à l'extérieur, personnellement, je pense que c'est juste une bonne conception car il garde une séparation nette entre la logique et les données. Mais une fois que vous avez placé vos données dans un conteneur, vous pouvez potentiellement jouer avec le feu.

Bien que les pilotes de stockage de conteneurs aient parcouru un long chemin, je ne suis personnellement pas encore prêt à plonger et à laisser mes données enchevêtrées dans un conteneur.