![](https://blog.seboss666.info/wp-content/uploads/2016/02/docker-logo.png)
Docker : j’ai pas eu d’effet waouh
![Close this notification close](https://blog.seboss666.info/wp-content/plugins/old-post-notifier/cross_grey_small.png)
Si vous versez un peu dans l’administration système où le développement, vous avez forcément entendu parler du truc à la mode, Docker. J’étais pas spécialement emballé par le concept, et avant même d’y avoir touché je vous ai partagé le point de vue d’un administrateur qui voyait ça d’un très mauvais œil. Et maintenant, j’y ai touché aussi. C’est…
Le piège de la légèreté
Si sur le papier les performances sont bonnes, on ne peut pas en dire autant du stockage. En effet, sans rentrer sans trop de détails aujourd’hui, il faut savoir que la majorité des applications empaquetées Docker sont dépendantes d’une image de base, qui représente l’OS d’origine. La taille nécessaire pour faire tourner une application est donc assez vite décuplée. À peine installée et légèrement configurée que mon dossier docker pesait presque 1Go.
Faites des images pour sauvegarder votre travail régulièrement et vous avez l’assurance de gonfler la facture assez rapidement, surtout sur un SSD. Et conserver ses données hors des containers ne sauve pas les meubles. Donc oui, en termes de performances CPU et de consommation mémoire c’est pas mal, mais pas gagné pour le reste.
Quelques contraintes gênantes pour moi
En effet, pour un système qui veut simplifier le déploiement d’application côté serveur, la contrainte d’avoir un logiciel en avant plan est assez lourde, notamment quand les programmes sont conçus pour fonctionner justement en arrière plan.
Si vous isolez plusieurs segments (typiquement Apache, PHP, MySQL), vous devez aussi multiplier les options pour permettre malgré tout une communication entre eux.
Et j’ai pas encore compris comment « plugger » plus d’un dossier sur un conteneur. Mais faut dire qu’après un week-end dessus, et vu le peu d’enthousiasme que ça a causé en moi, j’ai pas creusé plus que ça.
La sécurité : ça reste un problème
Il n’y a encore pas si longtemps, il n’y avait aucune forme de vérification de ce qui se trouvait sur le Docker Hub. Il était donc facile de se retrouver avec un conteneur qui fournit non seulement l’application recherchée, mais pourquoi pas un relais caché ou un logiciel espion pas vraiment respectueux.
Mais il reste un gros problème avec ce qu’on trouve sur le Docker Hub. Même une image pourtant très très minimaliste de Debian 8 n’était pas à jour quand je l’ai récupérée. Imaginez le nombre de personnes qui vont simplement choper les images de bases sans se poser la question de leur état : c’est comme une armée de personnes qui installent un Windows et ne le mettent jamais à jour. Et c’est pareil pour les applications seules.
Et on voit le problème : mettez à jour la distribution invitée, les modifications ne sont stockées que sur le conteneur, il faut recréer une image et relancer un nouveau conteneur basé dessus. Sans parler du fait que tout le monde le fait dans son coin. Il reste donc encore du chemin pour que la technologie soit fiable de ce point de vue là, et il serait intéressant de voir arriver un système de mises à jour d’images sans avoir à réinstancier les containers qui sont liés.
Pour le bien de tous.
Pour du prototypage peut-être
Au final, oui, ça peut éventuellement être pratique pour tester très rapidement une application, sans avoir à se manger une configuration complexe qui aura été préparée dans le container, histoire de valider son fonctionnement (ou pas d’ailleurs). C’est pratiquement ce que j’ai fait en montant un environnement lemp pour pouvoir tester des thèmes afin d’arriver à ce qu’on a maintenant sous les yeux, si ce n’est que les composants que j’ai utilisés étaient déjà connus.
Donc je laisserai docker installé sur ma machine, mais faudra quand même que j’y repense parce que je vais pas l’utiliser tous les jours, c’est clair. Mais je vois vraiment pas comment on peut appeler ça une révolution pour de la production.
Marrant, ce matin, alors que l’article devait sortir à 18h, j’ai lu cet article d’un développeur qui explique pourquoi il laisse tomber Docker. Comme quoi ce n’est pas la panacée y compris chez les développeurs.
Après c’est comme tout, il faut s’y intéresser vraiment pour voir le potentiel de l’outil. Pour un lamp je préfère des containers qu’une VM. Pas de boot, redemarre vite, prend moins de place. Pour plusieurs répertoires il suffit d’enchainer les -v. Après tu es des images officielles donc ont peut y faire confiance un minimum. Si tu veux faire un serveur apache tu créer un dockerfile se basant sur l’image officielle. De plus sur le dockerhub tu as accès aux dockerfile. Après pour les maj docker comme les plateforme cliud se base sur le principe d’immutabilité. Besoin d’une maj tu… Lire la suite »
J’ai bien aimé ton billet et c’est toujours intéressant d’avoir le point de vue d’autres personnes utilisant Docker. A mon sens, il faut bien garder à l’esprit que ce qui fait la force de Docker est son accessibilité mais c’est également sa faiblesse. Comme tu dis, si tu prends une image debian 8 non patchée, pas à jour etc. sur le Docker Hub, ce n’est pas la faute de Docker mais de la personne qui est censé gérer son os/maj. etc… Le fait est qu’utiliser Docker est tellement « simple » que les gens se contentent de faire « docker run » puis se… Lire la suite »
Oui mais justement, si tu passes ton temps à gérer tes images pour pouvoir gérer la sécurité, te faire un jeu d’images propres pour pouvoir lancer tes containers au propre, je vois pas le gain de temps au quotidien par rapport à de l’OS classique (y compris en mode VM).
Je dirais plutôt je passe un peu de temps à architecturer ma base mais une fois que c’est fait j’y touche plus, seul les volumes changent.
Le gain de temps c’est surtout que tu le fais 1x et que tu le referas plus. Il y a aussi un gain de temps sur mes dev. php quand je dois downgrade la version de php pour un seul projet.
D’un point de vue purement dev. c’est du vagrant mais en mieux ( plus rapide, modulable ).