Très cher journal,
Je profite du soleil rasant de cette fin de vendredi pour écrire un troll article hautement polémique sur Docker. Je présente d'avance mes excuses à la communauté pour ne pas avoir proposé ma contribution plus tôt dans la journée, mais j'ai été fort occupé ces derniers jours.
Alors voila, je suis dubitatif vis à vis de l'effet de mode généré par Docker. Peut-être pourrez-vous m'expliquer ce qu'il a de si génial. Parce que oui, j'en entends parler partout, tout le temps. Sur hacker news, dans les blogs que je suis, sur linuxfr et, plus surprenant, également au travail. On l'essaye, on fait des dépêches dessus, des formations sont lancées. Tout le monde veut Docker, c'est chaud, c'est hot, ça fait envie.
Mais Docker, c'est quoi exactement ? commencerez-vous par demander. On vous répondra immédiatement que Docker repose sur les conteneurs LXC, une forme de virtualisation légère où on n'émule pas de hardware et où on ne fait tourner qu'un seul noyau, et que vraiment vous ne suivez rien à rien. C'est comme une VM, mais en mieux, t'es nul ou quoi ?
Sauf que non. La philosophie derrière Docker, c'est de lancer un process (et un seul) par conteneur. Et en foreground parce que le conteneur s'arrête si le process lancé s'arrête. Et traiter les conteneurs comme des VM « fat containers » vous vaudra l'ire de la communauté Docker. Vous aurez à vous justifier longuement si jamais vous le faites. Et c'est là que le bât blesse. Rien que lancer un serveur web et un serveur d'application web (par exemple nginx et uWSGI pour django) nécessite de bidouiller avec supervisor. Impossible également de vous connecter en SSH dans votre conteneur pour voir ce qu'il s'y passe, y'a pas de serveur SSH dedans. Même chose, oubliez le logging, syslog n'y tourne pas non plus. Pas plus qu'il n'y a un init dans votre conteneur.
Bon soit. J'utilise sûrement juste mal Docker. Mais enfin, pour un truc censé simplifier le déploiement d'applications, si je dois créer 3 ou 4 conteneurs juste pour lancer une pauvre application web avec une base de données, j'ai un peu l'impression que ça va à l'encontre du but affiché. La page sur la configuration réseau des conteneurs Docker commence par un TL;DR, ça en dit long.
Quelques voix s'élèvent pour critiquer Docker, et je ne peux que vous inviter chaudement à lire les deux billets (en Anglais) listés ci-dessous :
Et leur liste des griefs est longue. Le système de cache de Docker ne comprends pas que apt-get update; apt-get full-upgrade n'est pas idempotent et gardera en cache une image avec une ancienne liste de paquets sans la mettre à jour. Super pour intégrer facilement des mises à jour de sécurité. Le système de construction via les Dockerfile est aussi trop rudimentaire pour gérer facilement des déploiements d'applications et la lenteur des builds et gênante.
Alors finalement, en pratique, quel problème résout Docker ? Est-ce que ses multiples défauts n'en font pas une couche de complexité inutile ?
Vous pouvez moinsser.
# c'est pas parce que c'est pas bien pour la prod qu'il faut tout jeter non plus
Posté par kna . Évalué à 10.
J'y voie deux utilisations :
Après, on trouvera des types qui vont l'utiliser parce que c'est à la mode alors qu'il y a d'autres solutions plus efficaces pour leur besoin, comme avec la virtualisation avant.
[^] # Re: c'est pas parce que c'est pas bien pour la prod qu'il faut tout jeter non plus
Posté par X345 . Évalué à 4.
Je suis complètement d'accord pour l'aspect tests/développements. Docker marche bien pour ça.
Reste que ce qu'on nous vend c'est « Build, Ship and Run Any App, Anywhere » et je trouve que pour déployer des applications, Docker ne m'aide pas vraiment.
[^] # Re: c'est pas parce que c'est pas bien pour la prod qu'il faut tout jeter non plus
Posté par MTux . Évalué à 5.
C'est pour faciliter la vie de ceux à qui tu vas filer ton container docker.
Imaginons que tu bosse sur une application web qui nécessite nginx + php5-fpm + mysql + des plugins maisons. Ceux qui veulent utiliser ton logiciel vont devoir installer / configurer tout ça.
Par contre si tu peux leur fournir un paquet docker, ils n'auront rien à configurer. Il leur suffira de récupérer le container et l'exécuter.
Je suis un peu critique sur ce système car si c'est mal utilisé cela permet de trimbaler des choses sales ou obsolètes et personne ne s'en rendra compte ou ne s'en souciera car ça juste marche…
[^] # Re: c'est pas parce que c'est pas bien pour la prod qu'il faut tout jeter non plus
Posté par lockidor . Évalué à 4.
Oui et non, en suivant la philosophie docker, il faudrait leur fournir un container pour nginx+PHP, un pour mysql et un pour l'appli maison.
Dans ce cadre, il me semble plus logique de leur donner une recette chef/puppet/ansible/salt ou une archive d'un disque a faire tourner sous KVM/LXC/systemd-nspawn/chroot.
[^] # Re: c'est pas parce que c'est pas bien pour la prod qu'il faut tout jeter non plus
Posté par richardd . Évalué à 5.
Non la philosophie Docker c'est pas un container par logiciel, mais par tâche. Donc ici tu peux faire un container qui englobe le tout…
Après oui tu peux t'amuser à découper ton appli en plusieurs sous taches, mais ça peut être inutile en fonction des cas. :)
[^] # Re: c'est pas parce que c'est pas bien pour la prod qu'il faut tout jeter non plus
Posté par lockidor . Évalué à 10. Dernière modification le 06 mars 2015 à 21:49.
Pour une machine de développement qu'on peut casser a loisir, je préfère un systemd-spawn, un chroot ou une jail, ça marche tout seul, le réseau est enfantin a configurer et il n'y a pas a se demander comment avoir un stockage persistent, comment mettre a jour la distro ou encore comment SSH-iser dedans.
[^] # Re: c'est pas parce que c'est pas bien pour la prod qu'il faut tout jeter non plus
Posté par Seb (site web personnel) . Évalué à 10. Dernière modification le 07 mars 2015 à 15:46.
Pour tous les besoins que tu évoques, LXC fait bien l'affaire (Docker aussi, mais comme j'utilise essentiellement LXC c'est de lui dont je vais parler).
Sur une Ubuntu 14.04 LTS, créer rapidement un conteneur Debian Wheezy (ou autre) se résume à :
Maintenant si on souhaite y mettre un serveur SSH :
Et passer le relai à un outil tel qu'Ansible pour déployer toute la configuration :
Après toute la création du conteneur LXC peut également se faire depuis Ansible, et cela sera encore plus facile avec le module prévu à cet effet qui a été mergé depuis peu : https://github.com/ansible/ansible-modules-extras/pull/123
L'avantage ici c'est de séparer les responsabilités : la techno s'occupant du conteneur n'est pas lié à la techno s'occupant du build, c'est Ansible/Puppet/Salt qui s'en occupe et les recettes/playbooks peuvent s'appliquer aussi bien à des machines physiques, du KVM, de l'HyperV, du LXC, ou de l'OpenVZ, peu importe au fond, chacun son rôle, le couplage entre tout ce beau monde est plus faible.
Pour le conteneur en lui même, on peut en faire un tar et le passer au collègue si on le souhaite. Mais on préfèrera reconstruire l'environnement de A à Z de manière identique sur la machine cible avec Ansible (on utilisera le même outil pour construire l'environnement de dev, de preprod et de prod).
Aujourd'hui déployer une application complexe tel qu'un ERP avec son SGBD, une réplication du SGBD (pour du failover), du reverse proxy, la mise en place des backups, de la supervision et tout le toutim, c'est fun et rapide avec un outil comme celui-ci.
[^] # Re: c'est pas parce que c'est pas bien pour la prod qu'il faut tout jeter non plus
Posté par gaston . Évalué à 3.
HAN! J'en révais, moi qui avait du me palucher les playbooks quivontbien pour faire lxc-create/lxc-start… \o/
[^] # Re: c'est pas parce que c'est pas bien pour la prod qu'il faut tout jeter non plus
Posté par reno . Évalué à 1.
Certes, mais chroot faisait déjà ça, non?
[^] # Re: c'est pas parce que c'est pas bien pour la prod qu'il faut tout jeter non plus
Posté par freeze . Évalué à 2.
Pas tout à fait: chroot partage le même espace dans /proc (si tu fais un point de montage et la pile réseau)
alors LXC/docker utilisent les mécanismes d'espaces de nommages qui isolent ces aspects là.
[^] # Re: c'est pas parce que c'est pas bien pour la prod qu'il faut tout jeter non plus
Posté par Anonyme . Évalué à 3.
chroot ne permet pas de télécharger et extraire en une seule commande le filesystem d'un grand nombre de distributions. chroot ne monte pas /proc et tout ce qu'il faut à ta place. chroot ne crée pas de namespaces.
Tout ce que fait docker n'a rien de nouveau, tout existait deja avant. Mais l'interet de docker c'est que tout cela est integré en une seule commande, et qu'il n'y a pas besoin de se préoccuper des details.
# Conclusion un peu hative
Posté par Firwen (site web personnel) . Évalué à 10. Dernière modification le 06 mars 2015 à 20:31.
Il n 'y aucune raison de moinsé, c'est un débat interessant.
J'aimerai savoir sur quoi tu te bases pour dire ça.
Tu peux parfaitement utiliser un seul container docker pour lancer plusieurs services.
Tu peux parfaitement l'utiliser pour lancer un serveur d'application et Apache ( et même rsyslog ) dans le même conteneur.
Et ce sans supervisord, un simple script bash fait l'affaire.
Installer SSH dans un container docker est considéré comme une mauvaise pratique en effet, pour la simple raison que c'est un over kill. Il y a une dizaines de manière différente de "binder" dans un container sans avoir à déployer SSH.
Les mises à jour sont problématiques oui. Mais ça c'est pas propre à docker, c'est propre à tout système qui a un versionning stricte. Que ça soit docker, le système d'apps d'OSX ou nix.
Un workaround pour ça est simplement de faire executer un apt-get upgrade au démarrage du container….
Ça c'est ton avis. J'aurai plutôt tendance à dire que sa simplicité est sa force. Le Dockerfile t'autorise simplement à construire une image comme une recette de cuisine, étape par étape, couche par couche.
Si tu trouves ça limité: qu'est-ce qui t’empêche d'utiliser Docker build avec Cloudinit, puppet ou je ne sais quel tool de on choix ? ça se fait en deux lignes dans le Dockerfile.
Docker (et tout système de container) n'est PAS une solution de virtualisation, c'est juste un chroot sous stéroïdes que tu peux déployer/cloner/distribuer facilement.
[^] # Re: Conclusion un peu hative
Posté par X345 . Évalué à 10.
Pour commencer merci pour toutes tes remarques contructives.
C'est vrai on peut faire tourner plusieurs process dans un conteneur Docker. Apparemment, c'est contre les bonnes pratiques : Best practices for writing Dockerfiles. L'idée derrière la philosophie « 1 conteneur, 1 application » est de garder les conteneurs simples (une bonne idée vu de loin) et de faire des liens entre les conteneurs si on a besoin que deux process communiquent. Mon argument est que les méchanismes pour faire des liens entre les conteneurs sont vraiment très rudimentaires dans Docker, ce qui complexifie énormément (au lieu de le simplifier) le déploiement d'applications. J'ai vraiment pas envie de configurer un réseau virtuel entre mes conteneurs pour que nginx communique avec django…
Si on doit lancer plusieurs process dans un conteneur la recommandation est d'utiliser supervisor. C'est également vrai qu'on peut le faire avec un script bash mais du coup faut lancer les premiers process en arrière-plan et de dernier en premier plan. Quant le dernier process termine, tout le conteneur est éteint. Même si ça marche, cette solution (le script bash) me laisse un arrière gout de truc ad-hoc et pas fini.
Pour ce qui est de l'installation de SSH, je ne sais pas si c'est overkill. Certes maintenant, il y
docker exec(etnsenter, mais ce dernier fait clairement bidouille), mais pendant longtemps il n'y avait pas grand chose pour inspecter un conteneur.Effectivement, ça n'est pas propre à Docker. Mais mon argument est que pour un système de contruction d'images, utiliser un versioning statique le rend complètement inutile. Comment je fais comprendre à
docker buildque git clone n'est pas idempotent etc. Je ne peux pas lancer toute la construction de mon container à son démarrage, ça tue l'utilité de Docker. Et d'ailleurs j'ai pas envie de lancer apt-get upgrade sur 150 machines alors que je pourrais directement déployer une image correcte.Parmi les points souvent critiqués, il y a:
Effectivement, mais quel est alors l'intérêt de
docker buildsi Ansible fait tout le boulot ? Le système de cache devient inutile et comme les builds docker sont horriblement lents… Et puis pourquoi ne pas utiliser directement ansible pour déployer la machine finale ?Ça j'ai bien compris. Mais ma question est alors, à quoi ça sert un « chroot sous stéroïdes ». Je suis pas sur que ça m'aide à déployer des applications. Et les présentations de docker sont clairement trompeuses (voir le petit schéma le comparant à de la virtualisation sur What is Docker), on
laisse clairement supposer que Docker, c'est comme une VM mais sans le Guest OS.
D'ailleurs, j'ai l'impression que Docker ne sait pas sur quel pied danser. Un peu VM. Un peu truc pour compiler statiquement une application.
[^] # Re: Conclusion un peu hative
Posté par Tangi Colin . Évalué à 4.
Et qu'est ce qui t’empêche de faire ça avec Docker ? Rien. Tu mets un seul fois ton image docker à jour et tu déploie cette image sur tes 150 machines (avec un docker save/export ou avec un docker registry).
Le loging sur stdout c'est un concept qui vient de chez http://12factor.net/ et ça scale bien mieux qu'un syslog. Nan parce que quand tu as 100 machines à gérer avoir du docker et du https://www.loggly.com/ par example (ou du pagger durty) c'est le bonheur par rapport à du syslog.
Je veux pas lancer un troll mais j'ai l'impression d'avoir le même débat qu'avec systemd et le traditionnel "c'était mieux avant". Docker (bien qu'apportant peu de chose techniquement parlant, google fais du container depuis 10 ans dans ses datacenter) est en train de révolutionner le monde du datacenter (isolation/déploiment…). Si google (kubernete), twitter, airbnb (mesos), redhat (openshit), ibm (bluemix) et demain microsoft … sont entrains de proposer des solutions autour de cette technologie c'est pas pour rien. On a un vrai standard commun (api utilisé par tous) qui est entrains d’émerger. Alors oui avec lxc et des scripts moulinette maison on peut faire X ou Y que docker arrive pas ou mal à faire mais quid de l'éco-système de ta solution, quid de l'écosystème compatible avec, qui de la facilité de déploiement, quid de l’inter-opérabilité ?
[^] # Re: Conclusion un peu hative
Posté par X345 . Évalué à 10.
Faire quoi ? Déployer une image à jour de Debian ? Je viens de le dire, par défaut, avec son système de cache qui ne fonctionne pas, docker ne rééxecutera pas
apt-get update; apt-get upgrade. Je sais qu'on peut bypasser le cache mais le souci est la construction des images Docker est vraiment lente.Oulà non. Non, c'était pas mieux avant quand on administrait les machines à la main. Surement pas. Ces dernières années, on a plein de technos qui sont apparues pour faire du DevOps, notamment tout un tas de systèmes de gestion de configuration et d'orchestration à la Puppet, Chef, Ansible et Salt. Et ça, indubitablement, c'est très bien.
Pour ce qui est du déploiement d'applications, on voit bien qu'on a besoin de containers. Une VM c'est clairement overkill pour isoler les applications; c'est totalement inutile d'aller émuler une carte réseau et les autre périphériques d'entrée-sortie. Pareil pas besoin d'avoir 15 noyaux Linux qui tournent sur une machine physique. Un seul suffira.
Oui on a besoin de conteneurs ! Mais mon argument est que docker le fait assez mal. Et l'effet de mode autour de Docker me gène parce que dès qu'on commence à l'utiliser, on se retrouve rapidement à devoir contourner toutes ses limitations, ce qui génère une charge de travail peut-être supérieure à une utilisation brute de LXC.
Et ça me fait chier, je vois bien que Docker est populaire et j'ai l'impression que c'est un boulet que je vais me trainer pendant des années.
Alors cette histoire de standard commun, c'est une blague ? Le format des conteneurs Docker est spéficique à Docker. Y'a bien un standard pour le format des conteneurs: App Container Specification mais Docker ne l'utilise pas. Rocket, le lanceur de conteneur derrière CoreOS respecte cette spécification, mais pas Docker.
La seule manière un peu raisonnable que je vois d'utiliser Docker, est l'utiliser uniquement comme lanceur de conteneurs et d'utiliser Packer pour construire les conteneurs. Mais même comme ça, on doit trouver des workaround pour pas mal de problèmes. Typiquement les conteneurs Docker ne sont pas composables facilement. C'est un merdier sans nom de faire communiquer deux conteneurs. Je peux pas fusionner deux conteneurs pour en faire un seul. Rien que faire tourner deux process dans un conteneur c'est chiant. Pour le logging, c'est bien mignon de logger sur stdout mais si j'ai 200 conteneurs qui tournent sur 5 machines, je veux que les logs arrivent à un endroit central pour savoir ce qui se passe. Docker complique ça. Même chose au niveau du monitoring. Docker complique le monitoring.
Ce qui me paraîtrait la bonne manière de faire serait que la plateforme Docker fournisse des services au containers sous forme d'API. Typiquement une API pour logger, une API pour communiquer avec d'autres conteneurs (et rêvons un peu, plus efficace qu'en émulant du réseau), une API pour accéder à un stockage persistant etc. Dans l'état actuel des choses, c'est vraiment difficile de faire des conteneurs Docker facilement composables et déployables n'importe où. Je me retrouve toujours à voir de la configuration supplémentaire sur l'hôte (logging, création et montage de répertoires pour Docker, configuration des interfaces réseau virtuelles). Sans
compter que je sais jamais sur quel pied danser au niveau de la séparation des conteneurs. Je mets nginx dans un conteneur séparé ou pas ? Pour une application web, c'est chiant de faire comme ça. Dès que j'en ai deux, faut aller créer un Dockerfile supplémentaire.
J'espère que tout ça s'améliorera avec le temps. Mais pour l'instant on a vraiment un système sous-optimal.
Bon et pour info, Mesos n'a rien à voir avec Docker et n'a pas été lancé par Twitter mais par l'amplab de l'université de Berkeley.
[^] # Re: Conclusion un peu hative
Posté par Prosper . Évalué à 2.
Mouais , enfin l'overhead d'une VM c'est pas grand chose, d'autant que la plupart des périphériques ne sont pas émulés mais paravirtualisés. En fait en terme de performance cpu ou réseau , c'est la même chose, là ou ça diffère c'est pour le lancement des instances , un container se lance sous 100ms alors qu'une vm on est plutôt de l'ordre de 30s. C'est d'ailleurs une des raisons de l'inclusion d'un client dhcp dans systemd-network ( et voulu par CoreOs ), pouvoir faire une requête DHCP extrêmement rapidement cf https://plus.google.com/+TomGundersen/posts/eztZWbwmxM8
[^] # Re: Conclusion un peu hative
Posté par X345 . Évalué à 4.
Sur une workload purement calculatoire (ie qui fait que du CPU et pas d'entrée sorties), effectivement, l'overhead est négligeable.
Dès que tu commences à faire des entrées-sorties (notamment réseau), c'est autre chose : voir "Network Throughput Results" sur http://dtrace.org/blogs/brendan/2013/01/11/virtualization-performance-zones-kvm-xen/
[^] # Re: Conclusion un peu hative
Posté par Prosper . Évalué à 2.
Euh….kvm porté sur solaris/illumos je suis pas sur que ce soit le meilleur exemple :)
[^] # Re: Conclusion un peu hative
Posté par Firwen (site web personnel) . Évalué à 2.
Ça dépend surtout de ton échelle et de tes cas d'utilisations, mais non l'overhead de la virtualisation n'est pas négligeable.
D'un point de vue purement CPU, tu as raison et c'est de l'ordre de 2-5%.
Par contre pour les I/O disk, c'est bien plus important. Spécialement si tes VM tournent sur un RBD ( type Ceph ou autre).
L'emprunte mémoire du guest OS est aussi à prendre en compte. Il peut aller de quelques Méga pour une image optimisé à quelques Giga pour des distros standards, là où il sera null dans le cas d'un container.
[^] # Re: Conclusion un peu hative
Posté par X345 . Évalué à 1.
Tu développes ? Si je ne m'abuse, avec Docker (ou n'importe quel système de conteneurs), la distribution guest tourne également en mémoire. Par exemple, si j'ai 20 conteneurs qui font tourner une Ubuntu, j'ai 20 Ubuntu en mémoire, non ?
Certes, l'overhead sera un peu moins important qu'avec un hyperviseur parce que j'économise un process hyperviseur par VM, et une table de pages par VM, mais globalement l'utilisation mémoire doit être assez similaire, non ?
[^] # Re: Conclusion un peu hative
Posté par Firwen (site web personnel) . Évalué à 5. Dernière modification le 09 mars 2015 à 12:19.
Non. Tu n'as pas réellement 20 ubuntu en mémoire. Tu as juste l'emprunte mémoire des quelques bibliothèques et du process que tu fais tourner dans son "environnent" Ubuntu.
Tu n'as pas l'emprunte mémoire associé au Kernel de chaque guest, tu n'as pas non plus l'emprunte mémoire associée aux démons d'init, de networking, de logging / monitoring de chaque guest. Toutes ces choses sont fait directement par l'host.
L'emprunte mémoire des containers est trés faible.
Ceci dit, un VMware fan me rétorquerait trés certainement que VMWare ou KVM ont leur propre solutions pour éviter le dédoublement des page mémoire identiques sur l'host ( KSM pour KVM ).
Mais même considérant ça, la containérisation est généralement beaucoup plus légère que la virtualisation.
[^] # Re: Conclusion un peu hative
Posté par gnx . Évalué à 4.
emprEINte
[^] # Re: Conclusion un peu hative
Posté par Firwen (site web personnel) . Évalué à 1.
certes
[^] # Re: Conclusion un peu hative
Posté par X345 . Évalué à 3.
Moui du coup, la différence n'est pas si énorme que ça. Peut-être même pas significative.
Parce que comme on l'évoquait, on est souvent obligé de faire tourner un démon de logging ou quelquechose s'apparentant à un init (runit, supervisor) dans les conteneurs. Au final la seule différence semble être le kernel + process hyperviseur qu'on économise.
Le beaucoup plus léger (en ce qui concerne l'occupation RAM, pour les I/O je suis convaincu) me semble vraiment exagéré.
[^] # Re: Conclusion un peu hative
Posté par Firwen (site web personnel) . Évalué à 3.
C'est ton opinion.
Pour l'anecdote, J'utilise beaucoup docker pour faire du re-packaging en local dans des environnements "propres".
Là où je peux sur ma machine personnel (un simple laptop) faire tourner maximum une dizaine de VM + distro standards en parallèle.
J'arrive aisément à faire tourner une cinquantaine de conteneurs pour le même genre de taches, sans grande difficulté.
[^] # Re: Conclusion un peu hative
Posté par Tangi Colin . Évalué à 1.
Le standard commun est tout sauf une blague. Aujourd'hui Docker est un standard de fait (suffisamment de grand nom l'informatique l'utilise et reconnaisse ses api). Dire que App container Specification est un standard alors que c'est un spec écrite par CoreOS pour leur projet rocket la c'est une blague. Qui a part eux l'utilise ? Et docker a aussi une spec de leur format d'image (depuis pas très longtemps je te l'accorde).
Le loging je comprend pas, entre configurer un rsyslog et un conteneur loggly c'est le même niveau de difficulté, ça me rajoute pas une surcharge de travail monstrueuse et ça me rend un service de bien plus grande qualité.
Et pour info Mesos a de plus en plus à voir avec Docker. C'est maintenant complétement intégré avec Mesos (et un port de kubernete et de docker swarm sont en cours).
[^] # Re: Conclusion un peu hative
Posté par X345 . Évalué à 6.
Le standard commun est tout sauf une blague. Aujourd'hui Word est un standard de fait (suffisamment de grand noms informatiques l'utilisent et reconnaissent son format). Dire que Open Document Format est un standard alors que c'est une spec écrite par les libristes pour leur projet OpenOffice la c'est une blague. Qui a part eux l'utilise ? Et Word aussi a une spec de son format de fichier (depuis pas hyper longtemps, au regard de l'ancieneté du logiciel, je te l'accorde).
Tu vois ce que j'ai fait ?
Pour te répondre plus factuellement, voici une liste de projets, autres que Rocket, reposant sur l'App Container Specification :
Pour être un peut sérieux, oui le format Docker est en train de devenir une norme de facto pour le déploiement et le format des conteneurs. (Pour ce qui est des API Docker, je ne sais pas de quoi tu parles, enfin surtout je vois pas en quoi les API sont en train de devenir un standard). D'ailleurs c'est un peu ça qui me dérange, parce que même si je reconnais que les conteneurs sont très utiles, je trouve que Docker aurait pu être mieux pensé et conçu, ce qui nous éviterait des emmerdes au quotidien.
Du coup, je suis assez intéressé par les alternatives (et en particulier par ce que vont faire les gens de CoreOS, je l'admets), pour voir s'ils vont réussir à résoudre une partie des défauts de Docker.
Oui, bien sur. Juste que logger des conteneurs Docker, ça demande un travail supplémentaire par rapport à logger des applications qui tournent sur une machine. Je trouve ça dommage pour un truc censé simplifier le déploiement d'applications. Faut que j'aille faire de la configuration sur l'hôte pour faire tourner les conteneurs, ça tue un peu l'intérêt des conteneurs.
Pour Mesos, j'insiste vraiment, ça n'a pas grand chose à voir avec Docker. Dire que Mesos à voir avec Docker c'est comme dire que Linux à voir avec Docker. C'est vrai, mais Mesos permet de faire des tas d'autres trucs (notamment faire tourner Hadoop et Spark ou des services type Cron distribués) que faire tourner des conteneurs Docker, et n'a pas été prévu pour ça à la base. Ça m'énerve un peu les gens qui font du name drop dans les discussions à grand coup de Docker, Mesos, Spark, Big data etc. sans prendre le temps d'analyser les briques technologiques.
[^] # Re: Conclusion un peu hative
Posté par Tangi Colin . Évalué à 2.
Désolé je suis pas convaincu par la comparaison avec Word/OpenOffice. Ça a pas grand chose à voir (ni l'App spec container de CoreOS, ni la spec de Docker ne sont des "normes" reconnu par quels organismes de normalisation que ce soit). Peut tu me dire pourquoi la spec de CoreOS serait plus légitime ?
Que tu la préfère pour la raison technique X ou Y pourquoi pas mais ce qui me dérange c'est que tu tente de faire passer ça pour une norme et Docker pour le méchant "Word", alors que c'est tout sauf ça.
Je sais que Mesos n'est pas historiquement lié à Docker et que ça vient du monde Hadoop (Développé chez Berkley avec en partie des sous de chez Yahoo). Mais Mesos a des besoins en isolations que docker leur amène (il le faisait avant avec leur propre implémentation de cgroup), mais maintenant ils ont fait le choix d'utiliser Docker par défaut pour apporter ça et pas mal de développement tourne autour de cette technologie. Donc si j'insiste, Docker est devenue une brique technique de base de Mesos. Et si tu regarde les développements en cours ça a une influence tels qu'un travail préliminaire sur la possibilité de virer zookeeper pour mettre etcd à la place (Bonjour Kubernetes, ou CoreOS ).
Docker n'est pas parfait certes mais c'est un projet OpenSource qui évolue vite avec pas mal de monde derrière, c'est pas juste DotCloud qui décide, y a un comité consultatif avec pas mal de gros acteurs.Et un sérieux qui à fait que ça à marcher (Non parce que lxc c'est l’exemple typique des projets opensource fait par des devs pour eux meme, doc minimaliste, api/abi qui pétait à chaque version …).
[^] # Re: Conclusion un peu hative
Posté par X345 . Évalué à 0.
Globalement, tu as raison sur ce point. Après je voulais juste réagir sur le standard de fait, ça me semble dangereux que des "standards" se mettent en place sans qu'ils soient explicitement documentés et discutés.
Sur Mesos, va vraiment falloir que tu me donnes une référence si jamais il repose sur Docker. Pour l'instant, d'après les docs que j'ai lues, il sait faire tourner des conteneurs Docker, c'est tout. Mais par exemple, pour faire tourner du Hadoop, du Spark, du taches MPI, du Chronos, du Storm sur Mesos, j'ai absolument pas besoin de Docker. En bref, Docker et Mesos, c'est complètement orthogonal.
Si jamais y'a d'autres personnes qui nous lisent, Mesos, décrit dans ce papier, c'est un gestionnaire/allocateur de ressources. En gros, les clients Mesos demandent l'exécution de taches avec des contraintes memoire/CPU (e.g. 2 CPU, 8G de RAM), et Mesos alloue les taches sur un pool de machines. Ça peut servir de brique de base pour Hadoop, Spark et Storm, et donc de partager un cluster entre ces trois frameworks et éviter de devoir dupliquer les données. Après oui, en plus d'un tas d'autres trucs, on peut faire tourner des conteneurs Docker desssus.
La encore quel est le rapport entre Zookeeper, etcd et Docker ? Aucun. Zookeeper et etcd sont des serveurs génériques pour faciliter la coordination d'application distribuées. Au cœur de Zookeeper et etcd, il y a des protocoles de consensus ou pour faire de la réplication de machines d'état. Il me semble que Zookeeper s'appuie sur Paxos et etcd sur Raft. Rien, mais rien à voir avec la conteneurisation.
Purée, mais tu te rends compte de ce que tu sors ? Tu te rends compte que Docker n'est basiquement qu'une surcouche à LXC et sans LXC, pas de Docker. Et le hard work, c'était de faire LXC. Après, je suis d'accord pour dire qu'avant que Docker arrive, LXC était chiant à utiliser et que docker apporte un gros plus en termes d'utilisabilité.
Je suis désolé de devoir être aussi brutal mais soit tu comprends rien, soit tu t'exprimes super mal, soit je comprends rien (mais si c'est ça, va falloir sortir des références). Et franchement, si c'est la première option, t'as vachement de culot de balancer absolument n'importe quoi avec une telle assurance !
[^] # Re: Conclusion un peu hative
Posté par Sufflope (site web personnel) . Évalué à 8. Dernière modification le 09 mars 2015 à 17:55.
Je ne conteste pas tes argumentaires sur l'orthogonalité de etcd ou autre et docker, mais fais quand même gaffe avant de le traiter de débile qui ne comprend rien et balance n'importe quoi avec assurance, parce que Docker en est à la version 1.5 et ils ont abandonné LXC à la 0.9.
[^] # Re: Conclusion un peu hative
Posté par X345 . Évalué à 4.
Effectivement, tu as raison, pour le coup je me suis bien planté sur LXC. Je pensais qu'il s'agissait d'interfaces noyaux pour définir/lancer/arrêter des conteneurs. Ça n'est pas le cas, les mécanismes noyau pour faire ça sont les cgroups et les namespaces principalement. LXC est une interface au dessus des cgroups, tout comme la libcontainer utilisée par Docker. Du coup, on peut effectivement dire que LXC est mourant (et que c'était pas hyper au point) :)
La page wikipedia de Docker illustre ça très bien.
Juste pour être pas envenimer le débat plus que je ne l'ai déjà fait, je redis que je n'ai pas dit le mot "débile" dans mon commentaire originel. Et j'avais aussi émis l'hypothèse que je pouvais me planter.
[^] # Re: Conclusion un peu hative
Posté par Tangi Colin . Évalué à 6.
Le rapport entre Docker et ZooKeeper ou etcd ? L'éco-système, docker est la brique de base qui te permet de faire de l'isolation mais dès que tu veux faire du déploiement multi machine tu as d'autre besoin que juste l'isolation tels que le load balancing, la haute dispo, la découverte automatique de service etc… Et ça Mesos peut l'apporter. Mais le coeur de Mesos repose sur l'algo à consensus Zookeeper qui n'est pas celui choisi par d'autre projet gravitant autour de Docker. Kubernetes de google utilise etcd et coreOS aussi. Y a un port en cours pour intégrer Kubernetes avec Mesos. Et avoir zookeeper et etcd en parallèle c'est un peu bancal comme architecture. Donc y a un travail en cours pour avoir un backend etcd à Mesos. Y a aussi un travail en cours pour intégrer l'api de Docker Swarm.
Et pour faire tourner du Hadoop, Spark et Storm sur le meme cluster tu as besoin d'isolation, avant Mesos proposait sa propre implémentation (toujours à base de cgroups) mais depuis la version 0.20 docker est devenue une brique "1st citizen". Il se repose dessus pour fournir leur isolation. L'ancienne implémentation reste disponible, tout ceci est configurable a travers la ligne de commande qui lance le mesos-slave. Mais meme si tu fait tourner du Storm et du Spark tu as tout de meme besoin d'isolation entre ses framework et tu peux utiliser docker comme conteneur.
Docker n'est pas un framework Mesos de plus, c'est pas au même niveau dans la "stack Mesos", tu as tout en haut les frameworks (Storm,Hadoop,ElasticSearch,Jenkins,MPI,Aurora,Marathon…) et en bas, au niveau des executeurs, (sur les slave mesos) tu as le conteneur (soit l'implémentation mesos de base, soit depuis la 0.20 docker). Donc je me permet d'insister, au vue de développement en cours (le jira mesos est public), il y de plus en plus de développement qui sont fait pour s'intégrer avec l'eco-système Docker (Docker Swarm,Kubernete,support etcd) et Docker est maintenant une brique de base de la stack Mesos (Elle n'est pas irremplaçable puisque l'ancienne implémentation reste disponible mais c'est tout de même une brique de base).
Concernant LXC, oui Docker était une surcouche à LXC et ils ont implémenté libcontaineur parce qu'il en avait marre de gérer les api breaks et les X versions différentes de LXC. J'ai la flemme de me replonger dans les mailings list docker mais ça transpire même dans l'annonce officiel :
http://blog.docker.com/2014/03/docker-0-9-introducing-execution-drivers-and-libcontainer/
Au passage pour ne pas opposé docker et LXC, la libcontainer dispose de plusieurs backend (celui par défaut en go) mais rien ne t’empêche d'utiliser LXC ou LMCTFY de google etc…
Mais si tu me relis tu verra que je dis que Docker n'apporte pas grand chose technologiquement parlant mais je suis pas d'accord pour dire que le hard work était LXC. C'était tout autant du hard work d'arriver à fédérer une communauté ouverte avec des gros acteurs du domaine, qui s'accorde pour dire : "on fait plus les choses dans notre coin, on utilise docker comme API de containérisation, on parle le même language et on bâti nos outils autour de cette solution car on a une techno simple à utiliser, clairement documenté, avec un processus de décision clair et ouvert.
LXC bien que beaucoup plus vieux que Docker n'a jamais décollé parce que centré sur lui même, de la technique pur mais aucune communication autour ni vraiment de doc (Ubuntu la dessus à rater une belle occasion et maintenant il tente de ce rattraper avec lxd).
Après je pense que la discussion va devenir stérile, on parle de la même chose mais avec une vue différente, tu parle technique, je parle éco-système. Je préfère mille fois une techno "non parfaite" utilisé par tous et avec un processus de qualité (Doc,livraison,roadmap,processus pour participer clairement établie) qu'une techno "parfaite" mais peu utilisé et mal documenté …
Pour toi Mesos et Docker sont complément disjoint et techniquement parlant tu as raison.
Pour moi il forme un tout cohérent et d'un point de vue service j'ai raison.
```
[^] # Re: Conclusion un peu hative
Posté par X345 . Évalué à 6.
J'arrête aussi la discussion, comme tu le dis, je pense qu'on est au bout et je suis d'accord avec ta conclusion. Je re-poste juste un commentaire pour te présenter mes excuses pour la pique excessivement violente de du commentaire plus haut.
[^] # Re: Conclusion un peu hative
Posté par Tangi Colin . Évalué à 2.
Aucun soucis pour ma part, je me suis pas sentis vexé par tes réactions et ça a été un plaisir de confronter nos point de vue.
[^] # Re: Conclusion un peu hative
Posté par FrogX . Évalué à 3.
Ah ? c'est compliqué ça ?
docker run -d --name apache repo/apache:latest
docker run -d --name jboss --link apache:apache repo/jboss:latest
Ben vi ya même plus simple, docker-enter, faut juste le chercher le petit script sur le repo de jpetazonni ….
Ca c'est une bonne question, qui revient souvent (pas forcemment pour git d'ailleur).
Tout cela est en train d'être réglé … mais docker est encore jeune. Un élément en faveur de docker c'est qu'il sont extrêmement attentif aux demandes de la communauté (faut juste demander).
Pour finir docker c'est des conteneurs avec un ensemble d'outils qui facilitent la mise en place et rien d'autre. Ce qui fait l’intérêt de la chose c'est tout l’écosystème autour et en particulier :
Pour ne citer que les plus mis en avant.
[^] # Re: Conclusion un peu hative
Posté par palm123 (site web personnel) . Évalué à 2.
Tu veux parler de l'ancien nsenter
https://github.com/jpetazzo/nsenter
Mais avec l'actuel docker 1.5 (et depuis plusieurs versions) tu fais juste
docker exec
https://docs.docker.com/reference/commandline/cli/#exec
ウィズコロナ
[^] # Re: Conclusion un peu hative
Posté par X345 . Évalué à 2.
Alors comme d'habitude, dans le cas simple, tout marche bien. Après quand tu veux construire tes propres conteneurs, tu vas lire la doc de Docker et euh :
Et puis :
C'est compréhensible, mais faut pas que ça merdouille (et forcément, chez moi ça a merdouillé). Et bien sur, tout ça marche plus si la base de données et le site sont pas sur le même hote (on s'en serait douté mais…).
Mais pour un truc faire censé tourner mes conteneurs « anywhere », on y est pas encore (et d'ailleurs, c'est un problème complexe, mais Docker fait croire qu'il le résoud, ce qui n'est pas le cas).
[^] # Re: Conclusion un peu hative
Posté par Tonton Benoit . Évalué à 6.
Un script bash, oui pourquoi pas, mais simple non, ça devra être un vrai petit substitut d'init pour terminer proprement les processus. Peut-être pas indispensable pour nginx, mais pour une base de données, si !
[^] # Re: Conclusion un peu hative
Posté par barmic . Évalué à 4.
Dans la doc officielle du projet ?
https://docs.docker.com/articles/dockerfile_best-practices/#run-only-one-process-per-container
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Des usages à cerner
Posté par anarnux . Évalué à 8.
Conclusion très pertinente. Je suis en train de travailler sur docker en tant que sujet de projet (je suis en licence) et je doit dire que certains points sont à développer sur cette solution.
Docker ne remplacera pas une solution de conteneurs traditionnel comme LXC. Docker est fait pour isoler les applications, pas pour créer un système virtuel.
Moi même je reste dubitatif quand à son utilisation dans une infrastructure de cloud computing, en tout cas dans l'etat, notament à cause de la partie réseau et de l'intégration avec le système.
Mais pour le développement, c'est un réel avantage. On travaille sur son application sereinement , sans impacté son système et sans perdre en performance. On ajoute ses propres bibliothèques et configuration, sans que rien sur l'hôte ne soit modifié.
C'est rapide, ça fonctionne en gros comme git (chaque action sur le conteneur créé une nouvelle couche associé à un commit). Ainsi on peut facilement revenir à un Etat antérieur. Docker sur ce point la fonctionne déja très bien.
Mais c'est quand la partie réseau est impliqué que ça change. en effet docker est une couche d'abstraction à LXC et maintenant lib-contenair. Dès le debut il créé un bridge et connecte les VM. Des services comme DHCP ne marche pas.
Par rapport à un LXC ou il suffit d'utiliser les outils du noyau , c'est vrai que rajouter une telle complexité peut paraître inutile.
Mais ne pas oublier que Docker n'est pas stable, et que en fait on cherche toujours à définir son cadre d'utilisation.
Ne pas oublier que Docker est fais pour déployer des applications, pas simuler un système. C'est là la différence avec LXC.
[^] # Re: Des usages à cerner
Posté par Misc (site web personnel) . Évalué à 4.
Alors parmi les cas d'usage, c'est deja le fait d'avoir un truc self contained à déployer. IE, ce que tu testes est exactement ce que tu déploies.
Ça, c'est globalement la théorie, la pratique est plus compliqué car la platforme est pas correctement isolé :
http://www.fewbytes.com/docker-selinux-and-the-myth-of-kernel-indipendence/
Autre cas d'usage, tu as la création de microservice, avec les promesses de "ça scale à mort si c'est bien fait, et ça mutualise les ressources", mais surtout "les gens vont pas avoir besoin d'avancer à la même vitesse" ( ie, une solution à des soucis qu'on peut qualifier de social ).
Tu as aussi les histoires de mutualisation, cad diviser tes machines sans avoir la lourdeur des VMs ( lourdeur dans le sens ou il faut gérer les serveurs même virtuels ). J'ai prévu quand j'aurais du temps de jouer avec openshift v3, une surcouche sur kubernetes, qui est lui même un système d'orchestration de containers pour faire de l’hébergement des projets sur lequel je bosse. L'idée de faire des rollbaks rapidement est à mon sens utile pour que les gens puissent pousser sans risque, le fait de pouvoir tester chez toi sur docker est aussi pas mal pour ça.
Donc bon, je me voit pas déployer tout ( loin de la ), mais y a des trucs ou ça peut se révéler pas mal.
# devops
Posté par Anonyme . Évalué à 7.
Pour utiliser Docker quotidiennement dans mon travail, je peux t'apporter quelques éléments de réponses.
La puissance de Docker est selon moi dans la capacité à penser le déploiement de ses applications en tant que développeur. Dans l'exemple que tu donnes concernant l'application django, il est possible du coup en tant que développeur de fournir son appli sous forme de container, ce qui va permettre à celui qui est chargé de la déployer de le faire en deux lignes de commandes sans tenir compte de l'environnement d'exécution.
Il faut comprendre qu'il est en réalité assez simple dès lors qu'on maitrise un peu l’outil de lier les containers entre eux, le container d'une appli django qui bind sur un port local pourra être relié à un haproxy uniquement en settant quelques variables d'environnement, de même pour une base de donnée, que cela le soit par une interface réseau ou sock, il devient du coup très simple à celui chargé de déployer l'appli de le faire.
Concernant la philosophie du 1 container / 1 process, cette interprétation est galvaudée car il s'agirait plus en réalité d'1 container / 1 tâche. Pour reprendre l'exemple de l'application django, on va sans doute avoir besoin d'une configuration de nginx particulière qui ne permettra pas de faire un bind aveugle d'un haproxy ou d'un nginx sur l'appli, la bonne pratique sera alors de faire exécuter dans le container un nginx et son gunicorn (ou autres) via supervisor (ou autres) qui lui pourra être bindé aveuglément sur un reverse proxy. Par contre, la bonne pratique sera toujours de ne pas inclure d'application de base de données dans son container car il s'agit dès lors d'une tâche différente et que cela poserait des soucis à celui qui serait en charge de déployer l'application pour conserver un contrôle sur la dite base de données (gestion des sauvegardes, etc).
Il faut également voir docker comme un framework pour adminsys/devops, on a accès très rapidement à plein de container de plein d'application sur lesquels te baser pour déployer tes applis, et une fois cela réalisé de pouvoir les déployer très rapidement (voir de les automatisé) sur un nombre de serveur très important (en ce sens je préfère docker aux solutions tel que salt/puppet).
[^] # Re: devops
Posté par barmic . Évalué à 4.
Dans le cas d'utilisation du devops, j'ai quelques questions :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: devops
Posté par Firwen (site web personnel) . Évalué à 1.
Généralement l'image directement. Il est tout à faire possible de faire des images minimalistes avec Docker. Un environnement de base épuré peut être réduit à 20-40Mb d'espace disque.
Ma solution pour ça c'est d'utiliser un volume externe qui contient les fichier de configuration.
Ça t'autorise à séparer le versionning du soft en lui même du versionning de la configuration.
Les plus pointilleux font ça via Cloud-init, etcd ou autre, comme pour une VM traditionnel.
[^] # Re: devops
Posté par X345 . Évalué à 2.
Mouais alors, vis à vis de ça, je suis très dubitatif. Apparemment, c'est compliqué de faire des images Docker minimalistes (voir Is Docker ready for production? Feedbacks of a 2 weeks hands on). Une partie de l'intérêt de Docker, c'est qu'on peut "packager" rapidement ses applications/services en utilisant images de bage Debian, Ubuntu etc. Si faut s'amuser à compiler en static ses applications et utiliser des distribution embarquées pour avoir des petites images, ça tue l'intérêt.
[^] # Re: devops
Posté par barmic . Évalué à 3.
J'étais fatigué ! :)
Comment parce que s'il s'agit d'utiliser des distributions très exotiques (comme dis au dessus) et donc pas toujours simples à maintenir, c'est pas très pratique.
C'est représenté comment au sein du conteneur ? C'est un point de montage ?
On pourrait donc imaginer avoir 3 conteneurs, un pour l'application, un pour la configuration et un pour les données ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: devops
Posté par Anonyme . Évalué à 1.
On peut faire un container qui contient à la fois les données et la configuration, il n'y a selon moi pas de raisons valables pour séparer les deux.
[^] # Re: devops
Posté par Firwen (site web personnel) . Évalué à 2.
C'est un point de montage.
Y a des raisons valables. L'une d'entre elle est de pouvoir "rebuilder" ton image en case de mise à jour sans avoir à te retaper toute la configuration….
[^] # Re: devops
Posté par X345 . Évalué à 2.
Il est évident que la configuration est injectée dans le conteneur au moment de la construction de l'image et que les fichiers de config existent ailleurs que dans l'image, sinon bonjour les mauvaises pratiques.
Et en case de mise à jour, tu reconstruis ton image avec les nouvelles version et tu réinjectes la configuration dedans. Ça permet notamment de faire des déploiement immutables, c'est assez à la mode en ce moment.
[^] # Re: devops
Posté par Anonyme . Évalué à 1.
J'ai dû mal m'exprimer, je parlais bien d'un conteneur contenant à la fois les données et la configuration, à savoir qu'on peu considérer la configuration comme une donnée de l'application qui va devoir être manipulée de la même manières que les autres données.
En ce sens, en cas de rebuild de l'application, cette dernier aura sans doute besoin de sa configuration ainsi que des données qu'elle aura précédemment générée. Donc remonter un seul conteneur de données permet de récupérer une application fonctionnelle. Mais il y a sans doute des cas où cette séparation serait pertinente, dans des clusters ou en cas d'utilisation parallèle de la même images ayant la même configuration mais des données différentes.
[^] # Re: devops
Posté par Anonyme . Évalué à 1. Dernière modification le 09 mars 2015 à 12:19.
En interne, j'ai tendance à fournir un dépot git du dockerfile, ça permet de build l'image docker en passant l'adresse du dépôt. Mais concernant la taille des images, j'ai envie de dire qu'on s'en bas un peu les steak en fait, dans les faits ça ne pose pas de soucis d'avoir une image de quelques centaines de Mio.
Comme le dockerfile est versionné, il suffit de rebuild l'image avec les même paramètre lors d'une mise à jour.
Personnellement, je n'ai pas rencontré de cas où la taille d'une image pouvait poser un soucis, ça ne représente jamais plus que quelques centaines de Mio, et si cela était un problème il y a 10 ans, ce n'en est clairement plus un désormais.
[^] # Re: devops
Posté par barmic . Évalué à 3.
Ils doivent donc maintenir leur config ailleurs (avoir un patch à réappliquer ou autre). Ça ne m'a pas l'air terrible.
Tu as bien de la chance. En upload c'est relativement long. Là où tu peut utiliser des appli web simple pour pousser jusqu'à quelques dizaines de Mio là, il va te falloir une config particulière, etc. Et même quoi qu'il arrive c'est pas agréable. Aujourd'hui passer ma version de l'application à mon collègue ça me prends quelques dizaines de secondes en lui passant via un transfert de fichier via xmpp ou skype. S'il me fallait 100Mio, ça ne marcherait pas.
Bref ce n'est jamais totalement bloquant, mais c'est désagréable à utiliser (là où pour du devops, il faut au contraire rendre les choses les plus agréables et rapide possibles).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: devops
Posté par Anonyme . Évalué à 1.
La config peut être importée via un autre container, avec l'option --volumes-from, les seuls limites sont quand une spec de config changent, mais ça on peut difficilement y échapper. Dans les fait ça ne pose pas vraiment de problème.
Justement, il reste infiniment plus simple de fournir une image sur un repo privée et donner une commande docker pull qu'envoyer du code brut qui devra ensuite être déployé manuellement, et même dans le cas où il n'y aurait pas de repo, la doc ne contiendra pas plus de lignes de commandes à taper (docker pull sera remplacé par docker build).
On a très rarement à uploader une image docker. Si j'ai un repo, je peux build l'image directement dessus via le Dockerfile, le seul cas où j'aurais en réalité à faire ça, ça serait dans le cas où j'aurais construit mon image manuellement avec des docker commit, ce qui n'est de toute façon pas une bonne pratique.
[^] # Re: devops
Posté par barmic . Évalué à 3.
Dans le cas assez classique ou tu connais la plateforme cible, j'ai bien du mal à avoir ce que ça va m'apporter face à un
dpkg -iqui est nettement plus simple à mettre en place, qui gère la configuration sans problème qui n'impose pas grand chose comme workflow, qui ne demande aucune performance particulière de la part du ou des serveurs,…Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: devops
Posté par Anonyme . Évalué à 0.
Je pense que tu es hors sujet là :)
[^] # Re: devops
Posté par barmic . Évalué à 4.
En quoi ? L'objectif est de pouvoir déployer une ou plusieurs applications rapidement et simplement. Pour ce cas d'usage utiliser une image docker, des scripts fabric/ansible/puppet ou un système de paquetage réponde au même besoin : permettre de pousser la dernière version d'environnement en environnement (développement, recette, production et toutes les étapes que tu veux lui donner).
La sécurité par isolation n'existe pas dans le déploiement tel qu'on en parlait au dessus. Si tu as un conteneur pour toute ton application et juste un ou 2 conteneurs pour la conf + les données.
Je passe à coté de quoi ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: devops
Posté par Anonyme . Évalué à 1.
Car avec dpkg, le déploiement de ton application devient directement dépendante de l'hôte, ce qui va à l'encontre de la philosophie devops.
Si je construit un paquet debian, en plus de la perte de temps qui en résultera, l'utilisateur sera dans l'obligation d'avoir la bonne version de debian/Ubuntu que j'aurais moi-même choisi d'utiliser, le déploiement de l'application aura un impacte sur le système hôte et n'importe quelle mise à jour pourra au mieux être bloquée par mon application, au pire, casser mon application. Elle devra également s'interfacer obligatoirement avec la configuration déjà existante de la machine hôte et impliquera une maintenance plus fastidieuse en cas de cohabitation avec des services similaires (Web par exemple).
Bref, dans le cas de la philosophie devops, dpkg est hors sujet.
# Docker c'est bien
Posté par Tonton Benoit . Évalué à 8.
J'aime bien Docker, je l'utilise sur mon serveur perso en tentant de rester au maximum dans sa "philosophie", mais moi aussi j'ai du mal !
l'IPv6, un projet si récent sans que le support de l'IPv6 soit pensé de base c'est regrettable, du coup je lance mes conteneurs sans réseau et le rajoute après avec
ip ns, perdant au passage toute la philosophie réseau de docker.La philosophie de CoreOS/Docker est que tout doit tourner dans un conteneur pour être plus facile à migrer, mais chez moi l'hôte fournis plusieurs services aux conteneurs (logging, stockage, cron)
Le logging justement, la solution de Docker de capturer la sortie du programme est très insuffisante, et les astuces pour recycler les logs des conteneurs relèvent du chamanisme.
Docker compte que toutes les applications accepterons de rester au premier plan, et de logger sur stderr mais c'est loin d'être le cas malgré l'arrivé de longue date de plusieurs superviseurs qui réclament ce mode de fonctionnement (genre runit ou Deamontools), de systemd, de Docker, le patch pour garder Postfix au premier plan, n'a jamais été aussi loin d'être intégré, et c'est pas le seul !
Du coup je log sur le rsyslog de l'hôte, y'a l'astuce qui traîne sur le net, mais /!\ elle n’est pas bonne, essayez de relancer rsyslog et ça cassera le bitoniau magique. Il faut partager un dossier contenant le socket et pas le socket lui-même.
docker exec, mais ça me permet pas de récupérer le code de sortie du programme, à voir si d'autres solutions genre nsenter le permettent.Si y'a un truc que j'aime bien par contre c'est les Dockerfile ! Elle sont parfaitement suffisantes pour moi et m'offre une sécurité appréciable.
Avant je conservais des images de mes VM avec toujours la problématique de garder une image saine dans le temps face à la menace des rootkits.
Avec les Dockerfile je garde qu'une recette et génère une image propre quand je le veut.
On peut même imaginer automatiser tout ça pour qu'un conteneur soit régénère toutes les genre 30 minutes.
Ça remplace pas SELinux mais c'est une sécurité supplémentaire pour moi.
J'aime tellement cette méthode que je fait la même chose pour mes serveurs physiques maintenant, au lieu de les sauvegarder je crée un script pour les ré-générer à l'identique.
Pour le "un service par conteneur", j'y arrive plutôt bien, il m'arrive même de redécouper un service sur plusieurs conteneurs pour mieux isoler ce qui sera directement exposé au net ou non, genre pour Dovecot :
- dovecot-pub : le service public accessible via le net
- dovecot-int : même-chose qu'au dessus, mais uniquement sur le réseau local, utilisé par horde pour accéder à l'IMAP
- dovecot-auth : la couche d'authentification SASL pour Postfix
- dovecot-lmtp : reçoit les mails entrant de Postfix et les place dans la boite de l'utilisateur
Sur ces quatre conteneurs, seul le premier est accessible directement via le net.
Par contre ce qui me manque c'est une possibilité de hiérarchiser les conteneurs dans une arborescence, je sais les tags c’est plus moderne, mais ça me parle moins.
C'est un bon projet, mais avec des défauts de jeunesse qu'on a du mal a comprendre sur des choses qui font partie de ce que j’estime être le minimum vital.
[^] # Re: Docker c'est bien
Posté par Anonyme . Évalué à 1.
Tu as mis publiquement ce que tu as fait avec dovecot sur docker ? Personnellement ça m'intéresse de voir comment tu as fait :)
[^] # Re: Docker c'est bien
Posté par Tonton Benoit . Évalué à 2.
Non pas de repo public car je me base sur des images de base fortement personnalisés.
Et j'ai rien fait de très spécial avec dovecot, j'ai juste plusieurs conteneurs avec une configuration différente chacun.
Enfin, si tu a des questions je suis dispo :)
[^] # Re: Docker c'est bien
Posté par Mildred (site web personnel) . Évalué à 2.
C'est rigolo, moi j'ai fait exactement l'inverse. Un conteneur qui contient a la fois dovecot et exim.
# Questions de vieux cons
Posté par Christophe B. (site web personnel) . Évalué à 5. Dernière modification le 07 mars 2015 à 07:58.
Bonjour à tous,
J'adore sincèrement ce genre de journal car cela me permet de comprendre et de découvrir une nouvelle technologie que je n'ai pas le temps de tester, Vive LinuxFr !
Et j'en profite pour poser quelques questions de débutants :
Sinon je vois une utilisation de suite :
si mettre en route un container est facile, alors il doit être possible de lancer :
- un container PRODUCTION : l'application réelle avec de VRAIS utilisateurs
- un container de TEST/RECETTE : pour tester avant passage en prod
- un ou plusieurs container DEV : bac a sable pour les developpeurs
et grand luxe
- un container FORMATION
Actuellement c'est ce que l'ont essaye de faire avec des modèles de VMs
mais bon je suis pas sur d'avoir compris la philosophie de docker
Derniere question : comment on sauvegarde ? cela change qq chose ?
et pour finir une méchanceté gratuite :) (je sais j'ai loupé dredi)
Write Once run every Where ?
Cela doit rappeler quelques choses à ceux qui ont plus de 20 ans :)
Encore merci pour ce type de journal ou le PARTAGE d'expérience et d'idée existe encore.
[^] # Re: Questions de vieux cons
Posté par G.bleu (site web personnel) . Évalué à 3.
L'idée de Docker c'est de découper son application en briques de bases, puis de conteneuriser ces briques.
Dans ton cas on a :
- une base de donnée : sur le site de docker son fourni des conteneurs tout prêt pour la plupart des bdd
- un service TCP, un service http : vu que http passe par TCP, je ne suis pas sûr de ce que tu veux dire, mais si il s'agit de deux services différents (un serveur web + un tracker de torrent d'iso linux), tu vas donc créer deux conteneurs docker (en écrivant deux Dockerfile)
Tout est potentiellement dockerisable ("quels sont les applications non exécutable dans une vm ?"), toutefois une application dont les composants sont fortement couplés se prêtera beaucoup moins (par exemple si ton application nécessite que ta base de donnée soit en local, ton Dockerfile va se complexifier, et la base de donnée va faire grossir l'image du conteneur qui deviendra difficilement portable avec le temps)
Où est-ce que java a échoué ? Pas dans le monde des serveurs où il est très présent ! Docker ne sert pas à empaqueter une application client (encore que, certain y pensent comme solution d'isolation, bien que ce ne soit pas au point pour le moment).
Java avais l'avantage de permettre au admin sys de déployer sur un serveur (pouvant être une architecture powerPC, sparc etc…) un binaire compilé par l'équipe de dev (travaillant sur x86), de nos jours les parts de marché de x86/amd64 sont écrasantes (et beaucoup de langages sont interprétés), on est donc en droit de se foutre de la gueule de java tous les vendredi ;-)
[^] # Re: Questions de vieux cons
Posté par MTux . Évalué à -2.
Les failles de sécurité à gogo
La lourdeur
L'enfer des changements de versions
Appli qui plante car elle a décidé de gonfler en RAM soudainement
Perso je refuse le Java sur les serveurs et je porterai mieux si tout le monde pouvait s'en passer en desktop également (et je suis pas le seul).
[^] # Re: Questions de vieux cons
Posté par X345 . Évalué à 10.
J'en ai vraiment marre du bashing anti-Java primaire. Faut arrêter de raconter n'importe quoi.
Mouais, la JVM c'est pas joli niveau failles de sécurité. Bind (le serveur DNS) non plus. C'est à mettre en parallèle avec les buffers overflows et autre cochonneries sur une application serveur codée soi-même en C++.
La lourdeur par rapport à quoi ? Par rapport à une application écrite en C++ ? Ok. Par rapport à du NodeJS, Python ou Ruby ? Sûrement pas. Pour info, Java (sur la JVM), c'est ce qu'on a de plus rapide derrière du C++. Et typiquement Ruby/Python, c'est 2-3 fois plus lent que du Java.
Si tu penses que Java est lent, va jeter un œil à ça : Techempower - Web frameworks benchmarks
Bon ok, la consommation RAM est mauvaise à cause de la manie de Java de boxer les types primitifs mais bon si on regarde à côté, une liste Python c'est pas la structure la plus légère qui soit.
Ouais alors entre Java et les appli web en NodeJS/Python/RoR qui ont besoin de la moitié des libs publiées sur Internet dans une version bien précise pour se lancer, c'est vraiment pas mieux. De toutes façons, c'est toujours le merdier de changer la version d'un runtime.
Hé bé, tu dois pas lancer grand chose sur tes serveurs. Y'a quand même une bonne grosse tétrachiée d'applications écrites en Java. Tu dois être sympa comme admin à prendre des décisions arbitraires comme ça. Moi je refuse toutes les applications dont le nom commence par "S". C'est comme ça.
Et puis pour finir, je ne sais pas où vous avez vu que Java a échoué. Ça doit être un des langages (dans le top 10) les plus utilisés de nos jours. Pendant certaines années, ça a du être le plus utilisé. Moi j'appelle ça un grand succès.
[^] # Re: Questions de vieux cons
Posté par MTux . Évalué à -10.
Réponse échauddée : le sysadmin doit faire en sorte que ça tourne, il n'a pas que ça à faire de passer n'importe quoi en prod juste parce que le developpeur aime.
Java c'est de la merde, c'est lourd, ça plante, c'est blindé de failles, et non heureusement qu'il n'y a pas tant d'applications que ça qui l'utilisent sur serveur.
[^] # Re: Questions de vieux cons
Posté par pasBill pasGates . Évalué à 6.
Je ne suis pas un fan de Java en tant que développeur, je trouves que c'est un langage chiant, auquel il manque des choses évidentes.
Par contre, il est plus qu'évident qu'il fonctionne très très bien pour les applications serveurs. Une grosse partie des plus gros services sur le net tourne en Java, et c'est pas un hasard.
[^] # Re: Questions de vieux cons
Posté par El Titi . Évalué à 7.
T'as raison. Une bonne infra LAMP, y'a rien de mieux en terme de sécurité et de montée en charge.
Tu voudrais nous dire où tu bosses qu'on évite les services proposés par ta boîte ?
[^] # Re: Questions de vieux cons
Posté par mael . Évalué à 6.
Et encore. La plupart des failles posent des problèmes au niveau du plugin pour navigateurs (qui ne sert quasiment plus à personne). Je n'ai pas l'impression qu'il y ait un nombre impressionnant de failles exploitables sur une JVM installée sur un serveur. Si ?
[^] # Re: Questions de vieux cons
Posté par claudex . Évalué à 3.
Toi, tu n'as pas de smartcard.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Questions de vieux cons
Posté par Christophe B. (site web personnel) . Évalué à 1.
Non le même service mais avec 2 visions différentes, une seule application peu réagir à 2 ports tcp différents.
exemple : picking, suivi de fab via des terminaux textes sur le port 8080 (telnet) et on peu consulter la même application sur le port 80 en http et html.
J'entrevois docker comme une base permettant de rajouter facilement des composants du style :
un container apache + un container application + un container base de données = une application finale
reste a voir comment tout cela s'organise pour communiquer avec le monde extérieur, faudrait pas se retrouver avec une joli collection de boite noire.
C'est pas marrant si ya personne pour répondre … tiens essayes de te moquer de windows phone par exemple … ou des tablettes surfaces … qui coulent mouahahah.
Bon week end a tous
[^] # Re: Questions de vieux cons
Posté par ckyl . Évalué à 9.
Par contre ça doit sembler très bête a toute personne comprenant l’idiotie de comparer Hotspot à Docker.
C'est un peu prêt aussi pertinent que comparer Parrot à VirtualBox ou une cuillère avec un choux de Bruxelles. Dommage de dire de telles âneries quand on a eu plus de 20 ans pour comprendre une techno…
Tu veux dire avoir ~9 millions de développeurs et être le langage et le runtime le plus utilisé au monde ? J'aimerai bien échouer un projet comme ça un jour personnellement.
[^] # Re: Questions de vieux cons
Posté par Christophe B. (site web personnel) . Évalué à 1.
Vous êtes formidable,
Je pose un question de béotien … un réponse, heureusement très pertinente.
En provoquant délibérément et maladroitement les afficionados d'une technologie … beaucoup plus de réponses :)
qui de plus me permette de mieux comprendre docker.
[^] # Re: Questions de vieux cons
Posté par Larry Cow . Évalué à 2.
Ils ne font pas tous honneur à Java, ceci dit. Loin s'en faut.
# Tu aimes Heroku ?
Posté par G.bleu (site web personnel) . Évalué à 5.
Si il y a une chose qui a changé la vie de mes applications web, c'est le passage du iaas (vm amazon "aws ec2") au paas (heroku):
avec aws, on te file une vm et tu installes l'OS, configure le routage, fait les mises à jours, gère les logs etc… C'est lourd au quotidien, mais la galère arrive vraiment quand on commence à vouloir hébergé sa base de donnée avec redondance (et sauvegardes récurentes), à scaller ses serveurs en fonction de la charge
avec Heroku, tu donnes ton code, tu précise ses dépendances et c'est tout ! Toute la maintenance sans rapport avec ton code est sous-traité à un spécialiste, les questions de scalabilité ne sont qu'un curseur à régler (voir rien du tout si on demande une scalabilité automatiquement !), on ne raisonne plus en terme de serveurs mais en terme de services.
La philosophie derrière cette révolution, c'est le concept de l'application aux 12 facteurs (traduction libre, allez voir http://12factor.net/). En respectant ces 12 règles, on obtient une architecture moderne® qui simplifie énormément le cycle de vie des applications.
Le rapport avec Docker ? Heroku utilise son propre système de conteneurisation des applications (le "slug"), Docker permet donc de disposer d'un format standard et open-source d'empaquetage des applications.
Grace à cette technologie le monde du PAAS est en pleine expansion :
- le projet Deis qui vise fournir une stack comme Heroku avec Docker (http://deis.io/)
- Amazon à lancé Beanstalk pour héberger des conteneurs Docker
- Des clouds basés sur docker se lancent à la pelle (premier lien sur google http://www.centurylinklabs.com/top-10-startups-built-on-docker/)
J'imagine qu'à l'avenir on pourra très simplement passer d'un fournisseur de cloud à l'autre (voir héberger son application via plusieurs fournisseurs) grâce à Docker, ce qui favorisera la concurrence (et donc baisse des $$$ ainsi que moindre dépendance aux géants comme Amazon et Google).
[^] # Re: Tu aimes Heroku ?
Posté par MTux . Évalué à 1.
Heu… c'est de la pub ?
[^] # Re: Tu aimes Heroku ?
Posté par G.bleu (site web personnel) . Évalué à 2.
De la pub pour quoi ?
Pour Heroku (qui est un super service, c'est vrai) ? Je donne des solutions alternatives
Pour appliquer des bonnes pratiques pour rendre ses applications meilleurs ? Assurément !
Pour Docker ? c'est le bon journal non ;-)
[^] # Re: Tu aimes Heroku ?
Posté par Bruno Michel (site web personnel) . Évalué à 8.
Du coup, autant faire de la pub pour un service basé sur docker et fait par des français : https://www.clever-cloud.com/fr/.
[^] # Re: Tu aimes Heroku ?
Posté par G.bleu (site web personnel) . Évalué à 2.
Je ne connaissais pas, merci pour l'info !
Ça a l'air assez jeune, tu as des retours d'expérience dessus ?
[^] # Re: Tu aimes Heroku ?
Posté par Seb (site web personnel) . Évalué à 2.
Clever Cloud avait fait une présentation de leur utilisation de Docker lors d'une mini-conférence à Rennes : https://www.youtube.com/watch?feature=player_embedded&v=3bg9ij4XwW4
[^] # Re: Tu aimes Heroku ?
Posté par Bruno Michel (site web personnel) . Évalué à 5.
C'est effectivement assez jeune. J'avais testé pour un petit projet. La doc est assez faible mais le support est très efficace, ce qui compense.
# process = /sbin/int ?
Posté par olm . Évalué à 1.
Si le processus lancé par docker est init, que va-t-il se passer ?
Attention, ça veut pas dire qu'il faut gérer les conteneurs comme des VM, sans quoi on perd tous les intérêts de cette techno :
-
sshdnsenter-
syslogd/dev/logDe toutes façons les images de base (debian pour moi, mais je l'ai constaté avec centos et même arch) sont généralement assez dépouillées.
J'utilise docker comme ça depuis un bail, tant pour des services pérennes que pour du jetable (validation de manifestes puppet notamment) avec le plus grand bonheur : ça démarre en une seconde, ça prend quasi-pas d'espace et le tout se gère très facilement grâce à une CLI bien gaulée (à la git).
[^] # Re: process = /sbin/int ?
Posté par Tonton Benoit . Évalué à 3.
Rien ?
Vaut mieux quand-même avoir un init qui soit "container aware" genre systemd ou OpenRC, j'ai adapté CentOS6 et Debian7 pour LXC et faut y aller à la hache pour que ça démarre sans messages d'erreurs (messages sans conséquences toutefois) !
# Et les dépendances ?
Posté par flan (site web personnel) . Évalué à 2.
(note : je n'ai jamais utilisé Docker, mais j'essaie de me tenir au courant)
Si j'ai bien compris, chaque conteneur va avoir toutes les dépendances. D'un côté, c'est le gros avantage vu qu'on n'a pas de problème avec l'OS hôte.
Mais d'un autre côté, on fait une croix sur toute la gestion de dépendances qui est (aux yeux de beaucoup) l'une des grandes forces des Linux, non ?
N'est-ce pas un peu dommage ?
[^] # Re: Et les dépendances ?
Posté par Anonyme . Évalué à 3.
Ca veut dire quoi "on fait une croix sur toute la gestion de dépendances" ?
Pour installer les dependances de ton application dans ton image docker, tu peux très bien utiliser des packages, donc je vois pas trop ou est ce qu'on fait une croix sur la gestion de dépendances.
[^] # Re: Et les dépendances ?
Posté par flan (site web personnel) . Évalué à 3.
J'ai souvent lu que le gros avantage du système de dépendance était de n'avoir qu'un seul exemplaire de chaque lib sur la machine, et qu'une mise à jour profitait à tout le monde.
Là, on a autant d'exemplaires que de conteneurs, et il faut mettre à jour chaque conteneur séparément… (à nouveau, si j'ai bien compris le fonctionnement).
[^] # Re: Et les dépendances ?
Posté par Anonyme . Évalué à 1.
Je ne vois pas très bien ce dont tu parles. C'est quoi le système de dépendance ?
Mettre à jour une lib dans un container ne va pas affecter les autres containers. Mais c'est justement l'interet des containers, de pouvoir faire des changements dans l'un sans que ca n'affecte les autres.
[^] # Re: Et les dépendances ?
Posté par barmic . Évalué à 5.
Tu as une faille dans ta bibliothèque ssl, tu dois mettre a jour chacune de tes images, contrairement à ce que permet une distribution classique. C'est la grande force des distributions par rapport à Windows justement.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Et les dépendances ?
Posté par Anonyme . Évalué à 2.
On peut aussi dire que avec plusieurs machines, si tu as une faille dans ta bibliothèque ssl, tu dois mettre a jour chacune de tes machines, contrairement à ce que permet une unique machine.
Mais utiliser plusieurs machines ca s'appelle pas "faire une croix sur toute la gestion de dépendances".
Si il y a une faille sur openssl, ben tu appliques simplement la mise à jour sur toutes tes machines ou images docker.
[^] # Re: Et les dépendances ?
Posté par barmic . Évalué à 3. Dernière modification le 16 mars 2015 à 11:19.
Qu'ils soit possible de le faire je n'en doute pas, mais c'est une vraie régression d'un point de vu ergonomie (et plus on perds en ergonomie, moins on prend le temps de le faire…). Je doute pas qu'ils trouveront une solution, mais tu ne peux pas nier que c'est un problème aujourd'hui.
Sachant qu'il faut aussi comparer ça à des systèmes « classiques » parce que certains veulent que l’hôte fasse le minimum est que toutes les application soient dans des images docker.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Et les dépendances ?
Posté par 16aR . Évalué à 1. Dernière modification le 07 avril 2015 à 13:24.
Si des images partagent les mêmes lib, pourquoi ne pas les faire partager une même image source ?
Au lieu d'un
FROM debian:7on metFROM ma-debian-avec-lib-communeEt ensuite, tu rebuildes cette image-là avec les nouvelles mises-à-jour de sécurité, et tu rebuildes chaque sous-image depuis celle là. En tout et pour tout, tu n'auras eu qu'un seul
apt-get update -y && apt-get dist-upgrade -ysur l'imagema-debian-avec-lib-communeet chacune de tes images dérivera de celle ci et devra rebuilder sur cette nouvelle base mise à jour.Globalement, la lourdeur est de gérer un Dockerfile supplémentaire pour ta distrib de base commune à chaque images de chacun de tes services.
En schéma, puisque j'ai l'impression que j'ai trop rédigé
au lieu de
Tu auras
# Back to the chroots
Posté par Richard Dern . Évalué à 2.
J'avais envie de bien séparer mes sites de prod de mes sites de dev, histoire de pas polluer l'environnement de prod avec des outils utilisés qu'en dev (genre gulp). Je me suis donc dis que Docker devait répondre à ce besoin. Mais comme ce journal l'a évoqué, un conteneur pour le serveur web et un pour la bdd, rien que ça, c'est chiant à mettre en place.
Surtout qu'apparemment, Docker c'est vachement plus simple et vachement mieux avec Ansible.
Donc pour faire les choses bien, il faut maitriser Docker, Ansible, et accepter d'avoir 36 000 conteneurs par application.
Donc, je me suis monté deux chroots sous ma Debian fétiche: un pour le dev, un pour la prod, l'hôte faisant du reverse-proxy pour les deux. C'est propre, y'a du logging, du ssh, tout ce dont on a besoin, et je peux fracasser le dev sans toucher à la prod.
Franchement, ces tools de hipsters me gavent… Donc je rejoins l'avis du journal (un poil à la bourre).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.