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.
Docker networking basics & coupling with Software Defined Networks
Docker, Pierre angulaire 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
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