© Copyright IBM Corporation 2016

La valeur de Docker pour le DevOps

Les directions informatiques sont souvent organisées en deux parties distinctes : d'un côté les équipes de Déve-loppement qui codent en fonction des besoins fonction-nels et de l'autre les équipes de Production qui s'atta-chent aux besoins non fonctionnels, au déploiement et au maintien en condition opérationnelle. Les développeurs souhaitent bénéficier des dernières innovations technolo-giques afin de coder des solutions adaptées aux nou-veaux besoins de leurs utilisateurs. La production, quant à elle, fournit un outil fiable et sécurisé, basé sur des pro-cessus, standards et sur une rationalisation des outils de travail. Cela crée souvent une frustration des deux côtés, les uns reprochant aux autres de ne pas leur permettre de développer leurs idées et donc de retarder leurs inno-vations vis-à-vis du marché, les autres reprochant aux premiers d’affaiblir la sécurité des données, les perfor-mances du système d'information et de mettre en danger son intégrité et sa cohérence.

Pourquoi Docker révolutionne-t-il la pratique du De-vOps 1?

Docker permet de séparer le travail de configuration du développeur de celui des opérations, tout en apportant un vecteur de travail commun et partagé.

Le développeur (le Dev) va se concentrer sur son code, les librairies dont il a besoin, la gestion des packages ap-plicatifs et des données. Cette configuration faite par le développeur est indépendante des configurations et ac-tions qui sont du ressort de la production (les Ops), tels que les patches de production associés de la version Li-nux, des middlewares, ou outils de supervision.

Source : Docker

Docker agit à trois niveaux pour faciliter le déploiement des applications dans une optique d’intégration conti-nue :

1. Entre les équipes de développement, de test, d’intégration et de production

1 DevOps / OpsDev : Docker comme facilitateur entre Dev et

Prod – « meet in the middle » - réconcilier l’agilité du dévelop-peur et les exigences non fonctionnelles (performance, dispo-nibilité, sauvegarde, sécurité) de la mise en production

2. Entre les environnements associés (développe-ment, assurance qualité, production)

3. Entre les infrastructures existantes (Legacies), ou de Clouds publics/privés externes ou internes

Au premier abord, la technologie de container est sédui-sante puisqu'elle incorpore toutes les dépendances per-mettant à une application de s'exécuter avec certitude dans l'environnement cible même si celui-ci est différent de l'environnement de développement. Un développeur pense rarement aux aspects non fonctionnels (perfor-mance, disponibilité, sauvegarde, sécurité). Ces besoins sont assurés par un outillage adapté mis en œuvre par les équipes de production. Mais pour que l'intégration de la technologie Docker porte ses fruits, elle doit s'accompagner d'une implication des équipes de Développement et de Production afin d'adop-ter une gouvernance adaptée englobant le cycle de vie complet du container de sa conception à son arrêt, en passant par sa mise en production et ses mises à jour régulières. Le dialogue entre le Dev et les Ops portant sur les ressources utilisées et les besoins non fonctionnels de l’application (concept d’une plateforme de service « con-tainer as a service ») serait ainsi « standardisé ».

Source : Docker

Les besoins du développeur

Le développeur souhaite être libre du choix de ses outils. On constate une forte adoption de Docker dans la com-munauté des développeurs et une bonne connaissance des APIs Docker.

Le développeur devient plus indépendant de l’OS cible : par exemple, il peut développer en CentOS sur sa ma-chine tout en ayant l’application déployée sur Red Hat ; le développeur n’est pas dépendant des considérations de déploiement physique, virtualisé ou Cloud public/privé.

TEC-F TechNotes TECF Volume X, Number X, 2016

© Copyright IBM Corporation 2016

C’est Docker qui assure cette cohérence grâce à ses ou-tils de gestion et de production de container.

Le développeur n’a plus besoin que de ses outils de dé-veloppement sur sa machine et n’a plus à installer, para-métrer et gérer les middlewares (web application server, base de données, …). Il lui suffit de déployer un container approprié issu des images du référentiel Docker. Le code de l’application, les librairies associées et les configura-tions sont inchangées lors du passage entre les mains des équipes de test et de production.

Docker permet de garder la « cohérence » du code et de sa configuration entre son environnement de développe-ment, de test, de qualification puis de production, en par-ticulier sur les niveaux des bibliothèques logicielles et des packages. Le développeur a moins de documentation à écrire car le modèle opérationnel est porté par la configu-ration du container (auto documentation).

Docker peut aussi faciliter le développement et la gestion du cycle de vie des architectures à base de micro-ser-vices (sujet qui fera l’objet d’une autre publication).

Les besoins de la production

Les réponses aux besoins non fonctionnels, comme la performance, la disponibilité, la sauvegarde, ou la sécu-rité, sont fournies par un outillage standardisé Docker qui amène les images sécurisées des OS, les outils de moni-toring et d’exploitation (backup…).

Les équipes de production ont la capacité à gérer des en-vironnements applicatifs développés avec des langages divers et avec des modèles de production hybrides (non Cloud, Cloud privé ou Clouds externes), avec le même outillage standard des containers, indépendamment de leur contenu.

Les principaux gains pour la production sont les sui-vants :

Les patches (applicatif et middleware) arrivent direc-tement dans un nouveau container en mode déploie-ment continu. La production ne s’en occupe plus, mais continue à gérer les patches de l’OS « Host »,

La mise en production est plus rapide,

On utilise moins d’outils de monitoring : on travaille différemment en remplaçant les outils dédiés middle-ware par des outils génériques en mode « Big Data sur logs ».

Un cas d’usage représentatif de la technologie Docker est la chaine de production du service DataWorks depuis Bluemix. DataWorks est un service de préparation et mouvement de données. Le déploiement initial utilisait plusieurs VMs nécessitant 5 à 6 heures de construction et déploiement à chaque nouvelle version ainsi qu’une gestion complexe de patchs spécifiques à l’application et ses différents composants.

2 http://www.slideshare.net/Docker/its-in-the-game-the-path-

to-microservices-at-electronic-arts-with-docker

L’utilisation de la technologie Docker a permis de rempla-cer tous les composants de DataWorks par des contai-ners Docker. Ainsi, chaque membre du cluster est un con-tainer docker basé sur une image Docker commune. Il en est de même pour les serveurs front-end HTTP. La pro-duction et le déploiement de ces containers a été réduite à une durée de 12 à 15 minutes au lieu des 5 à 6 heures précédentes. La notion de patch applicatif du point de vue de la production (Ops) a été supprimée, tout n’est qu’une nouvelle version de containers Docker. La mise en place d’une nouvelle version ou d’un patch du service existant utilise le même processus et les mêmes outils: le déploie-ment et l’exécution des containers Docker. Les procé-dures de maintenance telles que l’ajout de nouveaux membres dans le cluster pour supporter plus de clients ou l’ajout d’un serveur front-end HTTP de fail-over ont aussi été standardisés : il suffit de démarrer les containers Docker correspondant.

A la DockerCon EU 2015, dans la session “ It's in the game: the path to micro-services at Electronic Arts with Docker », les studios Firemonkeys d’Electronic Arts ont partagé leur expérience DevOps2. Le back-end des jeux (comme Real Racing ou Need for Speed) s’exécute sur le Cloud public IBM, Softlayer, sur près de 60 serveurs

de production (et 100 en dev) avec 100 Tb de données pour servir des pics d’un million de joueurs et d’un milliard de requêtes par jour. Ce back-end est construit sur les mid-dlewares Nginx, PHP (game logic layer), Memcache, MySQL, Redis. L’environnement est géré par une équipe de 7 personnes. Docker a été introduit par étapes d’abord sur les serveurs Nginx et PHP. Chaque serveur gère une centaine de containers Nginx et PHP, le tout orchestré par l’outil Fleet.

En conclusion, Docker permet de franchir une étape en utilisant les mêmes outils de déploiement et gestion de container Docker pour la production et le développement. Chaque développeur utilise un même environnement (les mêmes containers Docker) que celui de production et les mêmes outils. Cela permet de sensibiliser les dévelop-peurs aux contraintes de la production et en diminuant fortement les frictions entre les équipes et en réduisant les coûts associés.