Bonjour à tous ! Sans grande surprise, suite à cette image, aujourd’hui on parle des deux conférences qui ont traité de Docker lors de la 8ème édition de Be-Zend. La première a été réalisée par Benjamin Lazarecki et Kévin Verschaeve durant laquelle ils ont présenté un historique et les bases de l’outil. La seconde a été réalisée par Mario Loriedo qui nous a présenté une utilisation avancée de Docker et des outils permettant de faciliter le travail des développeurs. Voici un résumé des deux conférences.

1. Présentation de Docker
   1. Historique
   2. Containers et environnement de production
   3. Docker hub
   4. Kitematic
2. Utilisation
   1. Commandes de bases
   2. Dockerfile
   3. docker-compose
3. Docker 4 devs
   1. Building
   2. Testing
   3. Deploying
4. Conclusion

Présentation de Docker

  Historique

L’idée a débuté en 2008 sous l’initiative de Solomon Hykes dans le but d’harmoniser les environnements entre la productions et ceux des développeurs. L’idée est supervisée par la société dotCloud qui en assure le développement. La première version open source a vu le jour le 26 mars 2013. 2 ans après, Docker c’est:

• plus de 700 contributeurs
• plus de 103 millions de containers téléchargés (on reviendra sur le terme plus tard)
• dans le top 15 des projets les plus populaires de Github
• 70 000 applications qui tournent déjà sous Docker
• Contrairement aux autres systèmes de virtualisation, il est possible de faire tourner entre 100 et 1 000 containers sur un serveur standard.

Pour le moment, Docker est pleinement compatible sous Linux. Pour Mac et Windows, il est nécessaire de lancer une VM linux spéciale (très allégée) nommée Boot2Docker.

  Containers et environnement de production

Qu’est-ce qu’un container ? Un container peut être vu comme une VM, ce qui permet d’isoler des processus de ceux du système host (installation d’un programme, lancement de scripts, etc). Les principales différences avec les autres systèmes de virtualisation s’axent autour des besoins en ressources physiques et le temps de lancement. En effet, là où les autres systèmes ont la nécessité de lancer un OS, les containers se contentent d’utiliser les ressources du système host. Ceci permet un gain de consommation et des démarrages plus rapides tout en conservant un isolement des processus des autres présents sur le host.

Ainsi, il est possible d’exporter facilement les environnements de développement avec leurs projets.

Une analogie peut être effectuée dans le monde réel. Depuis bien longtemps, les hommes ont le besoin de déplacer leurs marchandises et une forme unique permet d’uniformiser les moyens de transports. C’est ainsi que le conteneur a vu le jour. C’est en s’inspirant de cette idée que les containers ont été créés, permettant d’isoler et transporter facilement les ressources d’un projet.

Déjà utilisé par de grandes sociétés tel que Netflix ou Spotify, il est cependant conseillé d’attendre avant d’utiliser Docker en production. En effet, dans l’état actuel, les containers sont exécutés avec les droits root, ce qui peut engendrer des failles de sécurités. Un travail est en cours pour régler ce soucis et rendre la technologie utilisable correctement en production.

  Docker hub

Le docker hub fait office de dépôt centralisé permettant de stocker des images (publics ou privés) de containers tout en les versionnant. On peut comparer ceci à un apt-get install sous Ubuntu. En effet, il est possible via une commande d’installer de nouveaux containers issues de cette plateforme.

A l’heure d’aujourd’hui, les tarifs pour stocker des images privées sont rédhibitoires et la création d’un dépôt local se révèle encore une tache ardue. Il est donc préférable, dans la mesure du possible, de rendre les images publiques.

  Kitematic

Depuis septembre 2014, un programme est développé dans le but de faciliter la manipulation des containers sous Mac. Nommé Kitematic, celui-ci offre une interface graphique offrant la possibilité de démarrer/stopper des containers ainsi que d’accéder aux logs, etc. Le projet a été mis sous la tutelle de dotCloud il  y a quelques mois. Il y a quelques jours, une issue sur Github demandant une version pour Linux a eu un regain d’attention ce qui semble annoncer une future version pour notre ami Tux.

Utilisation

  Commandes de bases

Voici une liste de quelques commandes de bases:

• docker images : liste les images déjà téléchargées (depuis le docker hub)
• docker search term : recherche une image sur le dépôt.
• docker pull name : télécharge l’image d’un container à partir de son nom.
• docker ps : liste les containers en cours d’exécutions. L’option -a permet également d’afficher les containers éteints.
• docker diff : affiche les différences entre l’état actuel du container et l’image dont il est issue.
• docker logs : affiche les logs de docker. L’option -f permet d’afficher un flux continu de logs (à l’image de la commande tail -f sous linux).
• docker commit id_container name_user/name_image:tag : crée une nouvelle version du container basée sur l’état actuel en lui précisant un nom de version (tag) et l’envoie sur le Docker hub.
• docker run name_image /bin/bash : lance un container depuis le nom de son image. Le dernier paramètre peut être un script ou une commande qui sera exécutée dans le container. Il faut s’avoir qu’un container se stoppe dès lors que tous ses processus sont terminés. Les options -i et -t permettent d’assigner un terminal au container et de prendre la main dessus.
• docker stop id_container : stoppe un container en fonction de son id (que l’on peut récupérer via un docker ps par exemple).

Pour plus d’information, vous pouvez retrouver la documentation présente ici.

  Dockerfile

Le dockerfile est un fichier permettant d’automatiser la génération des containers. Il doit être nommé Dockerfile. Quelques syntaxes de bases:

• FROM : l’image servant de base pour le futur container qui sera lancé (il est possible de sélectionner un tag particulier).
• RUN : une commande a exécutée.
• EXPOSE : lie certains ports de l’host aux ports du container. Par exemple, il est donc possible de lier le port 8080 de l’host au port 80 du container.
• ADD : copie un fichier depuis l’host vers le container.
• VOLUME : crée un point de montage dans le container qui pointe vers un dossier de l’host.
• WORKDIR : change l’emplacement d’exécution actuel des scripts.
• ENTRYPOINT : exécute des commandes lors du démarrage (ou redémarrage) d’un container.

Ensuite, il suffit d’exécuter la commande docker build. Il est bon de savoir que si le build échoue, docker build relancera l’exécution sur la dernière tâche qui a provoqué le blocage sauf si on lui demande de ne pas utiliser le cache (via l’option –no-cache). Pour plus d’informations, rendez-vous sur la documentation officielle.

  docker-compose

docker-compose permet la manipulation de multiple containers et de gérer simplement leurs interactions (quel container démarre en premier par exemple). Toute la configuration se fait via un fichier yaml nommé docker-compose.yml. Ensuite, il suffit d’exécuter la commande docker-compose up pour lancer tous les services. Ceci se révèle grandement utile dans le cas où vous séparez vos services dans de multiples containers.

docker-compose est également accompagné de quelques commandes qui lui sont propres. On retrouve par exemple la commande docker-compose ps qui permet de lister les containers lancés lors d’un docker-compose up. Comme d’habitude, pour plus d’informations, vous pouvez vous rendre sur la documentation officielle.

Docker 4 devs

Cette partie résume principalement la conférence de Mario. On évoquera l’utilisation de docker tout le long du processus de développement.

  Building

Depuis peu, des containers nommés language stack voient le jour. Ils ont pour but de regrouper les différents environnements nécessaires aux développement dans chaque langages. Ainsi, il suffit de préciser la version désirée d’un langage et l’on peut récupérer un environnement directement opérationnel.

En se basant sur ces containers, Mario a développé un plugin pour Sublime Text dans le but d’offrir la possibilité de build n’importe quel fichier via Docker en téléchargeant automatiquement l’image nécessaire. Le plugin offre également la possibilité de choisir avec quelle version du langage on désire réaliser ce build. Le plugin se nomme sublime-docker. Dans les évolutions futures, il est prévu de pouvoir exécuter directement les commandes docker logs et docker ps depuis Sublime Text.

Un plugin Eclipse (Doclipser) existe également. Il offre un éditeur de Dockerfile ainsi que l’exécution de son projet via Docker.

Il est important de noter que ceci s’inscrit dans une optique plus large. Le but final est de proposer un plugin pour chaque IDE afin d’y intégrer facilement Docker. Pour participer ou voir l’avancer dans chaque IDE, vous pouvez vous rendre sur le site du projet: http://domeide.github.io/.

  Testing

Docker peut se révéler une bonne pratique pour mettre en place rapidement vos environnements de tests (sur votre plateforme d’intégration continue par exemple). La conférence ne s’est pas étalée sur le sujet.

  Deploying

Il est possible de réaliser un processus de déploiement en production tout en utilisant Docker. Sur un simple push dans Github, il est possible d’enclencher une mise en production:

1. On commence par lier Github au Docker hub. Ceci permet de relancer automatiquement le build du Dockerfile et de stocker la nouvelle version du container sur Docker hub.
2. Côté Docker hub, il est possible de demander la notification d’une url (via POST) dans le but de signaler la mise à jour d’une image. Ainsi, on peut notifier notre plateforme d’intégration continue (par exemple CircleCI). Celle-ci relance les tests avec cette dernière version du container.
3. Une fois les tests réussis, il ne reste plus qu’à notifier la production pour qu’elle se mette à jour. Pour gérer ceci, il est possible d’utiliser Shipyard. Il propose de manager différents hooks et de prendre en charge la mise à jour des containers. De plus, il offre une interface graphique permettant de contrôler le tout.

Conclusion

Pour conclure, j’évoquerai brièvement docker-machine, qui a débuté en décembre 2014. Celui-ci permet de générer des VM dédiées à l’hébergement de containers. Ceci s’inscrit dans le but d’offrir un service cloud pour Docker.

Même si Docker est encore récent, il est bon de mentionner que des forks sont déjà en cours. On notera donc que le projet Rocket a vu le jour sous la direction de l’équipe de CoreOS. Celui-ci a pour but d’être plus ouvert que Docker et de palier à certains des soucis de ce dernier (comme les accès root des containers).

Je n’ai pas encore pu mettre en pratique les éléments qui nous ont été présentés mais j’en suis ressorti convaincu et avec des idées d’utilisations. Ainsi, j’envisage d’utiliser Docker dans mes futurs projets open source pour offrir une installation rapide de l’environnement nécessaire à leur utilisation. J’envisage également la possibilité d’améliorer mes tests via cette technologie et d’aider mes futurs stagiaires lors de l’installation de leur environnement de développement en leur proposant des containers regroupant les dépendances des différents projets.

Je tiens à terminer en remerciant grandement Kévin, Benjamin et Mario pour leurs présentations riches en informations sur Docker. Vous pouvez également retrouver les slides de la première conférence (les bases de Docker) en ligne.