Conteneurs et déploiement de logiciels : la nouvelle culture du package

La technologie des conteneurs révolutionne l’infrastructure. Elle permet aux architectures applicatives d'évoluer vers un modèle distribué de microservices optimisé pour piloter des processus de déploiement continu sans couture.

L’industrie IT évolue par vagues, au gré d’innovations qui touchent séparément l’infrastructure (du mainframe à l’environnement distribué ou virtuel), l’architecture applicative (du monolithe au client-serveur et web n-tier) et la méthodologie. Mais à présent, plus qu’une vague spécifique à l’un ou l’autre des domaines, c’est une transformation radicale de tous les domaines à la fois à laquelle nous assistons.

La technologie des conteneurs légers (représentée le mieux par Docker) révolutionne le domaine de l’infrastructure. Les architectures applicatives opèrent leur transition vers un modèle distribué de microservices pour permettre l’ajout rapide ou la modification d’une logique business à valeur ajoutée afin de mieux satisfaire l’utilisateur final. Côté logiciels, de nouvelles techniques émergent, inimaginables il y a seulement quelques années, comme les tests A/B en production et la technique des "feature flags". Ce qui est encore plus intéressant, c’est que ces vagues s’alimentent les unes les autres avec pour effet cumulé de produire plus de valeur plus rapidement pour l’entreprise / le consommateur / l’utilisateur.

Les conteneurs et le Déploiement Continu (CD) stimulent ensemble l’innovation au niveau des applications à base de microservices. Ce changement radical des outils et process IT peut avoir un impact potentiel énorme sur nous tous car ces innovations viennent s’amplifier les unes les autres au point de dépasser la somme des éléments qui les constituent. A tel point que nous allons peut-être assister à la même croissance exponentielle de l’innovation appliquée à l’IT d’entreprise que celle des applications mobiles et grand public ces cinq dernières années. 

Ce qui est marquant avec le phénomène Docker, c’est la nouvelle collaboration entre développeurs et équipes des Opérations simplement en passant d’une approche binaire des applications à l’approche de conteneur.

On peut voir Docker comme une nouvelle approche de packaging, à l’instar des packages d’applications RPM ou d’autres mécanismes. Mais si on résume Docker à un mécanisme de packaging, on tend à réduire son effet au seul passage des applications en production. Or comme Docker change fondamentalement et positivement toutes les étapes liées au packaging des applications, la maintenance, le stockage, les tests et le déploiement, l’environnement d'exécution de destination n’est pas quelque chose qu’on laisse à l’appréciation de l’équipe IT Opérations postérieurement au pipeline de Déploiement Continu. Or, l'environnement d'exécution est étroitement associé au code source de l’application dès le départ. Au tout début de chaque pipeline de Déploiement Continu figurent des gestionnaires de source de code et des gestionnaires de binaires qui contiennent des images Docker approuvées par l’IT Opérations pour les différents environnements (système d’exploitation, serveurs d’applications, bases de données, équilibreurs de charge, etc.). 

Le fait que Docker encapsule l’application et l'environnement de l'application ou la configuration de l'infrastructure apporte plusieurs avantages :

●      Premièrement, Docker permet de tester exactement ce que l’on déploie. Les développeurs fournissent des conteneurs Docker ou des éléments consommés par d’autres conteneurs ; l’équipe des Opérations IT déploie ces conteneurs. Le risque d’erreur à la transmission ou lors d’un assemblage est réduit ou éliminé. Les conteneurs Docker encouragent le principe de Déploiement Continu et la réutilisation des mêmes binaires à chaque étape du pipeline de déploiement pour ne pas risquer d’introduire des erreurs dans le processus de Build.

●      Deuxièmement, les conteneurs Docker posent les bases d’une infrastructure immuable. Il est possible d’ajouter des applications, d’en supprimer, les cloner et/ou de modifier leurs composants, sans laisser de résidus. En cas d’échec de déploiement, tout est confiné à l'intérieur du conteneur. Les ajouts et suppressions sont si simples qu’on ne se préoccupe même plus de l’état d’une application lors d’une mise à jour. De plus, la nécessité d’apporter des modifications à l’infrastructure sous-jacente indépendamment des applications crée inévitablement des problèmes et c’est ce qui sépare traditionnellement les responsabilités du Développement et des Opérations. De nouveau, l’abstraction du conteneur limite ou élimine l’exposition à ces frictions. C’est d’autant plus important quand les entreprises opèrent la transition de la virtualisation traditionnelle vers une infrastructure de Cloud privé ou public. Aucun de ces bienfaits de l’utilisation de Docker n’apparaît par magie. Vos logiciels et votre infrastructure doivent toujours être créés, intégrés avec d’autres logiciels, configurés, mis à jour et administrés tout au long de leur cycle de vie. Mais Docker fournit simplement de meilleurs outils pour ce faire. 

●      Troisièmement, la mise à jour de l’environnement devient plus formelle mais aussi plus simple. Dans un processus typique de déploiement de logiciel, le principal déclencheur d’un nouveau pipeline de Déploiement Continu sera un changement du code source de l’application. L'exécution des tests, intégrations, approbations, etc. forment dans leur ensemble un pipeline logiciel. Mais si quelqu’un veut effectuer une mise à jour de l’environnement lui-même (installer des correctifs pour le système d’exploitation), celle-ci s’opère séparément, parallèlement au processus de build de l’application, et ce n’est qu’à la prochaine exécution du pipeline que les éléments mis à jour seront pris en compte. Ceci peut arriver tardivement dans l’exécution du pipeline si bien qu’une application peut ne pas subir tous les tests avec ce nouvel environnement.

Avec Docker, un changement du code déclenche l’exécution d’un pipeline de Déploiement Continu, mais le fait de pousser une nouvelle image de base de Docker (du système d’exploitation par exemple) déclenche aussi l’exécution de tout pipeline consommateur de cette image. Comme les images de Docker peuvent être interdépendantes, l’installation de correctifs d’un système d’exploitation peut déclencher la mise à jour automatique des images de serveurs de bases de données et d’applications, et à son tour l’exécution de n’importe quel pipeline qui consomme ces images de serveurs de base de données/applications ! Un pipeline de Déploiement Continu n’est seulement plus réservé aux seuls développeurs et à leur code source. Développeurs et équipe IT Opérations peuvent désormais partager le même pipeline pour tous leurs changements. La sécurité et la sûreté d’une organisation IT s’en trouvent nettement grandement améliorées. En effet, face à un problème de sécurité de grande ampleur (comme la faille Heartbleed), les équipes IT Opérations peinent souvent à s’assurer que les correctifs ont bien été installés sur toutes les machines en Production. Comment être certain qu’aucun serveur n’a été oublié ? Avec un pipeline de Déploiement Continu à base de Docker, toute dépendance vis-à-vis de l’environnement est explicitement déclarée comme telle dans le cadre du pipeline.

Même si votre application n’a rien à voir avec Docker ou qu’elle ne sera pas elle-même une image Docker, vous aurez toujours intérêt à la créer et la tester sous forme conteneurisée. Pour les tests, vous aurez l’impression d’avoir un ordinateur entièrement à vous, abstraction faite que l’application est plutôt emprisonnée. L’image Docker devient un exécuteur éphémère, créé et détruit des centaines de fois par jour. Chaque job de test s’exécute dans un environnement entièrement virtualisé qui n’est ni visible, ni accessible par aucun build concurrent et chaque exécuteur est jeté à la fin de chaque build (ou réutilisé par un prochain build, si c’est ce que vous souhaitez).

Le fait de concentrer les efforts de développement et de test dans un conteneur présente aussi l’avantage de dispenser l’équipe IT Opérations d’administrer les environnements de Build et de les entretenir, tâche pénible mais essentielle dans un environnement IT bien géré. Les développeurs et équipes DevOps peuvent créer et gérer leurs images personnalisées tandis que les équipes IT Opérations mettent à disposition des environnements neutres génériques. L’adoption des images Docker présente de nombreux avantages en contrepartie d’efforts minimes.

A mesure que l’industrie s’habituera aux applications basées sur Docker, on verra apparaître des conteneurs individuels pour une application ou un service au sein d’une architecture à base de microservices. Dans ce monde de microservices, les outils de gestion de flotte de conteneurs comme Docker Swarm+Compose, Mesos et Kubernetes utiliseront les conteneurs Docker comme des modules de déploiement d’applications complexes. En évoluant vers ce degré de sophistication, ce besoin de construire, tester et livrer un ensemble de conteneurs deviendra critique.