Docker vient de franchir une nouvelle étape avec coreOS.
Docker dés sa sortie a suscité pas mal de polémique et de buzz. Oui, il est possible de faire un truc équivalent en bash, synchrone. Docker est juste une brique dans une infrastructure (c'est un produit liberé par DotCloud), il n'est pas autonome. Au-delà de son implémentation, en Go, c'est son principe qui est disruptif. Docker fait un petit pas dans l'ère post virtualisation. La virtualisation (et les concessions de la paravirtualisation) partent du principe les applications ne sont pas capable de faire d'efforts, et que tout doit rester comme avant, mais comme maintenant. Le Cloud, autre joli buzzword, a prouvé brutalement qu'avec quelques concessions, il est possible de changer d'échelle et de proposer des solutions élastiques, avec la possibilité de faire fluctuer les ressources facturées, en fonction des besoins. Quand l'application ne fait rien, elle ne consomme rien, quand elle fonctionne bien, le matériel grossit au fur et à mesure de la demande. Voilà, c'est avec cette théorie que Netflix peut bouffer 30% de la bande passante US, sans posséder de machines. La virtualisation a un cout (je pense plus à de la surconsommation, pas forcément en licences) et surtout du mal à se redimensionner, il est facile d'ajouter une VM, il est plus pénible de la couper en deux, ou de la doubler. Récemment, Linux, las des solutions plus ou moins intrusives, plus ou moins efficaces, a intégré dans son noyau les briques nécessaires pour construire par dessus des produits pour isoler et répartir des ressources. LXC, le produit utilisé par Docker est surtout un emballage de cgroups. Docker y a rajouté unionFS pour la gestion du disque dur, et surtout avoir du copy on write, qui permet d'instancier un container sans avoir à le recopier avant de pouvoir l'utiliser. Docker est clairement dans la lignée Cloud, mais avec un ticket d'entrée bien plus abordable. Il en reprend les concepts : une application est un ensemble de services, et le stockage doit aussi être un service. Donc, pour Docker, une application est un ensemble coordonné de services rangés dans des containers. Pour avoir plus de ressources, on instancie plus de container, pour diminuer la voilure, on en éteint quelques un proprement. Les containers peuvent être sur une ou plusieurs machines physiques. Il est même possible de mettre une nouvelle instance sur une machine B, puis d'éteindre une instance sur la machine A, pour faire de la place, et redimensionner une instance qui a du mal avec le découpage. Bref, de la souplesse, un meilleur rendement du matériel, mais pour ça, il faut de la coordination et faire la chasse au gras.
CoreOS est le quai pour accueillir les containers, avec la tour de contrôle pour coordonner l'ensemble. CoreOS est un tout petit Linux : un noyau, pour gérer le matériel, et Systemd pour démarrer. Il ne peut pas faire grand-chose, mais il le fait bien. Il sert à héberger des containers, en fait, qui eux contiennent le Linux qui vous aimez bien (votre distribution favorite, quoi). CoreOS n'a pas de gestion de paquet, la partition root est en lecture seule. Il se met à jour avec un système de double racine. On a la branche courante, qui est utilisée. Une mise à jour consiste à mettre à jour l'autre branche, de vérifier que tout ce passe bien, puis de faire la bascule, la branche récente devient courante, l'ex courante devient un backup pour effectuer un rollback en cas de drame. Solaris (et ses variantes libres) proposent des choses similaires. Pour les containers, l'approche est similaire, plutôt que de faire un upgrade, on se contente de déployer des versions plus récentes, et d'éteindre les vieux. Pour la petite histoire, les images de CoreOS sont construites à partir de Gentoo, et les applications Go sont conçus pour être autonome, juste un binaire à pousser sur le serveur. CoreOS n'est pas juste une distribution pour ascète manichéen, il assure aussi la coordination pour l'application. Son arme secrète est etcd un système de coordination décentralisée. Le terme est pompeux, mais c'est juste un point central pour l'application pour changer des paramètres et d'avoir tous les gens concernés au courant des changements. Un équivalent de Zookeeper ou de Doozer, en fait. Etcd a une approche minimaliste, avec une interface en REST. Il est implémenté en Go, et utilisé la théorie de Raft, une réponse plus simple que Paxos. Ce système de consensus est en fait la pierre angulaire de toutes architectures distribuées. On peut voir ça comme une base clef valeurs distribuée avec un pubsub pour prévenir les clients. Petit exemple, suite à un crash du serveur SQL, on souhaite promouvoir l'esclave en maitre, il suffit de changer la clef sql_master dans etcd et les clients vont se contenter de prévenir les applications (changer un fichier php, faire un kill -HUP...). On peut imaginer des exemples plus positifs, comme l'ajout de nouveaux serveurs pour soutenir une montée en charge. Voilà, il manque juste la brique loadbalancing devant pour avoir un produit complet, qui reste spécifique à chaque hébergeur Cloud, des trucs à base de Nginx+lua, haproxy ou plus exotique.
J'ai hâte de voir les solutions qui emballeront coreOS et Docker, et surtout les autres briques officielles qui permettront des construire des produits modulaires et distribuées.
