© Copyright IBM Corporation 2016

La valeur de Docker pour les équipes de développement

La transformation digitale ? Nous savons que nous allons devoir faire face à des de-mandes disruptives, sans forcé-ment en connaître la nature, car en rupture avec les pratiques usuelles : nouveaux modèles métiers, nouveaux clients, ex-périences individualisées, opti-misation drastique du délai de fourniture de nouveaux services. L'approche DevOps vise à répondre à 3 objectifs majeurs : • Accélérer la livraison d'un produit ; • Équilibrer les axes de réussite d'un projet (vélo-

cité, coûts, qualité et risques) ; • Réduire les temps de retour client. Pour cela, la chaîne de fabrication doit s’adapter et répondre aux exigences d’une innovation continue, avec un temps de mise sur le marché « TTM » tou-jours plus réduit, et la mise en place de boucles de retour permettant de réorienter en quasi temps-réel la transformation digitale. Les leviers du changement : • L’expérience client au cœur des préoccupations ; • L’adoption large du Cloud, sous toutes ses formes

(SaaS, API, micro-services, Hybrid Cloud, etc.) ; • Une transformation profonde du cycle de fabrica-

tion, abandonnant les cycles de releases larges au profit de scénarios de fabrication au fil de l’eau (mi-cro releases), accélérant d’autant les réponses aux demandes du marché ;

• Le déploiement large des principes DevOps avec un réalignement de l’organisation reposant sur des équipes intégrées responsabilisées sur l’ensemble du cycle (du métier à l’exploitation).

Cela amène à un changement de paradigme : la spécification n’est plus la référence, et le « feed-back » continu devient le guide de l’orientation à suivre. Répondant à cela, DevOps peut être considéré comme une nouvelle capacité apportée à l’Entre-prise, lui permettant de se positionner sur une boucle continue centrée sur le client. Les interac-tions entre ce dernier et la boucle de production con-tribuent à leur transformation continue. Les résultats tangibles attendus : une accélération de l’innovation, une capacité à se réorienter pour répondre à de nou-veaux besoins non encore identifiés, et surtout à me-surer en continu l’impact de l’offre sur la demande.

Les apports de Docker pour le dé-veloppeur Le développeur sera plus agile, car il devient plus indépendant de l’OS cible, faisant fi des considéra-tions de déploiement physique, virtualisé ou Cloud public/privé. Docker assure cette cohérence grâce à ses outils de gestion et de production de conteneur nativement intégrés.

Le poste du développeur se voit simplifié à l’ex-trême : un OS, supportant son « IDE », indépendant de la technologie utilisée pour l’implémentation cible de la solution développée (serveur d’applications, base de données, etc.). Il suffit au développeur de déployer un conteneur approprié issu des images du référentiel Docker. Le code de l’application, les bi-bliothèques associées et les configurations sont in-changés lors du passage entre les mains des équipes de qualification et de production.

Le développeur, le testeur, le qualifieur et l’exploitant conservent la cohérence du code et de sa configu-ration depuis l’environnement de développement jusqu’à l’environnement de production. En particu-lier, les niveaux des bibliothèques logicielles et des packages restent inchangés sur l’ensemble de la chaîne de production, car encapsulés dans la four-niture et la maintenance des images Docker.

Au niveau de la documentation, le développeur ap-plique un nouveau paradigme. Là où dans un mode traditionnel, le développeur devait, souvent au der-nier moment, écrire toute la procédure d’installation

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

© Copyright IBM Corporation 2016

à fournir aux opérations, l’apport de Docker entraine une facilité de documentation car il va fournir l’envi-ronnement cible réellement utilisé et non un en-semble de composants à installer, déployer et opé-rer. Le volume de documentation produit par le dé-veloppeur est grandement optimisé, car le modèle opérationnel cible est porté par la configuration du conteneur (auto documentation). Les équipes opé-rationnelles n’ont plus alors qu’à installer le conte-neur - qu’ils ont par ailleurs standardisé – sans avoir à se préoccuper de l’installation et de la cohérence de l’ensemble des composants nécessaires.

Le développeur bénéficie ainsi d’images standards fournies par l’équipe de production. Il n’a plus à se soucier de savoir s’il respecte le catalogue d’entre-prise, s’il a la bonne version du middleware, ou en-core si les procédures de sauvegarde et de purges sont en place.

A l'issue des tests, les images ainsi construites sont livrées dans les environnements de recette, pré-pro-duction et production, les conteneurs étant iden-tiques à l'exception des valeurs des variables d'en-vironnement utilisées.

Docker et la chaîne de fabrication L'industrialisation de la chaîne de fabrication est un vecteur fondamental de la transformation DevOps, et repose sur quatre piliers : standardisation et auto-matisation, communication et partage.

Ces principes sont au cœur de Docker, le cycle de vie des conteneurs étant géré de façon totalement agnostique à l'application, que ce soit pour les cons-truire, les publier ou les exécuter.

Ce mode de fonctionnement permet donc aux équipes de développement, de bâtir des conteneurs à partir d'images de base (disponibles dans un re-gistre docker), d'un fichier de description normalisé (« dockerfile ») et des fichiers de l'application (bi-naires et configuration). Les variables dépendant de l'environnement sont positionnées ou valorisées à l'exécution du conteneur.

Cela permet également de mettre en application un principe clé de DevOps : le « shift-left », qui consiste à rapprocher au maximum les environnements et les activités de production des activités de développe-ment.

La production peut préparer des images de bases contenant les versions de produits homologués avec la configuration technique adéquate et les fournir aux équipes de développement au travers du re-gistre docker (référentiel d'entreprise). Il devient alors très facile aux développeurs de construire et démarrer leur conteneur afin de tester leur applica-tion dans une configuration très proche de la produc-tion.

A l'issue des tests, les images ainsi construites sont livrées dans les environnements suivants (recette, pré-production ...) les conteneurs étant identiques à l'exception des valeurs des variables d'environne-ment utilisées. La légèreté des images, de même ordre que les applications, et leur simplicité d'utilisa-tion permettent d'effectuer ces tâches de façon quasi-transparente pour les développeurs.

© Copyright IBM Corporation 2016

Finalement, l'adoption de Docker bouleverse peu les bonnes pratiques de développement :

• Gestion de configuration : tout comme le code source des applications, les images docker sont gérées en version, et stockées dans un référen-tiel dédié (registre docker), les dépendances entre images étant gérées au travers de fichiers dédiés (Dockerfile) ;

• Externalisation de la configuration : la configura-tion des conteneurs s'effectue essentiellement au travers de variables d'environnement ;

• Assemblage et livraison : tout comme pour les applications, les étapes d'assemblage, déploie-ment et exécution des conteneurs sont parfaite-ment dissociées. A partir d'une image construite, on peut la déployer à plusieurs endroits et l’exé-cuter de multiples fois (par principe les conte-neurs Docker sont des processus 'stateless').

Cette industrialisation poussée est particulièrement précieuse pour les applications de type SaaS (soft-ware-as-a-service), destinées à être opérées dans un environnement de type Cloud, et pour lesquelles il est important de respecter des règles de base telles que celles des 12 facteurs1 .

Docker et les organisations Transformation des organisations et des personnes

L’émergence de Docker dans l'entreprise n'est pas sans poser des questions d'organisation, avec des impacts sur la formation des professionnels. Le point important de transformation est de travailler progres-sivement pour permettre une prise en compte de ce nouvel outil sans entrainer de rupture auprès des équipes (celles qui connaissent Docker et les autres).

La mise en place minimale requise pour démarrer ce type de transformation doit s’effectuer via une équipe réduite qui constituera les champions de de-main, en mesure d'accompagner l'entreprise dans sa transformation. Un centre de compétence ou d'excellence DevOps pourra par exemple accueillir ces champions. Si l'entreprise n'est pas dans une transformation DevOps, le centre de Compétence Docker sera l'animateur de cette transformation.

1 http://12factor.net/fr/

Un outil contribuant à supprimer les silos Au-delà des généralités de transformation que nous aborderons dans le chapitre suivant, nous pouvons profiter de cet outil pour supprimer les silos entre les équipes de développement, avec un changement de paradigme : ce ne sont plus les études qui fournis-sent les informations d'installation à la production, mais la production et le développement qui construi-sent les images/conteneurs qui seront mis en œuvre dès le début du développement, basés sur des stan-dards validés par la production. In fine, il s’avère que la contribution des équipes de production dans la constitution du référentiel Docker est primordiale. In-versement, il s’avère que les entreprises ayant mis en avant Docker en commençant par une transfor-mation des études se sont souvent vues stoppées au moment du passage en production.

Une transformation selon 5 axes :"Keep CALMS and adopt Docker"

Culture :

« Shift left », les équipes de production sont à l'ori-gine de la fourniture des standards et n'attendent plus les guides d'installations des applications is-sues des études, les environnements de dévelop-pement sont proches des configurations de la pro-duction.

Automatisation : Docker, en tant que conteneur est un acteur ma-jeur de la transformation de l'IT via l'automatisation des déploiements et entraine une facilité de mise en œuvre des déploiements en continu.

© Copyright IBM Corporation 2016

Lean : La mise à disposition des environnements reste un processus souvent mal perçu par les équipes de développement et représente un ensemble de tâches pour les équipes de production. La mise à disposition de conteneurs dans un référentiel est une source de simplification de ces processus. L'arrivée de Docker permet de travailler sur les pro-cessus de mise à disposition des environnements et ainsi simplifier la gestion des demandes d'envi-ronnement. Il permet aussi de simplifier le proces-sus de mise en production puisque l'on ne s'at-tache plus qu'à déployer le conteneur plutôt que la ou les applications.

Mesures : L'apport de Docker est important pour le TTM. Nous pouvons, via la mise en œuvre de Docker, contribuer à la culture de la mesure de l'entreprise, et ainsi, mesurer le temps de mise à disposition d'une application ou du conteneur devant héberger la ou les applications.

Share (Partage) : La mise en place de Docker est un élément de par-tage au sein de l'entreprise. Sa mise en œuvre peut être faite via des évènements de type Hackathon et va ainsi permettre de communiquer fortement sur sa mise en œuvre. Ce partage va se faire au sein de l'entreprise. Il est bien entendu im-portant de mettre en place la notion de partage au sein de l'équipe projet, de manière à ce que les équipes opérationnelles en charge de Docker soient en mesure d'expliquer leurs contraintes, et prendre en compte celles du développement. Ce partage va permettre d'améliorer progressivement la compréhension par chacun des contraintes des autres.

Mais pour que l'intégration de la technologie Docker porte ses fruits, elle doit également s'accompagner d'une implication conjointe des équipes de Dévelop-pement et de Production dans l'adoption d’une gou-vernance commune et adaptée, englobant le cycle de vie complet du conteneur 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 be-soins non fonctionnels de l’application (concept d’une plateforme de service « Container As A Ser-vice ») serait ainsi « standardisé ».

Offres GBS autour de Docker GBS accompagne ses clients dans le cadre de transformation digitale. Ces transformations devien-nent efficientes dès l’instant où les modes de fabri-cation des applications deviennent plus agiles et plus autonomes, en synchronisation avec les be-soins exprimés par les métiers.

GBS propose donc dans le cadre de l’émergence de Docker différentes prestations, visant à définir la stratégie d’adoption de Docker avec les équipes client, et la plupart du temps complétée d’une éva-luation de la maturité de l’entreprise.

GBS offre aussi la possibilité de mettre en œuvre cette transformation en accompagnant au plus près les équipes clients, allant de la mise en place du centre d’excellence Docker avec les Etudes, jusqu’à l’accompagnement des équipes opérationnelles dans le déploiement de nouvelles solutions en sy-nergie avec les équipes de développement. Finale-ment, la clé de succès reste la capacité à accompa-gner nos clients sur la totalité du cycle DevOps, pilier et cadre des transformations digitales actuelles et à venir.

Conclusion Docker est un outil qui révolutionne le mode de fa-brication et d’exécution des applications. Il apporte, à titre de comparaison, le même type de transforma-tion que ce que les porte-conteneurs ont apporté dans le transport maritime : une standardisation, et donc une automatisation et un gain d’efficacité cons-tatés sur l’intégralité de la chaîne de production, de la conception métier jusqu’au maintien en conditions opérationnelles. Il apporte son lot de transformation, avec un positionnement à valeur des équipes de production qui n’ont plus à subir les nouvelles livrai-sons rapides des études, mais à devenir acteurs de la transformation et maitres de ce qu’ils exploiteront, tout en accompagnant leur entreprise dans sa trans-formation digitale.