Les Containers promettent de renvoyer la problématique du déploiement aux oubliettes. S'ils apportent effectivement un certain nombre de réponses concrètes dans ce domaine, résolvent-ils pour autant tous les problèmes ? Quels sont les nouveau défis ?
Est-il enfin devenu facile d¹amener efficacement des applications jusqu'en production ?
Toutes les réponses avec XebiaLabs en 45 minutes !
Par Benoît Moussaud (Technical Director @XebiaLabs)
Toutes les vidéos des conférences seront disponibles sur Xebia.tv
3. @ContainerDay16
Unification
• Fin des packages os natifs (rpm / msi)
• Fin des packages applicatifs (war / html / js / ...)
• Un seul élément de livraison : l’image
• Enfin....
4. @ContainerDay16
Augmentation du Périmètre
• Fin de la séparation Infrastructure / Application
• Fin des zones de responsabilités
• Le déploiement englobe tout le périmètre
• Technique : (mémoire, stockage, réseau)
• Applicatif (middleware + app)
5. @ContainerDay16
Configuration, Configuration
• Toujours présente et pas près de disparaître
• Complexe, segmentée et volumineuse
• Les containers ne supportent nativement que
les variables d’environnement
• Changement : passage d’une solution fichier à
une solution distribuée.
7. @ContainerDay16
C’est la même chanson
Chaque nouveau système prétend « qu’une simple commande suffit
pour déployer l’application »
AdminApp.install(‘myapp.ear’)
Cf push myapp
Docker run myapp
Mais en réalité il faut gérer les éléments plus finement et ainsi utiliser
les 200 options qui existent !
- Connaissance ++
- Risque ++
- Adhérence ++
14. @ContainerDay16
XL Deploy: les règles de déploiement
Une règle définit de manière unique les étapes pour déployer, modifier et désinstaller un élément défini
dans le package sur un élément de l’environnement.
Exemple:
Quelles sont les étapes quand il faut déployer une archive de type Jee War sur un Tomcat ?
Quelles sont les étapes quand il faut supprimer une archive de type Jee War d’un Tomcat ?
XebiaLabs propose des règles regroupées sous forme de plugins
Il est possible de les analyser, activer, désactiver, modifier en fonction des besoins (XML, Python)
Il est possible de définir ses propres règles de déploiement (XML, Python)
15. @ContainerDay16
XL Deploy : plugins
Plugins 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
Oracle SOA Suite.
JBoss Application Server / WildFly
Tomcat Server
Microsoft Windows
Microsoft 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
OpenShift
CloudFoundry
DataPower
Liferay
Mule MC
ElasticSearch
....
https://github.com/xebialabs-community
16. @ContainerDay16
XL Deploy : fonctionnement
Génération automatique des plans de
déploiement
1. Basée sur le modèle,
2. Analyse d’écart sur 3 axes : Package,
Configuration & Infrastructure,
3. Application des règles de déploiement
4. Application de l’orchestration
5. Exécution
21. @ContainerDay16
XL Deploy & 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.
• 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 interpréter le fichier ‘compose.yml’ en fichier manifest
et ainsi profiter des fonctions d’XL Deploy (e.g Orchestration, Dictionnaires,...)