Bonjour à tous,
Je suis plutôt intéressé par les promesses de Docker et en particulier de CoreOS, et effectivement de premiers essais montrent que c'est plutôt pratique pour des applis web sans persistence.
Maintenant voilà, je ne suis vraiment pas rassuré d'y mettre ma base de données car on a vraiment l'impression que même si l'image se lance, les data vont se vaporiser au prochain reboot.
La question est donc, est-ce que quelqu'un l'a fait dans la vraie vie ? Est-ce que c'est viable ? Est-ce qu'il ne vaudrait pas plutôt mettre les serveurs de BDD sur des machines à part dans lesquelles on a invité etcd ?
Merci pour les retours
Le 2015-08-04 13:19, Rémy Sanchez a écrit :
Bonjour à tous,
Je suis plutôt intéressé par les promesses de Docker et en particulier de CoreOS, et effectivement de premiers essais montrent que c'est plutôt pratique pour des applis web sans persistence.
Maintenant voilà, je ne suis vraiment pas rassuré d'y mettre ma base de données car on a vraiment l'impression que même si l'image se lance, les data vont se vaporiser au prochain reboot.
En effet, c'est pour cela que la doc du conteneur MySQL de Docker recommande chaudement de mettre les données sur le système hôte, même si la base de données en elle-même tourne dans le conteneur
https://registry.hub.docker.com/_/mysql/ (section: "Where to Store Data").
On Tue, Aug 4, 2015 at 1:29 PM Xavier Claude contact@xavierclaude.be wrote:
Le 2015-08-04 13:19, Rémy Sanchez a écrit :
Bonjour à tous,
Je suis plutôt intéressé par les promesses de Docker et en particulier de CoreOS, et effectivement de premiers essais montrent que c'est plutôt pratique pour des applis web sans persistence.
Maintenant voilà, je ne suis vraiment pas rassuré d'y mettre ma base de données car on a vraiment l'impression que même si l'image se lance, les data vont se vaporiser au prochain reboot.
En effet, c'est pour cela que la doc du conteneur MySQL de Docker recommande chaudement de mettre les données sur le système hôte, même si la base de données en elle-même tourne dans le conteneur
https://registry.hub.docker.com/_/mysql/ (section: "Where to Store Data").
Il est même préconisé de créer un containeur spécialement dédié pour les données si je ne m'abuse.
Mais dans le contexte de CoreOS qui ordonnance les choses un peu comme il veut, j'ai peur de la fausse manip, qu'il bouge mes conteneurs sans raison sur un autre serveur et de me retrouver le bec dans l'eau.
2015-08-04 13:19 GMT+02:00 Rémy Sanchez remy.sanchez@hyperthese.net:
Bonjour à tous,
Je suis plutôt intéressé par les promesses de Docker et en particulier de CoreOS, et effectivement de premiers essais montrent que c'est plutôt pratique pour des applis web sans persistence.
Maintenant voilà, je ne suis vraiment pas rassuré d'y mettre ma base de données car on a vraiment l'impression que même si l'image se lance, les data vont se vaporiser au prochain reboot.
La question est donc, est-ce que quelqu'un l'a fait dans la vraie vie ? Est-ce que c'est viable ? Est-ce qu'il ne vaudrait pas plutôt mettre les serveurs de BDD sur des machines à part dans lesquelles on a invité etcd ?
Merci pour les retours
Rémy Sanchez http://hyperthese.net/
Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour Rémy,
Tu dois considérer tes containers comme un OS volatile. Tout ce qui est donnée résiliente ne doit pas y ếtre stocké. Pour ce genre de besoin, tu peux monter un volume dans le container. Ensuite, il ne reste plus qu'à dire à ton soft où lire son fichier de configuration et où stocker / lire ses données.
Baptiste
Le 4 août 2015 à 13:19, Rémy Sanchez remy.sanchez@hyperthese.net a écrit :
Bonjour à tous,
Je suis plutôt intéressé par les promesses de Docker et en particulier de CoreOS, et effectivement de premiers essais montrent que c'est plutôt pratique pour des applis web sans persistence.
Maintenant voilà, je ne suis vraiment pas rassuré d'y mettre ma base de données car on a vraiment l'impression que même si l'image se lance, les data vont se vaporiser au prochain reboot.
tu as plusieurs possibilités, créer un container "data" ou un simple dossier et l'attacher, mais cela ne fonctionne que sur la même machine. en mode "cluster", tu es obligé de passer par un stockage externe ( NAS / S3 / etc ... ) ou partagé ( glusterfs par ex ) afin que le volume soit disponible pour tous les hosts.
concernant coreos, cela a été testé et non approuvé chez nous ( repose sur systemd, le test fut rapide ;) ). Si tu veux faire du clustering docker simple, utilise rancheros. Pour les projets plus gros/sérieux/critiques, je te conseille apache mesos.
La question est donc, est-ce que quelqu'un l'a fait dans la vraie vie ? Est-ce que c'est viable ? Est-ce qu'il ne vaudrait pas plutôt mettre les serveurs de BDD sur des machines à part dans lesquelles on a invité etcd ?
Merci pour les retours
Rémy Sanchez http://hyperthese.net/ http://hyperthese.net/_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 04/08/2015 13:19, Rémy Sanchez a écrit :
La question est donc, est-ce que quelqu'un l'a fait dans la vraie vie ? Est-ce que c'est viable ? Est-ce qu'il ne vaudrait pas plutôt mettre les serveurs de BDD sur des machines à part dans lesquelles on a invité etcd ?
De notre côté la question c'est plutôt la sécurité. Ouvrir des ports dans tous les sens pour brancher les composants sur plusieurs hôtes c'est du délire niveau sécurité. L'impossibilité de faire cohabiter plusieurs applications finales (site web, api, progiciel) sur le même hôte, si un site change ses ports php / mysql dans ses fichiers de conf il accède aux dockers des autres applis ... Bref pour nous c'est juste pour faire des maquettes au même titre que vagrant. Mais j'imagine que pour un pure player web avec sa propre infra qui doit déployer n front web, n mysql y a sans doute un gain quoi qu'un ansible / puppet / chef ... fait tout aussi bien à mon sens. Question de goût donc.
Si c'est pour du semi-persistant (voire persistant) avec des serveurs qui ne sont pas en cluster et hébergeant des données spécifiques, l’intérêt de Dockers est limité au final face à une utilisation direct du système de conteneur LXC (ou VServer ou OpenVZ) sans "surcouche".
Tu te fais un template de conteneur MariaDB configuré comme tu veux et après tu peux déployer une nouvelle instance en quelques secondes en copiant l'arbo du template et en modifiant juste les quelques paramètres qui vont bien dans la conf du conteneur et eventuellement au niveau du système du conteneur (très simple vu que tu à accès à l'arbo depuis le système hôte donc de simples "sed" peuvent faire l'affaire).
A savoir que tu peux facilement partager des parties de l'arbo ou le namespace reseau par exemple entre deux conteneurs (s'ils sont sur la même machine évidemment), il est possible de partager le fichier sock de MariaDB entre deux conteneurs et donc de ne pas avoir d'accès réseau à configurer (ou de partager le même namespace réseau et de pouvoir donc se connecter sur 127.0.0.1 au niveau applicatif).
Le 04/08/2015 16:00, Wallace a écrit :
Le 04/08/2015 13:19, Rémy Sanchez a écrit :
La question est donc, est-ce que quelqu'un l'a fait dans la vraie vie ? Est-ce que c'est viable ? Est-ce qu'il ne vaudrait pas plutôt mettre les serveurs de BDD sur des machines à part dans lesquelles on a invité etcd ?
De notre côté la question c'est plutôt la sécurité. Ouvrir des ports dans tous les sens pour brancher les composants sur plusieurs hôtes c'est du délire niveau sécurité. L'impossibilité de faire cohabiter plusieurs applications finales (site web, api, progiciel) sur le même hôte, si un site change ses ports php / mysql dans ses fichiers de conf il accède aux dockers des autres applis ... Bref pour nous c'est juste pour faire des maquettes au même titre que vagrant. Mais j'imagine que pour un pure player web avec sa propre infra qui doit déployer n front web, n mysql y a sans doute un gain quoi qu'un ansible / puppet / chef ... fait tout aussi bien à mon sens. Question de goût donc.
Je ne suis pas certain de voir l'intérêt de mettre une base de données dans un container.
Perf DB = CPU * IO * RAM
Typiquement le genre d'objets qu'on ne virtualise pas.
Mais s'il faut absolument la mettre dans un container, j'irais plutôt la mettre dans un container LXC persistent, ou même juste dans un cgroups pour faire du contrôle de ressources.
Si c'est pour "sécuriser", voir firejail par example: https://l3net.wordpress.com/projects/firejail/
Cordialement, Stéphane
Rémy Sanchez a écrit :
Bonjour à tous,
Je suis plutôt intéressé par les promesses de Docker et en particulier de CoreOS, et effectivement de premiers essais montrent que c'est plutôt pratique pour des applis web sans persistence.
Maintenant voilà, je ne suis vraiment pas rassuré d'y mettre ma base de données car on a vraiment l'impression que même si l'image se lance, les data vont se vaporiser au prochain reboot.
La question est donc, est-ce que quelqu'un l'a fait dans la vraie vie ? Est-ce que c'est viable ? Est-ce qu'il ne vaudrait pas plutôt mettre les serveurs de BDD sur des machines à part dans lesquelles on a invité etcd ?
Merci pour les retours
*Rémy Sanchez* http://hyperthese.net/
Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour,
2015-08-04 16:19 GMT+02:00 Stephane Martin stephane.martin@vesperal.eu:
Je ne suis pas certain de voir l'intérêt de mettre une base de données dans un container.
Perf DB = CPU * IO * RAM
Typiquement le genre d'objets qu'on ne virtualise pas.
C'était peut-être vrai avant, mais je pense que si même Oracle se met à la virtualisation ( http://aws.amazon.com/fr/rds/oracle/ ) on doit pouvoir dire que c'est du passé, non?
D'autant que Docker (et les conteneurs en général) n'est pas de la virtualisation au sens traditionnel (ie virtualisation de matériel) mais de la virtualisation d'environnement.
En ce qui concerne les performances, IBM avait publié une étude sur le sujet l'été dernier. Le résultat est disponible en pdf ici: http://domino.research.ibm.com/library/cyberdig.nsf/papers/0929052195DD819C8...
Je vous laisse vous faire votre avis mais pour ma part, je trouve que Docker s'en sort plutôt bien. Si les questions de la connectivité (réseau et stockage) étaient réglés, il y a belle lurette que mes bases de données seraient dans des conteneurs.
Au passage après Microsoft, Oracle aussi se met à Docker. Autant sur Linux ( https://blogs.oracle.com/linux/entry/oracle_linux_images_for_docker ) que sur Solaris ( https://www.oracle.com/corporate/pressrelease/docker-gets-in-the-zone-with-o... ). Peut-être est-il encore temps de s'y mettre?
Mais s'il faut absolument la mettre dans un container, j'irais plutôt la
mettre dans un container LXC persistent, ou même juste dans un cgroups pour faire du contrôle de ressources.
Si c'est pour "sécuriser", voir firejail par example: https://l3net.wordpress.com/projects/firejail/
Cordialement, Stéphane
2015-08-04 21:22 GMT+02:00 Benoit Garcia benoit.garcia@gmail.com:
Bonjour,
2015-08-04 16:19 GMT+02:00 Stephane Martin stephane.martin@vesperal.eu:
Je ne suis pas certain de voir l'intérêt de mettre une base de données dans un container.
Perf DB = CPU * IO * RAM
Typiquement le genre d'objets qu'on ne virtualise pas.
C'était peut-être vrai avant, mais je pense que si même Oracle se met à la virtualisation ( http://aws.amazon.com/fr/rds/oracle/ ) on doit pouvoir dire que c'est du passé, non?
D'autant que Docker (et les conteneurs en général) n'est pas de la virtualisation au sens traditionnel (ie virtualisation de matériel) mais de la virtualisation d'environnement.
En ce qui concerne les performances, IBM avait publié une étude sur le sujet l'été dernier. Le résultat est disponible en pdf ici: http://domino.research.ibm.com/library/cyberdig.nsf/papers/0929052195DD819C8...
Je vous laisse vous faire votre avis mais pour ma part, je trouve que Docker s'en sort plutôt bien. Si les questions de la connectivité (réseau et stockage) étaient réglés, il y a belle lurette que mes bases de données seraient dans des conteneurs.
Au passage après Microsoft, Oracle aussi se met à Docker. Autant sur Linux ( https://blogs.oracle.com/linux/entry/oracle_linux_images_for_docker ) que sur Solaris ( https://www.oracle.com/corporate/pressrelease/docker-gets-in-the-zone-with-o... ). Peut-être est-il encore temps de s'y mettre?
Mais s'il faut absolument la mettre dans un container, j'irais plutôt la mettre dans un container LXC persistent, ou même juste dans un cgroups pour faire du contrôle de ressources.
Si c'est pour "sécuriser", voir firejail par example: https://l3net.wordpress.com/projects/firejail/
Cordialement, Stéphane
-- Cordialement, Benoit
Sans vouloir balancer sur docker, produit que j'apprécie et utilise assez régulièrement pour toute sorte de tests, niveau perf réseau, c'est pas encore ça...
Quand je bench HAProxy en natif sur mon laptop, j'ai plus de 35000 conn HTTP/s (1 requete HTTP par connection TCP, acceptée et forwardée vers un serveur, ce qui génère pleins de tout petits paquets) et je "tombe" à 6000 pour le même HAProxy dans un docker, sur la même machine. J'ai un process docker qui tourne à 100% de CPU alors que mon process HAProxy se trimbale à environ 15%...
My 2 cents,
Baptiste
Mes 50 cents,
Oui de base le networking de docker est slow. Cela concerne le mode "bridge+NAT" (défaut). De mémoire de mes tests c'est un débit divisé par 2.5 et une latence augmenté à 170% de la latence de base (sans docker).
En utilisant le networking de l'host avec --host par exemple, on est très proche des performances natives.
Le support de technologie comme vxlan permet également de retrouver des perfs quasi natives.
Bonne nouvelle, ces technologies sont applicable dans l'univers coreos (avec flannel) : plus d'infos dans l'article http://www.generictestdomain.net/docker/weave/networking/stupidity/2015/04/0....
Cordialement Tycho Le 4 août 2015 23:10, "Baptiste" bedis9@gmail.com a écrit :
2015-08-04 21:22 GMT+02:00 Benoit Garcia benoit.garcia@gmail.com:
Bonjour,
2015-08-04 16:19 GMT+02:00 Stephane Martin <stephane.martin@vesperal.eu :
Je ne suis pas certain de voir l'intérêt de mettre une base de données dans un container.
Perf DB = CPU * IO * RAM
Typiquement le genre d'objets qu'on ne virtualise pas.
C'était peut-être vrai avant, mais je pense que si même Oracle se met à
la
virtualisation ( http://aws.amazon.com/fr/rds/oracle/ ) on doit pouvoir
dire
que c'est du passé, non?
D'autant que Docker (et les conteneurs en général) n'est pas de la virtualisation au sens traditionnel (ie virtualisation de matériel) mais
de
la virtualisation d'environnement.
En ce qui concerne les performances, IBM avait publié une étude sur le
sujet
l'été dernier. Le résultat est disponible en pdf ici:
http://domino.research.ibm.com/library/cyberdig.nsf/papers/0929052195DD819C8...
Je vous laisse vous faire votre avis mais pour ma part, je trouve que
Docker
s'en sort plutôt bien. Si les questions de la connectivité (réseau et stockage) étaient réglés,
il
y a belle lurette que mes bases de données seraient dans des conteneurs.
Au passage après Microsoft, Oracle aussi se met à Docker. Autant sur
Linux (
https://blogs.oracle.com/linux/entry/oracle_linux_images_for_docker )
que
sur Solaris (
https://www.oracle.com/corporate/pressrelease/docker-gets-in-the-zone-with-o...
). Peut-être est-il encore temps de s'y mettre?
Mais s'il faut absolument la mettre dans un container, j'irais plutôt la mettre dans un container LXC persistent, ou même juste dans un cgroups pour faire du contrôle de ressources.
Si c'est pour "sécuriser", voir firejail par example: https://l3net.wordpress.com/projects/firejail/
Cordialement, Stéphane
-- Cordialement, Benoit
Sans vouloir balancer sur docker, produit que j'apprécie et utilise assez régulièrement pour toute sorte de tests, niveau perf réseau, c'est pas encore ça...
Quand je bench HAProxy en natif sur mon laptop, j'ai plus de 35000 conn HTTP/s (1 requete HTTP par connection TCP, acceptée et forwardée vers un serveur, ce qui génère pleins de tout petits paquets) et je "tombe" à 6000 pour le même HAProxy dans un docker, sur la même machine. J'ai un process docker qui tourne à 100% de CPU alors que mon process HAProxy se trimbale à environ 15%...
My 2 cents,
Baptiste _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-
Baptiste -
Benoit Garcia -
Jean Weisbuch -
Rémy Sanchez -
Stephane Martin -
Stéphane Cottin -
Tycho Tatitscheff -
Wallace -
Xavier Claude