Paris Container Day 2016 : Conteneurisation de l’usine logicielle (Retour d'expérience Xebia & Libon)

@ContainerDay16 @jlrigau @fthouny

Conteneurisation del'usine logicielleRetour d’expérience du projet Libon d’Orange Vallée

@ContainerDay16

@ContainerDay16

Jean-Louis RIGAU@jlrigau

Continuous Delivery, DevOps and Docker@ Xebia IT Architects

Fabien THOUNY@fthouny

Craftsmanship, Agile, Tech Lead@ Libon


Appeler...

● Appels VoIP (app to app) gratuits

● Appels VoIP-Out à prix réduits vers plus de 140 destinations


Envoyer des messages...

● Chat utilisant le protocole XMPP

● Échange de fichiers


Simplement !

● Multi-plateforme○ Android○ iPhone○ Web HTML5

● Synchronisées grâce à des API REST

@ContainerDay16

Il était une fois,il y a fort longtemps...


build1

Instance unique de Jenkins


● Mises à jour OS● Librairies systèmes● Versions de SDK

○ JDK 1.7/1.8

● Mutualisation des services○ Cassandra, Oracle, MySQL

● Ressources de la machine● Risque de défaillance

Difficultés multiples


build1

Gestion des besoins spécifiques

build2

slave


● 2 machines○ l’une surchargée○ l’autre sous-utilisée

● Versions OS différentes○ Écart entre les packages○ Davantage de maintenance

Toujours plus de complexité !

@ContainerDay16

Et vint le temps de la révolution...


Construire, transporter et exécuter tout type d’application sur tout type de plate-

forme

Opérer ses applications au sein de son Data Center comme s’il s’agissait d’une

ressource unique

Boîte à Outils 1/2

Déployer et orchestrer ses conteneurs au sein d’un cluster Mesos à l'échelle


Boîte à Outils 2/2

Configuration automatique de HAProxy et Découverte de Service pour Mesos

Marathon

Open-source TCP/HTTP load-balancing proxy server

Bamboo


Architecture du Cluster


Framework Marathon


build1 build2 buildfiler1

Mise en Cluster de la CI

Bamboo Bamboo Bamboo


● Gestion des images Docker○ Stockage○ Distribution

● Déploiement○ Image officielle sur le Docker Hub○ Utilisation de Marathon

● Sécurité ○ Authentification LDAP○ TLS

Docker Registry



Déploiement de la Registry



Configuration d’un Service

● Configuration au format JSON○ Image○ Volume, Mapping de ports○ Ressources○ Contraintes○ Health Check

● Déploiement avec l’API REST de Marathon

● Utilisation des images officielles○ Disponible sur le Hub



Déploiement des Services


API Docs

Slack BotZk UI Version

Board


Framework Jenkins Scheduler


● Création d’images de “Build”○ Héritant de l’image “build-tools”○ Une image Docker par runtime

● Utilisation du Jenkins Mesos plugin○ 1 slave = 1 image Docker○ Utilisation des labels dans les jobs

● Slave à la demande○ Création de tâches Mesos○ Nettoyage automatique

Création des slaves



Jenkins Slaves conteneurisés


API Docs

Slack BotZk UI Version

Board


● Binaire développé en Go○ Inclut dans les images de build○ Disponible sur le poste de DEV et sur l’environnement de CI

● Mêmes outils en CI et sur le poste de développement

Binaire “build-machine”


DEMOConstruction et déploiement d’une application

@ContainerDay16

Place à l’industrialisation de la plateforme...


Spécialisation de l’infrastructure

● Séparation Master / Slave○ Extraction du master vers une VM○ Conservation des machines physiques pour les slaves

● Réorganisation des modules Puppet○ 2 profils master et slave


build1 build2 buildfiler1 buildfiler2 buildfiler3 buildfiler4

Bamboo Bamboo Bamboo Bamboo Bamboo Bamboo

buildmaster1

Séparation Master / Slave

API Docs

Slack Bot

Version BoardZk UI


● 2 types de données○ Cache (Docker, Maven, NPM, Gradle, etc.)○ Données persistantes (Registry, Jenkins, Sonar, Nexus, Dashboard, etc.)

● Mise en place de GlusterFS○ Mutualisation des capacités de stockage des noeuds du cluster○ Volume répliqué et distribué (~ 1,6 To disponible au final)

● Création d’un point de montage “/shared”○ Accessible sur chacun des noeuds du cluster

Gestion des Données


build1 build2 buildfiler1 buildfiler2 buildfiler3

Distributed Replicated GlusterFS Volume

buildfiler4


buildmaster1

CI entièrement conteneurisée !

API Docs

Slack Bot

Zk UI Version Board


Performances de la Registry

● Registry : point faible de l’architecture○ Ajout d’une deuxième instance en cluster

● Le Docker Hub peut être lent○ Mise en place d’un cluster de miroirs

● Boucle sur Internet pour accéder à la registry○ Ajout d’une entrée dans le /etc/hosts de chacun des noeuds


build1 build2 buildfiler1 buildfiler2 buildfiler3

Distributed Replicated GlusterFS Volume

buildfiler4


buildmaster1

Registry en Haute Disponibilité

API Docs

Slack Bot

Version BoardZk UI

mirror

mirror


● Mise en place d’un système de gestion de droits sur la Registry○ PoC de Portus en cours

● Utilisation des images officielles pour nos builds○ Exploration de Jenkins 2.x et du Plugin Pipeline

● Élimination des dernières faiblesses de l’architecture○ Master à mettre en cluster

● Emmener les conteneurs jusqu’en Production !○ En s’appuyant sur l’expérience acquise sur la CI

Quelles évolutions ?


Q&A

Technology

Paris Container Day 2016 : Conteneurisation de l’usine logicielle (Retour d'expérience Xebia & Libon)