Ca depend quel application. Je peux t'en citer pas mal qui auront du mal a soutenir la charge.
Alors, fais-le :) , ca apportera au débat. Personnellement, je n'ai pas de noms en tête.
Comme on parle d'applications Web libres qu'on déploie soi-même pour soi et ses contacts, on suppose que le nombre d'utilisateurs reste <= 30 personnes par exemple.
La phrase est évidemment excessive, c'est trolldi. Les applications n'ont pas remplacé toutes les applications desktop. Mon argument, c'est de dire que les applications Web offrent plein d'avantages et qu'elles sont appelées à se développer dans les années à venir.
Et à la maison c'est pareil, je ne suis pas près de confier mes données à un tiers. Réactionaire ? Certainement, et j'assume. Le web offre des possibilités stupéfiantes mais le fait de dépendre d'une connexion pas assez fiable - ainsi que la difficulté d'avoir un niveau de confidentialité correct et facilement vérifiable - font que je préfère encore travailler et stocker en local.
Ah mais avec ça, je suis d'accord ! Je n'envisage pas non plus de filer toutes mes données à une entité externe, d'où le besoin d'applications Web libre, que l'on déploie soi-même et que l'on maîtrise. D'ailleurs, ces applications existent ou commencent à exister.
Le principal problème à mon sens, c'est que c'est applications restent difficiles à installer/déployer. Je me pose la question des solutions qu'on peut apporter à ce problème.
Tu te trompes complètement en pensant que le web remplace les applications bureau…
simplement plus pratique/rapide que ne le sera jamais une application Web
Je pense que tu as raison dans une certaine mesure. Mais si on regarde les choses sous un autre angle, Google vends déjà des Chromebook avec un OS qui fait juste tourner un navigateur Web. Ils fournissent tous leurs services sous forme d'applications Web.
Pour les développeurs, ils fournissent toute une bibliothèques de composants d'interface graphiques Polymer pour développer des applications web s'intégrant bien avec Android, mais fonctionnant aussi bien sur d'autres plateformes. Javascript est le langage le plus populaire sur Github. Bref, je crois que faut vraiment pas négliger cette tendance au développement d'application Web. Faut reconnaître que c'est vraiment pratique de juste taper une URL pour accéder à une application. Rien à installer, tes contacts ont automatiquement la même version, sans rien installer eux aussi, quel que soit leur OS.
Honnêtement, de nos jours, une application Web, c'est pas plus lent qu'une application desktop (enfin me semble-t-il).
(victime elle aussi de la loi de Moore sur le débit)
Tu pourrais développer ce point, je ne l'ai pas compris. Une application web, ça utilise pas énormément de débit, en tous cas, bien moins que streamer une vidéo par exemple.
Mais maintenant que les bureaux Windows/Mac/Linux visent tous l'intégration avec le web, les gens vont certes utiliser des services distants mais de moins en mois d'applications web…
C'est vrai que les applications desktop s'intégrent de plus en plus avec les services distants. Quand au fait qu'on va utiliser de moins en moins d'applications web pour cette raison, je ne suis pas convaincu.
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.
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.
docker run -d --name apache repo/apache:latest
docker run -d --name jboss --link apache:apache repo/jboss:latest
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 :
--link=CONTAINER_NAME_or_ID:ALIAS — using this option as you run a container gives the new container's /etc/hosts an extra entry named ALIAS that points to the IP address of the container identified by CONTAINER_NAME_or_ID. This lets processes inside the new container connect to the hostname ALIAS without having to know its IP. The --link= option is discussed in more detail below, in the section Communication between containers. Because Docker may assign a different IP address to the linked containers on restart, Docker updates the ALIAS entry in the /etc/hosts file of the recipient containers.
Et puis :
Whether two containers can communicate is governed, at the operating system level, by two factors.
Does the network topology even connect the containers' network interfaces? By default Docker will attach all containers to a single docker0 bridge, providing a path for packets to travel between them. See the later sections of this document for other possible topologies.
Do your iptables allow this particular connection? Docker will never make changes to your system iptables rules if you set --iptables=false when the daemon starts. Otherwise the Docker server will add a default rule to the FORWARD chain with a blanket ACCEPT policy if you retain the default --icc=true, or else will set the policy to DROP if --icc=false.
It is a strategic question whether to leave --icc=true or change it to --icc=false (on Ubuntu, by editing the DOCKER_OPTS variable in /etc/default/docker and restarting the Docker server) so that iptables will protect other containers — and the main host — from having arbitrary ports probed or accessed by a container that gets compromised.
If you choose the most secure setting of --icc=false, then how can containers communicate in those cases where you want them to provide each other services?
The answer is the --link=CONTAINER_NAME_or_ID:ALIAS option, which was mentioned in the previous section because of its effect upon name services. If the Docker daemon is running with both --icc=false and --iptables=true then, when it sees docker run invoked with the --link= option, the Docker server will insert a pair of iptables ACCEPT rules so that the new container can connect to the ports exposed by the other container — the ports that it mentioned in the EXPOSE lines of its Dockerfile. Docker has more documentation on this subject — see the linking Docker containers page for further details.
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).
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.
Désolé je suis pas convaincu par la comparaison avec Word/OpenOffice […]
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.
travail préliminaire sur la possibilité de virer zookeeper pour mettre etcd à la place […]
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.
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
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 !
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é.
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.
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.
L'emprunte mémoire du guest OS est aussi à prendre en compte […] là où il sera null dans le cas d'un container.
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 ?
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.
Le loging je comprend pas, entre configurer un rsyslog […]
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.
Mouais , enfin l'overhead d'une VM c'est pas grand chose […]
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/
J'en ai vraiment marre du bashing anti-Java primaire. Faut arrêter de raconter n'importe quoi.
Les failles de sécurité à gogo
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
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.
L'enfer des changements de versions
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.
Perso je refuse le Java sur les serveurs
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.
Et qu'est ce qui t’empêche de faire ça avec Docker […]
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.
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".
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.
Oui y'a toujours, toujours des couilles à la mise en prod. Toujours. Y'a aussi toujours, toujours des couilles quand on monte en charge. Toujours.
C'est pas parce qu'un test ne permet pas de détecter 100% des bugs qu'il ne faut pas le faire. Si y'a mettons 5 bugs qui vont se déclencher lors de l'ajout de la fonctionnalité, le test dans une VM permettra peut-être d'en détecter 2. Si on a une machine de pré-prod, on arrivera peut-être à en attrapper encore 2 supplémentaires. Ça fait un gros gain en termes de disponibilité.
Parce que clairement, si t'intervient directement sur le serveur de prod à l'arrache, tu vas le rendre indisponible pendant des heures. Sans compter qu'une fois que tu auras résolu les cind bugs, on plus personne ne saura ce que t'as fait. La prochaine fois qu'on installera le même logiciel sur une autre machine, on se retapera les heures d'indisponibilité et le temps de résolution des bugs. Ça n'arrivera pas avec un script de déploiement.
de plus, il se passe quoi, avec ton systeme de backup, si ta machine se voit ajouter une fonctionnalité en cours d'usage ? […]
Non, vraiment, vraiment, en 2015, on ne procède plus comme ça. C'est un tel nid à emmerdes d'intervenir directement sur une machine sans que ce soit documenté. Je sais que c'est chiant de changer, que ça prend du temps, et que dans certains cas les scripts sont vraiment longs à écrire mais faut vraiment arrêter d'intervenir au petit bonheur la chance sur les machines de prod.
Donc, la bonne manière de faire en 2015, pour ajouter une fonctionnalité à une machine, c'est :
Écrire les templates de fichier de configuration pour le nouveau logiciel/service
Mettre à jour le script Chef/Puppet/Salt/Ansible de déploiement
Tester le script sur une VM (vagrant est votre ami)
Commiter les modifications dans le dépôt git/svn/whatever contenant le scripts de déploiement
Lancer le déploiement du script sur la machine de prod
Oui, c'est un peu plus long (mais vraiment, une fois que les process sont en place, c'est moins de 25% plus long) que d'intervenir directement sur la machine mais :
Ça évite de casser la machine de prod parce qu'on s'est vautré dans la config de tel logiciel
Ce qu'on a fait est acté et documenté
On pourra réinstaller très facilement la machine ou la mettre à jour
On pourra installer une deuxième machine à l'identique pour faire des tests ou scale-out
Je suis pas sur que l'augmentation des coûts engendrée par l'augmentation du volume des sauvegardes soit vraiment significative. Regarde, dans 4TB (capacité standard d'un disque 3.5", on fait pas les sauvegardes sur du SAS 10K, enfin je me méfie ;-) ), on peut déjà stocker 200 partitions de 20Go. Un disque de 4TB, ça coute ~200€ HT, donc vraiment négligeable pour une entreprise.
Je pense que le vrai problème derrière les sauvegarde "images", c'est que ça encourage le "vite fait, mal fait". On ne documente plus les procédures d'installation, on ne les automatise pas non plus. C'est comme ça qu'on finit avec une CentOS 5 que personne ne peut mettre à jour ou réinstaller parce qu'on a plus aucune idée de ce qui tourne dessus, et de comment ça a été installé. Comme ça qu'on finit avec un rootkit qui vit pendant des années sur les serveurs de la boite.
Clairement, vaut 1000 fois mieux avoir des scripts Puppet/Chef/Ansible/Salt à jour qu'une tétrachiée d'images dont on sait à peine ce qu'elles contiennent. On peut facilement mettre à jour (on change la distribution dans le script, on teste sur une machine de pré-prod, on fixe les bugs, on déploie la nouvelle version) et si la machine a été compromise, on fixe la faille de sécurité, et on déploie un "système" neuf et propre ou on est sur qu'il n'y a pas de rootkit qui tourne. Pareil lorsqu'il y a un bug, c'est beaucoup plus facile de passer en revue ce qui est installé et les fichiers de configuration si on a un script de déploiement automatique. Non, vraiment, c'est une bonne pratique d'avoir des scripts d'installation automatiques.
Ton message parlant de "contrat de sauvegarde" a été moinssé et pourtant tu es dans le vrai. Le "/repertoireimprobable" n'a pas lieu d'exister. Comment on fait au bout de 5 ans quand tout le monde s'est installé un peu comme il veut sur la machine et créé des arborescences sans rien documenter ?
Ton journal me fait penser au débat images vs recettes :
Images : On fait une image complète du système installé que l'on restaure en cas de besoin
Recettes : On crée des scripts d'installation/configuration capables d'installer un serveur à l'identique
La question que tu poses, c'est est-ce qu'en 2015, il y a encore des raisons valables de préférer les images aux recettes ?
Peut-être que dans certains cas, le temps de restauration d'une image est inférieur au temps de réinstallation d'une machine via une recette. Peut-être que dans certains cas, 20 minutes, c'est trop et que restaurer le l'image via le réseau 40Gb/s est plus rapide. Tu noteras que ça fait beaucoup de peut-être.
Sinon je pense que la raison principale pour laquelle les images sont encore utilisées est le poids des habitudes, et le confort du non-changement, comme d'habitude.
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.
Pour commencer merci pour toutes tes remarques contructives.
J'aimerai savoir sur quoi tu te bases pour dire ça […]
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 (et nsenter, mais ce dernier fait clairement bidouille), mais pendant longtemps il n'y avait pas grand chose pour inspecter un conteneur.
Les mises à jour sont problématiques oui. Mais ça c'est pas propre à docker, […]
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 build que 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.
Ça c'est ton avis. J'aurai plutôt tendance à dire que sa simplicité est sa force. […]
Parmi les points souvent critiqués, il y a:
Pas de possibilité de faire des Dockerfile templates (Hello Packer)
Pas d'héritage multiple de Dockerfile
Pas de logique (if en fonction de variables d'environnement etc.)
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 ? […]
Effectivement, mais quel est alors l'intérêt de docker build si 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 ?
Docker (et tout système de container) n'est PAS une solution de virtualisation, c'est juste un chroot sous stéroïdes […]
Ç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.
Y'a deux ans, j'ai commandé une imprimante sur CDiscount (oui…, je sais) en demandant une livraison dans un point relai. Une fois le coli annoncé comme livré, je me rends au point relai que j'avais indiqué; point relai qui n'a pas reçu mon colis.
J'appelle CDiscount qui après avoir supporté Vivaldi 15 minutes et quelques négociations m'indique qu'il lance une enquête au près du transporteur. Rien que ça, une enquête. Au bout de deux jours, je reçois un mail m'indiquant que tout va bien et que le colis est disponible auprès du point relai. Bien sur, il n'y est pas. Rebelote, Re-appel à CDiscout, Re-Attente, Re-Vivaldi, Re-Ah-oui-mais-non-je-transfere-l-appel, Re-attente, Re-Vivaldi, Re-Attente. Re-Vivaldi. Re-négociation, Re-enquête auprès du transporteur. Bien sur, même résultat, le colis a bien été livré. Au total 10€ de claqués en communications téléphoniques. Rentable ce petit jeu. Ça fait une jolie marge supplémentaire sur un produit à 70€.
Je fouille sur le site de colissimo (le transporteur) et trouve un numéro à appeler, réponse en 3 minutes, attente incluse (ça fait plaisir d'avoir un interlocuteur qui met pas 14 plombes à comprendre votre problème), le colis à été livré au mauvais point relai. Eh beh, tout ça pour ça ! Le colis était effectivement disponible à l'autre point relai.
Alors je ne sais pas en quoi consistent les enquêtes auprès du transporteurs, mais s'ils ne sont pas foutus de gèrer un cas aussi simple qu'une petite erreur de livraison (les deux points relais étaient à 3Km l'un de l'autre), je vois vraiment pas à quoi elles servent.
La scalabilité horizontale et les architectures élastiques (c'est ça aussi le cloud actuel) c'est quand même assez formidable pour améliorer la consommation :
on utilise un paquet de petites machines plutôt qu'une grosse et on sait mieux gérer la consommation de ses bêtes là que de gros mastodontes ;
Je suis vraiment pas convaincu pas ça, et j'aimerais bien avoir des références de cas pratiques pour lesquels ça marche vraiment. Genre je voudrais bien voir un passage d'une architecture basée sur du x86 vers une architecture basée sur de l'ARM qui a apporté un gain en consommation et avec des besoins en calcul non triviaux (pour faire du NAS, j'imagine que ça marche bien). "ARM ça consomme moins", ça me paraît être un poncif qu'on répète souvent mais qui ne se vérifie pas dans le contexte du datacenter.
Certes, je veux bien admettre qu'il soit plus facile de gagner en consommation en éteignant de petites machines ARM inutilisées qu'on downclockant ou jouant avec les sleep states d'un gros processeur x86 (et encore…).
Reste que faut arrêter d'imaginer que 4 processeurs à 1Ghz en réseau, c'est équivalent à 1 processeur à 4Ghz. Ce n'est pas le cas. Dire ça, c'est oublier l'impact des caches, des latences mémoires et réseaux, des débits mémoire et réseaux et tout un tas d'autres problèmes. Ne serait-ce parce qu'on passe d'un espace mémoire partagé à des espaces mémoires cloisonnées.
Bref, je pense qu'il faut bien 200 Raspberry Pi pour remplacer un Core i5 chargé à 20%. Pas sur qu'on y gagne en consommation. Sans compter que ça amène à dupliquer les cartes réseaux, les alims et les périphériques de stockage, donc multiplier la consommation des éléments qui ne sont pas des processeurs. Pas sur non plus qu'on arrive à égaler la performance du Core i5. C'est sur que si le Core i5 ne fait rien, on peut aisément le remplacer par un ARM (e.g. NAS, dédibox ou kimsufi de particulier qui dort 90% du temps et qui n'est jamais chargé à plein).
Pour Facebook, la solution (pour l'instantà c'est d'employer des ingénieurs à optimiser aux petits oignons leur code et faire tourner ça sur trouzemille serveurs x86, pas d'utiliser de l'ARM.
Bref, non la scalabilité horizontale, c'est pas terrible pour la consommation. Vaut mieux probablement scaler verticalement dans la plupart des cas pour obtenir une conso basse. On fait de la scalabilité horizontale parce qu'on a pas le choix (au bout d'un moment, c'est compliqué de scaler verticalement, j'attends toujours mon Xeon avec 1000 cœurs à 17Ghz :))
[^] # Re: Perdu
Posté par X345 . En réponse au journal Linux pas prêt pour le desktop ? Pas grave !. Évalué à 2.
Alors, fais-le :) , ca apportera au débat. Personnellement, je n'ai pas de noms en tête.
Comme on parle d'applications Web libres qu'on déploie soi-même pour soi et ses contacts, on suppose que le nombre d'utilisateurs reste <= 30 personnes par exemple.
[^] # Re: Le desktop est mort ? Ah bon
Posté par X345 . En réponse au journal Linux pas prêt pour le desktop ? Pas grave !. Évalué à 2.
La phrase est évidemment excessive, c'est trolldi. Les applications n'ont pas remplacé toutes les applications desktop. Mon argument, c'est de dire que les applications Web offrent plein d'avantages et qu'elles sont appelées à se développer dans les années à venir.
Ah mais avec ça, je suis d'accord ! Je n'envisage pas non plus de filer toutes mes données à une entité externe, d'où le besoin d'applications Web libre, que l'on déploie soi-même et que l'on maîtrise. D'ailleurs, ces applications existent ou commencent à exister.
Le principal problème à mon sens, c'est que c'est applications restent difficiles à installer/déployer. Je me pose la question des solutions qu'on peut apporter à ce problème.
[^] # Re: Perdu
Posté par X345 . En réponse au journal Linux pas prêt pour le desktop ? Pas grave !. Évalué à 3.
Je pense que tu as raison dans une certaine mesure. Mais si on regarde les choses sous un autre angle, Google vends déjà des Chromebook avec un OS qui fait juste tourner un navigateur Web. Ils fournissent tous leurs services sous forme d'applications Web.
Pour les développeurs, ils fournissent toute une bibliothèques de composants d'interface graphiques Polymer pour développer des applications web s'intégrant bien avec Android, mais fonctionnant aussi bien sur d'autres plateformes. Javascript est le langage le plus populaire sur Github. Bref, je crois que faut vraiment pas négliger cette tendance au développement d'application Web. Faut reconnaître que c'est vraiment pratique de juste taper une URL pour accéder à une application. Rien à installer, tes contacts ont automatiquement la même version, sans rien installer eux aussi, quel que soit leur OS.
Honnêtement, de nos jours, une application Web, c'est pas plus lent qu'une application desktop (enfin me semble-t-il).
Tu pourrais développer ce point, je ne l'ai pas compris. Une application web, ça utilise pas énormément de débit, en tous cas, bien moins que streamer une vidéo par exemple.
C'est vrai que les applications desktop s'intégrent de plus en plus avec les services distants. Quand au fait qu'on va utiliser de moins en moins d'applications web pour cette raison, je ne suis pas convaincu.
[^] # Re: Conclusion un peu hative
Posté par X345 . En réponse au journal Docker, la plateforme à la mode. É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 X345 . En réponse au journal Docker, la plateforme à la mode. É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 X345 . En réponse au journal Docker, la plateforme à la mode. É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: devops
Posté par X345 . En réponse au journal Docker, la plateforme à la mode. É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: Conclusion un peu hative
Posté par X345 . En réponse au journal Docker, la plateforme à la mode. É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 X345 . En réponse au journal Docker, la plateforme à la mode. É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: devops
Posté par X345 . En réponse au journal Docker, la plateforme à la mode. É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: Conclusion un peu hative
Posté par X345 . En réponse au journal Docker, la plateforme à la mode. É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 X345 . En réponse au journal Docker, la plateforme à la mode. É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 X345 . En réponse au journal Docker, la plateforme à la mode. É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: Questions de vieux cons
Posté par X345 . En réponse au journal Docker, la plateforme à la mode. É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: Conclusion un peu hative
Posté par X345 . En réponse au journal Docker, la plateforme à la mode. É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: probleme de version ?
Posté par X345 . En réponse au journal Les sauvegardes, et les logiciels de sauvegarde. Évalué à 10.
Oui y'a toujours, toujours des couilles à la mise en prod. Toujours. Y'a aussi toujours, toujours des couilles quand on monte en charge. Toujours.
C'est pas parce qu'un test ne permet pas de détecter 100% des bugs qu'il ne faut pas le faire. Si y'a mettons 5 bugs qui vont se déclencher lors de l'ajout de la fonctionnalité, le test dans une VM permettra peut-être d'en détecter 2. Si on a une machine de pré-prod, on arrivera peut-être à en attrapper encore 2 supplémentaires. Ça fait un gros gain en termes de disponibilité.
Parce que clairement, si t'intervient directement sur le serveur de prod à l'arrache, tu vas le rendre indisponible pendant des heures. Sans compter qu'une fois que tu auras résolu les cind bugs, on plus personne ne saura ce que t'as fait. La prochaine fois qu'on installera le même logiciel sur une autre machine, on se retapera les heures d'indisponibilité et le temps de résolution des bugs. Ça n'arrivera pas avec un script de déploiement.
[^] # Re: probleme de version ?
Posté par X345 . En réponse au journal Les sauvegardes, et les logiciels de sauvegarde. Évalué à 10.
Non, vraiment, vraiment, en 2015, on ne procède plus comme ça. C'est un tel nid à emmerdes d'intervenir directement sur une machine sans que ce soit documenté. Je sais que c'est chiant de changer, que ça prend du temps, et que dans certains cas les scripts sont vraiment longs à écrire mais faut vraiment arrêter d'intervenir au petit bonheur la chance sur les machines de prod.
Donc, la bonne manière de faire en 2015, pour ajouter une fonctionnalité à une machine, c'est :
Oui, c'est un peu plus long (mais vraiment, une fois que les process sont en place, c'est moins de 25% plus long) que d'intervenir directement sur la machine mais :
[^] # Re: Tout dépend des postes
Posté par X345 . En réponse au journal Les sauvegardes, et les logiciels de sauvegarde. Évalué à 5.
Je suis pas sur que l'augmentation des coûts engendrée par l'augmentation du volume des sauvegardes soit vraiment significative. Regarde, dans 4TB (capacité standard d'un disque 3.5", on fait pas les sauvegardes sur du SAS 10K, enfin je me méfie ;-) ), on peut déjà stocker 200 partitions de 20Go. Un disque de 4TB, ça coute ~200€ HT, donc vraiment négligeable pour une entreprise.
Je pense que le vrai problème derrière les sauvegarde "images", c'est que ça encourage le "vite fait, mal fait". On ne documente plus les procédures d'installation, on ne les automatise pas non plus. C'est comme ça qu'on finit avec une CentOS 5 que personne ne peut mettre à jour ou réinstaller parce qu'on a plus aucune idée de ce qui tourne dessus, et de comment ça a été installé. Comme ça qu'on finit avec un rootkit qui vit pendant des années sur les serveurs de la boite.
Clairement, vaut 1000 fois mieux avoir des scripts Puppet/Chef/Ansible/Salt à jour qu'une tétrachiée d'images dont on sait à peine ce qu'elles contiennent. On peut facilement mettre à jour (on change la distribution dans le script, on teste sur une machine de pré-prod, on fixe les bugs, on déploie la nouvelle version) et si la machine a été compromise, on fixe la faille de sécurité, et on déploie un "système" neuf et propre ou on est sur qu'il n'y a pas de rootkit qui tourne. Pareil lorsqu'il y a un bug, c'est beaucoup plus facile de passer en revue ce qui est installé et les fichiers de configuration si on a un script de déploiement automatique. Non, vraiment, c'est une bonne pratique d'avoir des scripts d'installation automatiques.
Ton message parlant de "contrat de sauvegarde" a été moinssé et pourtant tu es dans le vrai. Le "/repertoireimprobable" n'a pas lieu d'exister. Comment on fait au bout de 5 ans quand tout le monde s'est installé un peu comme il veut sur la machine et créé des arborescences sans rien documenter ?
# Images vs Recettes
Posté par X345 . En réponse au journal Les sauvegardes, et les logiciels de sauvegarde. Évalué à 10.
Ton journal me fait penser au débat images vs recettes :
La question que tu poses, c'est est-ce qu'en 2015, il y a encore des raisons valables de préférer les images aux recettes ?
Peut-être que dans certains cas, le temps de restauration d'une image est inférieur au temps de réinstallation d'une machine via une recette. Peut-être que dans certains cas, 20 minutes, c'est trop et que restaurer le l'image via le réseau 40Gb/s est plus rapide. Tu noteras que ça fait beaucoup de peut-être.
Sinon je pense que la raison principale pour laquelle les images sont encore utilisées est le poids des habitudes, et le confort du non-changement, comme d'habitude.
[^] # Re: c'est pas parce que c'est pas bien pour la prod qu'il faut tout jeter non plus
Posté par X345 . En réponse au journal Docker, la plateforme à la mode. É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: Conclusion un peu hative
Posté par X345 . En réponse au journal Docker, la plateforme à la mode. É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: En gros, je résume avec une pelle :
Posté par X345 . En réponse au journal Superfish ou: j'ai rien compris au logiciel propriétaire. Évalué à 10.
C'est pas forcément un inconvénient, tout est une question de goût.
# Ah les fameuses réclamations au transporteur...
Posté par X345 . En réponse au message Commande chez LDLC, vol de smartphone chez Chronopost. Comment porter plainte ?. Évalué à 4.
Y'a deux ans, j'ai commandé une imprimante sur CDiscount (oui…, je sais) en demandant une livraison dans un point relai. Une fois le coli annoncé comme livré, je me rends au point relai que j'avais indiqué; point relai qui n'a pas reçu mon colis.
J'appelle CDiscount qui après avoir supporté Vivaldi 15 minutes et quelques négociations m'indique qu'il lance une enquête au près du transporteur. Rien que ça, une enquête. Au bout de deux jours, je reçois un mail m'indiquant que tout va bien et que le colis est disponible auprès du point relai. Bien sur, il n'y est pas. Rebelote, Re-appel à CDiscout, Re-Attente, Re-Vivaldi, Re-Ah-oui-mais-non-je-transfere-l-appel, Re-attente, Re-Vivaldi, Re-Attente. Re-Vivaldi. Re-négociation, Re-enquête auprès du transporteur. Bien sur, même résultat, le colis a bien été livré. Au total 10€ de claqués en communications téléphoniques. Rentable ce petit jeu. Ça fait une jolie marge supplémentaire sur un produit à 70€.
Je fouille sur le site de colissimo (le transporteur) et trouve un numéro à appeler, réponse en 3 minutes, attente incluse (ça fait plaisir d'avoir un interlocuteur qui met pas 14 plombes à comprendre votre problème), le colis à été livré au mauvais point relai. Eh beh, tout ça pour ça ! Le colis était effectivement disponible à l'autre point relai.
Alors je ne sais pas en quoi consistent les enquêtes auprès du transporteurs, mais s'ils ne sont pas foutus de gèrer un cas aussi simple qu'une petite erreur de livraison (les deux points relais étaient à 3Km l'un de l'autre), je vois vraiment pas à quoi elles servent.
[^] # Re: crimier!!
Posté par X345 . En réponse au sondage La navigation privée du navigateur me sert surtout :. Évalué à 3.
Non, il dit qu'il a plus de genou
[^] # Re: Amazon, Azure, Google, ...
Posté par X345 . En réponse au journal I had a dream : des pingouins verts !. Évalué à 6. Dernière modification le 31 décembre 2014 à 15:25.
Je suis vraiment pas convaincu pas ça, et j'aimerais bien avoir des références de cas pratiques pour lesquels ça marche vraiment. Genre je voudrais bien voir un passage d'une architecture basée sur du x86 vers une architecture basée sur de l'ARM qui a apporté un gain en consommation et avec des besoins en calcul non triviaux (pour faire du NAS, j'imagine que ça marche bien). "ARM ça consomme moins", ça me paraît être un poncif qu'on répète souvent mais qui ne se vérifie pas dans le contexte du datacenter.
Certes, je veux bien admettre qu'il soit plus facile de gagner en consommation en éteignant de petites machines ARM inutilisées qu'on downclockant ou jouant avec les sleep states d'un gros processeur x86 (et encore…).
Reste que faut arrêter d'imaginer que 4 processeurs à 1Ghz en réseau, c'est équivalent à 1 processeur à 4Ghz. Ce n'est pas le cas. Dire ça, c'est oublier l'impact des caches, des latences mémoires et réseaux, des débits mémoire et réseaux et tout un tas d'autres problèmes. Ne serait-ce parce qu'on passe d'un espace mémoire partagé à des espaces mémoires cloisonnées.
Bref, je pense qu'il faut bien 200 Raspberry Pi pour remplacer un Core i5 chargé à 20%. Pas sur qu'on y gagne en consommation. Sans compter que ça amène à dupliquer les cartes réseaux, les alims et les périphériques de stockage, donc multiplier la consommation des éléments qui ne sont pas des processeurs. Pas sur non plus qu'on arrive à égaler la performance du Core i5. C'est sur que si le Core i5 ne fait rien, on peut aisément le remplacer par un ARM (e.g. NAS, dédibox ou kimsufi de particulier qui dort 90% du temps et qui n'est jamais chargé à plein).
Pour Facebook, la solution (pour l'instantà c'est d'employer des ingénieurs à optimiser aux petits oignons leur code et faire tourner ça sur trouzemille serveurs x86, pas d'utiliser de l'ARM.
Bref, non la scalabilité horizontale, c'est pas terrible pour la consommation. Vaut mieux probablement scaler verticalement dans la plupart des cas pour obtenir une conso basse. On fait de la scalabilité horizontale parce qu'on a pas le choix (au bout d'un moment, c'est compliqué de scaler verticalement, j'attends toujours mon Xeon avec 1000 cœurs à 17Ghz :))