J’ai twitté il y a quelque temps l’article hilarant It’s the future. Mais j’ai bien conscience que plein de gens ne lisent pas l’anglais et ne peuvent profiter de cette perle. Comme on a ouvert le blog S&M en français, car on voulait justement créer des bonnes ressources dans notre langue, je traduis de temps en temps ces trucs fantastiques, comme par exemple Le bonheur des frameworks.
Donc voici la traduction de celui-ci. Faites-vous plaiz’
Hey, mon boss m’a dit de venir te voir. Il paraît que tu gères niveau web apps ?
– Ouais, je suis plus un spécialiste des systèmes distribués maintenant. Je reviens du ContainerCamp et de la Gluecon et je vais à la Dockercon la semaine prochaine. Je suis emballé par la direction que prend l’industrie – tout est plus simple et fiable. C’est le futur !
Cool. Je veux juste faire une simple Web app pour le moment – un CRUD normal avec Rails, que je vais déployer sur Heroku. C’est toujours d’actu ?
– Oh non. C’est old school. Heroku, c’est mort – plus personne ne l’utilise. Il te faut Docker maintenant. C’est le futur.
Oh, OK. Qu’est-ce que c’est ?
– Docker est la nouvelle façon de faire de la conteneurisation. Comme LXC, mais c’est aussi un format de package, une plateforme de distribution et des outils pour rendre la création de systèmes distribués très facile.
Conteneuri.. – Hein ? C’est quoi LXE ?
– LCX. C’est comme un chroot aux stéroïdes.
C’est quoi cheroot ?
– Ok, regarde. Docker. Conteneurisation. C’est le futur. C’est comme la virtualisation, mais plus rapide et moins coûteux.
Oh, comme Vagrant.
– No, Vagrant c’est mort. Tout va être conteneurisé maintenant, c’est le futur.
Ok, donc je n’ai pas besoin de savoir quoi que ce soit sur la virtualisation ?
– Non, tu as quand même besoin de la virtualisation, parce que les conteneurs ne fournissent pas toutes les couches de sécurité pour le moment. Donc ce que tu veux, c’est faire tout tourner dans un environnement multitiers de telle sorte qu’on ne puisse s’échapper de la sandbox.
Ok, je suis un peu perdu là. On rembobine. Donc il y a un truc comme la virtualisation qu’on appelle les conteneurs. Et je peux l’utiliser sur Heroku ?
– Et bien, Heroku a un support pour docker, mais je viens de le dire : Heroku c’est mort. Ce que tu veux c’est faire tourner tes conteneurs sur CoreOS.
Ok, c’est quoi ?
– C’est un OS hôte très cool qu’on peut utiliser avec Docker. Tu n’as même pas besoin de Docker, tu peux utiliser rkt.
Rocket ?
– No, rkt.
Ouais, Rocket.
– Non, ça s’appelle rkt maintenant. Rien à voir. C’est un format de conteneurisation alternatif qui n’est pas aussi intégré que Docker par défaut, et donc plus composable.
C’est une bonne chose.
– Bien entendu. La composabilité c’est le futur.
Ok, ça s’utilise comment ?
– Je ne sais pas. Je ne pense pas que qui que ce soit l’utilise.
Arf. Tu disais quoi à propos de CoreOS ?
– Ah oui, c’est un OS hôte pour Docker.
C’est quoi un OS hôte ?
– Un OS hôte fait tourner tous tes conteneurs.
Tourner mes conteneurs ?
– Ouais, tu dois avoir quelque chose pour faire tourner tes conteneurs. Donc tu te crées genre une instance EC2, tu mets CoreOS dessus, tu lances le daemon Docker, puis tu déploies tes images Docker dessus.
Quelle partie est le conteneur ?
– Tout. Écoute, tu prends ton app, écris un Dockerfile, tu en fais une image locale, puis tu la push sur n’importe quel hôte Docker.
Ah, comme Heroku ?
– Non, pas Heroku. Je te l’ai dit. Heroku c’est mort. Tu gères ton propre cloud en utilisant Docker.
Hein ?
– Ouais, c’est tout simple. Check #gifee.
Gify?
– Google’s infrastructure for everyone else. Tu prends les outils que tu veux, avec des conteneurs, et tu as la même infra que Google.
Pourquoi pas juste utiliser celles de Google ?
Tu crois que ça sera encore là dans 6 mois ?
OK, mais est-ce que quelqu’un fait du hosting pour ça ? J’ai pas la foi d’héberger mon bordel moi-même.
– Et bien, Amazon a ECS, mais il faut écrire du XML et 2, 3 merdes.
Et OpenStack ?
– Beurk.
Beurk ?
– Beurk.
Écoute, j’ai vraiment pas envie d’héberger tout ça.
– Na, c’est super simple. Tu te setup juste un cluster Kubernetes.
J’ai besoin d’un cluster ?
– Un cluster Kubernetes. Ça gère le déploiement de tous tes services.
J’ai seulement un service.
– Qu’est-ce que tu racontes. Tu as une app non? donc tu as bien au moins 8-12 services ?
Quoi ? Non. Juste une app. Service, on s’en branle. Juste un truc.
– Non, jette un coup d’oeil à la notion de microservices. C’est le futur. C’est comme ça qu’on fait tout de nos jours. Tu prends ton app monolithique et tu la divises en quelque chose comme 12 services, un pour chaque tâche.
Ça semble excessif.
– C’est le seul moyen de s’assurer que c’est fiable. Ainsi si ton service authentification tombe…
Service authentification ? J’allais juste utiliser une gem que j’avais déjà mis en place plusieurs fois avant.
– Super. Utilise la gem. Mets la dans son propre projet. Fous une API RESTful par dessus. Et fait en sorte que les autres services utilisent cette API et gèrent gracieusement les échecs. Mets ça dans un conteneur et push le bordel en déploiement continu.
Ok, donc là j’ai une douzaine de services ingérables, et maintenant ?
– Ouais, d’où Kubernetes. Il orchestre tes services.
Orchestre ?
– Ouais, donc tu as ces services, ils doivent être fiables donc il t’en faut plusieurs copies. Donc Kubernetes s’assure que tu en as assez, et qu’ils sont distribués à travers de multiples hôtes dans ta flotte de serveurs, afin qu’ils soient toujours disponibles.
Ah parce qu’il me faut une flotte maintenant ?
– Ouais, pour la fiabilité. Mais Kubernetes la gère pour toi. Et tu sais que Kubernetes ça marche vu que Google l’a fabriqué et que ça tourne sur etcd.
C’est quoi etcd ?
– Une implémentation de Raft.
OK, c’est quoi Raft.
– C’est comme Paxos.
Putain, jusqu’où ça va le terrier du lapin blanc là ? Je veux juste lancer une app. Arf. Bordel, Ok, on respire. Fiou. Ok, donc Paxos c’est quoi ?
– Paxos c’est ce très vieux protocole de consensus distribué des années 70 que personne ne comprend ou n’utilise.
Super, merci de m’en avoir parlé. Et donc Raft ?
– Comme personne ne pige Paxos, y a ce mec, Diego…
Oh, tu le connais ?
– Non, il travaille a CoreOS. Bref, Diego a créé Raft pour sa thèse de doctorat, car Paxos était trop compliqué. Futé le gars. Et il a écrit etcd comme implémentation, et Aphyr a dit que c’était pas de la merde.
C’est quoi Aphyr ?
– Aphyr est le mec qui a écrit Call Me Maybe. Tu vois, le mec spécialiste des systèmes distribués et du BDSM ?
WUT ? BDSM ?
– Ouais, BDSM. C’est San Francisco hein, tout le monde est à fond dans les systèmes distribués et le BDSM
Hum, OK. Donc il a écrit cette chanson de Katy Perry ?
– Nan, il a écrit des posts sur son blog comme quoi toutes les databases n’atteignaient jamais le CAP.
C’est quoi le CAP ?
– Le théorème CAP. Ça dit que tu peux avoir des données consistantes, disponibles et tolérantes au partitionnement, mais qu’il faut choisir 2 de ces caractéristiques sur les 3.
Ok, et donc toutes les bases de données foirent CAP. C’est à dire ?
– Ça veut dire qu’elles sont à chier. Comme Mongo.
Je pensais que Mongo scalait ?
– Ben personne d’autre ne le pensait.
Ok, et etcd.
– Ouais, etcd c’est un système de stockage de clé/valeur distribué.
Oh, comme Redis.
– Non, rien à voir. etcd est distribué. Redis perd la moitié de ce que tu écris en cas d’échec réseau.
Ok, donc c’est un système de stockage de clé/valeur distribué. Pourquoi c’est utile ?
– Kubernetes setup par défaut un cluster de 5 nodes et utilise etcd comme bus de transport de messages. En combinaison avec quelques services de Kubernetes lui-même, ça fournit un système d’orchestration assez résilient.
5 nodes ? J’ai une app. Combien de machines je vais devoir prendre pour tout ça ?
– Et bien tu vas avoir environ 12 services, et bien sûr il te faut des copies de chaque pour la redondance, quelques load balancers, le cluster etcd, ta base de données, et le cluster kubernetes. Je dirais peut-être 50 conteneurs.
WTF ?!
– Aucun problème ! Les conteneurs sont vraiment efficaces, donc tu peux les distribuer sur genre, 8 machines. C’est pas incroyable ?
C’est une manière de voir les choses. Et avec tout ça, je vais être capable de simplement déployer mon app ?
– Yep. Je veux dire, la question du stockage est toujours en suspend avec Docker et Kubernetes, et la partie réseau va demander un peu de travail, mais techniquement, tu es à 2m du bol de sangria.
Je vois. Ok, je pense que j’ai pigé.
– Super !
Merci pour l’explication.
– No problem.
Laisse-moi faire un résumé pour voir si j’ai bien tout compris.
– Bien sûr !
Donc j’ai besoin de diviser mon app CRUD toute simple, en 12 microservices, chacun avec leur propre API qui s’appellent les uns et les autres, mais qui gèrent les erreurs de manière résiliente, les mettre dans des conteneurs Docker, lancer une flotte de 8 machines qui sont des hôtes Docker tournant sous CoreOS, les orchestrer avec un petit cluster Kubernetes qui tourne avec etcd, me démerder avec la question du réseau et du stockage, et je fais tout ça en déploiement continu pour de multiples copies redondantes des microservices de ma flotte. J’ai bon ?
– Yep ! C’est pas fabuleux ?
Je retourne sous Heroku.
En relisant l’article, je réalise deux choses :
- Putain il en faut des références rien que pour comprendre la blague. Plein de devs ne savent même pas ce qu’est Heroku.
- Et franchement cette parodie est vraiment gentille, dans la réalité cette stack pose beaucoup d’autres problèmes : il y a plus de trucs que ça, ça s’emboîte mal, les versions changent, la doc est merdique, faut former les nouveaux arrivants car personne ne connaît ces technos, y a plein de roues à réinventer, il faut un temps fou pour choisir les briques technos, etc. Mais on peut aussi utiliser Docker très simplement, avec un image, à la main, sous Ubuntu. C’est presque simple et pratique.
ahahaha…. ça me rappelle ça: https://www.youtube.com/watch?v=b2F-DItXtZs
La vache, c’est dense. Et teeeellement vrai. Je suis moins dev que beaucoup d’entre vous, mais putain, j’ai entendu ce genre de discours combien de fois ! Je sais pas comment ils font. Soit ils sont des bêtes de travail et maîtrisent en permanence toutes les dernières techno (et chapeau bas !), soit ils surfent en surface, ça marche aujourd’hui et inch allah… Mon mauvais esprit me fait pencher plutôt pour le second angle de vue, un peu à la zeub – ah pardon, c’est mort zeub, plus personne ne le dit…
Ça me rappelle le film “Le diable s’habille en Prada”.
L’informatique est affaire de mode. Et la mode, ça me gonfle, surtout les divas qui ne jurent que par la dernière techno en vogue, la nième silver bullet, toujours soit-disant meilleure que la précédente.
Hé les gars, redescendez de votre nuage (ha ha).
Des fois c’est bien de faire un truc qui “juste marche”.
Quand je vois ça, je suis content d’être plutôt du côté informaticien théoricien.
C’est pas dans ce domaine que les langages hermétiques sont en voie de disparition,
mais on est moins touché par la hype sur des technos diverses. Je dirais que l’environnement n’intègre pas de nouvelles fonctionnalités : elles améliorent celles qui fonctionnent.
Bon, après, quand on voit ceux qui sont encore sur du fortran pour faire des poc… Bref, il existe un juste milieu.
Je ne suis pas développeur professionnel mais j’imagine que c’est comme la mode du NoSQL?
De ce que j’entends de-ça de-là, c’est un problème récurrent de miser à mort sur les technos tip top de la mort qui tue à en oublier les besoins du clients, j’ai bon ou je suis à côté de la plaque?
(J’ai quand même pas mal fait joujou avec docker et j’accroche complètement, après j’ai aucune idées des avantages/inconvénients dans un contexte professionnel)
Je n’ai jamais vraiment compris non-plus toute cette excitation autour de Docker. C’est juste un genre de VM faisait tourner un OS minimal auquel on vient greffer différentes applis, rien de neuf quoi …
Pour nos amis anglophones, je me permets de recommander également l’excellent Hitler uses docker
Surtout pas Docker !
C’est écrit en Go dont le compileur est backdooré par une entitée gouvernementale !
Ca me rappelle les conversations du boulot aux USA… Y a des jours où j’ai envie de bazarder toutes ces Single Page Applications tellement la complexité explose. Ils font des micro architectures à moitié, ces services pètent, du coup je les cache dès que je peux. Au final j’ai l’impression que c’est une arnaque pour notre boss car maintenant il ne peut virer personne… Bref, le future…
@desfrenes: ouai, surtout qu’on a des servers avec un To de RAM maintenant, alors avant d’avoir besoin de partitionner ses données, faut vraiment attendre une charge de connard.
@JMarc: on est à l’ère du projet jetable. Beaucoup de taff utilisant des trucs hypes (nosql, conteneurs, javascripteries, etc) sont des projets qui zombisent au bout de quelques mois.
@sebsauvage : pendant ce temps, des milliers de sites en PHP codé en 2003 continuent de rigoler en faisant vivre l’industrie.
@lucas : comme souvent dans l’industrie on a les 2 extrèmes, et camper sur ses positions donne aussi lieu à de l’arrachage capilaire. Quand je croise des gens qui sont encore sous CVS, je fuis.
@daimebag : c’est exactement ça. Note que j’utilise Mongo, Node et Docker. Ce n’est pas à jeter. Mais c’est tellement survendu. Le problème majeur étant la stabilité, la doc, et la recrutabilité de ces technos qui sont vraiment dans leur enfance et ça se sens à tous les niveaux.
@SuperMan : la révolution de docker, c’est le faible poids du truc, les conteneurs ne bouffe rien. Ca se lance tue et relance en 2 microsecondes, tu peux en poper 300, etc. Et le packaging : les outils en ligne de commande, le format, le système de versioning et la plateform de distribution des images, tout est bien intégré. C’est ce qui a fait le succès de docker. Ca et le hype autour de Go.
@Paul : la sécurité de l’emploi par la complexité de la stack, c’est une astuce vieille comme IBM :)
Etape_1 : Faire gonfler le buzz sur une techno
Etape_2 : Entretenir l’idée que si tu n’est pas dessus, tu rate le train
Etape_3 : Vendre (cher) du dev ou de “l’expertise” dessus
Etape_4 : Passer à une autre techno, GotoEtape_1
@Sam: s’pas faux. Faut voir les projet comme jwilder/nginx-proxy couplé à jrcs/letsencrypt qui te permettent de monter un reverse proxy en deux secondes avec un certificat https qui se renouvelle tout seul comme un grand. C’est cool, sauf que depuis que docker est passé en 1.12 puis compose en V2, tout ce qui touche au réseau à été complètement passé en revu, donc en une update plein de choses sont à revoir.
Docker est jeune, donc il subit beaucoup de changement en peu de temps (mais ça va dans le bon sens), je suppose que ça va se calmer d’ici quelque temps.
Merci, sujet rassurant.
Je commencais a me demander si c’était moi qui était largué ou les e-psters qu’on entend trop.
Ca me fait penser au JS (ancular & cie).
Du mal à me retenir de rire parfois
Pour une version sérieuse de l’article:
http://fr.slideshare.net/PanagiotisMoustafell/copy-of-micro-services-presentation-docker-athens
Le théorème CAP est un vrai problème, sérieux, qui touche toute application en ligne ayant un fort traffic. Si vous avez des millions d’utilisateurs connectés en même temps, les microservices sont une solution.
Le mot clé est : Design for Failure.
De la même manière que le “test driven development” est devenu un standard incontournable, le “design for failure” est déjà devenu un standard pour les applications à fort traffic.
Le concept est très simple: on développe en se posant: “comment va se comporter l’application quand elle va planter?”, car un jour ou l’autre elle va planter: aucun doute.
Si on ne comprend pas le design du “test driven development”, on ne peut pas comprendre la logique des tests unitaires. De la même manière, si on ne comprend pas le “design for failure”, on ne peut pas comprendre la logique des microservices encapsulés dans des conteneurs.
Bref, au lieu de rire comme des dinosaures qui regardent passer les météorites, vous feriez bien de vous poser la question: “est-ce que je sais comment va se comporter mon application quand elle va planter?”, car un jour ou l’autre elle va planter: aucun doute.
N empêche docker c est cool ;)
http://blog.octo.com/design-for-failure/
J’ai lu la version en anglais et ça m’a bien fait marrer, même si c’est tristement vrai.
Du coup, en 2016, si tu fais une petite webapp en PHP, tu uploades ton fichier *.php quelque part et ça marche. Mais en Python, il faut faire quoi ?
(c’est une vraie question : je lis plein d’articles sur le développement de webapps en Python, mais je n’en vois presque jamais sur le déploiement desdites webapps sur son serveur perso, un VPS ou un serveur partagé ?)
C’est comme en PHP, ça dépend de l’hébergeur.
En php, certains hébergeur te demande d’uploader tes fichiers à un certain endroits, d’autres d’avoir un fichier nommé index.php, d’autres d’avoir un fichier .httaccess, d’autres de configurer apache, d’autres de configurer ton serveur à la main, etc.
En Python, tu as aussi cette forme de diversité. Mais généralement, tu upload ton code à un endroit, et tu saisie quelqeu part le chemin vers un fichier de ton projet appelé le fichier WSGI qui est le point de départ de ton appli. Parfois pour certains framework, comme Django, il faut aussi renseigner le chemin vers le fichier de settings. C’est le cas avec des hébergements simples comme pythonanywhere.com
Mais il existe bien entendu des setup plus complexes, comme heroku qui demande d’upload le code à travers un certain nombres de commandes ou carrément des serveurs dédiés où tu mets en place ta propre stack à la main. Ca dépdend donc non seulement de l’hébergement, mais aussi du niveau de control que tu souhaites.
CircleCI (ceux qui ont publié le premier article), en ont également publié un autre : https://circleci.com/blog/it-really-is-the-future/, avec un point de vue plus sérieux sur la question.
Parce que Docker résout quand même de nombreux problèmes. Par exemple, comment avoir simplement un environnement de développement similaire à celui de prod ? Certes, on peut faire ça avec du Vagrant, mais c’est extrèmement lourd.
La semaine dernière, j’ai cassé ma machine de développement. Lorsque j’ai eu la nouvelle, je n’ai eu besoin de que de deux commandes pour être prêt à bosser:
docker-compose up (créé et lance les containers)
la commande pour importer un dump de BDD de dev
Il s’agit d’une application django, servie par gunicorn, avec Redis en cache, et PostgreSQL en base de données, ainsi que du livereload, du lint, etc. Je vous laisse imaginer l’enfer s’il avait fallu installer et configurer chaque service à la main.
Les conteneurs permettent également de partager des configurations complexes, et avouons le, pouvoir installer un serveur mail avec DKIM, ou un serveur LDAP ou un serveur OpenVPN en une ou deux commandes, c’est toujours appréciable.
C’est vraiment agréable de se dire qu’on n’est pas à la ramasse parce qu’on n’adhère pas à cette mode.
J’ai vraiment l’impression qu’avec toutes ces couches, surcouches, et sur-surcouches, on ne maîtrise en fait plus rien, on empile et on espère que ça fonctionne parce qu’on délègue à des grosses boites qui centralisent toutes les compétences.
Il n’y a aucun doute que ça peut répondre à certains besoin, mais c’est comme avec Javascript, on se retrouve à empiler des trucs qui patchent un souci, puis un autre, et encore un autre, mais chaque patch génère un autre problème. Et on a l’impression d’évoluer ?
Là on tombe sur des devs qui vont lire un fichier de config, le réutiliser en le modifiant pour leur web app, sauf que derrière, que ce soit des containers ou pas, l’aspect sécurité est quasi ignoré dans tous les cas que je peux entendre. Donc on se retrouve avec une API qui gère des p*** de commentaires qui doit être déployée sur 20 pseudo machines, mais plus personne ne sait gérer les fondations d’un serveur et en assurer la sécu. Un clicodrome et 2 fichiers de config, et t’es un master chef de l’infra ? mélol
@MetroGeek: Ça sert aussi à ça, laisser les gens plus compétents que nous dans un domaine s’occuper de configurer une image propre et “sécurisée” si possible, évidemment sur le hub public ça dépanne mais j’imagine qu’au niveau sécurité ça ne doit pas être ce qu’il se fait de mieux. Mais dans un registre privé tu peux laisser quelqu’un de plus compétent que toi gérer une image qui va servir pour différents projets pour que tu n’ai plus qu’à faire le lien entre cette image et celles dont tu te serviras.
Encore une fois je le répète, je ne suis pas pro, j’imagine juste les possibilités offerte par la techno.
@MetroGeek
ça s’appelle l’industrialisation de la production.
aucun domaine n’y échappe, surtout pas les domaines techniques.
Ho punaise article super interessant :)
Malgres le coté blague il file pas mal de piste qui donnent un peu le tournis.
Mais bon,
merci pour l’article
je dois toujours me bouger le cul pour l’article sur le crochet anal.
Ouai ben étant donné nos performances en écriture, on va pas te vanner hein.
La version JavaScript vient de sortir! https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f#.gop15s8vk
Tiens, ça me fait penser au début de cette présentation de turbolinks 5
Le truc qui me donne envie de voir ce que donne rails 5.
Docker n’est qu’une partie émergée de l’iceberg.
Petit retour en arrière.
Un processeur moyen gamme de 2015 est à peine 50% plus rapide qu’un processeur moyen gamme 2005.
La loi de Moore (cofondateur d’Intel) prédit que la puissance des CPUs double tous les 18 mois.
Manifestement ce n’est pas le cas.
Sur quoi a travaillé l’industrie des CPUs pendant 10 ans ?
Principalement 3 choses :
– passage du 32 au 64 bits
– l’accélération matérielle de la virtualisation
– moins de consommation électrique
Le développement du noyau linux a suivi le même chemin.
L’accélération matérielle c’est l’ajout des instructions VT-x et AMD-v.
Au niveau du noyau linux, ça crée un Ring -1 ou l’hyperviseur s’exécute.
Les noyaux invités restent en Ring 0.
Une autre façon de voir les choses est qu’avant, un seul noyau se partageait le matériel mais avec l’ajout des instructions matérielles d’accélération de la virtualisation, plusieurs noyaux peuvent être au même niveau et se partager les mêmes ressources matérielles.
Docker franchit une étape de plus dans le partage des ressources.
Au lieu d’avoir plusieurs noyaux côte à côte, pourquoi ne pas avoir un seul noyau mais “partitionné” ?
Matériellement ça ne demande pas de rajouter de nouvelles instructions d’accélération, mais ça demande une réécriture en profondeur du noyau linux.
Concrètement, les UID et GID sont uniques et ce sont les mêmes utilisés par le noyau hôte que dans les containers.
Avec un noyau partitionné, il y aura pour chaque container un tableau des UID et GID à part.
Ainsi on peut être root dans son container sans l’être sur l’hôte, ce qui est actuellement impossible.
Il y a cette notion de “namespace” chère aux développeurs.
Chaque container a son “namespace” qui l’isole totalement du reste, mais techniquement c’est très très compliqué à mettre en place.
Le futur développement du noyau linux c’est principalement la mise en place de ces “namespace” pour “partitionner” le noyau.
Le développement du noyau linux et de docker se feront en parallèle.
docker n’est que la 1ère implémentation du partitionnement du noyau et c’est un mouvement de fond qui prendra des années.
La tendance est à de plus en plus d’abstraction, de virtualisation et de séparation pour accroître la productivité, l’industrialisation et la spécialisation.
Bon je comprend la raillerie sur les défauts de docker (il y en a beaucoup), mais bon le côté on attaque sur la “mode” ne tient pas … ça fait 4 ans qu’elle dure la mode ! Dans l’informatique c’est presque les dinosaures ;-). Le système ne cesse de s’améliorer sur tous les points (en particulier la sécurité, mais si tu oublie de fermer la porte faut pas te plaindre que l’on vienne piller tes affaires hein !). Alors on a tendance a dire “il faut tout conteneuriser!” => la je dis il faut arrêter d’être stupide ! Docker n’est pas fait pour tout le monde loin de la, mais dans son domaine (le déploiement rapide, reproductible et scalable) il fait très bien le job. Donc stop le FUD sur docker et restons pragmatiques. (BTW on a eu le même discours sur la virtualisation à une époque, et pourtant …. ).
Docker marche aussi sur windows maintenant.
A la demande d’un client, j’ai installé docker sur une image windows server 2016, elle même tournant sur une VMware.
Une machine virtuelle tournant dans une machine virtuelle, on arrête pas le progrès.
Tout ça pour “containeuriser” une vieille appli jboss.