Présentation au salon du libre de Montréal en Septembre 2016

1. Livraison en Continue, avec l’outillage Devops
(Jenkins, Docker, Ansible et Nexus)
et Architectures Microservices
Karim Djaafar
Tech Leader of

2. Agenda
• Qui suis je ?
• Les bases de Devops et Notion de Livraison en Continue (Continuous
Delivery)
• Ingrédients d’un processus SDLC
• Configuration logicielle et Automatisation
• Conteneurs et MicroServices dans un processus Devops
• Refactoring d’une application monolithique JEE vers une architecture
microservices
• Une démo pour terminer …

3. Qui suis je ?
• Architecte et Team leader de la Société de Conseil en ingénierie libre
Jasmine Conseil
• Auteur de nombreux ouvrages parus chez Eyrolles et d’Articles autour
de l’IDE Eclipse et JBoss
• De nombreux projets menés autour de divers serveurs JEE
(JBoss/Wildfly, WebSphere, TomEE…)
• Actuellement en charge du projet Devops et de l’industrialisation des
environnements de recette et de déploiement au sein de l’equipe
Expertise et support middleware d’EDF (France)

4. Les bases de Devops et Continuous
Integration vs Continuous Delivery

5. Continuous Delivery
• Devops suppose un outillage compatible SDLC (Software
Development Life Cycle) qui le supporte
Développeur ClientBuild Test release
SDLC

6. CI (Continous Integration) vs CD (Continuous
Delivery)
• Un processus CI s’assure que le livrable est stable et fonctionnel grâce
a l’utilisation des tests automatises du code de l’application
• Livraison dans des cycles court des évolutions et une remontée rapide
en cas de problèmes via des notifications aux développeurs
concernés
• Un processus CD est un processus beaucoup plus large qui va au delà
du code et englobe tout l’environnement nécessaire pour que
l’application fonctionne (OS, réseau, serveur d’application, BD …)

7. Processus CD (Continuous Delivery): les étapes
Développeur Développeur
Référentiel
de code
L’outil de CI
surveille le
code du dépôt
et lorsqu’un
changement
est détecté
lance les
étapes du
pipeline
Le pipeline exécute
différentes taches au sein
du goal et vérifie que le
code fonctionne comme
requis.
Les développeurs
commitent leur code sur
la branche principale ou
sur la branche features.
Plus tard les features de la
branche seront fusionnees
a la branche principale
Si une des étapes
échoue, le processus est
avorté et une notification
d’échec est envoyé au
développeur qui a
effectue le commit
Si l’intégralité du pipeline s’execute
sans échec, le commit est promu a
une release candidate qui nécessitera
des vérifications complémentaires
manuelles
Promotion Notification d’échec

8. Devops c’est quoi ?
• Dev : « Ca fonctionne chez moi ! »
• Ops : « C’est pas le serveur c’est le code ! »

9. Devops: réconcilier les développeurs et les
opérationnels de l’infrastructure
• Un état d’esprit, une culture qui
va plus loin que les outils
• Complémente la démarche Agile
plus axe sur les devs
• Réduire le gap entre les
développeurs d’applications et
les opérationnels en charge de
l’infrastructure et des
déploiement

10. Avantages
• Short Time to Market
• Les livraisons sont plus rapides, plus stables
• Meilleure collaboration entre les équipes de développement et les
opérationnels et le personnel en charge de la maintenance et du
déploiement opérationnel
• Meilleure intégration et prise en compte des évolutions fonctionnelles
voulues par le client
• Organisation optimisée

11. Les ingrédients d’un processus
SDLC

12. Les outils devops
• Cloud Computing et PAAS (AWS, OpenShift,…)
• Gestionnaire de version a la base d’un processus CI (Github ou
Bitbucket)
• Infrastructure de “code”: Ansible ou Puppet pour la gestion des
serveurs centralisee
• Build/Test et CI: Jenkins
• Architecture conteneurisee (Docker) vs Virtualisee (VirtualBox)
• Microservices (voir plus loin)

13. L’outillage Devops et SDLC
Docker compose

14. Configuration logicielle et
Automatisation

15. Provisioning vs Gestion de la configuration
Application Déploiement (installation et
Configuration du logiciel et de
l’applicatif dans la machine
provisionnée
Serveur Physique
Hyperviseur
/ Conteneur
API
Provisioning (création des
Machines avec OS et logiciel)
Serveur
Web
Config Config
Java Automatisation et
Gestion de configuration

16. OSLC et le cycle provisioning et déploiement
Développeur ClientBuild Test release
Provisioning
Déploiement

17. Vagrant
• Un outil en ligne de commande écrit en Ruby
• Out-of the Box avec le support de Virtualbox
• Pour provisionner une machine Ubuntu 14.04 on lancera par exemple la
commande suivante:
• Puis lancer ssh dans la nouvelle machine ainsi construite:
• Puis une fois la machine utilisee, vous pouvez la détruire par la commande

18. Ansible: les principes
• Orchestrer et automatiser les taches d’administration système
• Provisionner des machines
• Déployer des applications

19. Installer Ansible
Pré requis:
• Installer python et la dernière version du package pip (systeme de
gestion de paquets de Python)
$ brew install python (version recommandée 2.7.10)
$ pip install pip –upgrade
• Installer Ansible et support AWS en ligne de commande
$ pip install ansible --upgrade
$ pip install awscli

20. Inventory
Ansible: Architecture et Flux
Playbook
Modules
Ansible
Config
Python
SSH

21. Ansible
Inventory:
192.168.0.1
192.168.0.2
SSH private key
Server 1
192.168.0.1
SSH public key
Server 2
192.168.0.2
SSH public key
Connexion SSH sur l’hôte distant
.ssh/authorized_keys

22. Une Démo ?
Quelques commandes Ansible avec Vagrant
Provisionner des machines

23. Notion de
Microservices et de Conteneurs

24. Des concepts qui font le buzz, Docker
• Un sujet « dans le vent » qui révolutionne la manière de concevoir et
de packager du logiciel
• Docker une évolution du container qui offre:
Build
Le packaging d’une application et de ses dépendances dans un container
Ship
Le déplacement facilite du container d’une machine a une autre
Run
Lancer le container, c’est a dire l’application qu’il contient
Any
App
Tout ce qui peut tourner sous Linux

25. Docker vs Java
• Java est WORA (Write Once Run everywhere), Docker est PODA
(Package Once Deploy Antwehere)

26. Quelques définitions: Un conteneur
• Une application, ou une image en
cours d’ execution
• Les processus, le réseau, la
configuration
• Pas une VM

27. Image vs Conteneur
Image Docker run
Running
Container

28. Les Microservices dans les
Architectures Devops

29. Microservices, c’est quoi ?

30. Caractéristiques clés
• Comme SOA, mais avec quelques « subtiles » différences:
• Pousse par la « vague » des conteneurs Docker, des infrastructures de type PAAS, etc.…
• Pousse aussi par les principes Devops et CI/CD
• Un microservice fait une seule chose et est responsable que d’une seule
fonctionnalité
• Chaque microservice peut être construit par un ensemble d'outils ou de
langage puisque chacun est indépendant des autres
• Un microservice est très faiblement couple
• Indépendance des équipes développant différent micro service
• Test plus facile et déploiement de type CD
• En général se base sur un style RESTFUL (pas obligatoire)

31. Les microservices, oui mais pourquoi faire ?
• Les besoins IT augmentent et se complexifient
• Les clients sont de plus en plus exigeants
• Les exigences du Continuous Delivery pipeline:
• Livrer rapidement
• Déployer facilement des portions de code
• Les exigences d’évolutivité de l’architecture
• Évoluer plus facilement vers d’autres frameworks ou langages

32. Application monolithique
Nœud 1
UI
Couche
métier
DAO
BD
• Un Design classique en couches
qui convient a des petites
applications et proposant une
bonne répartition des rôles
• Assez complexe a maintenir et a
déployer avec le temps
• Difficultés d’introduire de
nouveaux frameworks (exemple
Angularjs)

33. Application monolithique avec de
nombreuses fonctionnalités
Fonct. UI Fonct. UI Fonct. UIFonct. UI
UI
Fonct. Metier Fonct. Métier Fonct. MétierFonct. Métier
Business Layer
Fonct. DAO Fonct. DAO Fonct. DAOFonct. DAO
DAO

34. Une scalabilite médiocre
Nœud 1
UI
Couche
métier
DAO
BD
Nœud 1
UI
Couche
métier
DAO
BD
Nœud 1
UI
Couche
métier
DAO
BD
Load Balanceur
Node-03Node-02
Node-01

35. Quelques avantages …
• Typiquement package dans un seul .ear
• Facile a tester (tous les services sont disponibles)
• Développement facilite

36. Une architecture microservice
Internet Application 1 Internet Application 2
Microservice1
Microservice2
Microservice3
Microservice4

37. Refactoring d’une Architecture
Monolithique vers une
Architecture microservices

38. Refactoring de la Base : Etape 1
GUI
Servlets, Contrôleurs,
Managed Beans
HTML, JavaScript, JSPs,
Templates...
Utilisateur Commande Catalogue

39. Après refactoring (Step 1):
chaque microservice possède sa propre base
GUI
Servlets, Contrôleurs, Managed Beans HTML, JavaScript, JSPs, Templates...
Utilisateur Commande Catalogue

40. Architecture et Design : Step 2
• S’appuyer sur l’architecture REST pour l’exposition de son SI sous
forme de web services
• Utiliser les patterns d’architectures (Agrégateur et Proxy notamment)

41. Pattern Aggregator
Service C
WAR
Service B
WAR
Service A
WAR
Service
Agrégateur
Load
Balancer

42. Pattern Proxy
Service C
WAR
Service B
WAR
Service A
WAR
Service
Proxy
Load
Balancer

43. Packaging JEE : Passer du WAR a l’EAR
• Décomposer en unité fonctionnel autonome, chaque module en
module WAR au sein d’un EAR
Pages Web
Fichiers de
configuration
Classes Java
WAR EAR
Pages Web
Fichiers de
configuration

44. Dockerisation de l’application refactoree: Step 3
Pages Web
Fichiers de
configuration
Classes Java
WAR
BD

45. Docker Pro and Cons
• PROS
• Portabilité maximale
• Facile a créer et
• Démarrage des conteneurs
• CONS
• Solution host centric

46. Une Démo ?
• Manipuler quelques commandes Docker
• Lancer l’usine logicielle avec Docker Compose (Nexus repository, Jenkins,
GitHub…)
• Présentation de l’usine logicielle dockerisee
• Présentation de la solution Microservices JBoss Swarm, en version
standalone et dockerisee

47. Merci pour votre attention