Docker est sous les feux de la rampe depuis maintenant un an et demi environ. Après l’engouement des early-adopters, toujours prompts à porter au pinacle une nouvelle technologie et à l’abandonner aussi facilement pour une autre quelques temps après, il est sans doute temps de prendre un peu de recul et essayer de comprendre comment marche Docker et à quoi il peut bien servir.

Qu’est-ce que Docker ?

Commençons par dire ce que Docker n’est pas ! Ce n’est pas une technologie de virtualisation à proprement parler, ça ne permet pas de créer des machines virtuelles, mais des containers. La différence fondamentale tient à ce qu’une machine virtuelle s’exécute sur une abstraction de la couche physique, exposée par la couche de virtualisation et lui faisant par exemple croire qu’elle dispose d’un CPU, de 4 Go de RAM et de deux interfaces réseau alors que le serveur physique sous-jacent est très différent. La containerisation est un peu différente puisqu’elle résulte de l’isolation d’un ensemble de ressources (CPU, mémoire…) et de process qui le rendent complètement étanche à son environnement direct, le système hôte, dont il partage uniquement, mais c’est une différence importante avec les système de virtualisation, le kernel (noyau).

Ceci est illustré sur le site officiel de Docker par les schémas suivants :

vmSchéma avec Docker

On peut y voir à gauche l’empilement classique d’un hôte de virtualisation, avec un hyperviseur exposant aux VM les ressources sélectionnées. A droite, la couche « docker engine » est plutôt une couche d’orchestration et de référencement de containers fonctionnant de manière isolée sur l’hôte principal dont il partage le noyau. Docker ne fonctionne donc nativement pour l’instant qu’avec Linux, de même que les containers ne peuvent contenir que des logiciels Linux. Dans le container, on va donc trouver toute la pile applicative nécessaire au fonctionnement de l’application voulue, depuis les librairies système (glibc par ex.) jusqu’aux exécutables finaux.

Plus qu’une technologie, un écosystème.

Jusqu’à présent, la description ainsi faite de Docker pourrait avoir été presque identique s’il s’était agi de LXC, la technologie Linux sous-jacente sur laquelle Docker s’appuie. Sauf que si Docker a du succès, c’est un peu comme GitHub car il a su mettre en place un écosystème complet autour de sa technologie. En effet, sur le site docker vous trouvez des images vous permettant de lancer très facilement des containers pré-configurés de WordPress, ElasticSearch, MySQL, PostgreSQL. Ainsi, il suffit de lancer une commande simple de type « docker run -d neogeo/mapserver » pour lancer une instance de MapServer 7.1 configurée par nos soins sur votre système, isolée du reste de votre OS, mais accessible par le port prédéfini 80 (que vous pouvez aussi mapper vers un autre port de votre hôte). L’interpréteur docker vous permet ainsi de lancer des containers, de les arrêter, d’en construire vous-même et de les publier sur le dépôt central.

Dès lors, il est très facile de trouver des images intéressantes, de les tester, voire de s’appuyer dessus pour en construire de nouvelle. Car Docker a ceci de particulier qu’il référence le contenu des containers en une multitude de couches, les Layers, qui sont partageables entre plusieurs instances de containers. De la sorte, si vous lancez trois Docker Ubuntu, l’image elle-même et ses centaines de Mo ne sera pas répliquée trois fois sur votre système, mais utilisée à partir de la même origine. Donc économie d’espace, et surtout, dès que l’image a été récupérée une fois, lancement instantané des nouveaux containers.

OS ou pas OS ?

C’est une question existentielle qu’on se pose assez rapidement après avoir essayé Docker. Quand on voit toutes ces images Ubuntu, Debian ou CentOS, on s’interroge légitimement… Pourquoi charger un OS, on m’avait dit que Docker s’appuyait sur celui de l’hôte ? En effet, mais uniquement à bas niveau, sur le kernel. Dès lors, il faut quand-même installer dans le container tout ce qui permet au système de fonctionner (librairies diverses, applications de bas niveau telles que bash…). Et c’est donc des OS simplement allégés de leur kernel qu’il s’agit de déployer à l’intérieur des containers. Ce qui explique les différentes déclinaisons des principaux OS Linux, ou même de dérivés spécialement dédiés à Docker tels que CoreOS. Il y a aussi une distribution dédiée à la machine hôte (celle qui héberge les dockers), RancherOS.

Configuration

La configuration d’un modèle de container se fait via un fichier nommé Dockerfile, qui contient les différentes instructions de construction, depuis l’image de base (OS) à utiliser jusqu’aux composants à y installer et aux options à spécifier. Certaines configurations peuvent être très complexes, et il sera nécessaire à chacun de bien s’immerger dans le sujet afin de commencer à la maîtriser. D’excellentes ressources sont évidemment disponibles sur le web (mais sont parfois contradictoires quant à certaines méthodes d’optimisation, preuve que le sujet est vraiment neuf) et le meilleur point de départ est sans doute le site Docker lui même et ses dockerfile best practices.

Repenser les architectures

Au-delà des aspects techniques de son utilisation, Docker enjoint à s’interroger sur les architectures à mettre en place. La vocation assumée de Docker est en effet de faire tourner des micro-services. A la différence de machines virtuelles dans lesquelles on va reproduire ce qu’on aurait mis dans une machine physique (un serveur web, différentes applications et modules), le mode Docker incite à découpler tout ce qui peut l’être. Pour une simple application web, on peut par exemple utiliser 3 containers différents : un pour le serveur web et l’application proprement dite, un pour un serveur de base de données, un pour les données de la base de données, de manière à pouvoir mettre à jour et manipuler chacun des containers sans impacter les autres aspects de l’architecture. Vu la facilité associée de déploiement des containers, et de chaînage des containers entre eux, on est vite conduit à décomposer l’architecture applicative, à la déconstruire pour se diriger vers un ensemble de micro-services distribués. L’API part ici, l’admin par là, autant de containers différents pour des rôles applicatifs différents, avec l’avantage notable de faciliter les mises à jour différenciées et l’isolation de certains services.

Pour bien illustrer ce propos dans le contexte géomatique, on peut se pencher sur des services WMS/WFS. En appliquant les principes de Docker, on va pouvoir composer des containers dédiés à un service en particulier. Si on utilise MapServer, exemple pris au hasard, on peut très bien avoir 1 container pour 1 instance nginx + mapserver + 1 mapfile (qui peut par ailleurs être partagé sur la machine hôte de manière à être facilement modifiable par l’administrateur, ou partageable avec un autre container). Ainsi on fait glisser la sémantique applicative de « serveur OGC » à « services OGC », indépendants les uns des autres, même s’ils partagent un même modèle initial de container.

Conclusion

Les technologies de containerisation, et Docker en particulier, sont récentes et encore immatures par certains aspects. Mais elles bénéficient d’un développement très rapide (il est très difficile de suivra l’actualité de Docker tant l’effervescence est grande sur le sujet) et de nouveaux outils de plus haut niveau de configuration ou d’orchestration (Docker a récemment dévoilé Compose et Machine) permettent de s’affranchir de la relative rusticité des outils de base en travaillant à un niveau d’abstraction plus élevé. Un sujet à suivre, de toute évidence, car au moins autant que la virtualisation en son temps il porte les germes de pratiques réellement innovantes.

 

Un petit peu de Docker

Une pensée sur “Un petit peu de Docker

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *