Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare une entreprise Scribd logo

REX Devops Docker

•Télécharger en tant que PPTX, PDF•
•
Romain Chalumeau
Romain Chalumeau

Retour d'expérience sur docker dans un environnement Bare Metal

Diaporamas connexes

CI, CD, pipelines, conteneurs : la cohabitation est elle possible ?
CI, CD, pipelines, conteneurs : la cohabitation est elle possible ?CI, CD, pipelines, conteneurs : la cohabitation est elle possible ?
CI, CD, pipelines, conteneurs : la cohabitation est elle possible ?
 
Présentation Docker
Présentation DockerPrésentation Docker
Présentation Docker
 
Des principes de la démarche DevOps à sa mise en oeuvre
Des principes de la démarche DevOps à sa mise en oeuvreDes principes de la démarche DevOps à sa mise en oeuvre
Des principes de la démarche DevOps à sa mise en oeuvre
 
1  sur  13
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é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
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 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
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 Data Gestion 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?

Contenu connexe

REX Devops Docker

  • 1. REx DevOps & Docker
  • 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
  • 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 ?