Un conteneur dans un autre


Docker.

Ce nom revient de plus en plus, difficile de ne pas le remarquer. Et pour cause, l’idée est très bonne et s’immisce parfaitement dans la logique actuelle de créer des applications utilisant un tas de microservices.

Je n’ai pas encore “pratiqué” réellement, j’attend d’avoir le besoin d’en utiliser pour parfaire mes connaissances et me rendre compte. Je vais donc simplement parler “haut-level”, et dire ce que j’en pense et quelles sont les cas d’utilisations qui existent / que je vois.


Tout le monde n’a pas forcément déjà utilisé des machines virtuelles (ou alors, sans le savoir). Personnellement, j’en ai très peu l’usage. Au travail, je ne m’en occupe pas, nous avons quelques VMs simplement pour séparer les concepts : un serveur de base de données, un autre qui joue serveur web, un autre qui fait serveurs de jeux (!), mais qu’ils soient virtualisés ou non, aucun impact pour nous. Une IP et ça suffit.


A quoi Docker pourrait-il bien servir et comment peut-il se révéler vraiment utile comparé aux autres solutions existantes ? Par exemple, comparé à Xen, KVM, VMWare, VirtualBox ? De l’usage que j’en ai eu (VMWare, VirtualBox), c’était déjà assez pratique, facile à créer, à installer son système, et hop, on se retrouve avec une image que l’on peut dupliquer. Le seul truc c’est que je trouvais ça lent, mais c’était sans doute car je tourne sous Windows. :-)

De ce que j’en ai compris, l’énorme avantage de Docker c’est qu’il repose sur le principe de “conteneur” au sein d’un même système d’exploitation, rien n’est émulé, pas d’interfaces virtuels supplémentaires à traverser de l’OS hôte à l’OS cible. On tourne au sein du système hôte comme n’importe quel programme, sauf qu’on est “dans son monde”. On ouvre des ports accessible de l’extérieur (serveur http, base de données, du redis, etc.), on voit ainsi les conteneur comme de simple modules offrant un service. On pourrait tout faire tourner sur la même machine dans ce cas, mais l’avantage de séparer par conteneur, c’est justement qu’on sépare et qu’on ne “salit” pas sa machine hôte. On sait exactement le “contrat/l’interface” exposé par le conteneur.

On peut alors mettre à jour uniquement les conteneurs qui le nécessite (sans avoir peur des dépendances), les remplacer par un autre conteneur offrant le même service sans affecter la configuration hôte, pouvoir scaler ultra-facilement en dupliquant les conteneurs que l’on veut (en ayant une configuration de load-balancing approprié sur l’hôte).

On peut même installer un OS dans un conteneur, lui même contenant d’autre conteneur. Récursivité, nous voilà. Ca pourrait arriver dans le cas où l’on utilise un conteneur qui lui même se base sur d’autres conteneurs pour fonctionner (qui eux même, pourrait faire de même etc.). La boucle est bouclée, on peut faire ce que l’on veut, tout en gardant des modules.

Un peu comme npm avec nodejs. Notre module a besoin du module babel par exemple pour compiler de l’ES6. babel dépend lui-même d’autres modules, qui eux-mêmes… etc. Même histoire en fait. C’est “juste” que Docker le fait avec des “plus gros” modules qui sont carrément des applications complètes.


Ah, et Docker, ça se fait naturellement en ligne en commande. Même pas besoin de télécharger soi-même les conteneur qu’on souhaite utiliser, comme avec npm, il va les chercher tout seul mais en plus, les garde bien au chaud au cas où on les réutiliserait sur la machine.

On peut installer plusieurs conteneurs et les relier ensemble. Par exemple, chacun expose un service genre un Wordpress et l’autre une BDD, on indique au conteneur Wordpress où est la BDD. Il y a par exemple “fig” qui s’occupe de faire ça avec des scripts très clairs.


La logique des conteneurs excelle au niveau du test. Elle permet par exemple de pouvoir lancer des tests qui nécessite une base de données propre, sans dépendre des autres tests (qui pourrait modifier la base de données “maître”). Si chaque conteneur a sa BDD, on peut tout lancer en même temps, no problem. On peut aussi faire des tests niveau réseau (vu que chacun est dans sa bulle) pour tester des configurations données. Tests finis ? On supprime les conteneurs utilisés, hop, ni vu ni connu.


Un problème ou une mise à jour de conteneur ? On peut facilement le remplacer à la volée en installant un autre conteneur exposant le(s) même(s) service(s), le faire prendre en compte par le load-balancer en amont, et supprimer tranquillement l’ancien conteneur inutile.


Enfin, autre avantage que je vois, le scaling automatisé d’une application. Si notre application processe des data par exemple. Soudain un pic de data afflue, on le détecte et on lance 10 nouveaux conteneurs (sur le même serveur physique ou un autre) pour absorber la charge, puis on peut les supprimer quand la charge redescent. Du cloud computing en horizontal scaling quoi !


Après, faut pas non plus remplacer toutes ses VMs par du Docker. Si ça marche bien avec les VMs (pas de problèmes de perfs), autant laisser les VMs. Le jour où on veut évoluer, par contre, autant jeter un coup d’oeil à Docker, ça ne pourra être que mieux.

Ah, et Windows arrive sur Docker. Hâte de voir ça. Un Windows propre et rapide forever, et toutes les applications dans des conteneurs isolés, dont on se débarasse intégralement (jamais eu confiance en la désinstallation classique) quand on veut, le rêve ?

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.