2. Stabilisation, Productivité, Adaptabilité
2
RELEASE
MANAGEMENT
INTÉGRATION CONTINUE
LIVRAISON CONTINUE
INFRASTRUCTURE AS A CODE
ORGANISATION PLUS AGILE
FEATURE BRANCHING
STABILISATIO
N
PRODUCTIVIT
É
ADAPTABILITÉ
DÉPLOIEMENT CONTINU
SCALABILITÉ DYNAMIQUE (CLOUD)
FULL DEVOPS
STABILISATIO
N
PRODUCTIVIT
É
ADAPTABILITÉ
4. Une évolution naturelle
vers Docker liée à des contraintes
budgétaires
4
LXC - 2014
------------------------------------------------------
Quoi ? Virtualisation de
l’environnement
Pourquoi ? Pour simuler des
environnements interconnectés
Exemple : Simulation de bus pour
multiple applications
Docker - 2015
---------------------------------------------
Quoi ? Meta-package d’une
application et son
environnement
Pourquoi ? C’est tout l’objet de
cette présentation !
Cgroups - 2013
---------------------------------------------------------------------------
Quoi ? Isolation de l’utilisation des ressources
système par les process.
Pourquoi ? Mutualiser les hôtes en cloisonnant les
ressources des applications.
Exemple : indexation asynchrone + serveur web
5. Ce que rajoute docker par rapport à LXC
5
Centré application !1 Un dépôt centralisé 2
Des couches versionnées
réutilisables
3
Séparation de l‘application
et des données
4
deploy
docker run
Img1
Img2
Registry
build
docker build
docker commit
DML
OS1
Apache
PH
P
Tomcat
Jar
s
OS3
PHP
Apache
conf
OS1
Jars
Tomcat
conf
OS2
conf conf
Machine QUAL Machine PROD
IMG IMGData
Qual
Data
Prod
identiqueUbuntu
Apache
PHP 1
Docker
file
Tomcat
PHP 2 App 3
Patch Sécu
6. Pour quel usage ?
6
Configuration
identique
à tout « stage »
Debug de la
production
Applications
cloisonnées
Déploiement et
rollback facilités
Multiples versions,
A/B testing, …
Développement
orienté production
Scalabilité
7. La stratégie choisie, étape 1 : conteneuriser simplement
Conteneuriser des applications « stateless » 1 pour 1
Typiquement les serveurs Apache + PHP (sans DB)
7
80 443
Ubuntu
Code PHP
Conf
Apache
/logs
Gains :
- Performance préservée
- déploiement & rollback instantanés (container actif / passif)
- debug de la production sur machine de développement
80 443
Ubuntu
/logs
docker
80 443
Code PHP
Conf
Apache
Ubuntu /logs
8. docker
proxy
La stratégie choisie, étape 2 : mutualiser les hôtes
Plusieurs niveaux applicatifs sur des hôtes mutualisés
(UAT, A/B testing, … )
8
/logs/
prod
Prod Recette
/logs/
recette
www…/prod www…/rec
80 80
80818080
Contraintes :
- Revoir les mécanismes de supervision
Supervision
de prod
Supervision
de recette
Paging !
9. La stratégie choisie, étape 3 : dynamiser l’infra hôte
9
docker docker
NETWORK
IP? IP? IP?
Interconnexion de conteneurs
sur de multiples hôtes
App
docker
App
Data
Data
Gestion de conteneurs
de données
docker
10. Idéalement Docker s’accompagne d’une démarche IaaS / PaaS
10
Service réseau (interfaces, flux, sécurité, …)
Service monitoring (stages, capacité, permanence, …)
11. Le marché
11
Docker (Docker) – mars 2013
actuellement v1.4.1
Largement adopté par la communauté (Google, MS, …)
Se dirige vers une solution complète, tout
environnement (linux, windows)
Rocket (CoreOS) – décembre 2014
actuellement v.0.2
Orienté briques et linux
Manta (Joyent) – opensourcé en novembre 2014
Container de données
LXC (consortium GNU) – août 2008
actuellement v1.0.7
L’historique. Canonical développe un outil de gestion des
LXC : LXD.
12. • C’est incroyablement simple !
• Package une application et son
environnement de run (gestion des
dépendances)
• Ne laisse quasi-aucune empreinte machine
(pas d’hyperviseur)
• Est rapide à instancier
• Respecte le principe de DML (versions dans la
registry)
• Sépare déploiement et mise en service
• Limite les variations entre les stages fiabilisant
les tests
• Ouvert à Windows
• Est jeune !
• Peu de retours d’expériences sur des
infras importantes,
• Particulièrement au niveau sécurité
• Profite d’un effet buzz, et génère une
profusion d’outils périphériques… Difficile de
s’y retrouver
• Est un véritable outil DevOps
• Permet des prototypages aisés
• Oriente l’architecture vers :
• les micro-services
• la séparation app / data
• Facilite la mutualisation sur « bare metal »
(gain CAPEX)
• Clarifie les responsabilités :
• entre construction du service et
déploiement
• entre le cycle de vie logiciel et le cycle
de vie système
• Complexifier l’inventaire des composants
utilisés (effet boite noire):
• Audit sécurité
• Analyse des impacts d’un composant
• Etre tenté de se passer d’une chaine de build
(changements manuels et « commités »)
• Docker devient une plateforme monolithique
plus qu’un container (vs Rocket) –
dépendance ?