Débat sur les conteneurs : single ou multi services ?

Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Débat sur les conteneurs : single ou multi services ?

zer

Bonjour à tous,

Il y a un point sur l'utilisation de Docker qui reste flou pour moi et dont je n'arrive pas à saisir toutes les subtilités.

Le fait est que Docker encourage fortement à appliquer la règle du 1 container = 1 service.
Si je comprend bien, pour installer Wodpress, ça nous donne :
1 container pour apache
1 container pour mysql
1 container pour php
1 container pour wordpress (encore que vu qu'il n'y a que des fichiers, on doit pouvoir les mettre dans une partition "data" du serveur)

Mais je trouverai ça plus efficace d'utiliser 1 container par application du type :

Par exemple, un container "Wordpress" contiendra :
- apache
- mysql
- php
- wordpress

un autre container "owncloud", contiendra :
- apache
- mysql
- php
- owncloud

Certes, on multiplie les instances de apache, mysql... Mais les avantages de cette solution sont quand même nombreux en terme d'installation, d'administration et même de continuité de service :
- Besoin de sauvegarder owncloud ? un export du container en question et paf, tranquille.
- Besoin de déplacer Wordpress sur un autre serveur ? Facile, j'exporte le container wordpress du serveur A, je l'importe direct dans le serveur B et c'est fait.
- si owncloud fait tomber mysql pour une raison X, alors ça n'impactera pas wordpress qui est complètement isolé.

Qu'est-ce que j'ai mal compris dans l'utilisation de Docker ?
Merci de vos réponses éclairées

Hardware

Ça dépend de tes besoins, si tu a une base de donnée qui est utilisée par une seule application, c'est peut-être mieux de tout mettre dans le même conteneur. Au contraire, si tu as une base de donnée partagée entre de multiples applications (exemple avec le serveur mail postfixadmin --> mysql <-- postfix), vaut mieux un conteneur séparé.

J'aurais même tendance à dire qu'un conteneur hébergeant une base de donnée en prod ne devrait jamais être présente sur la même machine physique que l'application, mais plutôt sur un serveur séparé et isolé d'internet, accessible uniquement depuis l'autre serveur, dans un tel cas, les conteneurs seront forcément séparés.

Un autre cas qui peut être intéressant quand on utilise des conteneurs séparés, c'est l'utilisation de plusieurs instances d'une même application (scabilité horizontale), exemple avec un chat :

On peut multiplier le nombre de conteneur pour supporter une montée en charge, les utilisateurs ne se connectant pas tous à la même instance mais les données entre les instances sont les mêmes vu que le backend redis lui est unique (on peut aussi imaginer plusieurs instances redis synchronisées avec un mécanisme de round robin).

Wonderfall

L'intérêt de ce découpage réside dans la scalabilité. Cf. message ci-dessus.
J'ai envie de dire que c'est aussi courant de faire du multi-processus dans ce genre de cas, et de faire un conteneur all-in-one. Sur le Hub, tu trouveras d'ailleurs de nombreuses builds Wordpress et Owncloud qui embarquent le serveur web, PHP et MySQL (ou sqlite tout simplement) dans le même conteneur.

xataz

Salut,

Question très interressante, qui malheureusement n'a pas de réponse toutes faites.

D'abord un conteneur = 1 service => Oui, mais ceci est relatifs, apache2 est un service applicative, mais apache+mysql+php+owncloud est également un service.

Après comme le dit Hardware, dans certains cas il faut penser à la scalabilité, donc dans ce cas séparer les services applicatives est un avantages. Il faut également penser à la mise à jour d'un conteneur, par exemple passage de owncloud 7 à 8, car le but étant de mettre à jour l'image, et non le conteneur directement.

Il y a plusieurs façon de travailler avec docker, et je ne suis pas sur qu'il y ai une solution plus adapté qu'une autre.

Personnellement sur ce genre de service, j'aurais tendance à faire :
1. apache+php+owcloud
2. apache+php+wordpress
3. Mysql
4. Nginx pour reverse proxy

Le tous avec les données, et les configurations hors des conteneurs.
Et donc pour la sauvegarde, je sauvegarde que le répertoire /docker de l'hôte, qui contient la configuration des conteneurs, ainsi que les dockerfiles (qui eux sont sauvegardé sur github, et le dockerhub).

Hardware

J'avoue que niveau sauvegarde, cette méthodologie est juste parfaite, un simple backup du répertoire /docker et c'est terminé. Je vais pas tarder à enterrer mon script de sauvegarde je sens

Wonderfall

Personnellement c'est /docker pour les images et les conteneurs (40Go), et /home/docker pour la configuration et les fichiers. C'est à peu près pareil, et finalement tu as un juste ce dossier à backup pour remettre tes services en route et en quelques secondes. Les images sont sur le Hub, les dockerfiles sur Github.