Si vous aimez jouer au buzzword bingo, vous avez bien remarqué que Docker est un mot compte triple. Vous allez l’adorer, le détester, ou adorer le détester. Comment un machin si récent peu déclencher autant d’engouement ? Pourquoi les gros du cloud (abrégé en GDC) se prosternent devant lui, ou monte une équipe pour lui casser les genoux et lui rappeler sa place?
TL;DR
Une architecture web est composée d’un ensemble de services, ensemble que l’on doit pouvoir utiliser à différents endroits, du poste de dev, à l’intégration continue, et finalement les serveurs de prod, en un ou plusieurs exemplaires.
S’abstraire du matériel
Avant de râler que s’était mieux avant, mieux vaut le définir, ce avant, histoire de parler de la même chose.
Les machines virtuelles
Les machines virtuelles n’ont jamais été qu’un mensonge. Qemu propose vraiment de la virtualisation, lui. Il isole complètement l’OS invité de la machine, et ce, à la vitesse d’une tortue qui a trop mangé de poutine.
Tous les outils utilisables de virtualisation (KVM, Xen, Virtualbox, hypervisor… ) sont en fait de la paravirtualisation, le kernel invité est adapté à ce que fournit son hôte, et s’appuie sur des fonctions spécifiques du processeur. Il est d’ailleurs impossible de virtualiser de la virtualisation en mélangeant des technos.
Le vrai mensonge n’est pas là, mais dans le “Rien n’a changé, tout est comme avant, un serveur virtuel s’utilise comme un serveur physique, c’est kifkif”.
Même si l’accès à la RAM sera dédié, le processeur sera partagé ou alors gâché avec de l’épinglage (du pinning, quoi). Dans tous les cas, les cartes réseau et disques durs seront partagées. La tragique conséquence est le classique phénomène du voisin bruyant.
De faux drivers permettent d’accéder de manière isolée à des fonctions du matériel, comme l’horloge ou le générateur d’aléatoire. Mais les vrais paranoïaques n’ont pas de voisins (allez lire la doc de SecureDrop).
Autre partage pénible, les IPs, que l’on doit soit router (niveau 4 ou 7) caché derrière un LAN, soit gaspiller de l’IPv4, bientôt plus rare qu’un panda en liberté.
Mais au fait, pourquoi virtualiser ?
La réponse est simple, on virtualise pour isoler.
Isolation qui permet de
- limiter la portée des bêtises (erreurs ou agressions)
- mélanger des versions d’OS et d’avoir des cycles de mises à jour indépendants, voir même utiliser différents OS, pour les plus créatifs
- installer des logiciels ou des bibliothèques dans des versions non compatibles
- ne pas mélanger les pommes et les oranges, aka co-tenant
- garantir une répartition plutôt équitable des ressources
Tout ça permet donc d’entasser plein de choses sur un même serveur, on parle alors de densification.
Ces entités isolées, abstraites de la couche matérielle peuvent être manipulées :
- redimensionnement (RAM, CPU, Disques)
- déplacement d’une machine à l’autre, pour rééquilibrer, ou mettre à jour le matériel
- snapshot et restauration
- Jouer à jour/nuit avec des cycles de vie courts, pour faire des tests, des benchmarks, des essais
- Ajouter de la puissance pour tenir la charge d’un évènement, comme un passage à la télévision
- Lancer des lots violents de calculs, de manière ponctuelle
Les limites de la virtualisation des machines
Les machines des développeurs
Il est complexe d’amener les machines virtuelles sur les postes des développeurs, et super pénible de gérer une grappe de serveur. Ça reste lent, ça bouffe des tonnes de RAM, le partage de fichier pour une édition local est mou des genoux, le watch de fichier ne marchera pas forcément. C’est ballot, tous les OS proposent maintenant de la virtualisation de série, bhyve dépote sur Mac, mais, étonnement je n’ai jamais vu de dév Linux utiliser KVM.
Rebelote pour faire des tests fonctionnels ou même unitaires utilisant un service (comme une base de données), avec en prime des surprises comme ah tiens, Xen ne veut pas de Virtualbox.
Vagrant est un excellent outil pour systématiser la mise en place de machines virtuelles. De toute façon, il est ridicule de travailler directement avec Virtualbox (ou l’un de ses concurrents), et même criminel si l’on travaille à plusieurs sur un même projet. Entendons-nous bien, je suis un grand fan de Vagrant, mais il est au top, il n’y aura rien après, Otto, son successeur a été sabordé.
Vouloir simplifier la stack du développeur en ne travaillant qu’avec des services directement installés en local a rapidement montré ses limites. Le temps de setup est énorme, la bascule d’un projet à l’autre est souvent la garantie d’écraser des données, et la flemme du commun va empêcher d’utiliser des outils qui sauvent le monde comme Redis ou Elasticsearch. De toute façon, qui utilise le même OS que le serveur cible sur sa machine locale? Une Debian stable en poste client?
La taille des tranches de virtualisation
La virtualisation fonctionne bien, et est très largement utilisée, mais elle a un ticket d’entrée, avec moins de 2 coeurs et 2 Go de RAM, ce n’est plus une VM, mais un jouet (AWS appelle ça T2, pour flatter). Dédier une machine pour des services peu gourmands, reviens vite hors de prix, sans compter la place disque occupé par l’OS (et l’application) sur la machine physique si l’on n’a pas de système de COW, qui reste complexe à mettre en place.
Du coup, on se rabat sur le classique entassage sur une même machine, mais avec quelle garantie d’isolation (sécurité et ressource)?
Même si la haute dispo est heureusement réservée à des applications très spécifiques (brrrr, des gros mots comme HAlinux, drdb, heartbeat, pacemaker…), il est maintenant classique d’avoir des applications distribuées. Une base de données répliquée en master/slave est courante, un Elasticsearch est malheureux tout seul. Pour pouvoir espérer tenir un pic de charge, il faut tout simplement que l’application métier puisse être déployée sur plusieurs serveurs.
La notion de services
Les architectures actuelles sont de plus en plus riches. L’indétrônable LAMP, qui a permis à Wordpress de conquérir le monde est maintenant détrôné.
On garde le classique service de persistance (la base de données, quoi), le service applicatif, puis un service pour stocker des fichiers (FS local, ~~GlusterFS~~, un S3 like), mais aussi un service de mémoire partagé (Memcache, Redis…) pour gérer le cache, les sessions, les évènements. Pour travailler avec des timeout décents, on va utiliser un service de taches asynchrones (~~cron avec wget~~, Sidekiq/Celery/Beanstalk…). De la recherche full text avec ~~Solr~~ Elasticsearch. Un machin pour gérer les websockets par ce que son langage chéri est bien incapable de gérer de l’asynchrone, Un petit Logstash pour manger les logs, un Sentry pour les erreurs, un Statsd pour les compteurs de performances, un Cuttlefish pour les mails transactionnels, un Pootle pour les traductions… Et là, je ne parle que de services Open Source que l’on peut déployer, et pas des services en ligne, les fameux SAAS.
La décrépitude du système
Server rots
— Ori
L’entropie mange le monde, c’est comme ça, et c’est prouvé par Pr Ian Malcom dans Jurassic Park : ce n’est qu’une question de temps, mais ça va partir en sucette.
Au fil du temps, son petit serveur d’amour, nommé en suivant un champ lexical spécifique, installé avec amour et inspiration, va commencer à sortir du champ de rationalité, il va continuer de fonctionner, bien sûr, mais il y aura des changements subtils, des innovations, des corrections sauvages, mais, promis, temporaires. Et au bout de suffisamment de temps, il va devenir un snow flake, unique et inreproductible comme un flocon de neige. Plus on entasse de choses, plus on bataille pour prolonger une version d’OS dépassé, plus le décollage sera rapide.
La seule solution est d’avoir un système immuable, construit de manière reproductible avec une recette, en précisant les quelques dossiers capables d’écrire, pour assurer la persistance.
Et Docker dans tout ça ?
L’isolation par la virtualisation est couteuse, et il n’y a aucun intérêt à avoir un système complet pour accueillir un service.
Il faut revenir à quelque chose de simple, de très UNIX en fait : demander au kernel d’isoler des process.
Chroot existe depuis toujours, et cgroups a été initialement conçu par Google il y a maintenant 10 ans.
Rajoutez à ça un système de fichiers en oignon, comme AUFS, pour mutualiser la place occupé sur le disque dur et avoir des mises à jour tranche par tranche.
Pour répondre à la ribambelle de questions que je viens d’énumérer, la conteneurisation apporte une réponse différente (et potentiellement complémentaire) à la virtualisation.
LXC
Petit incident de parcours, ces éléments ont été utilisés pour construire LXC (wouaaais) le chantre du Fat Container (Oooooohhhh). Plutôt que de travailler avec des process, comme tout le monde, LXC a trouvé très malin de singer un système complet, avec un init et une grappe de process, vous savez, “comme avant”. Pour parfaire le tout, LXC est livré avec une stack réseau en DIY (démerde-toi, en VF). Ubuntu a bien essayé de sauver les meubles avec son LXD, mais non. La simulation d’OS que propose LXC est très différente d’un OS même virtualisé. Faire des tests fonctionnels dans LXC en espérant que ça ressemblera à la cible, non LXC, est la garantie d’un drame. De toute façon, LXC, avant LXD est trop pénible à mettre en place pour du dev/test. Et LXD, ça veut dire Ubuntu, et du coup, grosse flemme de lui laisser une seconde chance. Surtout que LXD ne remet pas en cause le fat container, et la concurrence, elle, fonctionne.
Docker, qui avant d’être un projet libre, a utilisé TOUTES les technos de contenurisaton disponible sous Linux, une à une. Au moment de sa libération, Docker était une surcouche à LXC. En utilisant dans un vrai cadre ces outils (avec des tonnes de clients et des brouettes de devs dédiés), Docker a vraiment utilisé LXC, qui n’était qu’un gadget un peu reloud. Ca a permis de trouver plein d’horreurs dans le code du kernel, et les corrections qui ont suivis ont abouti au mythique 3.11, la première version offrant de la conteneurisation décente. LXC a été jeté au profit de bibliothèques maisons, en Go, qui utilise des fonctions avancées du kernel.
Docker
Donc, première révélation aux haters : Docker n’existe pas. Docker se contente d’utiliser des fonctions du kernel, sans le patcher, et d’autres outils bas niveau pour proposer une solution cohérente de conteneur. D’autres outils proposent leurs propres solutions de conteneurisation en utilisant les mêmes briques de bases.
De toute façon, Docker n’existe pas, ce n’est qu’une API basée sur runc, l’implémentation officielle de l’Open Container Initiative (crée grâce à la saine polémique lancée par Rkt).
Donc, pour ceux qui ne suivent pas, Docker, c’est un process lancé dans un chroot avec le kernel isole ou partage un maximum de choses.
La conquête
Docker a choisi une stratégie bottom top. Sa première cible a été les développeurs, les postes clients. Je ne sais pas si c’était leur stratégie, mais clairement, leurs premières victimes ont été des développeurs.
Docker propose une api CLI élégante, une API REST logique, et surtout une très bonne documentation, des évangélistes de prestiges, comme Petazzoni ou Jess Frazelle (qui bosse maintenant chez Mesos).
Immuable
Une image n’a pas vocation à conserver ses données modifiées. Pour ça, il y a les volumes, des dossiers en RW qui existe hors du container.
Les images sont définies par couches, et si l’on suit la tendance actuelle, la première couche sera une debian stable, commune à toutes les images.
Il est possible d’avoir plusieurs instances d’une même image dans sa grappe de machine.
Les réglages spécifiques à une instance doivent passer par des variables d’environnements, et non les classiques fichiers de conf.
Tous ces points (une image immuable, configurée depuis l’extérieur, avec quelques dossiers explicites qui assureront un stockage non volatile), permettent de conserver une même image pour les tests d’intégration, préprod, et enfin la production, limitant au maximum le drame des tests qui passent dans un environnement, mais pas dans un autre.
La recette Dockerfile
Docker permet un système simple de recette, Dockerfile, pour construire ses propres images, et le Hub pour aller piocher dans un catalogue. Bon, on y trouve tout et n’importe quoi dans ce hub et il est sage de se contenter des repos officiels. Ces images publiques sont fort pratiques pour du dev, plus polémique pour de la prod.
On ne met pas à jour une image, on la reconstruit. Voilà, contre l’entropie, la reconstruction.
L’approche en pelures d’oignons du filesystem permet de profiter d’un cache tacite. Pratique, mais pas suffisant, il y a actuellement du travail qui est fait pour améliorer le cache, sans affaiblir la sécurité.
Dockerfile est la solution par défaut pour construire une image, mais il est possible de se débrouiller autrement.
Le multi OS
Pour achever les dernières poches de résistance, Docker, qui fonctionnait déjà très bien sur Mac dans un Virtualbox (merci l’archi client/serveur) a développé la première appli connue utilisant la toute fraiche API de virtualisation de MacOS (basé sur un produit FreeBSD). Même effort coté Windows, mais c’est un monde que je ne fréquente pas.
La composition de Docker-Compose
Docker a clairement dit que le fat container était une mauvaise idée (voir le troll de Phusion), et vante l’approche “service par conteneur”. Pour une application complète, il faut donc plusieurs conteneurs, configurés, décrits simplement dans une recette. C’est ce que propose Docker-Compose.
Docker à distance
Docker est basé sur une architecture client/serveur, qui utilise une socket UNIX, ou une authentification par certificats. Il est donc possible de laisser son docker client causait avec un docker daemon, distant.
C’est ce que propose Docker-machine, qui permet d’utiliser de la virtualisation ou du Cloud.
Tous les gros du Cloud proposent une offre spécifique à Docker, qui, en proposant une abstraction pour distribuer des services, met à mal le côté captif des différents Cloud.
Docker en cluster
Une fois son application bien rangée en petit conteneur, il est tentant de la distribué sur plusieurs serveurs, voir même d’avoir quelque chose de mouvant, que ce soit pour accompagner une montée en charge, ou pour survivre à une panne d’un des serveurs.
C’est ici que ce positionne Docker-Swarm, mais aussi Kubernetes, Nomad, Mesos.
Docker-swarm propose d’utiliser la même API pour gérer un ou plusieurs serveurs, et de laisser un algo se débrouiller pour répartir les services et élire des masters des services, si besoin.
Avec sa dernière release, Docker a mis le bazar en allant s’attaquer aux offres d’hébergements distribués. Par ce que bon, humilier LXC ou Vagrant, tout le monde s’en fout un peu, par contre, s’attaquer à de vrais produits qui génèrent de vrais sous, comme Kubernetes, c’est une autre histoire. Surtout que cette version 1.11 semble avoir été sorti un peu vite, sans trop se soucier de réutiliser des choses existantes.
Ce qui marche avec Docker
Docker, sur un poste de dev, c’est un nouveau dans une équipe qui peut commencer à bosser dans 1h, avec Vagrant, il fallait compter 1 jour.
Pour l’intégration continue, Docker est pour l’instant sans concurrence, surtout que l’on n’a pas à simuler ce que va utiliser le dev, mais on va prendre la même configuration.
Docker est un fan de 12 Factor, il permet de déclarer simplement comment lancer un service, et se chargera des logs et de son cycle de vie.
Pour compiler, et encore plus avec des outils trop récents (Golang, je pense à toi), ou des trucs qui veulent installer des tonnes de paquets en *-dev, Docker est magique, on monte le dossier courant comme volume de travail, et paf, ce qui se fait là bas, atterrit ici.
Pour les instances à la demande, comme ce que permettent les notebook de Jupyter, il est tentant d’utiliser des images contenant tout le bazar (les scientifiques n’ont pas la même notion de packaging que les développeurs).
Pour installer une application composée de plusieurs services (tout ce qui est à peine plus complexe que phpmyadmin, quoi), la mettre à jour, puis la bazarder, Docker a peu de concurrents.
Ce qui n’est pas sec
Docker a décidé de se friter avec Systemd, c’est une querelle de personnes, mais aussi une concurrence. Mais bon, j’en cause dans un autre billet: Quis custodiet ipsos custodes?.
Par grosse flemme, Docker a décidé de ne pas gérer de compatibilité ascendante entre son client et son serveur. Quand on est sur la machine où se trouve le daemon, ce n’est pas grave, c’est le même paquet, à distance, ou pour les APIs tiers, c’est une autre histoire.
Pour la gestion de plusieurs machines, c’est actuellement la bataille, avec Google qui a envie de mettre en valeur son propre Cloud qui permet d’avoir le Kubernetes le plus beau du monde. Nomad et Mesos visent les très gros trucs, et Docker ne veut rien lâcher de sa conquête de l’Univers, et pour cela, il est prêt à aller trop vite.
Les APIs peuvent changer brutalement et potentiellement tout défoncer les produits tiers.
Ce qui est de la mauvaise foi
Docker c’est pourri par ce qu’on ne peut pas mettre à jour openssl
Une image est immuable, et ne dois pas être mise à jour sur place. Il faut donc une nouvelle image de l’application. Avec le système de couches, il suffit de repartir d’une image système à jour, et de redéployer.
Le souci est le même pour tout ce qui est compilation (hors bibliothèque partagé), et donc Java, Scala, Golang… Même drame pour les frameworks.
La réponse à ça est le baking.
De manière générale, il est assez criminel de demander à un dev de pousser une image depuis son poste de travail. Il est nettement plus sage d’utiliser de l’intégration continue, et donc d’avoir un combo build+test automatisé, pour redéclencher la création d’une nouvelle image.
De toute façon, un apt-get upgrade ne marche qu’un temps (sur deux versions d’OS, grosso modo), et même les langages (PHP, je te vois!) ne sont pas maintenus jusqu’à la fin des temps.
Avec les architectures distribuées, vous allez vous retrouver avec un service frontal qui va assurer le proxy/routage des services. Le classique Nginx/HAproxy/Traefik/Caddy/… qui va bien, et qui va affronter Internet, faisant rempart de son corps devant l’application. Ce proxy HTTP pourra être mis à jour, indépendamment du cycle de vie de l’application.
La mise à jour d’openSSL sera nécessaire pour dans la grande majorité des cas à une utilisation client, pas serveur. Mais en parlant de ça, savez-vous si l’application va accepter des réglages débiles (comme le fit Ruby), ne pas vérifier la concordance entre le nom du serveur, et le nom du certificat (comme le fit Python), si le pinning et la révocation sont gérés?
Je ne veux pas sur mon infra une image qui sort du cul d’Internet
Clairement, c’est une bête idée de lancer un binaire sans un minimum de crédibilité. Coup de bol, une image polie doit être fournie avec son Dockerfile, et donc, de fait, ses sources permettant de la construire.
Ce problème est de plus en plus générique. Qui a envie de recompiler Elasticsearch après avoir relu le code, ou même MongoDB?
De toute façon, c’est celui qui construit qui répare. Un dev peut très bien bosser avec une image “postgres:9.4” sur son poste de travail, mais rien ne vous oblige à la déployer. Son service a besoin d’un service Postgres dans la version 9.4, bah, coïncidence, c’est la version packagé Debian, et vous avez tuné avec amour sa conf et sa réplication. Si vous êtes de bonne humeur, vous pouvez même construire votre image Pg, basée sur “debian:stable”, avec les réglages que verront l’utilisateur. Image qui servira en dev, et pour le CI.
Docker, ce n’est pas secure
Oui, clairement, la surface d’attaque entre la virtualisation et la conteneurisation n’est pas comparable, ni leur maturité.
Par contre, il y a un souci pour la virtualisation qui va protéger l’hôte, et les autres VM, laissant libre ce qui se passe au sein de la VM. Visualisez un alien qui se faufile dans le véhicule blindé, ok, il aura du mal à sortir, mais pour les passagers, ce sera une autre affaire.
La taille minimale des VMs oblige à y déployer plusieurs services, la contamination de l’un d’entre eux pourra mettre en danger les autres.
Il y a deux réponses à ça.
En plus de l’isolation permise par Cgroups et les Namespaces, Docker permet d’utiliser simplement l’arsenal classique de Linux : Apparmor/SELinux, les capabilities et seccomp.
Apparmor est déployé par défaut sur Ubuntu (et est plaisant à utiliser), mais Seccomp est peu utilisé en dehors de Chromium. Docker est un évangéliste de ces technos soit ignorés, soit méprisés.
Seconde approche, mise en évidence par Rancher et CoreOS, utiliser la tactique de ceinture et bretelles, en mettant des containers dans des machines virtuelles (grâce à la délégation de droit que permet KVM). L’idée n’est pas d’avoir du un pour un, mais d’isoler les services critiques ou au moins de les séparer.
De toute façon, vous n’êtes pas tenu de faire du co-tenant sur vos serveurs.
Docker, ça tourne en root
Oui, c’est un poil reloud. Par contre, le root dans les images, c’est juste une histoire de flemme, et d’ailleurs Kubernetes refuse maintenant les images sans utilisateur dédié.
Pour l’hôte, c’est une limitation de Linux, qui bosse sur ce sujet, et une partie des outils sont déjà possibles sans privilège. Docker piaffe d’impatience d’avoir son outil qui puisse fonctionner sans root.
Juste pour le plaisir de dire du mal : ping a besoin du compte root, lui aussi.
Docker c’est pourri, je ne peux pas me connecter en SSH pour déboguer mon service
Ni pour y faire un apt-get upgrade, on a compris.
Un conteneur utilise les namespaces pour isoler son process hôte, mais il est tout à fait possible, lors de la création d’un conteneur d’utiliser les mêmes namespaces qu’un conteneur existant. On parle de side kick container (Robin qui vient déboguer Batman, quoi). Un conteneur peut ainsi stracer un autre.
Je vous invite à RTFM nsenter.
Je parle bien de conteneur en général, rien de tout ça est spécifique à Docker.
Docker, c’est pourri, ça veut scaler mes services en les clonants, faisant fi des threads
Non, ça, c’est une connerie des 12 factor. Heroku a la flemme de gérer les possibilités de scaling des différents serveurs webs, du coup, hop, la vérité c’est eux, ne vous occupez de rien, on n’a qu’à prendre le plus petit commun. Donc, dans la vraie vie, Docker sait passer les messages UNIX au process, et il se fiche de savoir si votre application fait du fork en COW (comme peut le faire Gunicorn), ou des threads. Rien de vous empeche d’avoir une grappe de process/thread web dans votre container, et quand vous aurez besoin de scaler, d’instancier une (ou plusieurs) grappe, un peu plus loin.
12 factor, qui ont le bon gout d’être pratique et lisible, reste quand même de la propagande post mortem d’Heroku.
Docker, c’est pourri, je ne peux pas sécuriser l’accés à mes services en utilisant des sockets UNIX
Bah, déjà, quand je mets mon Mysql d’un côté, et mon Wordpress de l’autre, je ne peux plus utiliser de sockets UNIX, pour gérer les droits. Pour ceux qui ne sont pas attentifs, mais les solutions de types Heroku sont encore pire, il n’y a pas de notion de VLAN privé, et du coup, tous les services non moisis proposent de l’authentification, même Memcached sait le faire, c’est dire.
Dans les gros boulets ouverts aux quatre vents, personnellement, je vois Statsd (avec son protocole UDP) et Elasticsearch, pour son gossip de cluster. Mais Docker ne vous a pas oublié, il propose un système de réseau extensible, pour créer des sous réseaux permettant de regrouper vos différents services. Pour le reste du monde, ça s’appelle Software Defined Network, et il existe plein d’implémentation libre. Le réseau virtuel est d’ailleurs actuellement ce qui fait la qualité d’un service Cloud (OVH, je te regarde).
Docker, c’est pourri, ça utilise Alpine qui utilise musl que c’est compatible avec rien
Une application à besoin d’un contexte : une arborescence Linux, et un kernel pour accéder au matériel.
Une Debian nue doit faire dans les 125Mo, pourquoi ne pas utiliser quelque chose de plus minimaliste, surtout avec les technos qui ont des traditions d’autarcisme (JVM, Erlang, Golang…)? Alpine Linux est une distribution qui a une approche “embarqué”, basée sur busybox et musl comme libC. 5Mo tout mouillé.
C’est rigolo à utiliser, jusqu’à ce qu’on essaye de compiler un truc non packagé, et que l’on tombe sur du code spécifique glibc. Une image Debian embarque clairement beaucoup trop de bazars pour lancer un seul service bien bordé. Mais bon, ça à le bon gout de marcher, on a la garantie qualité Debian™, et avec le système de couches, l’image de base sera commune à la plupart des images.
Pour l’instant, les images de base sont basées sur Debian, et c’est un choix excellent, ça limite au maximum les surprises de la couche basse, et permet de se concentrer sur le côté trop à jour de l’application.
Docker aime explorer des voies, mais bon, si Alpine vous chagrine, vous pouvez toujours tester Slackware, comme avant.
Dans tous les cas, rien ne vous oblige à utiliser une image que ne vous sentez pas, les Dockerfile sont tellement simples à hacker, ne vous privez pas.
Docker, c’est pourri pour de la prod
Il y a beaucoup de concurrents pour le concours de “pourri pour la prod”, hein. Docker avance couche par couche. L’étape prod distribué, par ce que prod sur un serveur, ce n’est pas non plus super complexe, est son chantier actuel. Docker Swarm est arrivé avec La release 1.12, et a fait hurler pas mal de personnes. Mais bon, on change d’échelle niveau complexité, et Raft, c’est quand même un gros morceaux. Allez demander aux devs de Etcd ou Consul.
Swarm a quand même l’audace de s’attaquer à Kubernetes, la version libre de l’outil interne de Saint Google, quand même.
Kubernetes builds upon 15 years of experience of running production workloads at Google, combined with best-of-breed ideas and practices from the community.
Voici l’argumentaire “take that, Batman” de Google pour ses conccurents.
Enfin bon, avoir un avis définitif sur un tel outil, sorti fin juillet, c’est un poil hatif. Il est possible d’utiliser Docker sans Swarm, promis!
Docker, c’est pourri
Imprimez des teeshirts et des stickers, c’est efficace avec les slogans.
Docker est opiniated, avance vite, et il fait beaucoup de bruit.
On peut lui reprocher plein de choses (avec des arguments), mais s’il n’y a qu’un seul argument à retenir pour le défendre : Docker est un produit opensource qui explore, code, explique et corrige. Et ça, que vous soyez utilisateur ou non de leur produit, c’est déjà super important.
La conteneurisation fait déjà partie de l’informatique moderne, il va falloir s’y faire.