REx DevOps & Docker
Stabilisation, Productivité, Adaptabilité
2
RELEASE
MANAGEMENT
INTÉGRATION CONTINUE
LIVRAISON CONTINUE
INFRASTRUCTURE AS A...
3
Une évolution naturelle
vers Docker liée à des contraintes
budgétaires
4
LXC - 2014
--------------------------------------...
Ce que rajoute docker par rapport à LXC
5
Centré application !1 Un dépôt centralisé 2
Des couches versionnées
réutilisable...
Pour quel usage ?
6
Configuration
identique
à tout « stage »
Debug de la
production
Applications
cloisonnées
Déploiement e...
La stratégie choisie, étape 1 : conteneuriser simplement
Conteneuriser des applications « stateless » 1 pour 1
Typiquement...
docker
proxy
La stratégie choisie, étape 2 : mutualiser les hôtes
Plusieurs niveaux applicatifs sur des hôtes mutualisés
(...
La stratégie choisie, étape 3 : dynamiser l’infra hôte
9
docker docker
NETWORK
IP? IP? IP?
Interconnexion de conteneurs
su...
Idéalement Docker s’accompagne d’une démarche IaaS / PaaS
10
Service réseau (interfaces, flux, sécurité, …)
Service monito...
Le marché
11
Docker (Docker) – mars 2013
actuellement v1.4.1
Largement adopté par la communauté (Google, MS, …)
Se dirige ...
• C’est incroyablement simple !
• Package une application et son
environnement de run (gestion des
dépendances)
• Ne laiss...
13
Questions?
Prochain SlideShare
Chargement dans…5
×

REX Devops Docker

345 vues

Publié le

Retour d'expérience de l'utilisation de docker et de ses avantages dans un environnement Bare Metal

Publié dans : Technologie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
345
Sur SlideShare
0
Issues des intégrations
0
Intégrations
12
Actions
Partages
0
Téléchargements
9
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

REX Devops Docker

  1. 1. REx DevOps & Docker
  2. 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É
  3. 3. 3
  4. 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. 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. 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. 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. 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. 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. 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. 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. 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 ?
  13. 13. 13 Questions?

×