DOCKER, PIERRE ANGULAIRE DU CONTINUOUS DELIVERY ?
-UNE EXPÉRIENCE DEVOPS
DevOps coach & Infra. product ownerSociété Géné[email protected]@adrienblind
202/05/2023
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
302/05/2023
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
402/05/2023
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-jre8MAINTAINER adrienADD gameoflife.war /usr/local/tomcat/webapps/EXPOSE 8080CMD ["catalina.sh", "run"]
Le DockerFile de MyApplication:
Les Devs et les Ops partagent un même “vocabulaire”et un même écosystème
@adrienblind
502/05/2023
PIPELINE CONTINUOUS DELIVERY
Registry
Récupèrer l’imagesous-jacente
RHEL 6.7 (OPS/system owned)
JAVA 1.8 (OPS/middleware owned)
APP x.y (APP team owned)
0cIntégrer dans une nouvelle
image docker et tester !
0b
Récupèrele code
0a
@adrienblind
602/05/2023
PIPELINE CONTINUOUS DELIVERY
001101010011010110110101111101110101111010011
Registry
CD platform
1
Récupèrer l’imagesous-jacente
RHEL 6.7 (OPS/system owned)
JAVA 1.8 (OPS/middleware owned)
APP x.y (APP team owned)
2bIntégrer dans une nouvelle
image docker
2cRenvoyer 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
702/05/2023
PIPELINE CONTINUOUS DELIVERY
001101010011010110110101111101110101111010011
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
3bPull APP image
D
U U
P
P
@adrienblind
802/05/2023
PIPELINE CONTINUOUS DELIVERY
001101010011010110110101111101110101111010011
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
3bPull APP image
D
U U
P
P
@adrienblind
902/05/2023
PIPELINE CONTINUOUS DELIVERY
001101010011010110110101111101110101111010011
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
3bPull APP image
D
U U
P
P
One (versionned) artifact to rule them all !
@adrienblind
1002/05/2023
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-deployedup to DEV + click to
promote to UAT
Click to promote to prod
Corresponding git commit hash
@adrienblind
1102/05/2023
TECHNOLOGIES UTILISÉES
Nous avons bâti un PoC qui reposait principalement sur :● Github on premises● Jenkins
Delivery Pipeline pluginCloudbees 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
1202/05/2023
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
1302/05/2023
DU CONTENEUR À L’APPLICATION
‘’Docker est passé du conteneur universel à une topologie d’infra. applicative orientée objet’’
ApplicationExé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
1402/05/2023
Host file system Host file system
‘’Mais jusqu’il y a peu, la résilience du stockage reposaitencore 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 immuableset donc de sortir la donnée du conteneur applicatif...’’
@adrienblind
1502/05/2023
Host file system
Container
Volume
‘’Le conteneur peut devenir un avatar permettant de déléguer la gestion du stockage’’
VOLUMES DOCKER
@adrienblind
1602/05/2023
Host Host Host Host
SDN
sSDN 1
SDN 2
SDN 3
RÉSEAUX APPLICATIFS
‘’Le réseau est devenu une problématique applicative’’
@adrienblind
1702/05/2023
Chaque application devient une bulle autonome
RÉSEAUX APPLICATIFS
@adrienblind
1802/05/2023
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
1902/05/2023
« 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çonadaptée pour faire du continuous delivery »
ORGANISATION
@adrienblind
2002/05/2023
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
2102/05/2023
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
2202/05/2023
CONCLUSION
Docker facilite le continuous deliveryDes propriétés du conteneur idoines (granularité fine, versionnable, immuable…)Un écosystème docker programmatique facilement interconnectableL’universalité du conteneur facilite le continuous delivery pour différents écosystèmes
Docker est passé à un modèle objetLa 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