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.