REX Devops Docker

1 183 vues

Publié le

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

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

Aucun téléchargement
Vues
Nombre de vues
1 183
Sur SlideShare
0
Issues des intégrations
0
Intégrations
7
Actions
Partages
0
Téléchargements
38
Commentaires
0
J’aime
1
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?

×