Ce diaporama a bien été signalé.
Le téléchargement de votre SlideShare est en cours. ×

Docker, Pierre angulaire du continuous delivery ?

Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Prochain SlideShare
REX Devops Docker
REX Devops Docker
Chargement dans…3
×

Consultez-les par la suite

1 sur 22 Publicité

Docker, Pierre angulaire du continuous delivery ?

Télécharger pour lire hors ligne

This presentation explores continuous delivery principles leveraging on Docker : it depicts the use of Docker containers as universal application artifacts, delivered flowly all along a deployment pipeline.

This slideshow has been initially presented at Devops D-Day conference, Marseille.

This presentation explores continuous delivery principles leveraging on Docker : it depicts the use of Docker containers as universal application artifacts, delivered flowly all along a deployment pipeline.

This slideshow has been initially presented at Devops D-Day conference, Marseille.

Publicité
Publicité

Plus De Contenu Connexe

Diaporamas pour vous (20)

Les utilisateurs ont également aimé (20)

Publicité

Similaire à Docker, Pierre angulaire du continuous delivery ? (20)

Publicité

Plus récents (20)

Docker, Pierre angulaire du continuous delivery ?

  1. 1. DOCKER, PIERRE ANGULAIRE DU CONTINUOUS DELIVERY ? - UNE EXPÉRIENCE DEVOPS DevOps coach & Infra. product owner Société Générale adrien.blind@sgcib.com @adrienblind
  2. 2. 216/02/2016 LE CHALLENGE DU CONTINUOUS DELIVERY Promouvoir une démarche agile et automatisée jusqu’à la production pour améliorer la vélocité et la qualité des produits livrés De nouveaux challenges apparaissent (non exhaustif !) ● Réconcilier le cycle de vie des apps et de leurs infra. : penser produit ● Accroitre l’autonomie des équipes applicatives ● … tout en augmentant le besoin d’interactions avec des Ops Des éléments de solutions émergent à différents niveaux ● Organisationnel : Culture DevOps, avénement des feature-teams... ● Architecture applicative : micro-services, loose-coupling, stateless, APIs versionnées… ● Infrastructure : services cloud de plus en plus riches, infrastructure-as-code Code développé Tests unitaires Intégration Tests d’accept. Mise en prod Exécution @adrienblind
  3. 3. 316/02/2016 LE PARADIGME DU CONTENEUR « Un artefact universel, autosuffisant et standard, contenant un module applicatif et sa configuration d’infrastructure sous-jacente »  Docker fournit à la fois le conteneur et l’écosystème pour l’opérer Immuable Versionné LégerPortable Jetable Programmatique Social Incrémental @adrienblind
  4. 4. 416/02/2016 POUPÉES RUSSES  Un catalogue d’images de base ● Les Ops de l’entreprise et la communautée proposent des bases système élémentaires ● Qu’ils utilisent pour proposer des produits finis directement utilisables (ex. Une instance REDIS) ● Ou que les DEVs enrichissent pour construire leur propre application RHEL 7.0 (OPs) Tomcat8 + Java1.8 (OPs) MyApplication x.y (DEV) FROM tomcat:8-jre8 MAINTAINER adrien ADD gameoflife.war /usr/local/tomcat/webapps/ EXPOSE 8080 CMD ["catalina.sh", "run"] Le DockerFile de MyApplication:  Les Devs et les Ops partagent un même “vocabulaire” et un même écosystème @adrienblind
  5. 5. 516/02/2016 PIPELINE CONTINUOUS DELIVERY Registry Récupèrer l’image sous-jacente RHEL 6.7 (OPS/system owned) JAVA 1.8 (OPS/middleware owned) APP x.y (APP team owned) 0c Intégrer dans une nouvelle image docker et tester ! 0b Récupère le code 0a @adrienblind
  6. 6. 616/02/2016 PIPELINE CONTINUOUS DELIVERY 0011010100110 1011011010111 1101110101111 010011 Registry CD platform 1 Récupèrer l’image sous-jacente RHEL 6.7 (OPS/system owned) JAVA 1.8 (OPS/middleware owned) APP x.y (APP team owned) 2b Intégrer dans une nouvelle image docker 2c Renvoyer le nouvel artefact dans la registry On instancie un pipeline à chaque changement de code: 2a Git commit du code ou du dockerfile Build Deploy DEV Deploy UAT Deploy PRD @adrienblind
  7. 7. 716/02/2016 PIPELINE CONTINUOUS DELIVERY 0011010100110 1011011010111 1101110101111 010011 Registry CD platform RHEL 6.7 (OPS/system owned) JAVA 1.8 (OPS/middleware owned) APP x.y (APP team owned) On instancie un pipeline à chaque changement de code: Build Deploy DEV Deploy UAT Deploy PRD Cluster docker 3a Retirer l’ancienne version et ordonner le déploiement d’une nouvelle version 3b Pull APP image D U U P P @adrienblind
  8. 8. 816/02/2016 PIPELINE CONTINUOUS DELIVERY 0011010100110 1011011010111 1101110101111 010011 Registry CD platform RHEL 6.7 (OPS/system owned) JAVA 1.8 (OPS/middleware owned) APP x.y (APP team owned) On instancie un pipeline à chaque changement de code: Build Deploy DEV Deploy UAT Deploy PRD Cluster docker 3a Retirer l’ancienne version et ordonner le déploiement d’une nouvelle version 3b Pull APP image D U U P P @adrienblind
  9. 9. 916/02/2016 PIPELINE CONTINUOUS DELIVERY 0011010100110 1011011010111 1101110101111 010011 Registry CD platform RHEL 6.7 (OPS/system owned) JAVA 1.8 (OPS/middleware owned) APP x.y (APP team owned) On instancie un pipeline à chaque changement de code: Build Deploy DEV Deploy UAT Deploy PRD Cluster docker 3a Retirer l’ancienne version et ordonner le déploiement d’une nouvelle version 3b Pull APP image D U U P P One (versionned) artifact to rule them all ! @adrienblind
  10. 10. 1016/02/2016 JENKINS PIPELINE VIEW 1 pipeline instantiated automatically at each git commit: ●Version N is on DEV ●Version N-1 is on UAT ●Version N-2 is on PROD Auto-deployed up to DEV + click to promote to UAT Click to promote to prod Corresponding git commit hash @adrienblind
  11. 11. 1116/02/2016 TECHNOLOGIES UTILISÉES Nous avons bâti un PoC qui reposait principalement sur : ● Github on premises ● Jenkins Delivery Pipeline plugin Cloudbees plugin pour Docker (surtout pour build & push) ● Une plateforme d’exécution Docker SWARM hybride et une registry Et pour aller plus loin... ● Explorer une démarche plus intégrée et industrialisée : UCP ? DTR ? Vendor solutions ? @adrienblind
  12. 12. 1216/02/2016 IMPORTANCE DE L’ARCHITECTURE APPLICATIVE Une architecture applicative adaptée facilite le déploiement continu ● Ex. Zero Downtime Deployment en faisant du déploiement par roulement des conteneurs d’une même ferme ● Patterns loose coupling, multi versioned, stateless, etc. @adrienblind
  13. 13. 1316/02/2016 DU CONTENEUR À L’APPLICATION ‘’Docker est passé du conteneur universel à une topologie d’infra. applicative orientée objet’’ Application Exécution (Run containers) Stockage (Volumes) Transport (Network) Topologie (Compose) ‘’... reposant sur une plateforme d’exécution’’ Plateforme de CaaS • Composants élémentaires : engine, swarm, machine, registry • Plateforme Docker : HUB/Tutum (cloud), DTR/UCP (on premises) • Plateformes tierces : topologie non-docker, quid du support des volumes, des réseaux ? @adrienblind
  14. 14. 1416/02/2016 Host file system Host file system ‘’Mais jusqu’il y a peu, la résilience du stockage reposait encore sur le système hôte, et la démarche n’était donc pas élastique’’ VOLUMES DOCKER ‘’Le continuous delivery requiert de créer des conteneurs immuables et donc de sortir la donnée du conteneur applicatif...’’ @adrienblind
  15. 15. 1516/02/2016 Host file system Container Volume ‘’Le conteneur peut devenir un avatar permettant de déléguer la gestion du stockage’’ VOLUMES DOCKER @adrienblind
  16. 16. 1616/02/2016 Host Host Host Host SDNs SDN 1 SDN 2 SDN 3 RÉSEAUX APPLICATIFS ‘’Le réseau est devenu une problématique applicative’’ @adrienblind
  17. 17. 1716/02/2016 Chaque application devient une bulle autonome RÉSEAUX APPLICATIFS @adrienblind
  18. 18. 1816/02/2016 CONTINUOUS DELIVERY DE TOPOLGIES ? Dans certains cas, on ne délivre donc plus tant un artefact unique qu’une topologie complète ! ●Même un micro-service peut être composé de plusieurs briques ●Dans l’expérimentation nous avons simplement piloté une topologie docker-compose avec Jenkins @adrienblind
  19. 19. 1916/02/2016 « Organizations which design systems... are constrained to produce designs which are copies of the communication structures of these organizations ». - M. Conway, 1968 « Organisez-vous opérationnellement de façon adaptée pour faire du continuous delivery » ORGANISATION @adrienblind
  20. 20. 2016/02/2016 REDISTRIBUTION DES CARTES DEVOPS Equipes applicatives focalisées sur le contenu  Ne se préoccupe pas de la façon d’opérer des conteneurs  Sait comment construire des conteneurs et opérer des applications  DevOps “You build it, you run it!” Services cloud focalisés sur l’aspect extérieur  Ignore la façon dont sont construites les images  Sait comment opérer de grandes quantités de conteneurs  DevOps @adrienblind
  21. 21. 2116/02/2016 CA PAAS OU CA CAAS ? IaaSCapacité (VM, Stockage, réseau…) PaaSApplication (code) CaaSConteneur Legacy Le CaaS facilite notamment l’accès au cloud des applications “legacy” La topologie d’une application peut tout à la fois reposer sur des composants CaaS/PaaS/IaaS @adrienblind
  22. 22. 2216/02/2016 CONCLUSION Docker facilite le continuous delivery Des propriétés du conteneur idoines (granularité fine, versionnable, immuable…) Un écosystème docker programmatique facilement interconnectable L’universalité du conteneur facilite le continuous delivery pour différents écosystèmes Docker est passé à un modèle objet La topologie et l’orchestration sont des sujets de plus en plus importants Au delà de la technologie, Docker est un outil “DevOps” Favorise l’autonomie des équipes applicatives portant l’ensemble d’un produit @adrienblind

×