Docker: Que faut-il en penser ?
Docker est un moteur open-source qui automatise le déploiement de n’importe quelle application en un container léger, portable, autonome pouvant être exécuté pratiquement n’importe où.
Les containers Docker peuvent encapsuler n’importe quelle charge utile, tout en restant consistants entre pratiquement n’importe quel type de serveur. Le même container, construit par un développeur pour des essais sur un ordinateur portable pourra être déployé et dimensionné en production sans modification. Ces containers peuvent tourner sur des machines virtuelles, des serveurs physiques, des clusters OpenStack, des instances publiques ou n’importe quelle combinaison des éléments précités.
Il est possible d’utiliser Docker dans ces cas notamment:
- Automatisation du packaging et du déploiement d’applications.
- Création d’environnements PAAS « Platform As A Service » légers, privés.
- L’automatisation des tests et l’intégration continue.
- Déploiement et dimensionnement (scaling) des applications web, des bases de données et des services de back-end.
Docker est en cours de développement intensif et n’est pas (encore) recommandé pour la production.
Alors pourquoi ce bout de logiciel fait-il autant parler de lui depuis le lancement du projet en mars 2013 ?
Au carrefour de la virtualisation et de l’automatisation
La définition de Docker laisse entrevoir un positionnement particulier de l’outil, à mi-chemin entre automatisation des infrastructures et virtualisation. Toutes proportions gardées, cela fait rentrer Docker dans le champ des logiciels comme Chef, Puppet, Ansible, Rudder qui sont spécialisés dans le déploiement et l’automatisation d’infrastructures mais aussi dans le champ de logiciels « Cloud » comme Libvirt-bin, Proxmox…
Une automatisation simple
Si vous avez utilisé l’un des systèmes d’automatisation cités ci-dessus, vous avez alors constaté la charge de travail non négligeable, le temps passé pour créer des recettes et autres manifests pour gérer vos serveurs. Ce coût n’est alors amorti que si vous avez un grand nombre de serveurs à configurer de la même façon. Et si possible sur des systèmes relativement équivalents car la promesse de l’abstraction totale des systèmes d’exploitation sous-jacents rendent les recettes encore plus compliquées, voir impossibles à maintenir dans le temps.
Docker répond par un worklow très simple. A chaque application est associé un ou plusieurs containers nécessaires au fonctionnement de celle-ci. Chaque container est un dérivé d’un container sous-jacent plus simple. C’est donc un modèle par couche ou pour les devs et admins plus pâtissiers, un millefeuille !
A chaque container est associé un fichier Dockerfile listant les opérations nécessaires à l’obtention d’un container prêt à la production. On est pas très éloigné d’un script shell post-installation pour l’écriture de ces étapes mais en plus prévisible!
Ces fichiers et les containers résultant sont versionnés de sorte qu’il est possible de traiter ces containers comme du code. Il existe par ailleurs un index des containers de la communauté Docker.
Virtualisation performante
Et pour cause, Docker s’appuie sur LXC et ne gère donc pas des machines virtuelles complètes au hardware émulé mais de simples containers isolés du système hôte par un ensemble de mécanismes.
À partir du moment ou vous n’avez besoin que de virtualiser des serveurs Linux tournant sur la même version du noyau, utiliser des containers LXC plutôt qu’une virtualisation complète comme KVM ou VMware est un gage de performance. Vos serveurs démarrent en moins de temps qu’il ne faut pour le dire et sont moins consommateurs en ressources.
Qu’apporte Docker par rapport à LXC seul ?
C’est simple, Docker agit au dessus de LXC comme une API orientée dev. Et là où LXC s’arrête commence la magie de Docker.
Prenons le cas concret de quelqu’un souhaitant construire un blog wordpress et souhaitant isoler chacune des briques composant la solution. Il va donc avoir besoin de:
- Un serveur web Apache2, Nginx ou autres.
- Un serveur MySQL ou MariaDB.
- Un serveur PHP5-FPM.
Sans rentrer dans le détail, pour construire un container Nginx par exemple, nous pouvons écrire le Dockerfile suivant:
# use the ubuntu base image provided by dotCloud
FROM ubuntu
# get nginx apt repository key
RUN apt-get install -y wget apt-utils
RUN wget -q -O - http://nginx.org/keys/nginx_signing.key | apt-key add -
# make sure the package repository is up to date
RUN echo "deb http://nginx.org/packages/ubuntu/ precise nginx" > /etc/apt/sources.list.d/nginx.list
RUN echo "deb-src http://nginx.org/packages/ubuntu/ precise nginx" >> /etc/apt/sources.list.d/nginx.list
# update all before anyhting else
RUN apt-get update
RUN apt-get upgrade
# install nginx
RUN apt-get install -y nginxC’est je crois plutôt parlant et commenté. Nous dérivons avec FROM notre container depuis le container officiel Ubuntu. Et chaque étape RUN n’est ni plus ni moins que l’exécution d’une ligne de commande.
Un simple docker build . à l’endroit ou est stocké le fichier Dockerfile vous permet désormais de reproduire ce résultat systématiquement.
Un pas vers l’immutabilité des serveurs
Il est possible de définir l’immutabilité d’une infrastructure par deux caractéristiques:
- Automatiser la configuration et le déploiement pour toutes les parties et toutes les couches de votre infrastructure.
- Ne jamais changer une partie de votre système une fois qu’il est déployé. Si vous avez besoin de changer, déployez un nouveau système.
Complétez votre Dockerfile des quelques éléments nécessaires à résoudre le delta entre la production et la cible et bootez cette nouvelle version du container.
Un projet français Monsieur !
Avec Docker, vous êtes au carrefour des technologies et méthodes qui font le buzz comme DevOps, l’intégration continue, la virtualisation, l’automatisation des infrastructures, systèmes immutables…
Et bien c’est un français, Solomon Hykes qui a démarré le projet et ils restent nombreux à travailler au sein de docker.io. Voilà qui devrait faire plaisir à un certain Mr M.;et ce même si les équipes travaillent depuis les États-Unis.
L’essayer, c’est peut-être l’adopter
Comme tout concept un tant soit peu « novateur », il faut un peu de temps pour prendre en main Docker. Non pas que la prise en main technique en soit complexe mais le cycle de vie d’un serveur est complètement redéfini. Il faut du temps pour admettre, surtout pour un vieil admin sys habitué à bichonner ses serveurs; que ceux-ci sont désormais une matière jetable, à dates de péremption de plus en plus courtes.
Docker n’est pas non plus sans surprise puisqu’il ne sauvegarde pas les modifications apportées au container pendant sa durée de vie. Il faut donc prévoir quelque chose si vous souhaitez gérer des données persistantes avec ce genre de technologie.
Docker est un tout cas un hybride bien fascinant dont je ne manquerais pas de vous reparler sur Wooster.
