docker@etatvs -...
TRANSCRIPT
Docker@EtatVS
A DevOps perspective
Agenda
• Contexte initial
• Faiblesses
• Docker == Chuck Norris ?
• Résultat après la première “release”
• Prochaines étapes
• Leçons apprises
• Questions - Tentatives de réponses...
Contexte Initial – l’avant Docker 1/2● Humain
○ Deux équipes - Dev : 8 développeurs | Ops : 2 sys middleware + 1 dba.
● Méthodologie
○ Scrum pour le Dev (sprints de deux semaines) | opération pour les Ops.
● Applications
○ Plus de 8 applications java, basées sur des technologies différentes, JEE 5 sur weblogic 10,
JEE JSF / Vaadin sur JBoss EAP 6 et JEE JAX-RS - Angular sur EAP 6.
● Infrastructure
○ WebLogic commun
○ JBoss EAP commun
Contexte Initial – l’avant Docker 2/2
● CI (Continuous Integration)
○ Jenkins - Build uniquement pour les applications hors WebLogic.
○ Immutabilité ASAP.
● Source - RTC (IBM Rational team Concert)
● Monitoring / Logging
○ Nagios (limité) / Graylog
Rappel - Points clés DevOps du manifeste agile
● Agile Manifesto
○ “Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.”
○ “Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.”
○ “Simplicity--the art of maximizing the amount
of work not done--is essential.”
○ “Working software is the primary measure of progress.”
Processus CI - Delivery
● Serveur JBoss en local pour développer.
● Vm avec serveur JBoss pour du CI.
● Vm JBoss pour QA et Prod.
● Configuration manuelle du serveur d’applications
sur l’ensemble des environnements.
● Jenkins build les artefacts depuis RTC et les publie
dans le repository Nexus (.war immutable).
● Applications déployées depuis Nexus.
● Config jboss dans nexus.
Faiblesses - Dev
● Maintenances - Bug Fix
○ Le temps pour réparer le bug est beaucoup plus faible que le temps pour préparer
l’environnement pour le corriger.
● Environnement de développement
○ Difficile à maintenir entre développeurs (gestion des datasources, endpoints,
etc…).
● Grosse différence entre environnements
○ Dev : windows
○ Prod et QA : Linux)
Faiblesses DevOps● Impossibilité de faire du CD
○ Serveur d’application centralisé.
○ Configuration des apps sur le serveur - à faire par les Ops.
● Migration infrastructure technologique lourde
○ Les applications doivent suivre les évolutions des plateformes de manière uniforme.
● Obligation de limiter l'empreinte technologique
○ Impossible de supporter plusieurs serveurs d’applications par les Ops.
● Ressources partagées
○ Impossible d’isoler une application JEE (gestion des ressources par application).
● Feedback loop beaucoup trop grande
Faiblesses - Ops
● Beaucoup de travail manuel - risque d’erreur élevé.
● Forte sollicitation en cas de problème.
● Travail répétitif peu intéressant sans véritable valeur ajoutée.
● Bottleneck de l’IT, forte pression.
● Nombre de projets acceptés en front totalement dépendant de la capacité
opérationnelle.
Frustrations
● Frustrations Ops
○ Travail peu intéressant. / Forte sollicitation. / Plus le temps d’amener de la valeure ajoutée.
● Frustrations Dev
○ Difficile de prendre plus de projets métiers. / Constamment en attente de ressources Ops.
○ Grosse perte de temps pour se remettre dans des projets.
● Frustration métier
○ Beaucoup trop temps entre le feedback agile et la mise en production.
○ Temps (trop long) de mise à disposition de fixes / nouvelles fonctionnalités.
○ Décalage entre les promesses de l’agilité et la réalité.
Docker == Chuck Norris ?
● Solution de gestion des
environnements au travers de Vm
possibles (Vagrant, Puppet, Ansible,
etc.)
Malheureusement ;-( :
○ Coûteux au niveau mémoire.
○ Performance moyenne.
○ Gestion réseau plus complexe.
● Besoin d’une solution plus légère.
Les promesses de Docker…. (sur papier) 1/2
● Infrastructure as code
○ Simplifier l’échange des configs entre développeurs.
○ Assurer un environnement commun du Dev à Ops.
○ Plus de config manuelle - CD possible.
● Container
○ Support de multiples versions d’OS et de serveurs en parallèle.
○ Maîtrise du Dev à Ops de la stack technologique.
○ Gestion des ressources par application.
○ Même image du Dev à Ops (même OS) – « What you write is what you run... »
○ Immutabilité de l’infrastructure ASAP
Les promesses de Docker…. (sur papier) 2/2
● Container Orchestration
○ Agilité étendu aux Ops.
○ Architecture microservices.
○ Elasticité applicative.
Introduction de Docker@EtatVS - Roadmap 1/2
● Mise en place d’une infrastructure Docker - DataCenter
○ Infra docker clusterisée.
○ Multi environnements.
○ Registre d’image docker privé - sécurisé.
● Mise en place DevOps
○ Plus d’opérations manuelles.
○ Prêt pour la délivrance continue - déploiement continu.
○ Ops débute dans le Dev.
○ Pas de couplage fort à une solution.
○ SCM (Software Configuration Management) Commun -> GIT.
Introduction de Docker@EtatVS - Roadmap 2/2
● Mise en place d’un environnement de Dev Docker
○ Environnement de Dev == Prod.
○ La contrainte 2’ - project ready.
● Hors scope
○ Bases de données
Introduction de Docker@EtatVS - Méthodologie
● Aide externe avec une vision DevOps (Consulting).
● Mise en place itérative.
● Feedback loop très court.
● Petits incréments.
● Passer au plus vite en production une application “non critique”.
● Formation sous forme de workshops - communs autant que possible.
Résultat - Docker perspective Opération
● Docker DataCenter
○ Swarm
○ Registry docker
○ UCP
● Loadbalancer
○ Nitrox
● Utilisation des labels - immutabilité des images
Cluster Docker - Docker Swarm
● Attention - pas Swarm mode…
● Plusieurs Swarm Manager sur des Vm Red Hat Linux.
● Plusieurs Swarm Worker sur des Vm Red Hat linux.
● Les Vm sont provisionnées via Red Hat Satelite et Puppet.
Gestion des images et des containers
● Utilisation de la
Docker Private
Registry pour gérer
nos images infras et
applicatives.
● Utilisation d’UCP
(Universal Control
Panel) pour visualiser
en temps réel les
containers (par
contre, pas pour le
déploiement).
Dynamic Proxy
● Utilisation d’un container
de médiation - Nitrox
Installer sur Swarm
Manager.
● Configure et met à jour
automatiquement Load
balancer pour lier une URL
externe à une URL(URL +
port dynamique) d’un
container Docker.
Résultat - Perspective DevOps
● Chaque projet / service
○ Jenkins Groovy Script qui crée les pipelines requises CI / CD.
■ Pas d’opération manuelle sous Jenkins.
■ Travail effectué par Ops -> force intégration des Ops ASAP dans les projets.
○ L’image Docker et le compose se trouvent dans le code de l’application.
○ L’image est créée par Jenkins (CI) et poussée dans la registry Docker en cas de réussite.
○ L’image est immutable du CI à la Prod.
○ Utilisation manuelle depuis Jenkins pour pousser en Dev / QA / Prod.
○ Tag git == Jenkins build == Docker image name.
○ Branche presque inutile (sauf en cas de bug bloquant).
CI - CD Process avec Docker● Ops développe image
infra.
● Dev utilise image infra.
● Dev développe image
applicative.
● Images construites par
CI à chaque push Git
et enregistrées dans la
registry Docker.
● Image applicative
déployée
automatiquement sous
CI.
● CD - click to deploy.
Jenkins Sacquet - one rule them all…. ● Un job Jenkins “root”
s’occupe de créer les
“jobs” CI + CD pour
chacun des projets.
● CI - CD as code.
Chaque projet définit son
process de CI et de CD.
● Le job root se base sur
un repository Git.
Project CI et CD● Création de la partie CI -
utilisation de pipeline - laissée
au développeur.
● Création de la partie CD - définis
les environnements cibles.
● Création des jobs Jenkins
correspondants.
CI Pipeline● Pipeline (Jenkinsfile)
définie par le développeur
- par projet.
● Tag Git avec le numéro
du build (traçabilité).
● Push image dans Docker
avec le numéro du build
(num image == tag Git).
● Exécuté à chaque Push
(automatique).
Job CD contre environnement
● Le “déployeur” choisit la version et la branche Git (version à déployer)-
● Le job Jenkins installe la version demandée dans le cluster Docker en se
basant sur le docker-compose et l’image taguée.
Résultat - Docker perspective Dev
● Docker-machine et docker-compose via Docker toolbox.
● IntelliJ - Docker plugin.
● Image de base fournie par Ops.
● Image applicative fournie par le Dev.
● Infra as code Chaque projet / service
○ Jenkins file et docker-compose dans le projet métier.
○ Un docker-compose et un fichier variable d’environnement par environnement.
Ops starts in Dev….
● L’ensemble des fichiers Docker et Jenkins requis pour les
différents environnements font partie intégrante du projet
métier.
● Le développeur travaille directement sur un environnement
Docker, sur l’image qui sera identique à l’image de
production.
Dev - Infrastructure as code en local
● Le dockerfile local est dans le code,
donc, l’infrastructure de l’application
est mise à jour par le développeur et
partagée avec les autres via GIT (plus
de config manuelle).
● Compose permet de lancer le
container avec les bons paramètres et
de recréer le container si des
dépendances du dockerfile ont été
modifiées.
Docker Image - Responsabilité du développeur
● Le dockerfile de l’image finale ajoute
simplement l’application directement
dans l’image.
● Compose ne rebuild pas l’image -
effectué par jenkins. Déploie une
version donnée de l’image depuis la
registry.
● A noter, l’utilisation des labels pour
exposer l’application en interne ou en
externe (loadbalancing).
Docker@EtatVS - Résultat première étape
● Process Devops CI + CD.
● Time to deploy radicalement amélioré.
● Maintenance beaucoup plus rapide.
● Implication des Ops dès le début.
● Très bonne séparation des responsabilités.
● Beaucoup moins de travail inutile, augmentation du
temps à disposition pour du travail à forte valeur
ajoutée.
● Dev plus efficace.
● Prêt pour le déploiement continu…
● Plus de 15 applications / services en production...
● Augmentation de projet métiers.
● Augmentation de notre capacité à répondres aux
besoins métiers.
● Au niveau Dèv, la plupart des problèmes venaient d’un
migration technologique (weblogic -> jboss), mais pas
d’issus inhérentes à Docker.
Docker@EtatVS, c’est bien, mais...
● Orchestration
○ Relativement faible, difficile à “scaler” nos applications - pas encore d’élasticité.
● Monitoring
○ Très faible via Nagios. Manque beaucoup de métriques - mauvaise visibilité de notre
production - (réactif et non proactif) - pas pire qu’avant.
● Qualité docker enterprise
○ Fortement instable - qualité moyenne.
○ Peu réactif pour corriger des bugs majeurs.
● API insuffisante - pas possible de reproduire le modèle vers nos partenaires.
● Solution pas prête pour un cloud hybrid.
● Pas d’automatisation pour la mise en place de l’infrastructure Docker.
Docker@EtatVS - But initial - sans feedback loop rapide
● Système d’orchestration scalable.
● Passage de l’ensemble de nos projets sous
Docker.
● Ouverture de Docker à nos partenaires.
● Mise en place d’un système de monitoring
global.
● Système d’alerting global.
● Système de logging global.
● Grosse intégration de l’Ops et du Dev.
Docker@EtatVS - Résultat du but initial….
● Report du problème de capacité opérationnelle.
● Risque énorme sur un projet globale de monitoring.
● Multiples échanges avec les partenaires externes.
● Difficulté - incapacité à utiliser un cloud hybride.
Docker@EtatVS -> Besoins réels
● Découplages en zone applicative des
containers.
● Possibilité de gérer des mini orchestrateurs
aussi bien dans un cloud public que dans un
cloud privé ou on premise de manière
transparente.
● Séparation encore plus claire des
responsabilités entre le Dev et l’Ops.
● Possibilité d’augmenter la capacité métier
sans impacter la capacité opérationnelle.
● Délégation d’une partie opérationnelle aux
Dev.
Prochaines étapes
● Mise en place de la nouvelle solution d’orchestration Docker.
● Adaptation step by step de nos process de build existants.
● Mise en place d’un monitoring local et global.
● Mise en place de déploiement “blue/green”.
● Amélioration des tests pour pouvoir passer de Continuous Delivery à
Continuous Deployment.
● Embarquement de nos partenaires step by step.
Leçons apprises 1/2
● Commencez petit -> grandissez rapidement.
● Feedback loop comme un projet métier.
● Evitez le couplage fort - Minimisez l’empreinte technologique.
● Pas de solutions “toute faite”.
● Solution win-win (Ops and Dev Win -> Business Win).
● Humilité : savoir se faire aider.
● Formez vos équipes - et autant que possible mixez Dev et Ops.
Leçons apprises 2/2
● “L’opérabilité” d’une application commence dès le développement.
● Docker simplifie le DevOps, mais ce n’est pas Chuck Norris.
● Les conflits DevOps seront toujours présent - mais constructifs…
● Docker == Linux ! gros changement dans vos équipes de dèv.
● Gestion de la mémoire et des threads java 8 très différente sous docker ->
passez au plus vite sous java 9.
Leçons apprises – Métiers 1/2
● Le métier n’a plus le temps de tester en QA…
○ QA - uniquement pour rassurer l‘IT sur la qualité de ses livrables à travers des tests
fonctionnels.
● Moins risqué de déployer plusieurs petits incréments qu’une énorme release.
● Délivrer du software de manière continue augmente la qualité.
● La “délivrance” de software au métier est comme un sport ; plus on le
pratique, plus on s’améliore, moins on prend de risques.
● Une application n’est jamais terminée. Elle est en constante évolution, à
l’image du métier qu’elle soutient. -> DOD = Décommissionement.
Leçons apprises – Métiers 2/2
● Docker et Devops n’améliorent en aucun cas la qualité du code d’une
application. Par contre ils offrent la capacité de corriger les bugs et de mettre
à disposition les correctifs de manière continue.
● DevOps, c’est avant tout une aventure humaine, un rapprochement non
seulement du Dev et de l’Ops, mais aussi du métier. La technologie n’est
qu’un facilitateur pour y parvenir.
Les clés du succès
● Une direction qui appuie la démarche DevOps.
● Un consultant qui comprend aussi bien les besoins des Ops que du Dev.
● Un chef acquis à la cause agile et DevOps (son soutien total).
● Et, surtout, une équipe DevOps incroyable, prête à relever tous les défis, et
pour qui le changement est inscrit dans leur ADN.
Quelques liens….● Docker
○ devops toolkit : https://leanpub.com/the-devops-2-1-toolkit
○ Java with docker : https://dzone.com/articles/java-ram-usage-in-containers-top-5-tips-not-to-
los
● DevOps
○ The Phoenix project : https://www.amazon.com/Phoenix-Project-DevOps-Helping-
Business/dp/0988262592
○ DevOps Handbook https://www.amazon.com/DevOps-Handbook-World-Class-Reliability-
Organizations/dp/1942788002/ref=pd_lpo_sbs_14_img_0?_encoding=UTF8&psc=1&refRID=
KEM23MGDY9PT40JAVEKH
○ DevOps tech Guru : Arun Gupta - http://blog.arungupta.me/
○ Devops topologies : http://web.devopstopologies.com/
○ Consulting Guru : Neurones - Frederic Legrand http://www.neurones.pro/
Merci de votre attention.