REX Devops Docker
-
Upload
romain-chalumeau -
Category
Technology
-
view
151 -
download
0
Transcript of REX Devops Docker
REx DevOps & Docker
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É
3
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
Ce que rajoute docker par rapport à LXC
5
Centré application !1 Un dépôt centralisé 2
Des couches versionnées
réutilisables3
Séparation de l‘application
et des données4
deploydocker run
Img1
Img2
Registrybuild
docker build
docker commit
DMLOS1
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
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é
La stratégie choisie, étape 1 : conteneuriser simplement
Conteneuriser des applications « stateless » 1 pour 1Typiquement 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
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 !
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
DataGestion de conteneurs de données
docker
Idéalement Docker s’accompagne d’une démarche IaaS / PaaS
10
Service réseau (interfaces, flux, sécurité, …)
Service monitoring (stages, capacité, permanence, …)
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.
• 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 ?
13
Questions?