Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
💥 1 livre papier acheté 
= la version en ligne automatiquement offerte. Cliquez ici

Docker et l'usine logicielle

Introduction

Nous vivons une période passionnante en informatique. En effet, durant les dernières années, nous avons constaté un changement de paradigme du développement (l’industrie a globalement adopté le développement en mode Agile plutôt qu’en mode Waterfall, connu aussi sous le nom de cycle en V) et une évolution radicale des outils et langages. De nouveaux patterns et de nouvelles méthodes de travail ont émergé à la suite de ces nouveautés, et Docker est, entre autres, une réponse à tous ces changements.

Mais, par-dessus beaucoup de choses, c’est un nouveau mode de travail collaboratif qui a vu le jour : le mode DevOps. DevOps est une contraction des termes "développeurs" et "opérationnels" (ou opérations). Cela signifie que cette façon de travailler a pour but de rapprocher les développeurs des opérationnels. Jusqu’à présent, nous avons utilisé Docker pour tester nos développements, mais vous avez dû constater que de petites subtilités à respecter en vue d’une mise en production ont plusieurs fois été mentionnées. Étant donné que nous, développeurs, sommes maintenant beaucoup plus proches des opérationnels, notamment pour traiter leurs retours plus rapidement, nous devons également nous mettre à leur écoute et les assister du mieux que nous pouvons, afin que toute l’équipe gagne en efficacité.

images/06EI01.png

Figure 1 :Figure DevOps (source : Wikipédia)

La forme choisie pour illustrer les principes DevOps, comme on le constate ci-dessus, est assez explicite. Le signe de l’infini permet de mettre en évidence qu’il s’agit d’un cycle qui s’enchaîne et se répète continuellement. Le développeur a la responsabilité de participer à la planification du travail, de créer le code associé pour répondre aux besoins fonctionnels, d’effectuer les vérifications nécessaires (tests automatisés) et de livrer une version empaquetée. Les opérationnels, eux, vont effectuer le déploiement de cette version, la configurer selon le point de vue de l’infrastructure et suivre...

Pipeline DevOps

L’intégration continue se déroule en plusieurs phases distinctes :

  • Récupération du code source depuis un ou plusieurs dépôts.

  • Installation des outils nécessaires pour compiler la solution.

  • Installation des dépendances externes de la solution (packages…).

  • Compilation de la solution.

  • Exécution des tests automatisés.

  • Invocation de services externes (Sonar…).

  • Publication des rapports (temps passé, couverture de code…).

  • Publication des artefacts de compilation.

Il est assez facile de constater qu’il y a beaucoup de choses à faire. Certaines étapes de cette liste sont bien entendu facultatives, et il est également possible d’inclure des étapes personnalisées, mais il faut garder à l’esprit qu’une bonne intégration continue couvre le maximum de choses pour assurer un haut niveau de qualité, car c’est là son but. De la même façon, il est assez facile de se rendre compte qu’il y a deux groupes logiques d’actions dans cette liste : les actions de création/construction et les actions de vérification/publication.

À la suite de la publication des artefacts de compilation, il sera possible d’enchaîner sur un déploiement continu qui déploiera ces artefacts sur une infrastructure d’exploitation.

Dans le cadre d’un workflow de développement, il faudra réaliser ces opérations et publier sur notre poste local pour pouvoir tester. Docker et Git nous permettent de réaliser la totalité de ces opérations, voyons tout d’abord comment construire un pipeline manuel sur un poste de développeur.

1. Création manuelle

L’étape la plus importante, et forcément indispensable, est celle de la création du code binaire. Et par code binaire, on peut entendre plusieurs choses :

  • Les éléments devant être exploités par un runtime.

  • Une image Docker.

  • Toute sorte d’éléments nécessaires au bon fonctionnement de l’applicatif.

Il est essentiel que cette étape se déroule de la façon la plus pure possible, c’est-à-dire sans aucune intervention externe. Il faut donc partir d’un environnement le plus...

Outils pour le développement

Généralement, un pipeline DevOps va proposer une collection d’outils supplémentaires qu’on ne retrouve pas aisément sur un poste local de développeur. Par exemple, on y trouvera des outils d’analyse de code, comme Sonar, ou, comme on l’a utilisé précédemment, un dépôt privé pour mettre à disposition nos images. Bien qu’il soit possible d’installer ces éléments sur le système, ils peuvent être configurés différemment d’un poste à l’autre et vont, dans tous les cas, altérer le système du développeur en y ajoutant certaines choses.

Finalement, il va exister des tests automatisés qui auront besoin d’éléments d’environnement, comme par exemple une base de données ou un message broker, afin de simuler un environnement de préproduction.

Docker va nous permettre de monter ce type d’outils rapidement et facilement en local, afin d’améliorer le flux de travail.

1. Dépôt privé

Cette option pourra être choisie pour éviter les coûts supplémentaires liés à un dépôt privé hébergé sur une plateforme tierce, comme Azure par exemple. De la même façon, l’utilisation d’un dépot comme Azure passe par Internet, et si l’équipe de développement est sur un réseau local, il est inutile et peu performant d’utiliser la connexion Internet pour récupérer les images.

Il existe plusieurs solutions de dépôt privé qui s’exécuteront sous Docker pour atteindre cet objectif. Nous allons en voir deux : le dépôt principal officiel fourni par Docker et Sonatype Nexus qui, lui, va au-delà de mettre simplement à disposition des images Docker.

a. Dépôt officiel

Docker a mis officiellement à disposition une version de son dépôt afin de permettre l’hébergement local de nos propres images (sur un poste ou sur un réseau). Ce dépôt se trouve sous le nom de registry (https://hub.docker.com/_/registry). Il existe deux versions de cet outil, et nous allons travailler avec la version 2, la version...