Amener vos applications Dockerisées jusqu’en production avec XebiaLabs

1 Copyright 2014. Confidential – Distribution prohibited without permission
G l o b a l L e a d e r s D e l i v e r S o f t w a r e w i t h X e b i a L a b s
VISIBILITY
AUTOMATION
CONTROL
Amener vos applications
Dockerisées jusqu’en
production avec XebiaLabs

Benoit Moussaud / Directeur Technique
bmoussaud@xebialabs.com
@bmoussaud
Richard MATHIS / Directeur Commercial
rmathis@xebialabs.com

VISIBILITY
AUTOMATION
CONTROL
 Pionnier, autorité et leader
technologique du
Continuous Delivery et du
DevOps
 Présence globale
(Europe, US, & APAC)
 200+ clients grands comptes
 Reconnu par les analystes
Connecting the dots for
Continuous Delivery
at Enterprise scale
A propos de
XebiaLabs
G l o b a l L e a d e r s D e l i v e r S o f t w a r e w i t h X e b i a L a b s

Des clients majeurs nous font confiance
Outsourcing
TelcoBanque, Finance, Assurance
Sites web, SaaS, high tech
u
Secteur public Energie et Industrie
Transport et tourisme

Des tendances de fond poussent à automatiser
Virtualisation
Migrations
middleware
Compliance
Agilité DevOps Continuous
Delivery
CloudScalabilité
Réduction
des coûts

DevOps & C.A.M.S.
C.A.M.S.
oCulture
oAutomation
oMeasurement
oSharing

Operations
Development
Architects
Release Managers
Les organisations IT ont besoin de :
▪ Processus de livraisons standardisés,
répétables, et automatisés
▪ Réduire les risques (erreurs de saisie,
gouvernance et conformité)
▪ Visibilité et contrôle sur l’ensemble
du processus de livraison
▪ Accélérer leur time to market
À travers…
Les organisation IT qui ont essayé d’adapter leurs outils existants pour
faire du DevOps connaissent un taux d’échec de 80%
“
>
Legacy Web Mobile IoTMicroservice
ThingCloudOn-PremMainframe
Dev Test Prod
Tools
Releases
Apps
Environments

V I S I B I L I T Y
C O N T R O L
AUTOMATION
Award-winning tools,
recognized by leading industry analysts
Les Solutions XebiaLabs

Provision
Plan Code Build Test Release Operate
Dev Test Prod
mainframe
Orchestrer le pipeline de Continuous Delivery

Provision
Dev Test Prod
mainframe
Déployer tout type d’application sur tout type
d’environnement (physique, virtuel, Cloud)

Déployer tout type d’application sur tout type
d’environnement (physique, virtuel, Cloud)
o Déposer des packages sur des
machines
o Configurer des composants
middleware
o Arrêter/redémarrer des composants
o Configurer les applications installées
en fonction des environnements
Dans le bon ordre !
Mon app
v 1.x
v 2.x
v 3.x
Dev/Test 1
QA 1&2
Prod
1,2&3

Provision
Dev Test Prod
mainframe
… prendre les bonnes décisions de go/no go en
fonction de vos différents résultats de tests

Pourquoi orchestrer les livraisons ?
▪ Nombreux acteurs / équipes
▪ Gestion de la transition Dev / Ops
▪ Outils variés
▪ Dépendances
▪ Pas de vision globale du processus
▪ Contrôle / validation
▪ Mesure du Lead Time

Les solutions actuelles et leurs limites
Scripts complexes & déploiements manuels
o Coûteux
o Spécifiques
o Sujets à erreurs
Impacts organisationnels
o Imprédictible
o Tâches à faible VA
o Consommateur en temps
o Manque d’autonomie
Impacts business
o Time to market
o Coûts directs et indirects
o Indisponibilité des applications
o Pertes opérationnelles
Taux d’erreurs élevé
Délais trop longs
Déploiement manuels

Qu’est-ce que Docker ?
▪ Docker ...
− est un format léger de machines virtuelles
− est facilement partageable entre les équipes
− s’exécute de la même façon du poste de développeur aux environnements de production
▪ Pourquoi les équipes (surtout les Dev) lorgnent sur Docker :
− Beaucoup plus léger que tous les autres formats
− Les containers Docker sont très pratiques pour les environnements de test locaux, en
particulier dans une approche microservices
− Les containers Docker peuvent être facilement partageables et étendus, promesses de
réutilisation élevées que les autres formats ne proposent pas
− La promesse est que l’exécution des containers consomme moins de ressources que les
classiques VM

Qu'est-ce que les gens entendent par "Docker"?
▪ Un nouveau “paradigme” ou toutes les applications pourraient être livrées via
des containers versionnés par les équipes de DEV
− Nouvelle version d’une application = nouvelle version d’un ensemble de containers
− Souvent en partant du principe que ces applications seront construites à base de
microservices
▪ Un écosystème en pleine expansion d’outils qui offrent :
− Des frameworks multi-containers
− Des plateformes d’exécution de containers
− Des outils de livraison de containers (Pipeline).

Que recouvrent les “microservices”
▪ Une application basée sur une architecture “microservices” est construite en
assemblant plusieurs petits éléments indépendants qui remplissent chacun une
fonction unique.
▪ « Passer aux microservices » implique généralement non seulement les
nouvelles applications mais également la transformation des applications
existantes (monolithiques) en les découpant en différentes fonctionnalités dans
de nouvelles applications.

Et dans votre organisation, cela
implique-t-il des changements ?

Quels changements avec Docker ?
Docker impacte :
▪ Les équipes Dev :
− changement des éléments livrés
▪ Les équipes Ops :
− fourniture de nouveaux types d’environnements d’exécution (stockage, réseau,
monitoring) pour les containers
− Mode « exécution Boite Noire »
▪ Les équipes de Sécurité :
− nouvelle politique de sécurité des livraisons

Quels changements avec les microservices?
Les Microservices impactent :
▪ Les Architectes : les microservices sont un principe d’architecture
▪ Les équipes de Dev : nouvelle façon d’écrire les applications
▪ Les équipes de Test/QA, : nouvelle manière de tester (unitaires / intégration)
▪ Les équipes Release et intégration : devront gérer plus d’éléments mais de
taille réduite
▪ Les Ops, devront avoir une meilleure visualisation et surveillance et
comprendre ce qui s’exécute

Et qu’est-ce qui ne change pas ?
▪ Votre processus de livraison ne va pas magiquement devenir plus
simple : différents types de tests et des validations restent nécessaires
▪ Vos processus transverses ne changent pas : la sécurité, les contrôles
d’accès, les audits,…doivent maintenant inclure ces nouvelles
technologies !
▪ Vos applications existantes et leurs environnement d’exécution
perdureront encore très loooonnnntemps, même si vous démarrez avec
Docker et les Microservices demain.

En résumé !
▪ Les Microservices seront au final plus perturbants que Docker
▪ Les technologies et les processus dans ce domaine sont nouveaux et
changent régulièrement au fil du temps
▪ Comme toutes les nouvelles vagues, il faut supporter le mode “hybride”
▪ …qui sera d’actualité pour toutes les entreprises qui adopteront Docker et
microservices pendant très longtemps.

En résumé !
▪ Cela ne veut pas dire qu’il ne faut pas aller vers les containers et les
microservices !
▪ Docker et les microservices sont déjà pleins de promesses et auront un
impact dans les prochaines années
▪ Point Clé : identifier quel seront les bénéfices pour les métiers !
− Ex : Accélération, réduction des erreurs, satisfaction des équipes

Notre vision : un modèle de déploiement unifié
Package de
Déploiement
Environnement
Application Déployée
Déploiement
Mappe les artefacts et resources du Package de Déploiement
sur l’Environnement pour les rendre spécifiques à
l’Environnement
Indépendant de
l’Environnement

Le package de déploiement
o Un par version d’application
o Il contient l’ensemble des ressources nécessaires
o archives (WAR, EAR, JAR…)
o .exe, .dll, application pool
o contenu statique (html, javascript, images, video)
o scripts de bases de données et datasources
o fichiers de configuration
o Docker: images, volume, network ….
o Complet !
o Structure adaptable aux modes opératoires existants
o Indépendant de l’environnement

L’environnement
o Machine ou ensemble de machines sur lesquelles sont installés des middlewares
o Serveurs d’applications
o Serveurs web
o Bases de données
o Portails
o ESB…
o Docker : Machine, Cluster Swarm …
o Classiquement :
o Développement (simple)
o Test
o Acceptance
o Production (complexe)

Le déploiement
o Associer un package (version X de l’application Y) sur un environnement Z
o Chaque élément du package (deployable) est associé à un ou plusieurs containers de l’environnement pour
devenir un ‘deployed’
o Chaque ‘deployed’ est configurable.

Le même package traverse différents
environnements jusqu’en production

Configuration : les dictionnaires
o Permettent de centraliser et gérer les paramètres en fonction de l’environnement cible
o Valeur par défaut des propriétés (ex: file.DeployedFile.targetDir)
o Valeur des placeholders (ex:{{DB_USERNAME}}, {{ULR_BACKEND}})
o Association
o Plusieurs par environnement
o Partageables entre plusieurs environnements
Package de déploiement EnvironnementDéploiement
DictionaryDictionary
Dictionnaires
Fournit les valeurs

Périmètre fonctionnel de XL Deploy
GERER UN ETAT
o Basé sur un modèle (UDM)
o Référentiel
o des environnements
o des applications
o des versions applicatives installées
o Point central de configuration et de
paramétrage de ressources
o Gestion complète de la traçabilité
GERER LES CHANGEMENTS
o Moteur de calcul automatique des plans
de déploiement
 Calcul des deltas entre packages
 Application des règles de déploiement
TRANSPORTER et EXECUTER
o Automate de déploiement
des packages applicatifs sur
les serveurs
o Exécution des commandes

Embedded
database
XL Deploy core
Satellite connector
Extensible REST API
served by Embedded HTTP Server (Jetty)
Extensible web-based GUI
(HTML 5, Flash)
Continuous integration
(Jenkins, Bamboo, TFS, …)
Command line interface
(Jython)
External
database
Internal
repository
LDAP
Configurationrepository
(JCR)
or or
Security(Spring)
architecture
Cloud (EC2, vSphere, …)
Docker
SSH
CIFS
WinRM
SSHREST or
other
Command line
interface
Middleware
MiddlewareWindows Remote Hosts
Unix Remote Hosts
Deployment Rules

Règles de déploiement
Utiliser en standard
o Plugins apportent les règles de déploiement
o Travaillent ensemble pour constituer la tâche
de déploiement
Plugins officiels Plugins communautaires
IBM WAS 6, 7, 8 et 8.5
IBM WebSphere MQ
IBM WebSphere Process Server
Oracle Weblogic Server 9, 10, 11g, 12c
Oracle Service Bus 10 et 11
JBoss Application Server / WildFly
Tomcat Server
Microsoft Windows / IIS / Biztalk
F5 Networks Big IP
Citrix Netscaler
Command
File
Web Server
Database
Notification
Release Authorization
Maven
Bamboo
Jenkins
TFS
Smoke Tests
Lock
Change Management
Generic Load Balancer
DataPower
RPM
Personal Credentials
Puppet
Docker
....
Adapter
o Par simple configuration (XML) pour
refléter ses propres règles
Créer
o Définir ses propres régles pour supporter
d’autres cibles.

XL Deploy, solution d’entreprise sécurisée

XL Deploy : réconcilier Dev et Ops

Solution type « Livraison Continue »
Development Test Acceptance Production
App B
V 3.3
App B
V 3.2
App B
V 3.1
App B
V 3.0
Development Test Acceptance Production
App A
V 2.0
App A
V 1.2
App A
V 1.1
App A
V 1.0
Projets en développement
Intégration Continue
Provisioning d’infrastructure
Automatisation des déploiements

Différentiateurs XL Deploy
AutoFlow
Pas de scripts
à écrire / à
maintenir
Plugins
out of the box
Modèle
puissant,
ouvert et
extensible
Rapidité
de mise en
oeuvre
Architecture
sans agents
Licensing

Demo
Release
Orchestration
Deployment
Automation
Test
Analytics
Orchestrate,
automate and get
visibility into
release pipelines
Automate and
standardized
complex application
deployments
Analyze test results
across multiple
test tools

1.2
Tomcat
SqlClient
From « PetPortal » to « PetDocker »
Petclinic
jee.war
petclinic-backend
jee.War
Config
Tomcat.ConfigFile
sql
Sql.SqlScripts

1.2
Tomcat
SqlClient
Petclinic
jee.war
petclinic-backend
jee.War
Config
Tomcat.ConfigFile
sql
Sql.SqlScripts
Petclinic
jee.war
petclinic-backend
jee.War
Config
Tomcat.ConfigFile
sql
Sql.SqlScripts

2.0
SqlClient
Petclinic
Docker.Image
petclinic-backend
jee.War
Config
Tomcat.ConfigFile
sql
Sql.SqlScripts
Docker Machine
Tomcat

2.0
Tomcat
SqlClient
Petclinic
Docker.Image
petclinic-backend
jee.War
Config
Tomcat.ConfigFile
sql
Sql.SqlScripts
Docker Machine
Petclinic
Docker.Image
petclinic-backend
jee.War
Config
Tomcat.ConfigFile
sql
Sql.SqlScripts

2.2
SqlClient
Petclinic
Docker.Image
petclinic-backend
Docker.Image
Config
Docker.Volume
sql
Sql.SqlScripts
Docker Machine

2.2
SqlClient
Petclinic
Docker.Image
petclinic-backend
Docker.Image
Config
Docker.Volume
sql
Sql.SqlScripts
Docker Machine
Petclinic
Docker.Image
petclinic-backend
Docker.Image
Config
Docker.Volume
sql
Sql.SqlScripts

4.2
Petclinic
Docker.Image
petclinic-backend
Docker.Image
Config
Docker.Volume
Sql
docker.SqlScripts
Docker Machine

4.2
Petclinic
Docker.Image
petclinic-backend
Docker.Image
Config
Docker.Volume
Sql
docker.SqlScripts
Docker Machine
Petclinic
Docker.Image
petclinic-backend
Docker.Image
Config
Docker.Volume
Sql
docker.SqlScripts

Full Stack
▪ Déployer des docker.Images sur des docker.Machines c’est bien !
▪ Créer des docker.Machines / des clusters docker.Swarm c’est encore mieux !

Demo Full Stack
Machine Consul

Demo Full Stack
Machine Consul
consul

DOCKER SWARM CLUSTER
Demo Full Stack
Machine Consul
consul
Machine
Swarm-master
Machine node-2
« back »
Machine node-1
« front »

DOCKER SWARM CLUSTER
Demo Full Stack
Machine Consul
consul
Machine
Swarm-master
Machine node-2
« back »
Machine node-1
« front »
Ha-proxy
petclinic
Petclinic-
backend
cAdvisor
Swarm-
demo

Docker Compose
▪ Docker Compose est un format de description d’une ou plusieurs images avec
leur configuration (environnements, volumes, ports, command)
▪ « docker-compose up » est la commande qui va permettre d’instancier
l’ensemble des images sur une docker machine.

From « DockerCompose » to Manifest
▪ Coté ‘Dev’ c’est très pratique : la commande build les images (en plus de les
instancier)
▪ Coté ‘Ops’ moins:
− Black box : une commande lancée avec un multiplexage des sorties est difficile à gérer en cas de
problème.
− Solution : DockerComposeImporter qui va interpreter le fichier ‘compose.yml’ en fichier manifest et
ainsi profiter des fonctions d’XL Deploy (e.g Orchestration, Dictionnaires,...)
XL Deploy Docker plugin permet
− Packager un ou plusieurs fichiers ‘compose.yml’
− Gérer des placeholders pour la configuration par environnement + dictionnaire

XL Deploy & Docker Compose
▪ XL Deploy Docker plugin permet de
− Packager un ou plusieurs fichiers ‘compose.yml’
− Gérer des placeholders pour la configuration par environnement avec les dictionnaires

From « DockerCompose » to Manifest

Next Steps
Demo✔ POC
Get
Started✔ ✔
Business
Value

VISIBILITY
AUTOMATION
CONTROL
ThankYou
Ressources
Continuous Delivery
Q&A?
www.XebiaLabs.com

Appendix

XL Release dans son écosystème

Exemple d’orchestration @ Digital Globe

Exemple de modèle de livraison

Reporting avancé

Reporting avancé : améliorer son ratio
d’automatisation

Value Stream Mapping

Amener vos applications Dockerisées jusqu’en production avec XebiaLabs

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (6)

Semelhante a Amener vos applications Dockerisées jusqu’en production avec XebiaLabs

Semelhante a Amener vos applications Dockerisées jusqu’en production avec XebiaLabs (20)

Mais de XebiaLabs

Mais de XebiaLabs (20)

Amener vos applications Dockerisées jusqu’en production avec XebiaLabs

Notas do Editor