Docker et la tendance de la conteneurisation

smolski · 18-02-2018 05:14:25

Un lien fourni par bendia à propos de l'utilisation de Docker et sa critique :
https://blog.imirhil.fr/2016/10/09/dock … -hell.html

Passionnant !

hyrr0 · 22-02-2018 14:52:54

Salut smolski et merci à toi et bendia pour l'article.

C'est marrant de voir écrit noir sur blanc ce que des années de pratiques m'ont apprises et que je n'ai jamais écrites. Comme quoi, certaines personnes ont un talent inné pour l'écriture et le transfert de connaissances. Chapeau à l'auteur et merci à lui.

Je partage pas mal de ses avis. Que la "hype" Docker est une tendance mais que ça n'est pas une solution.

En soit, Docker est une bonne chose. Enfin, Docker n'apporte rien de nouveau. La société se base sur les LXC (Linux Containers) qui existaient déjà mais que personne utilisait. Ils fournissent "juste" un logiciel au dessus de tout ça. Bref, passons... sans commencer dans le technique, on peut essayer de comprendre la hype qui se créée autour de Docker. Pourquoi? C'est une boîte de la Sillicon Valley. Comme Google et Facebook. Ils ont su apporter une réponse à des problèmes en entreprise et dans le monde du développement. Et c'est vrai que ça a aidé!

Moi même je bosse souvent avec Docker. Je teste une base de donnée, je change de version... bref, ça a ce côté pratique du "plugnplay". J'arrive avec mon conteneur, je l'utilise, il dégage. Mon système reste propre. En développement, c'est cool pour ça! En plus, ça permet d'avoir le même environnement que le serveur de prod. Donc ça évite certains bugs de version par exemple. Sur le papier, c'est magique !

Dans les faits, j'ai bossé pour une petite startup (aujourd'hui fermée) quand j'étais en stage ingénieur. Là, c'était l'avènement du "TOUT DOCKER". On bossait sur des conteneurs, avec des conteneurs pour compiler, des conteneurs pour tester, des conteneurs partout! Limite si y'en avait pas dans ton assiette le midi. Et bah franchement, c'était le pire stage de ma vie. J'ai passé 3 mois, tous les jours, à galérer comme un porc avec ces conteneurs. Le site était codé en Java. Je réalisais mon code puis, compilais pour enfin aller vérifier le résultat dans le navigateur. Pour faire cette simple action, il me fallait exécuter 4 conteneurs qui se recréaient depuis 0 (heureusement, docker-compose existait!). ça prenait du temps, beaucoup de temps! comparé à une simple JVM installée sur le PC.

Quand il fallait mettre en prod, c'était la même galère! Tout était dans des conteneurs; Fallait tout démonter, recréer, remonter. Alors que, quand on y pense... on aurait pu juste copier un war généré par Spring sur notre serveur Tomcat. ça aurait prit quoi... 5 minutes en comptant la pause café. Là, c'était juste la journée (qui plus est, le dimanche -- bah oui, faut pas gêner les clients en semaine...).

Bon, tout ça, c'est l'aspect négatif! Pour le positif, cet article oublie de parler d'un point à mon avis important. Quand on créé un conteneur (surtout pour du web) on "expose" des ports. Le conteneur à lui seul agit comme une sorte de Firewall et permet d'éviter que des ports qui auraient été nativement exposés le soit à l'extérieur. Il évite donc autant de potentielles attaques.

Mon bilan : Perso j'utilise Docker à des fins de développement. Jamais en production (sauf sur des très vieilles machines dont je ne peux pas avoir les dernières versions nécessaires à l'exécution du projet). Je préfère de loin maitriser mes environnements et pouvoir les gérer rapidement via un tunnel SSH par exemple plutôt que de devoir tout reconstruire ce qui induit nécessaire un temps non négligeable pour moi, et pour les utilisateurs des clients qui sont coupés du service.

Là c'est en plein "boom"! Ca fait un an ou deux que Docker vit une épopée miraculeuse. Pour moi, ça va vite se tasser quand tout le monde aura finit par voir ce que l'auteur de l'article et moi avons vu.

bendia · 22-02-2018 20:45:46

Merci pour ton témoignage de pro

Pour ma part, je ne suis qu'un modeste amateur, j'ai juste tenté de joué avec, en déployant Octoprint, serveur d'impression 3D. Ce logiciel est codé en python et est installable via pip. Je crois même le package installé créé un environnement virtuel tout seul

Donc, en gros, le container n'apporte pas grand chose dans ce cas (si une version du slicer Cura compatible avec Octoprint).

Je pense qu'a mon petit niveau, si je devais isoler des applications, j'opterais plutôt pour des container LXC "fait main".

Pourtant, de récentes discussions chez les développeurs Debian (en anglais, désolé smolski

) évoque le container comme solution à l'énorme difficulté de packager des applications complexes (web souvent), comme Dolibarr ou Gitlab par exemple.

Mercredi · 22-02-2018 22:24:54

bendia a écrit :

Pourtant, de récentes discussions chez les développeurs Debian (en anglais, désolé smolski tongue ) évoque le container comme solution à l'énorme difficulté de packager des applications complexes (web souvent), comme Dolibarr ou Gitlab par exemple.

Après je ne sais pas si ces applications web sont couramment installée via les dépôts Debian.
J'utilise Dolibarr et je préfère de loin installer avec l'archive du site de Dolibarr ; cela permet une plus grande indépendance (version utilisée, test des mises à jour sur une copie avant de décider si je la fait "en prod" ou non, etc ...).

Pour les cms (je pense à Wordpress) les versions sont souvent "trop vieilles" car ça évolue trop vite par rapport au cycle stable de Debian.

Ps : j'ai découvert récemment qu'avec LXC on peut "virtualiser" sur un pc qui ne le peut pas, genre mon Acer avec son Celeron. Finalement c'est pas mal LXC

bendia · 22-02-2018 22:35:06

Mercredi a écrit :

Après je ne sais pas si ces applications web sont couramment installée via les dépôts Debian.

Tout à fait, c'est ce que pointe la discussion des devs Debian. Le problème, c'est que tu te prives ainsi de la maintenance du projet Debian, en terme de sécurité notamment, ou de garanties concernant la licence des logiciels que tu utilises.

Si une bibliothèque utilisée par une appli web présente une faille de sécurité, c'est alors au développeur de cette appli de la corriger, et à toi de mettre à jour à la main. Si tu multiplie par le nombre d'appli, voire, le nombre de version de la même bibliothèque utilisée par différentes applis, ça peut vite devenir compliqué

Mercredi · 23-02-2018 09:42:55

Pour utiliser un cms à gaz, je confirme que faire les mises à jour soi-même est assez fastidieux notamment lorsqu'elles sont fréquentes.
Aller lire les forums dédiés pour voir si il y a des remontée de bugs, tester sur la version de test, faire toutes les vérifications, repérer les changements apportés par la maj qui doivent être répercutés sur des fichiers que j'ai modifié pour les adapter à mon besoin (thème par exemple), les répercuter/adapter ; puis si tout va bien, passer en prod.

Ce cms n'étant pas dans les dépôts je n'ai de toute façon pas le choix mais même si je l'avais je préférerai toujours faire à la main.
Pour moi un cms ou erp comme Dolibarr s'installe indépendamment du système d'exploitation car ce sont 2 choses qui doivent impérativement se gérer indépendamment, même si ça demande plus de travail.

hyrr0 · 23-02-2018 10:51:01

bendia a écrit :

Pourtant, de récentes discussions chez les développeurs Debian (en anglais, désolé smolski ) évoque le container comme solution à l'énorme difficulté de packager des applications complexes (web souvent), comme Dolibarr ou Gitlab par exemple.

Faut regarder du bon côté de la lorgnette. C'est plus simple à déployer. Mais faut quand même quelqu'un pour maintenir l'image à jour.

Alors oui, ça simplifie un déploiement rapide. C'est cool pour les petites boites ou les particuliers qui ont besoin d'un truc rapide à mettre en place. Mais je reste "vieux con" à dire que quand on commence à taper dans le domaine du distribué, de la gestion des ressources fine... bref qu'on commence à tuner un peu... là Docker n'a pas sa place. Ils proposent des solutions... Y'a Docker swarn, Kubernetes... Mais rien ne vaut l'expertise d'un admin sys dédié ou, à minima, d'un devops.

Docker à ce côté pratique dans la vie de tous les jours. Dans les solutions apportées à des prises de tête techniques qui sont (je me répète) très bien pour les petites structures. Mais un moment faut s'en abstraire. Le "tout docker" est à mon sens une très mauvaise idée et ce, ne serait-ce que pour une simple raison : On oublie les basiques. N'importe qui peut déployer n'importe quoi. Sauf que derrière, peu de gens savent vraiment maitriser ce qu'il se passe. Et moi, ça me fait peur! Docker sur un CV ça fait cool. C'est jeune, et ça a la côte. Mais en vrai, c'est comme si vous marquiez sur ce CV "j'ai pas le permis mais je sais conduire si besoin".

bendia · 23-02-2018 13:32:40

hyrr0 a écrit :

Faut regarder du bon côté de la lorgnette. C'est plus simple à déployer. Mais faut quand même quelqu'un pour maintenir l'image à jour.

Certes. Ceci-dit, c'est pareil avec un paquet, il faut bien le maintenir aussi. Qui plus est, container ou paquet, tu ne règles pas le problème de compréhension de ce qu'il y a dedans, ça juste marche.

En gros, tu fais confiance au mainteneur (du paquet ou de l'image). La discussion en cours chez les devs Debian porte plutôt sur l'aspect compliqué, voir impossible de créer un paquet utilisant des bibliothèques compatible avec celles disponible dans la distribution, avec des applications qui changent sans arrêt de bibliothèque cassant la rétrocompatibilité. En gros, si un mainteneur Debian créé une image Docker, embarquant ces bibliothèques particulières, et qu'il est en mesure d'en assurer la maintenance de sécurité, en ajoutant/adaptant les outils qui automatisent tout ça dans le projet Debian, ça ne change pas grand chose pour nous, utilisateurs finaux (à défaut d'être finauds ), sauf d’alourdir un peu le poids des applications avec pas mal de lib en multiple versions.

La discussion parle aussi de problèmes légaux, avec la disponibilité des sources et des licences de ces libs, pour du javascript minifié notamment si je pige bien. Là, container ou pas, ça ne change pas grand chose

En fait, cette tendance remet pas mal en cause le principe même d'une distribution avec un cycle de parution relativement long telle que Debian. Note que retrouve aussi une problématique similaire avec les applications desktop et les Appimges, flatpacks et autre snap. A l'instar d'Octoprint, je n'ai que très peu d'applications du domaine du making/DIY disponible dans les dépôts. Que ça soit l'Arduino ou l'impressin 3D, c'est uniquement disponible sous forme d'Appimages

hyrr0 · 23-02-2018 14:16:32

Tu as parfaitement raison. Et ta comparaison est parfaitement juste d'ailleurs. Un package est exactement la même chose. Quelqu'un a compilé un programme et l'a distribué pour les autres. Cependant, quand tu as besoin d'un truc "sur-mesure" la seule solution reste la compilation. Je l'admets, c'est marginal. Et ça arrache une épine du pied à bien du monde. Mais connaitre comment un package est fait est aussi important que pour un conteneur. Car lorsque ça fonctionne pas, à part pleurer et attendre une màj des dépôts y'a pas beaucoup de solutions (sans mettre les mains dedans j'entends).

Y'a quelques années j'ai repris avec un devops toute l'architecture de notre chaine d'intégration continue sous Docker. Cette même chaîne qu'il avait créée en deux semaines était déployée en une demie journée.

Je crache pas sur Docker. C'est vraiment pratique. Je crache sur la hype qu'il y a autour. On veut faire du conteneur partout et pour tout. C'est bien. Mais Jean-Michel Toutlemonde qui va mettre en prod un Wordpress pour l'association de bridge du club des anciens aura bien du mal à débugger si le conteneur est foireux

Artheriom · 23-02-2018 14:22:29

Salut,

Article très intéressant en effet, concernant Docker, une technologie que j'utilise fréquemment pour déployer en prod... Mon environnement de dev, ça ressemble plutôt à, hum, un champ de mine qui a été bombardé intensivement et soumis à des tirs de mortier.

Je ne suis cependant pas d'accord sur les points noirs évoqués plus haut. Il est tout à fait possible de lancer plusieurs processus dans une image Docker. Il est tout à fait possible de mettre un conteneur Docker à jour sans le détruire également. Cela demande simplement un effort supplémentaire sur l'architecture du code, ce qui peut être rebutant aux premiers abords.

Techniquement, que fait Docker ? Il construit une image à partir d'un fichier (j'utilise un Makefile personnellement, mais on peut aussi utiliser une structure xml), et cette image va avoir un point d'entrée, un script d’exécution. Une fois ce script terminé, le container qui contient l'image qu'on à lancer va s'arrêter. A comprendre par là que, admettons, si on tape "service apache2 start", l'image va automatiquement s'arrêter : Dans le container, le service apache2 va démarrer, puis le prompt va revenir, ok j'ai fini mes commandes, je me stoppe. Idem, si on lance un truc dans un screen, ça va s'arrêter immédiatement. Le but, c'est que le container tourne tant qu'il à des instructions à effectuer.

FROM debian:stretch

RUN apt-get update && apt-get install -y apache2

COPY apache2.conf /etc/apache2/apache2.conf

ENV APACHE_CONFDIR /etc/apache2 

ENV APACHE_ENVVARS $APACHE_CONFDIR/envvars 

ENV APACHE_RUN_USER www-data 

ENV APACHE_RUN_GROUP www-data 

ENV APACHE_RUN_DIR /var/run/apache2

ENV APACHE_PID_FILE $APACHE_RUN_DIR/apache2.pid 

ENV APACHE_LOCK_DIR /var/lock/apache2 

ENV APACHE_LOG_DIR /var/log/apache2 

ENV LANG C 

RUN mkdir -p $APACHE_RUN_DIR $APACHE_LOCK_DIR $APACHE_LOG_DIR

EXPOSE 80 

CMD ["apache2", "-DFOREGROUND"]

Bon, c'est un exemple fait à l'arrachée. Ici, on va partir d'une image stretch, installer apache2, définir les variables d'environnement d'apache2, créer les dossiers, exposer le port 80 et lancer apache2 en mode "non détaché du shell" (le -DFOREGROUND). Mais si on avait fait un service mysql start avant de démarrer apache2 en mode foreground, le serveur SQL aurait démarré. Si on avait mis un script dans un screen qui effectue telle ou telle action à un intervalle de temps donné, il l'aurait fait aussi. Je suis presque sûr qu'on peut effectuer des crontasks propres, mais j'ai jamais réellement cherché. En important lors de la création de l'image le fichier des tâches cron, ou simplement en exécutant une série de commande comme ça (je répète, jamais essayé, j'ai juste été jeter un oeil à Stack Overflow, https://stackoverflow.com/questions/878 … ive-editor) :

#write out current crontab

crontab -l > mycron

#echo new cron into cron file

echo "00 09 * * 1-5 echo hello" >> mycron

#install new cron file

crontab mycron

rm mycron

Pour résumer, l'aspect "mono-processus" évoqué dans l'article est à mon sens une aberration, pour toutes les raisons évoquées plus haut.

Autre point important : La mise à jour des images (et des containers...). Pour mettre à jour l'image, on doit en effet la recompiler depuis le Makefile. Par contre, on peut très bien modifier un container en cours d'exécution : Docker nous offre la possibilité d'attacher le shell du container, autrement dit de pouvoir modifier le contenu et lancer des commandes à la main en live. Bien entendu, quand on s'attache au shell, on peut exécuter des commandes qui feront revenir le prompt sans stopper le container...

Mais le plus important, ça relève là aussi de la gestion de Docker : Quand on travaille proprement avec Docker, on est censé pouvoir détruire un container et le recréer sans que ça nous dérange. En vérité, le conteneur n'est censé contenir que l'exécution de l'image en cours, en aucun cas les dossiers ou fichiers à conserver. Docker permet en effet de créer des dossiers "montés" qui seront des ponts entre votre véritable système d'exploitation et l'image. Par exemple, le contenu du container présent dans "/mount/sdb0/" (juste un exemple, en réalité vous pouvez monter n'importe où) correspondra en fait au dossier "/home/coucou/Documents" de votre véritable serveur. Pour résumer, un container ne doit pas contenir d'informations importantes (à conserver) en son sein, juste des fichiers temporaires et l'exécution du/des processus. Il faut que ces documents soient montés dans un dossier partagés. Ainsi, quand vous mettez à jour votre image, vous pouvez détruire le container, et le reconstruire sans aucun soucis. (Et pour automatiser le tout, un bon vieux script Shell qui fera les commandes tout seul, bien entendu).

Enfin, dernier point : Docker à été conçu pour faciliter le déploiement, et isoler les tâches. En utilisant Docker, on est pas censé avoir plusieurs processus qui tournent dans un seul container. On est censé avoir un container qui gère un serveur SQL et qui expose son port 3306, un autre qui gère un serveur Apache et qui expose son port 80 et 443, un autre qui va gérer un serveur TeamSpeak et qui va exposer son port 10011 et 9987,etc. Ces containers viendront ensuite s'interconnecter entre eux. C'est pour ça qu'il n'est pas facile de base de lancer plusieurs processus dans un seul container, pour la simple et bonne raison que ce n'est pas prévu pour ça à la base. Pour finir, je dirais que pour ceux qui ont besoin de beaucoup de containers etc, il existe plein d'outils très sympa pour les gérer, par exemple Portainer et Kubernetes...

Pour terminer (oui je sais, ça fait redondance avec le Enfin, mais tant pis), je dirais que Docker n'est pas une solution magique. Docker, c'est un outil qui va permettre, sur des grosses infras, ou sur un service à déployer des centaines de fois, de gagner du temps par rapport à le faire à la main. Mais la configuration d'une image et d'un container Docker, ça demande du temps, de la réflexion, et surtout d'organiser ce qu'on fait d'une manière précise. Le commun des mortels, qui lance un serveur Web avec un petit serveur SQL derrière, sur un VPS, n'aura en effet aucun intérêt à utiliser Docker. Cela prends un intérêt quand vous avez des dizaines de services, un besoin de déployer rapidement, ou de devoir gérer un cluster.

En bref, le soucis de Docker à l'heure actuel, comme l'a mentionné mon VDD, et qui me fait éditer ce message, c'est cette hype constante qu'il y à autour, pour tout et n'importe quoi (et surtout n'importe quoi). C'est comme admettons un serveur Samba : Si vous avez besoin de partager une seule fois dans votre vie un document de 80ko, vous aurez plus vite de prendre une clef USB ou vous l'envoyer via un uploader de fichier, plutôt que monter un serveur... Par contre, s'il vous faut partager tout les jours des répertoires entiers, là, Samba devient intéressant. Bah c'est la même avec Docker.

Bisous et peace. <3

(PS : Je ne suis pas un pro de Docker, je réponds en me basant uniquement sur mon expérience et donc il est possible que, comme tout être humain, j'ai écrit une c*nnerie. Auquel cas, hésitez surtout pas à me le faire remarquer)

Dernière modification par Artheriom (23-02-2018 14:26:35)

hyrr0 · 27-02-2018 11:01:38

Ce que tu mentionnes là va à l'encontre des principes de Docker. C'est en effet possible de "Dockeriser" plusieurs processus. C'est néanmoins plutôt crado. Docker c'est l'esprit du KIS (Keep It Simple). T'es censé avoir un conteneur avec un processus. Si t'en a un second... bah t'as un second conteneur et t'as plus qu'à lier les deux.

C'est là que ça devient méga complexe. Parce que imagine sur un serveur web... le mec qui fait son site avec un back Python, un front React, Redux, Redis, une base postgres, un reverse proxy nginx ... bah ça lui fait si je compte bien 7 conteneurs mini.

Suffit que ce mec ait quelques besoins spécifiques et faut en plus qu'il se créé quelques images à la main. Là où il aurait simplement pu installer ses dépendances sur son serveur de prod.

Docker à cela de pratique qu'il permet un déploiement rapide. Une fois tout ça géré, ce mec aura juste une commande à taper s'il utilise docker-compose. C'est vrai que c'est quand même simple. Mais avant d'en arriver là, faut avoir fait un bac+15000 en architecture Dockerienne... Parce que Docker c'est un peu comme le JS : Tu peux pas compter sur les librairies des autres. Y'a tellement de changements, tellement vite, que t'as à peine le temps de faire un peu de dev avec que le truc est déjà obsolète.

Comme tu le dis si bien, ça dépend des besoins. Si c'est pour mettre en prod un site amateur : Docker est inutile. Si c'est une grosse SSII spécialisée en dev C# qui déploie 10 sites la semaine chez des clients, ça peut valoir le coup d'y jeter un oeil.

Maintenant y'a un truc qui me gène (en tant que Libriste). Docker c'est une entreprise. Beaucoup de collaborateurs. La sillicon valley (comme Facebook, Google, Apple... bref les GAFAM). Docker prend le même chemin. Ils ont déjà signé un partenariat avec Microsoft. Ils s'orientent très clairement vers le marché boursier... Bref, d'un point de vu "moral" je n'accroche pas. La petite startup qui devient grosse pourquoi pas. Mais l'allégorie de la grenouille et du bœuf ne me plait guère.

Debian-facile

#1 18-02-2018 05:14:25

Docker et la tendance de la conteneurisation

#2 22-02-2018 14:52:54

Re : Docker et la tendance de la conteneurisation

#3 22-02-2018 20:45:46

Re : Docker et la tendance de la conteneurisation

#4 22-02-2018 22:24:54

Re : Docker et la tendance de la conteneurisation

#5 22-02-2018 22:35:06

Re : Docker et la tendance de la conteneurisation

#6 23-02-2018 09:42:55

Re : Docker et la tendance de la conteneurisation

#7 23-02-2018 10:51:01

Re : Docker et la tendance de la conteneurisation

#8 23-02-2018 13:32:40

Re : Docker et la tendance de la conteneurisation

#9 23-02-2018 14:16:32

Re : Docker et la tendance de la conteneurisation

#10 23-02-2018 14:22:29

Re : Docker et la tendance de la conteneurisation

#11 27-02-2018 11:01:38

Re : Docker et la tendance de la conteneurisation

Pied de page des forums