Docker est présenté comme un outil clé pour le continuous delivery, permettant une plus grande vélocité et qualité dans la livraison des produits. Le document couvre divers aspects du développement et déploiement d'applications avec Docker, y compris la gestion de l'infrastructure et l'architecture applicative pour optimiser ce processus. Il souligne l'importance de la culture DevOps et de l'intégration des équipes pour réussir la mise en œuvre du continuous delivery.

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 1716/02/2016
Chaque application devient une bulle autonome
RÉSEAUX APPLICATIFS
@adrienblind

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. 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. 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. 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. 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