DOCKER,

A QUOI A SERT ?
AUTEUR : DAVID NEGRIER
JUIN 2015

A QUI SADRESSE CE LIVRE BLANC ?

Lun des enjeux principaux de Docker est de rapprocher les quipes de dveloppement
de celles de la production. Docker permet, en effet, daisment installer une
application, mais galement de la modifier rapidement.
Ce livre blanc sadresse donc la fois aux oprationnels et aux dveloppeurs mais
aussi tous ceux qui organisent la DSI ou les diffrents projets.

CONTEXTE
Cre il y a tout juste 2 ans, Docker est la startup par excellence. 135 millions de
dollars levs, value en avril 2015 plus de 1 milliard de dollars de capitalisation
boursire, la socit cre par des franais fait le buzz dans la Silicon Valley. Elle attire
lattention des plus gros : Google, Amazon, IBM, Microsoft, tout le monde suit de prs
son volution. Alors simple bulle ou vraie rvolution ? Et puis dabord, cest quoi
Docker ?

LHEBERGEMENT AVANT DOCKER

Docker modifie en profondeur la manire dont on hberge les applications en crant
des containers. Les containers sont des sortes de botes noires dans lesquelles
diffrentes applications vont sexcuter. La notion nest pas vraiment nouvelle en
informatique. En effet, dans dautres domaines, on parle souvent de sandbox (ou bac
sable) pour isoler un processus du reste de la machine. Mais comme souvent le diable
se cache dans les dtails, avant daller plus en avant dans cette notion de containers,
voyons o elle se positionne par rapport aux autres technologies dhbergement dj
existantes.
Vous avez un site web mettre en ligne. Vous allez donc vous adresser un
hbergeur. Jusquen 2013 et lapparition de Docker, les hbergeurs vous offraient
gnralement ces options :

UN HEBERGEMENT MUTUALISE :

cest le domaine des petits sites

webs, qui ne contiennent que du contenu, des sites amateurs ou des forums type
PHPbb. Ce type dhbergement -spcifique au monde PHP- a tendance disparaitre.

UN SERVEUR DEDIE : vous louez un serveur dans les locaux de lhbergeur.

Libre vous dinstaller ce que vous voulez dessus, vous tes matre de la machine. En
France, des socits comme OVH ou 1&1 sont spcialises dans ce domaine avec des
offres trs comptitives.

UN SERVEUR VIRTUEL : vous louez une machine virtuelle , dans le cloud

. En ralit, votre machine virtuelle sexcute sur un serveur bien rel (lhte), chez un
hbergeur. Du point de vue de lutilisateur cependant, le serveur virtuel se comporte
comme un serveur ddi. Le serveur hte alloue une partie de ses ressources (CPU,
mmoire, rseau et disque) au serveur virtuel. Typiquement, un hte sera une machine
extrmement puissante (64 ou 128 Go de RAM, 24 ou 48 curs, etc.) qui hbergera de
nombreuses petites machines virtuelles. La technologie de virtualisation utilise
simule une machine complte. Cela signifie quil est possible de faire fonctionner une
machine virtuelle Linux sur un serveur hte Windows, ou inversement !
Les serveurs virtuels ont dclench toute la folie marketing autour du cloud , et ce
nest pas surprenant. Ils offrent en effet de nombreux avantages ! Une machine
virtuelle est facile administrer. On peut par exemple augmenter sa RAM dun simple

clic. On peut la faire passer dun serveur un autre par une simple copie dun fichier,
etc.
Pour terminer ce tour dhorizon des solutions dhbergement pre-Docker , rajoutons
une nuance propos des machines virtuelles. Nous allons faire la distinction entre 2
types dhbergements :

LE SERVEUR VIRTUEL PUBLIC est une offre dans laquelle le serveur que
vous commandez fonctionne sur un hte dont lhbergeur est responsable. Cest par
exemple le cas avec Amazon Web Services (AWS pour les intimes). Vous commandez
un serveur virtuel, vous ne savez rien de lhte sur lequel il tourne. Dautres serveurs
virtuels dautres clients fonctionnent sur le mme hte. En fait, Amazon pourrait trs
bien dcider de changer votre serveur dhte, cela ne vous concerne pas.

AVEC UN SERVEUR VIRTUEL PRIVE, au contraire, vous possdez toute

larchitecture, donc tous les htes. Vous choisissez comment rpartir les machines
virtuelles sur chacun des htes votre guise. Evidemment, le cot est sensiblement
diffrent ! Des technologies ouvertes comme par exemple OpenStack permettent de
crer un cloud priv. Leur installation est cependant fort complexe (nesprez pas
mettre en place OpenStack sans passer pralablement plusieurs semaines
apprendre le systme !)

LARRIVEE DES CONTAINERS

En 2013, larrive des containers secoue le monde Linux. Pour tre parfaitement exact,
la notion de container existe dj depuis 2008, mais na t jusque-l utilise qu la
marge.
Un conteneur est un espace bac sable dans lequel sexcute une application. Cela
ressemble normment une machine virtuelle, quelques dtails prs :
Tous les conteneurs partagent le mme noyau Linux. Cela signifie quun
conteneur fonctionne forcment sous Linux. Il partage avec le systme hte la
RAM, les CPU et lespace disque.
Les conteneurs sont donc beaucoup plus lgers quune machine virtuelle (ils
nembarquent pas lOS).
Ils contiennent nanmoins tous les fichiers dun systme dexploitation. Comme
une machine virtuelle, un conteneur dispose de ses propres utilisateurs, de son
adresse IP, et videmment de ses applications.
On comprend mieux lintrt de partager le noyau avec les autres containers sur le
schma ci-dessous. Dans le cas de la virtualisation, les ressources doivent tre
alloues en dur aux machines virtuelles. Une machine virtuelle doit tre
dimensionne pour tenir les pics de charges, donc on va lui allouer la quantit de RAM
maximale dont elle pourrait avoir besoin. Dans le cas des containers, chaque container
ne consomme que la RAM dont il a besoin un instant t , laissant de la place pour
plus de containers sur la mme machine.

Pour faire simple, avec un mme serveur, on gre plus dapplications, donc on fait des
conomies ! Succs assur, surtout auprs de gros consommateurs de serveurs
comme Google !
Cet avantage est aussi un inconvnient potentiel. Puisque les containers partagent le
mme noyau, un container pourrait sattribuer toutes les ressources dun serveur.
Mme sil existe des techniques pour viter cela, on comprend que les containers ne
soient pas aussi efficaces que les machines virtuelles dans le cadre dun cloud public.
Les containers sont donc en fait naturellement en concurrence avec les offres de
cloud priv, type OpenStack.

Evidemment, les containers seront installs sur un serveur hte, qui sera la plupart du
temps un serveur ddi, mais qui pourrait aussi tre un serveur virtuel !
ce niveau de lecture de ce livre blanc, vous devez dj avoir une ide de la rponse
la question Est-ce que Docker est fait pour mon entreprise ? . Si vous avez ressenti
le besoin de disposer dun cloud priv, si vous multipliez les serveurs pour de petites
applications ou si au contraire vous avez de nombreuses applications hberges sur
un seul serveur et que vous souhaitez les stocker dans des environnements bien
spars, il est probable que la rponse soit oui.

DOCKER, UN OUTIL POUR LES

DEVELOPPEURS
Cela ne vous aura pas chapp, jusquici, nous avons surtout parl hbergement. Mais
ici, chez TheCodingMachine, notre mtier, cest plutt le dveloppement web. Alors
pourquoi crire un livre blanc sur une technologie plutt utilise par nos partenaires
hbergeurs ? Il doit bien y avoir quelque chose de particulier pour les dveloppeurs,
non ?
Tout juste !
Vous avez sans doute dj entendu parler de mouvement DevOps , qui vise
rduire la friction entre les quipes de dveloppement (dvs) et les quipes
oprationnelles en charge de la maintenance des serveurs (ops). Et bien Docker
sinscrit prcisment dans ce mouvement.

LE DOCKERFILE
Afin de mettre en place un container Docker, il faut indiquer Docker la liste des
commandes excuter pour installer les applications que lon souhaite mettre dans le
container. Cette liste de commandes est saisie dans un fichier nomm Dockerfile. Et
qui rdige ce Dockerfile ? Le dveloppeur !
Docker dclenche donc un transfert de responsabilit des ops vers les devs .
Avant Docker, le choix des applications installes (base de donnes, serveur web, etc.)
tait la main des ops . Souvent, les dveloppeurs navaient pas la main sur la
machine de production pour installer lapplication. Avec Docker, le dev fournit un
container dans lequel il a configur lui-mme les applications.
Est-ce une bonne chose ?
Oui, pour plusieurs raisons :
Le dveloppeur a souvent une trs bonne connaissance des applications quil
utilise et sait les configurer trs prcisment.
Cette configuration est de plus stocke avec le code (donc versionne dans un
dpt de code type GIT).
Le fichier Dockerfile est autodocument et remplace avantageusement une
documentation dinstallation qui pourrait ne pas tre toujours mise jour.

Les diffrents environnements (dv, tests, prprod, prod) sont strictement

identiques.

Attention cependant ! Le mtier dhbergeur impose des responsabilits que les

dveloppeurs nont pas lhabitude de porter :
Le suivi des failles de scurit ;
La mise jour rgulire des paquets utiliss.
Ces 2 points ne sont pas aujourdhui intgrs nativement dans les images Docker et
demandent une attention particulire !
Enfin, il est important de noter que le format du Dockerfile est absolument trivial. Il
nest donc pas trs compliqu de crer son propre container.
Vous ne me croyez pas ? Mettons les mains dedans alors ! Voici un exemple dun
Dockerfile qui cre un container contenant le serveur web Apache.
DOCKERFILE
FROM ubuntu
RUN apt-get update && apt-get -y install apache2 && apt-get
clean
ADD default.conf /etc/apache2/sites-available/default.conf
EXPOSE 80
CMD ["/usr/sbin/apache2ctl", "-D", "FOREGROUND"]
La premire ligne (FROM) nous donne le point de dpart pour la construction de notre
container. Sous Docker, nous ne partons jamais de zro, mais toujours dun container
que lon tend. Dans notre cas, nous tendons ubuntu , qui est un container
possdant les fichiers du systme dexploitation ponyme. Do vient ce ubuntu ?
Du repository principal Docker. Nous parlerons de ce repository tout lheure.
La deuxime ligne (RUN) permet dexcuter des instructions dans le container. Ici, les
habitus des systmes Debian / Ubuntu auront reconnu la commande dclenchant
linstallation dun serveur Apache.
La troisime ligne (ADD) permet de rajouter des fichiers partir de notre serveur dans
le container. Il sagit gnralement de fichiers de configuration spcifiques.

La quatrime ligne (EXPOSE) permet douvrir le port 80. Il sagit du port rseau utilis
par le protocole HTTP. Nous devons systmatiquement prciser Docker quels sont
les ports qui sont accessibles depuis lextrieur du container pour des raisons de
scurit.
La dernire ligne (CMD) contient linstruction qui sera lance par dfaut au dmarrage
du container. Ici, nous dmarrons le serveur Apache.

LE SYSTEME DE FICHIER DE DOCKER : UNION FILE SYSTEM

Il est trs facile de crer et dmarrer de nouveaux containers avec Docker. Mais quid
de lespace disque ? Puisque chaque container dispose dun systme de fichier dun
OS complet, a risque de prendre de la place non ?
Et bien pas tant que a. Les dveloppeurs de Docker ont pens tout. Reprenons
notre exemple prcdent. Notre container Apache est bas sur un container
ubuntu . Si on dmarre 2 containers Apache , on pourrait sattendre ce que les
fichiers de Apache et de Ubuntu soient dupliqus. Mais au lieu de cela, seuls les
fichiers modifis dans un container et pas dans lautre seront stocks en plus, grce
lUnion File System, un systme de fichier qui sait ne stocker que les deltas.
Ainsi, chaque Dockerfile cr en fait un layer sur lequel vont sappuyer dautres
containers, qui seront eux-mmes les layers dautres containers

LA REGISTRY DOCKER
9

Puisque chaque container est bas sur un container parent, lorsque vous souhaitez
construire votre propre container, la premire question va tre :
de quelle image partir ?
Mais avant tout, quest-ce quune image ? Une image est cre partir de fichiers de
configuration Dockerfile qui proposent une description exacte de ce qui doit tre
install sur le systme. Les images contiennent tout ce que lon souhaite y installer (un
script lancer, une base de donnes MySQL) mais ne sont pas actives. Cest le
container qui a le pouvoir dinteragir avec les applications prsentes dans limage (faire
tourner un serveur par exemple).
Une des grandes forces de Docker, cest justement doffrir une registry
(http://registry.hub.docker.com/). Il sagit dun site rfrenant un trs grand nombre
dimages (plusieurs dizaines de milliers de containers !)
Nimporte qui peut se crer un compte dans la registry et venir dposer ses propres
images (qui seront publiques).
Attention cependant, la plupart de ces images sont de trs mauvaise qualit, ou non
maintenues ! Il faut donc apprendre faire le tri. Voici nos conseils :
Utiliser en priorit des images officielles si elles existent. Celles-ci peuvent tre
soit :
o Dveloppes par les quipes de Docker (par exemple limage ubuntu)
o Dveloppes par les quipes des projets eux-mmes (par exemple
limage Mysql)
Si lapplication que vous utilisez ne dispose pas dune image officielle, il est
probable que quelquun en ait dj dvelopp une. Avant de vous prcipiter
dessus, vrifiez :
o Le nombre de tlchargements et dtoiles , qui donnent une
indication de la popularit de limage
o Les diffrents tags , qui permettent de voir si limage est supporte
dans le temps par son auteur
Si vous navez pas une grande confiance en une image, par exemple parce
quelle semble non maintenue, il vaut mieux rcuprer le code du Dockerfile de
limage et repartir de ce code pour votre projet (i.e. faire un fork).
Note : les images publies sur Docker sont par dfaut publiques. Docker offre
nanmoins la possibilit dhberger des images prives contre un abonnement

10

mensuel. Dailleurs, le business-model de Docker semble tre bas sur cet

hbergement dimages prives.
Chez TheCodingMachine, on est un peu circonspects vis--vis de cette stratgie
commerciale on peut trs bien utiliser Docker sans publier dimages prives dans la
registry ! Nous navons pas besoin de publier nos Dockerfile pour les utiliser. Docker
est trs utile dans sa version gratuite et les services offerts par labonnement nous
semblent limits. Bref, on voit mal Docker devenir une cash-machine juste avec ces
abonnements. Lintrt que portent les grosses entreprises Docker et les tours de
table successifs semblent tre plus lis aux conomies que permet de faire Docker
(limiter le nombre de serveurs), plutt quaux potentiels bnfices venir sur lactivit
abonnement de Docker.

11

ORGANISER LES CONTAINERS

Si vous allez voir la registry Docker, vous allez trouver de trs nombreuses images. Par
exemple, vous trouverez des images de serveurs Apache+PHP pour le serveur web,
des images MySQL pour la base de donnes, des images Elasticsearch pour la
recherche full-text, des images Postfix pour le serveur de mails
Mais votre application web vous, elle a besoin de tous ces composants. Vous vous
mettez donc la recherche dun container Apache + PHP + MySQL + Elasticsearch +
Postfix Stop ! Vous partez dans la mauvaise direction !
Il y a un point important dont nous navons pas encore parl ! Dans la philosophie de
Docker, chaque container est cens faire une tche et une seule. Donc votre
application devrait rellement tre compose de 4 containers :
Les containers MySQL, ElasticSearch et Postfix, que vous utiliserez tels-quels

Le container Apache+PHP, que vous tendrez via un Dockerfile pour ajouter le

code PHP de votre application lintrieur.
Il faut imaginer chaque container comme une sorte de bote noire, grant un microservice, et qui peut tre connecte dautres containers.
Et l, vous vous dites : 4 containers pour une simple application web ? Mais cela
ajoute de la complexit et de la maintenance ! Dans le cas dune machine virtuelle, je
pouvais mettre toutes mes applications au mme endroit. Avec Docker, jai 4 lments
diffrents administrer !
Effectivement ! Et pour grer cette complexit, Docker propose des outils
dorchestration. Nous allons ici parler du plus connu : Docker-compose.

12

Avec Docker-compose, le devops crit un simple fichier de configuration (au format

YAML) qui dcrit lensemble des containers composant une application, ainsi que la
manire dont ces containers sont interconnects que ce soit un accs rseau ouvert,
un partage de systme de fichier, etc.

Docker-compose est la glue qui rassemble les diffrents containers de votre

application.
Cependant, comme souvent avec Docker, on dtecte dans Docker-compose des
dfauts de jeunesse.
Voici notre exprience. Lorsque nous avons commenc travailler avec Dockercompose (dbut 2015), celui-ci sappelait FIG. Ctait un projet communautaire. Le
projet a t depuis repris officiellement par lquipe de Docker, et le format du fichier a
lgrement chang, forant une petite adaptation.
En mars 2015, loutil ne permettait pas de distinguer certains paramtres par
environnement. On avait alors un fichier de configuration Docker-compose par
environnement, ce qui occasionnait de la redondance donc de la double maintenance.
Un mois plus tard, une fonctionnalit tait ajoute pour grer le support de ces
diffrents environnements
Docker-compose est encore plus jeune que Docker et cela se ressent, avec un rythme
de sortie de nouvelles versions assez important.
Egalement, Docker-compose dispose dune limitation importante : il ne gre les
environnements que sur une machine unique. Impossible donc dutiliser Dockercompose pour une architecture distribue sur plusieurs machines (load-balancing ou
haute disponibilit).

13

Pour ce genre de besoins, on se tournera vers lun des nombreux concurrents de

Docker-compose :
Helios, dvelopp par Spotify
Machine et Swarm, fournis par Docker directement
Shipyard
Kubernetes, fourni par Google
OpenStack, qui propose dans sa dernire version une gestion des containers en
plus des machines virtuelles

Il y a plus dune trentaine de solutions disponibles et concurrentes !
Lorchestration de containers Docker est un sujet en pleine bullition, et une
consolidation devrait avoir lieu dans les prochains mois. Ainsi, il est difficile lheure
o nous crivons ces lignes de savoir quels outils prendront le dessus et quels outils
seront abandonns. Nous ne pouvons que vous recommander la prudence si vous
devez choisir un de ces outils.

14

HEBERGER PLUSIEURS APPLICATIONS

WEB SUR UN MEME HOTE
Lintrt principal de Docker est de permettre disoler votre application web dans un
container. Comme nous lavons expliqu, un container dispose de sa propre adresse IP
interne (commenant par 172.17.XXX.XXX). Le container nest pas accessible depuis
lextrieur, sauf si un port est expos. Dans le cas dune application web, on exposera
le port 80 (port par dfaut pour le protocole HTTP).

Mais que se passe-t-il si vous voulez disposer de plusieurs containers (donc plusieurs
applications web) sur le mme hte ?
Par exemple, vous avez peut-tre 2 containers PHP et un container NodeJS qui
souhaiteraient rpondre sur le port 80. Hlas, un port ne peut tre occup que par un
seul container !
Pour rsoudre ce problme, Docker propose de passer par un reverse-proxy .
Derrire ce nom barbare se cache un processus tout simple. Cest un autre container
(gnralement utilisant le serveur web Nginx), qui va couter sur le port 80. En fonction
du nom de domaine demand, la requte sera automatiquement transfre au
container concern.

15

Point important signaler, la configuration du reverse-proxy est extrmement

simple mettre en place. Il suffit de rajouter une simple variable denvironnement dans
les containers web contenant le nom de domaine pour que le reverse-proxy
comprenne quil doit transfrer les appels web du domaine au container.

16

COMPATIBILITE OSX ET WINDOWS

La technologie des containers nest disponible que sous Linux. Si la plupart des
serveurs fonctionnent sous Linux, les dveloppeurs, eux, peuvent utiliser une varit de
systmes dexploitation.
Aujourdhui, lors de la phase de dveloppement, les dveloppeurs utilisant Linux sont
nettement avantags par rapport leurs homologues sous Mac ou Windows car ces
derniers ne peuvent pas utiliser directement Docker. Il y a nanmoins une solution de
contournement :
Boot2Docker fournie par Docker, est une machine virtuelle qui permet de dmarrer un
Linux contenant Docker sous nimporte quel systme dexploitation.
Hlas, dans la pratique, lutilisation dune machine virtuelle est fastidieuse. Par
exemple, lheure o nous crivons ces lignes, la machine virtuelle Boot2Docker nest
pas compatible avec Docker-compose, loutil dorchestration. Egalement, les carts de
droit entre la gestion des fichiers Windows et Linux peuvent causer des problmes.
Heureusement, la technologie avance grands pas. Si la solution nest pas mature
pour linstant, gageons quelle le sera bientt.

DERNIERE MINUTE !
Nous allions publier ce livre blanc et une nouvelle vient juste d'tre annonce... Docker,
CoreOS, Google, Amazon et Microsoft (entre autres) ont dcid de travailler ensemble
pour crer un standard unique de dploiement de containers: the Open Container
Project. Il s'agira d'un standard permettant l'introprabilit entre des containers
Docker (le standard de-facto jusque l) et d'autres containers. Quand on vous dit que
les choses bougent vite dans le monde des containers.

17

CONCLUSION
Alors Docker, simple mode ou vraie rvolution ?
Rvolution, assurment. Docker est une technologie trs jeune, et pourtant dj trs
ancre auprs des devops. Il est clair que les avantages offerts par la technologie et sa
facilit dapproche vont rendre lutilisation des containers incontournable dans le futur.
Mais doit-on adopter Docker tout de suite ?
Et bien tout dpend de votre besoin. La solution est neuve et bouge encore beaucoup:
Suivre les volutions de Docker peut tre couteux.
Egalement, la qualit assez moyenne des images existantes dans le repository
impose un cot dadaptation assez fort. La promesse de Docker est de fournir
des images de containers comme des boites noires qui marchent du
premier coup, mais force est davouer que pour linstant, il est frquent de
devoir modifier ces images.
Les bonnes pratiques dutilisation commencent tout juste merger et ne sont
pas encore universellement partages, tant du point de vue dveloppeur que du
point de vue oprationnel.
Les outils dorchestration sont trop nombreux pour savoir lequel choisir pour
une architecture complexe, avec un vrai risque de choisir un outil qui va prir.
Cependant, il ne sagit que de dfauts de jeunesse et dici quelques annes,
lenvironnement sera plus stable et plus mr.
La preuve ? Les leves de fonds successives de Docker assurent que la technologie va
voluer. Si Docker est une technologie qui ne fonctionne aujourdhui que sous Linux,
Microsoft est en train de travailler une compatibilit Windows, preuve de lintrt des
gants de linformatique pour les containers.
Et cest comprhensible ! la clef, nous parlons dconomies importantes en termes
de matriel et dune automatisation de processus dinstallation complexes.
Alors nul ne peut lire lavenir, et peut-tre que Docker tombera aussi vite quelle est
monte, mais une chose est sre : la technologie des containers que Docker a russi
dmocratiser est l pour rester.

18

A PROPOS DE THECODINGMACHINE
TheCodingMachine accompagne ses clients sur des missions de conseil
technologique et sur des projets de dveloppement d'applications Web.
Nous sommes spcialiss dans le dveloppement de sites Internet, dextranets
(videmment), dintranets, dapplications Web mtiers en PHP et en JavaScript.
Fonde en 2005, TheCodingMachine a pilot plus de 300 projets. Nous travaillons
aussi bien pour des grands comptes privs et publics, pour des PME-PMI que pour des
startups. Nous avons investi ds notre cration dans la R&D, ce qui nous permet par
exemple dtre la pointe des technologies web (PHP, Node.JS, AngularJS, streaming
video etc.).

www.thecodingmachine.com
Tl : 01 71 18 39 73
contact@thecodingmachine.com
4, rue de la Michodire 75002 PARIS

19