Bonjour,je suis toujours dans les containers jusqu'au cou :). J'ai un problème : comment stocker mes données ? (BDD, ...). On m'a répondu" bind mount" ou avec des containers volume, mais je n'ai aucune idée sur ce qui est le plus adapté. D'après vos expériences, qu'est qui est le mieux sur une prod ? Merci pour vos réponses. Olivier
Salut,
Je dirais que cela dépends de ton usage, je n'utilise bind que si je veux pouvoir modifier les données utilisées par le docker sans aller dedans. Le bind permet aussi de monter des espaces disques en RO ce qui n'est pas le cas des volumes. Si c'est pour des fichiers qui ne sont utilisés que par le docker par ex. je préfère utiliser les volumes quitte à avoir à faire un "docker exec -it docker_name /bin/bash" pour rentrer dans le docker. Pour une base, je préférerai à titre personnel utiliser un volume pour la base et un pour faire les backups.
Cdt Stan
On Mon, 4 Mar 2019 at 09:50, Olivier Meyer via FRsAG frsag@frsag.org wrote:
Bonjour, je suis toujours dans les containers jusqu'au cou :). J'ai un problème : comment stocker mes données ? (BDD, ...). On m'a répondu" bind mount" ou avec des containers volume, mais je n'ai aucune idée sur ce qui est le plus adapté. D'après vos expériences, qu'est qui est le mieux sur une prod ?
Merci pour vos réponses.
Olivier _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 04/03/2019 à 09:50, Olivier Meyer via FRsAG a écrit :
Bonjour, je suis toujours dans les containers jusqu'au cou :). J'ai un problème : comment stocker mes données ? (BDD, ...). On m'a répondu" bind
Quel est le problème ? j'ai plusieurs serveur mysql en conteneur et je n'ai rien de particulier à faire... (cela dit, si je me trompe merci de me l'indiquer ;-) )
mount" ou avec des containers volume, mais je n'ai aucune idée sur ce qui est le plus adapté. D'après vos expériences, qu'est qui est le mieux sur une prod ?
Utilise mount bind si cela t'arrange: je n'ai pas connaissance de problème particulier avec cela (outre que cela rajoute des indirections supplémentaires qui complexifie les configurations et que cela est spécifique à linux) Sans plus de détails sur ta configuration ni sur ce qui te parait problématique, il est difficile d'être plus utile que par ces généralités.
Hello,
On Mon, Mar 4, 2019 at 6:41 PM un+FRsAG@pontesprit.net wrote:
Le 04/03/2019 à 09:50, Olivier Meyer via FRsAG a écrit :
Bonjour, je suis toujours dans les containers jusqu'au cou :). J'ai un problème : comment stocker mes données ? (BDD, ...). On m'a répondu" bind
Quel est le problème ? j'ai plusieurs serveur mysql en conteneur et je n'ai rien de particulier à faire... (cela dit, si je me trompe merci de me l'indiquer ;-) )
Le but est de rendre tes données indépendantes de ton application: Avec de genre de mécanismes, tu peux mettre à jour ton MySQL ou changer de moteur (Percona, Galera, version Enterprise, whatever) très facilement: Tu arrêtes ton container MySQL actuel et tu en démarres un autre qui fait tourner la nouvelle version de MySQL (et qui accède au même volume bien entendu). Il n'y a pas de migrations de données, d'imports/exports ou de restauration.
mount" ou avec des containers volume, mais je n'ai aucune idée sur ce qui est le plus adapté. D'après vos expériences, qu'est qui est le mieux sur une prod ?
Si il n'y a pas besoin d'accéder aux données depuis l'extérieur de ton
container (et ça devrait être le cas pour une base de données), je partirais sur des container volumes. Mais ce n'est que théorique, les seuls MySQL que je fais tourner dans du Docker sont pour des tests (restauration de backups, exécution de migration de données, etc).
Utilise mount bind si cela t'arrange: je n'ai pas connaissance de problème particulier avec cela (outre que cela rajoute des indirections supplémentaires qui complexifie les configurations et que cela est spécifique à linux) Sans plus de détails sur ta configuration ni sur ce qui te parait problématique, il est difficile d'être plus utile que par ces généralités.
-- Benoit
Le mardi 5 mars 2019 à 10:08:39 UTC+1, Benoit Garcia benoit.garcia@gmail.com a écrit :
Si il n'y a pas besoin d'accéder aux données depuis l'extérieur de ton container (et ça devrait être le cas pour une base de données), je partirais sur des container volumes.Mais ce n'est que théorique, les seuls MySQL que je fais tourner dans du Docker sont pour des tests (restauration de backups, exécution de migration de données, etc). ah tu m'intéresses, tu backup ta base comment ? Tu sauvegardes le volume ? Tu fait un dump ta base en dehors de ton volume ? Tu intégres un client de backup dans ton container ?quid des performances ? Olivier _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
On Tue, Mar 5, 2019 at 10:26 AM Olivier Meyer via FRsAG frsag@frsag.org wrote:
Le mardi 5 mars 2019 à 10:08:39 UTC+1, Benoit Garcia < benoit.garcia@gmail.com> a écrit :
Si il n'y a pas besoin d'accéder aux données depuis l'extérieur de ton container (et ça devrait être le cas pour une base de données), je partirais sur des container volumes. Mais ce n'est que théorique, les seuls MySQL que je fais tourner dans du Docker sont pour des tests (restauration de backups, exécution de migration de données, etc).
ah tu m'intéresses, tu backup ta base comment ? Tu sauvegardes le volume ? Tu fait un dump ta base en dehors de ton volume ? Tu intégres un client de backup dans ton container ?quid des performances ?
Je ne pense pas que la sauvegarde du volume MySQL (ou de son contenu) ne puisse garantir la consistance de la base de données (pb des transactions en cours, etc). Donc pour moi c'est à éviter.
Si je devais réaliser les sauvegardes de MySQL dockerisé, je ne changerais pas des masses par rapport à ce que je fais aujourd'hui sur un serveur(/vm) dédié: Je lancerais ma sauvegarde via un outils qui pourrait se connecter à mon instance, que ce soit un outil genre Commvault ou des plus simples genre Mysqldump ou Xtrabackup. Éventuellement j’exécuterais ça dans un conteneur éphémère qui irait créer le jeu de sauvegarde sur un volume externe. J'archiverais ensuite le contenu de ce volume (bande, s3, glacier, whatever). Reste à voir comment se feraient les restauration de données...
Et si la sauvegarde plombe vraiment les performances, il resterait la possibilité de rajouter un conteneur avec un slave et de faire la sauvegarde sur celui-ci.
Olivier
Le 5 mars 2019 à 13:10, Benoit Garcia benoit.garcia@gmail.com a écrit :
On Tue, Mar 5, 2019 at 10:26 AM Olivier Meyer via FRsAG frsag@frsag.org wrote:
Le mardi 5 mars 2019 à 10:08:39 UTC+1, Benoit Garcia benoit.garcia@gmail.com a écrit :
Si il n'y a pas besoin d'accéder aux données depuis l'extérieur de ton container (et ça devrait être le cas pour une base de données), je partirais sur des container volumes. Mais ce n'est que théorique, les seuls MySQL que je fais tourner dans du Docker sont pour des tests (restauration de backups, exécution de migration de données, etc). ah tu m'intéresses, tu backup ta base comment ? Tu sauvegardes le volume ? Tu fait un dump ta base en dehors de ton volume ? Tu intégres un client de backup dans ton container ?quid des performances ? Je ne pense pas que la sauvegarde du volume MySQL (ou de son contenu) ne puisse garantir la consistance de la base de données (pb des transactions en cours, etc). Donc pour moi c'est à éviter.
+1000, le snapshot d’un volume pour un SGBD(R) me fait toujours un peu peur, mais ça dépend du soft.
Si je devais réaliser les sauvegardes de MySQL dockerisé, je ne changerais pas des masses par rapport à ce que je fais aujourd'hui sur un serveur(/vm) dédié: Je lancerais ma sauvegarde via un outils qui pourrait se connecter à mon instance, que ce soit un outil genre Commvault ou des plus simples genre Mysqldump ou Xtrabackup. Éventuellement j’exécuterais ça dans un conteneur éphémère qui irait créer le jeu de sauvegarde sur un volume externe. J'archiverais ensuite le contenu de ce volume (bande, s3, glacier, whatever).
+2000
Reste à voir comment se feraient les restauration de données…
La plupart des (bonnes) images publiques intègre un mécanisme dans le script d'entrypoint pour importer des dumps sql (ou autre) que l’on peut passer via un volume.
Pour MySQL : https://github.com/docker-library/mysql/blob/a7a737f1eb44db467c85c8229df9d886dd63460e/8.0/docker-entrypoint.sh#L197
La convention est de placer les fichiers d'init dans /docker-entrypoint-initdb.d/
Le 05/03/2019 à 13:22, HURTEVENT VINCENT a écrit :
+1000, le snapshot d’un volume pour un SGBD(R) me fait toujours un peu peur, mais ça dépend du soft.
Plus que de faire peur c'est clairement connu comme une source de problèmes.
Tu peux le faire que sur un slave sorti de la synchro le temps de faire son snapshot et uniquement dans ce cas ou alors c'est une micro base qui fait très peu de requêtes et la personne qui gère s'en fou si ça plante.
Ca dépend,
je lock les écritures, fait un snapshot ZFS (très rapide) puis je release le lock d'écriture.
Certes, ça lock pendant quelques secondes, mais ça fonctionne pas si mal que ça.
Après sur le slave ça reste une valeur sûre (il faut bien entendu une supervision de la synchro de tes serveurs de base de données).
Cordialement, David Durieux
On Tue, 5 Mar 2019 14:37:22 +0100 Wallace wallace@morkitu.org wrote:
Le 05/03/2019 à 13:22, HURTEVENT VINCENT a écrit :
+1000, le snapshot d’un volume pour un SGBD(R) me fait toujours un peu peur, mais ça dépend du soft.
Plus que de faire peur c'est clairement connu comme une source de problèmes.
Tu peux le faire que sur un slave sorti de la synchro le temps de faire son snapshot et uniquement dans ce cas ou alors c'est une micro base qui fait très peu de requêtes et la personne qui gère s'en fou si ça plante.
salut,
Je comprends pas très bien, quelle est la différence entre le snapshot à chaud et une coupure de courant par exemple ? C'est pas censé respecter les propriétés ACID un SGBD ?
À+
Le 05/03/2019 à 14:55, David Durieux a écrit :
Ca dépend,
je lock les écritures, fait un snapshot ZFS (très rapide) puis je release le lock d'écriture.
Certes, ça lock pendant quelques secondes, mais ça fonctionne pas si mal que ça.
Après sur le slave ça reste une valeur sûre (il faut bien entendu une supervision de la synchro de tes serveurs de base de données).
Cordialement, David Durieux
On Tue, 5 Mar 2019 14:37:22 +0100 Wallace wallace@morkitu.org wrote:
Le 05/03/2019 à 13:22, HURTEVENT VINCENT a écrit :
+1000, le snapshot d’un volume pour un SGBD(R) me fait toujours un peu peur, mais ça dépend du soft.
Plus que de faire peur c'est clairement connu comme une source de problèmes.
Tu peux le faire que sur un slave sorti de la synchro le temps de faire son snapshot et uniquement dans ce cas ou alors c'est une micro base qui fait très peu de requêtes et la personne qui gère s'en fou si ça plante.
Liste de diffusion du FRsAG http://www.frsag.org/
Le 5 mars 2019 à 16:16, Sébastien Le Ray sebastien-frsag@orniz.org a écrit :
salut,
Je comprends pas très bien, quelle est la différence entre le snapshot à chaud et une coupure de courant par exemple ? C'est pas censé respecter les propriétés ACID un SGBD ?
De mon point de vue, ça peut être ACID au niveau du service applicatif mais pas forcément consistent au niveau stockage en cas d’incident. Le snapshot au niveau du stockage est intéressant pour de petites bases, que ne sont pas forcément réparties, au niveau FS, serveurs de stockage, etc.
PostgreSQL par exemple te dit que le snapshot c’est ok si ton WAL est activé, car il servira à rejouer les transaction qui n’ont pas forcément été écrites durablement.
Mais si ton WAL est activé, autant streamer ton WAL sur un stockage externe, pour faire de la sauvegarde continue et de la restauration PITR et c’est 100%pévu pour.
Les snapshots, ça présente toujours un risque, sans doute petit, mais si tu y mets tes sauvegardes, c’est dommage.
À+
Le 05/03/2019 à 14:55, David Durieux a écrit :
Ca dépend,
je lock les écritures, fait un snapshot ZFS (très rapide) puis je release le lock d'écriture.
Certes, ça lock pendant quelques secondes, mais ça fonctionne pas si mal que ça.
Après sur le slave ça reste une valeur sûre (il faut bien entendu une supervision de la synchro de tes serveurs de base de données).
Cordialement, David Durieux
On Tue, 5 Mar 2019 14:37:22 +0100 Wallace wallace@morkitu.org wrote:
Le 05/03/2019 à 13:22, HURTEVENT VINCENT a écrit :
+1000, le snapshot d’un volume pour un SGBD(R) me fait toujours un peu peur, mais ça dépend du soft.
Plus que de faire peur c'est clairement connu comme une source de problèmes.
Tu peux le faire que sur un slave sorti de la synchro le temps de faire son snapshot et uniquement dans ce cas ou alors c'est une micro base qui fait très peu de requêtes et la personne qui gère s'en fou si ça plante.
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
L'usage conseillé par Docker est dans le cas général d'utiliser un volume de données, ce qui permet d'en faire ce que tu veux (partage, export, sauvegarde, etc) avec le plus de souplesse possible.
On Mon, 4 Mar 2019 18:41:14 +0100 un+FRsAG@pontesprit.net wrote:
Utilise mount bind si cela t'arrange: je n'ai pas connaissance de problème particulier avec cela (outre que cela rajoute des indirections supplémentaires qui complexifie les configurations et que cela est spécifique à linux)
L'inconvénient principal sera de devoir gérer les droits de ce montage sur l'hôte ; car en effet, comme tu auras suivi les recommandations et n'auras pas lancé ton service conteneurisé en root, il faudra des droits cohérents entre le conteneur et l'hôte (typiquement l'utilisateur mysql n'existera pas sur l'hôte, et il faudra donc réserver un uid/gid sur l'hôte qui correspondra à celui du conteneur).
Aloha,
Si c’est pour du MySQL, j’avais utilisé il y a quelque mois un post de severalnines pour monter une infra Galera sur Docker/K8s.
https://severalnines.com/blog/mysql-docker-running-galera-cluster-clustercon...
Après ca depend si ton docker et sur du baremetal ou de la VM et de l’orchestration. Perso pour se projet j’ai utiliser la plateforme redhat virtu + Atomic pour K8s.
On 6 March 2019 at 15:50:49, yk+frsag@64.re (yk+frsag@64.re) wrote:
L'usage conseillé par Docker est dans le cas général d'utiliser un volume de données, ce qui permet d'en faire ce que tu veux (partage, export, sauvegarde, etc) avec le plus de souplesse possible.
On Mon, 4 Mar 2019 18:41:14 +0100 un+FRsAG@pontesprit.net wrote:
Utilise mount bind si cela t'arrange: je n'ai pas connaissance de problème particulier avec cela (outre que cela rajoute des indirections supplémentaires qui complexifie les configurations et que cela est spécifique à linux)
L'inconvénient principal sera de devoir gérer les droits de ce montage sur l'hôte ; car en effet, comme tu auras suivi les recommandations et n'auras pas lancé ton service conteneurisé en root, il faudra des droits cohérents entre le conteneur et l'hôte (typiquement l'utilisateur mysql n'existera pas sur l'hôte, et il faudra donc réserver un uid/gid sur l'hôte qui correspondra à celui du conteneur). _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 6 mars 2019 à 17:14, professor geek <prg33k@gmail.commailto:prg33k@gmail.com> a écrit :
Aloha,
Si c’est pour du MySQL, j’avais utilisé il y a quelque mois un post de severalnines pour monter une infra Galera sur Docker/K8s.
https://severalnines.com/blog/mysql-docker-running-galera-cluster-clustercon...
Après ca depend si ton docker et sur du baremetal ou de la VM et de l’orchestration. Perso pour se projet j’ai utiliser la plateforme redhat virtu + Atomic pour K8s.
Pour de l’infra conteneurisée dans Kubernetes, je pense qu’il vaut mieux se tourner vers les operators existants et éviter de faire soit même. Je ne connais pas les operators MySQL existants, mais ça fera sans doute tout ce que vous voulez, HA, scale up, backup, restauration, du DBaaS en somme.
- https://github.com/oracle/mysql-operator - https://github.com/presslabs/mysql-operator - https://kubedb.com/docs/0.10.0/guides/mysql/
On 6 March 2019 at 15:50:49, yk+frsag@64.remailto:yk%2Bfrsag@64.re (yk+frsag@64.remailto:yk+frsag@64.re) wrote:
L'usage conseillé par Docker est dans le cas général d'utiliser un volume de données, ce qui permet d'en faire ce que tu veux (partage, export, sauvegarde, etc) avec le plus de souplesse possible.
On Mon, 4 Mar 2019 18:41:14 +0100 un+FRsAG@pontesprit.netmailto:un%2BFRsAG@pontesprit.net wrote:
Utilise mount bind si cela t'arrange: je n'ai pas connaissance de problème particulier avec cela (outre que cela rajoute des indirections supplémentaires qui complexifie les configurations et que cela est spécifique à linux)
L'inconvénient principal sera de devoir gérer les droits de ce montage sur l'hôte ; car en effet, comme tu auras suivi les recommandations et n'auras pas lancé ton service conteneurisé en root, il faudra des droits cohérents entre le conteneur et l'hôte (typiquement l'utilisateur mysql n'existera pas sur l'hôte, et il faudra donc réserver un uid/gid sur l'hôte qui correspondra à celui du conteneur). _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/ _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 06/03/2019 à 17:24, HURTEVENT VINCENT a écrit :
Pour de l’infra conteneurisée dans Kubernetes, je pense qu’il vaut mieux se tourner vers les operators existants et éviter de faire soit même.
Pour payer plus cher et perdre les compétences en interne dans une boite y a rien de mieux.
Je compte plus toutes les boites qui ont fermé à cause d'une infra entièrement déléguée dans le cloud et qui coûtait tellement cher à la fin par rapport à une infra en propre dans deux DC qu'ils ont pas eu le choix que d'arrêter les frais. Et quand ils ont voulu sortir pour économiser, la facture prévisionnelle de la bande passante de synchronisation des bases de données le temps de mettre quelques slaves ailleurs, les synchroniser et arrêter côté cloud leur aurait coûté 2 fois le prix de l'infrastructure ...
Les DSI ne parlent plus que d'hybridation après avoir juré que par le 100% Cloud, pourquoi? Le prix d'une part, la perte de la maitrise de l'infrastructure, la dépendance trop forte à des technologies fermées (coucou AWS), l'exploitation faite des données par les cloud providers.
En ce moment on bosse que sur de la réinternalisation d'application non publiques (compta, erp, crm, partage de fichier, bases de données, git, ...) pour nos grands comptes. Bien entendu @job on leur infogère cette infra qui revient, même s'ils ne le font pas directement, le fait d'être au courant de comment c'est monté et comment ça marche permet de garder un regard sur l'infra. Les RSSI adorent car chez les clouds ils ont plus grand chose à faire en dehors du code des applis.
Les moyens et les petits clients ne se rendent pas encore compte que cela va leur coûter très cher à la fin, dommage.
Le 6 mars 2019 à 17:45, Wallace wallace@morkitu.org a écrit :
Le 06/03/2019 à 17:24, HURTEVENT VINCENT a écrit :
Pour de l’infra conteneurisée dans Kubernetes, je pense qu’il vaut mieux se tourner vers les operators existants et éviter de faire soit même.
Pour payer plus cher et perdre les compétences en interne dans une boite y a rien de mieux.
Kubernetes se déploie aussi on permise. Je ne parle pas d’un opérateur de cloud public, mais d’un « operator » pour Kubernetes qui est un modèle qui permet d’exploiter des applications statefull dans kubernetes.
Je compte plus toutes les boites qui ont fermé à cause d'une infra entièrement déléguée dans le cloud et qui coûtait tellement cher à la fin par rapport à une infra en propre dans deux DC qu'ils ont pas eu le choix que d'arrêter les frais. Et quand ils ont voulu sortir pour économiser, la facture prévisionnelle de la bande passante de synchronisation des bases de données le temps de mettre quelques slaves ailleurs, les synchroniser et arrêter côté cloud leur aurait coûté 2 fois le prix de l'infrastructure ...
Les DSI ne parlent plus que d'hybridation après avoir juré que par le 100% Cloud, pourquoi? Le prix d'une part, la perte de la maitrise de l'infrastructure, la dépendance trop forte à des technologies fermées (coucou AWS), l'exploitation faite des données par les cloud providers.
En ce moment on bosse que sur de la réinternalisation d'application non publiques (compta, erp, crm, partage de fichier, bases de données, git, ...) pour nos grands comptes. Bien entendu @job on leur infogère cette infra qui revient, même s'ils ne le font pas directement, le fait d'être au courant de comment c'est monté et comment ça marche permet de garder un regard sur l'infra. Les RSSI adorent car chez les clouds ils ont plus grand chose à faire en dehors du code des applis.
Les moyens et les petits clients ne se rendent pas encore compte que cela va leur coûter très cher à la fin, dommage.
Liste de diffusion du FRsAG http://www.frsag.org/
-
Benoit Garcia -
David Durieux -
HURTEVENT VINCENT -
Olivier Meyer -
professor geek -
Stan Garret -
Sébastien Le Ray -
un+FRsAG＠pontesprit.net -
Wallace -
yk+frsag＠64.re