docker le buzz est il justifié ?
TRANSCRIPT
#docker
Romain Chalumeau – Altran - 22 mai 2015
Le buzz est-il justifié ?
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
Docker, c’est quoi ?
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
…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
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
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
L’application clé en main !
9
« Build, ship and run any app, anywhere » *
BuildPackager 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)
Anywhereque ce soit sur une VM local, du baremetal ou une instance de cloud
* slogan de docker.com
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 ?
Docker Engine
Infrastructure d’éxécution
Double abstraction du container
UN CONTAINER EST
AGNOSTIQUE DE SON
CONTENU
COMME DE SON
TRANSPORTEUR
App 1 App 2 App 3
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
CONTRAINTES DE L’HÔTE :
- CPU 64BITS
- LINUX KERNEL > 3.10
La distribution d’application sans dockerQuelle 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
.npmDé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 !
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 !
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 ?
pull & run
pull & run
Distribution et déploiementSans 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
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
ConfianceAutorise 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
Intégration
continue
Debug
Abstraction
du contenu
Abstraction
de la cible
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 commitEnregistre les modifications du container dans une nouvelle image (modifications manuelles)
docker buildConstruit une image docker à partir d’un fichier d’instructions (appelé Dockerfile)
docker push Envoie l’image dans une registry afin de la partager
C’est simple !
En fait… non !C’est bien joli tout ça, mais ça doit être une sacrée usine à gaz !
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 !
Le container est à la fois immuable et adaptable
DEV
VM sur cloud Machine bare metal
PROD
/data_test
App V1
/logs
:8080
:8080
/data
App V2
/logs
:8080
:8082
/data
App:V1
EXPOSE 8080VOLUME /dataVOLUME /logs $ docker run
-v /data_test:/dataapp:v1
$ docker run -p 80:8080-v /opt/data:/data-v /var/logs:/logsapp:v1
/opt/data /var/logs
App 1
:80
/logs
:8080/data
Sonde
/logs
$ telnet localhost 8080 $ telnet www.prod 80
Partage des livrablesentre 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
DEVOPS
Ça tombe pile au bon moment !
Docker est un facilitateur DevOpsDEVOPS
Docker a été implémenté par une équipe DevOps
pour des utilisateurs DevOps
Construit le livrable final au plus tôtdonc réduit les écarts de dev à prod
Facilite l’automatisation
L’architecture en micro-services
Monolithique Micro-services
Orienté serveur Orienté composition d’applications
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
…mais vu de plus haut, c’est ouvert !
Ça foisonne !Sans doute trop…
Alors ?Justifié ou pas ?
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
Y a-t-il une concurrence ?
Rocket (CoreOS) – décembre 2014 actuellement v.0.4.1Orienté briques et linux
LXC (consortium GNU) – août 2008 actuellement v1.1.2L’historique. Canonical développe un outil de gestion des LXC : LXD.
NON !
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
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
Questions?