Introduction à Docker et analyse de ses avantages et problèmes.

1. #docker
Romain Chalumeau – Altran - 22 mai 2015
Le buzz est-il justifié
?

2. 2
Agenda
Partie 1
Partie 2
Docker, c’est quoi ?
Alors ? Justifié ou pas ?
Ca tombe pile au bon moment !
C’est simple !
L’application clé en main !

3. 3
Docker, c’est quoi ?

4. Docker, une évolution du container…
2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015
Docker n’a pas
inventé le
container !

5. 5
…qui provoque une révolution !
levée de
40M$levée de
95M$
levée de
15M$
+900 contributeurs
+100 000 applications disponibles
09/2014
04/2015
01/2014
github
• dockerhub
En seulement
deux ans

6. Machine virtuelle ou container ?
Hardware
OS hôte
Hyperviseur
OS A
Bin/libs X
OS A
Bin/libs X
OS B
Bin/libs Y
App C
VM
Hardware
OS hôte
Daemon
Bin/libs X
A B
Bin/libs
Y
App C
Containers
Gourmand Léger
Isolation complète (sécurité) Cloisonnement
VS
B
Bin/libs X
A
Docker est de la
famille des
containers !
A BB A

7. 7
Pourquoi un tel buzz ?
Parce que :
Docker est orienté application « clé en main »
Docker est extrêmement simple à prendre en main !
Docker tombe pile au bon moment !

8. 8
L’application
clé en main !

9. 9
« Build, ship and run any app,
anywhere » *
Build
Packager une application et ses dépendances
dans un container
Ship Déplacer ce container d’une machine à une autre
Run Lancer le container, c.-à-d. l’application qu’il contient
Any App Tout ce qui peut tourner sous linux (aujourd’hui en tout cas)
Anywhere
que ce soit sur une VM local, du baremetal ou une instance de cloud
* slogan de docker.com

10. 10
Un container est une application
Une image docker est une et une seule application
avec ses dépendances de runtime
Ce n’est pas une VM !
Ce n’est même plus une light weight VM !
Et je fais comment
si je dois lancer
deux applications
?
Tu lances deux
containers !
On peut faire ça
avec une VM !
Oui, mais c’est un
peu overkill,
non ?

11. Docker Engine
Infrastructure
d’éxécution
Double abstraction du container
App 1 App 2 App 3

12. Machine virtuelle
Debian Red Hat Ubuntu Fedora
Bare metal
Windows
?
CoreOS
StandaloneCloud Cluster
Docker Engine
Double abstraction du container
Docker
App 1 App 2 App 3
PHP
Apache
Debian
Java
Tomcat
Fedora
C++
Red Hat

13. La distribution d’application sans
docker
Quelle est la
cible de mon
application ?
Code
Déploiement et Test !
.deb
Dépôt yum
Déploiement et Test !
.rpm
Dépôt debian
.egg
.phar
.jar
.npm
Dépôt nodejs
Readme
- Installer les librairies X v1.0, Y v2.1 & Z
v2.3
- N’est pas compatible avec les versions
antèrieures
Sur debian
- Installer les paquets A.deb, B.deb &
C.deb
- Configurer /etc/init.d/my_app
- Lancer service my_app start
Sur fedora,
- Installer les paquets A.rpm, B.rpm &
D.rpm
- Configurer
/usr/lib/systemd/my_app.service
- Lancer systemctl start abrtd.service
Dépôt maven
Dépôt php
Dépôt python
Allo le support ?
Je suis sous
gentoo !
Déploiement et Test !
Déploiement et Test !
Déploiement et Test !
Déploiement et Test !

14. On me remonte un bug.
Pourtant, ça marche sur ma
machine !
Le déploiement d’application sans
dockerMon
environnement
est-il supporté ?
Ai-je les bonnes
dépendances?
Y a-t-il des conflits
avec d’autres
applications déjà
installées ?
Je veux seulement tester une
appli : est-ce que ça vaut le
coup de passer tant de
temps au déploiement ? Je ne le
sens pas !
Si ça ne marche pas,
saurai-je revenir à
mon environnement
initial ?
Rhaaa !! Une
nouvelle manière de
déployer !

15. La distribution et le déploiement
d’application avec docker
Code
Dockerfile Registry
Readme
- docker pull my_app
- docker run my_app
Déploiement et Test !
build & push pull & run
Que doit
faire mon
application ?
L’application
répond elle à
mon besoin ?

16. Distribution et déploiement
Sans docker Avec docker
La construction et la validation de la distribution
doit prendre en compte l’environnement cible
La construction de la distribution s’abstrait de
l’environnement cible hormis la disponibilité du
daemon docker
Le développeur documente les procédures
d’installation de l’environnement
L’utilisateur installe l’application et les
dépendances tiers
Le développeur embarque les dépendances
tierces dans l’image
L’utilisateur doit préparer son plan de rollback
avant d’installer l’application (état des lieux)
L’utilisateur installe la version précédente de
l’image pour rollbacker
L’utilisateur doit gérer les conflits potentiels de
dépendances avec d’autres applications de son
environnement
Les dépendances sont embarquées dans l’image
L’utilisateur installe l’image

17. Les promesses de cette orientation
Productivité
Le développeur peut se concentrer sur l’application, et non la
plateforme cible
Qualité
L'image peut être dupliquée sans altération
d'une machine a une autre
Confiance
Autorise les ruptures technologiques
sans rupture de méthode de déploiement ou de rollback
“Marché” Le spectre des utilisateurs potentiels de l’application s’élargit

18. 18
C’est incroyablement simple à
prendre en main !
Ca ressemble à de
la gestion de
code…
C’est l’idée !
docker pull Récupère une image depuis un dépôt (appelé registry)
docker run Lance une instance de l’image (appelé container)
docker commit
Enregistre les modifications du container dans une nouvelle image
(modifications manuelles)
docker build
Construit une image docker à partir d’un fichier d’instructions (appelé
Dockerfile)
docker push Envoie l’image dans une registry afin de la partager

19. C’est simple !
En fait… non !
C’est bien joli tout ça,
mais ça doit être une
sacrée usine à gaz !

20. 20
On hérite du travail des autres
build & push
une image serveur_web
Registry privée
Dockerhub
Dockerfile
FROM socle
build
une appli_web_1
Dockerfile
FROM svr_web
Waouh !
Je n’ai qu’à
ajouter mon
code !
Dockerfile
FROM svr_web
build
une appli_web_2
Moi aussi !
Je n’ai à le
configurer
qu’une seule
fois !

21. Le container est à la fois immuable et
adaptableDEV
VM sur cloud Machine bare metal
PROD
/data_test
App V1
/logs
:8080
:8080
/data
App V2
/logs
:8080
:8082
/data
App:V1
EXPOSE 8080
VOLUME /data
VOLUME /logs$ docker run
-v /data_test:/data
app:v1
$ docker run
-p 80:8080
-v /opt/data:/data
-v /var/logs:/logs
app:v1
/opt/data /var/logs
App 1
:80
/logs
:8080
/data
Sonde
/logs
$ telnet localhost 8080 $ telnet www.prod 80

22. Partage des livrables
entre dev et ops
Les promesses de cette simplicité
Montée en compétences rapide
par dev comme par ops
Adoption très large
par dev comme par ops
Mutualisation des méthodes
entre dev et ops
DEV

23. Ça tombe pile au bon moment !

24. Docker est un facilitateur DevOps
Docker a été implémenté par une équipe DevOps
pour des utilisateurs DevOps
Construit le livrable final au plus tôt
donc réduit les écarts de dev à prod
Facilite l’automatisation

25. L’architecture en micro-services
Monolithique Micro-services
Orienté serveur Orienté composition d’applications

26. 26
Docker développe un
environnement d’orchestration…
• Docker Machine
– Permet de gérer des hôtes Docker (sur cloud ou cluster)
• Docker Compose
– Permet de définir une application composée de plusieurs
containers
• Docker Swarm
– Permet de gérer un cluster d’hôtes Docker

27. …mais vu de plus haut, c’est ouvert !
Ça foisonne !
Sans doute trop…

28. Alors ?
Justifié ou pas ?

29. 29
Y’a bien quelque chose
qui ne va pas…
Techniquement :
• Faiblesse sur la sécurité
– « disappoint when it comes to secure administration and management, and to
support for common controls for confidentiality, integrity and availability. »
Rapport Gartner
• Communication entre containers sur de multiples hôtes complexe
Victime de son succès !
• Profusion de solutions
– Difficulté de faire des choix pérennes
• On attend beaucoup de docker… trop !
– Comme remplacer complètement la virtualisation…
– Quelle direction va prendre docker inc. ?
Du coup, ils
rachètent une
startup réseau
Mais communauté
très active

30. 30
Y a-t-il une concurrence ?
Rocket (CoreOS) – décembre 2014
actuellement v.0.4.1
Orienté briques et linux
LXC (consortium GNU) – août 2008
actuellement v1.1.2
L’historique. Canonical développe un outil de gestion des
LXC : LXD.
NON !

31. Le buzz est-il justifié ?
OUI !
Parce que le container Docker
 est orienté application « clé en main »
– Ça facilite la distribution et le déploiement des applications
– Ça complète l’offre de virtualisation plus que ça ne la concurrence
 est extrêmement simple à prendre en main !
– Que l’on vienne du dev ou de la prod
 tombe pile au bon moment !
– Ça s’inscrit dans la mouvance DevOps
– Les applications sont de plus en plus distribuées

32. 32
Nos cas d’utilisation
• Applications stateless destinées de la production
– Gain sur déploiement et rollback
– Faciliter l’A/B testing
– Mutualiser les machines « bare metal »
• Instances à la demande d’outils d’intégration continue par
équipe plutôt qu’un serveur centralisé
– Montage d’équipes DevOps
– jenkins, chef, registry
• Images de build (compilation, TU, packaging) partagées entre
développeurs et serveurs d’intégration continue
– Partage et maintenance
– Mise en place environnement nouvel arrivant

33. 33
Questions?