docker logo

Il existe déjà bon nombre de documentations ou références concernant l’éco-Système Docker, notamment une première approche sur notre Blog au Canada. Nous souhaitons au travers cet article compléter notre vision d’un monde container « idéal » d’un point de vue OPs.

Containers et Machines virtuelles, à ne pas confondre mais complémentaires

En guise d’introduction, même si ce sujet a été de nombreuses fois abordé dans les différents blogs, meetup, conférences, etc., il est très important de bien faire la distinction entre machines virtuelles et containers. Sans rentrer dans les détails techniques des différences entre ces solutions, il est primordial de ne pas confondre les apports et bénéfices de chacun. Considérer les containers comme des VMs (ou micro VMs) est une mauvaise approche pour appréhender Docker et pour vraiment tirer parti des avantages des containers (ou des machines virtuelles). Chacun apporte des bénéfices que l’autre n’apporte pas même si la frontière est parfois floue. VMs et containers ne sont nullement exclusif, voir même souvent complémentaires. L’isolation apportée par la virtualisation, aussi bien d’un point de vue consommation des ressources que de sécurité et cloisonnement, n’est pas comparable à ce qu’apporte Docker sur ce domaine.

Résoudre les problématiques liées au cycle de vie de l’application

Dans ce cas, qu’apporte Docker ? Quand dois-je l’utiliser et surtout pourquoi l’utiliser ? Que va m’apporter l’utilisation des containers ? Quels sont les éléments à bien prend en compte dans le développement d’un projet reposant sur Docker ? Le mieux est d’expliquer cela via un cas d’usage.

Docker s’inscrit dans la mouvance des architectures de type micro-services : l’application est décomposée en briques élémentaires simples et faiblement couplées. L’avantage de ce modèle d’architecture est la simplicité de maintien (d’un point de vue fonctionnalité, développement mais aussi opérationnel) : il est plus simple de faire évoluer une brique élémentaire qu’une application monolithique complexe. Les containers Docker suivent ce modèle : chacun d’entre eux est spécialisé et ne fait tourner (idéalement) qu’un seul service, processus, fonctionnalité. Les containers Docker doivent être vus comme des éléments volatiles (doivent pouvoir être détruits et recréés à l’identique depuis l’image) et immuables (aucune modification au sein d’un container, les évolutions passent par la fourniture d’une nouvelle image qui viendra remplacer l’ancien container).

On parle alors d’infrastructure immuable. Docker permet donc de résoudre de nombreuses problématiques liées au cycle de vie de l’application :

  • Reproductibilité et portabilité des développements : l’image Docker n’a comme seule adhérence technique que le démon docker. C’est d’ailleurs le slogan de Docker : « Build, Ship, Run Any App, Anywhere »
  • Agnostiques aux socles OS (distributions, noyau Linux et versions applicatives fournis par les éditeurs) : toutes les librairies, démons et configurations nécessaires au fonctionnement de l’application sont intégrées au sein de l’image Docker.
  • Isométrie des déploiements : la même image est utilisée tout au long du cycle de déploiement de l’application de l’environnement de développement jusqu’aux  serveurs de production.
  • Facilitation du process de mise à jour de l’application : les images Docker sont versionnées et permettent une mise à jour simplifiée et maîtrisée. Le process de rollback est aussi simplifié : on redéploie la version précédente de l’image.

Finalement, tous ces éléments améliorent la productivité des équipes de développement, le « time to market » de l’application ou des nouvelles fonctionnalités ainsi que la simplification du cycle de vie de l’application.

Docker permet également de répondre plus rapidement au besoin d’évolutions des applications et aux fonctionnalités attendus par le métier (agilité).

Les points de vigilance

Cela dit, l’adoption de Docker pour un projet de production nécessite également de bien prendre en considération un certain nombre de points de vigilance.

  • Tout d’abord, sur le respect des best practices d’utilisation de Docker (approche micro service, gestion des données persistantes, immuabilité des containers, appétence à la technologie, …)
  • Egalement, la gestion de la sécurité des images est l’un des sujets récurrent lié à l’utilisation de docker.Les images publiques présentent sur les registry Docker, ne sont pas exempte de failles de sécurité. Certaines bénéficient d’un réel suivi, d’autres moins.
  • Un service d’analyse de vulnérabilité d’images va également être proposé par Docker, afin d’améliorer la qualité des images des registry publics. C’est également un sujet sur lequel LINKBYNET travaille activement, afin de pouvoir proposer des outils et méthodes pour améliorer l’aspect sécurité des applications Dockerisés  et accompagner les développeurs à la détection et corrections des éventuelles failles qui pourraient apparaître durant la vie de l’application.

Il est donc primordial que les images Docker soient suivies dans le temps par les développeurs d’applications et qu’une TMA (Tierce Maintenance Applicative, soit un suivi pour les correctifs, etc. et ce, pendant toute la durée de vie du projet) soit bien intégrée dans toute demande de développement  reposant sur l’utilisation de Docker.

L’importance de l’infogérance Dockerimage graphic docker

Comme évoqué précédemment, l’image Docker n’intègre pas uniquement l’application (code ou binaire), mais potentiellement un middleware, des librairies, des daemons, etc. Là ou dans un contexte VM  ces éléments peuvent faire partie du périmètre d’infogérance de Linkbynet (installation, configuration, patching, fine tuning, etc.), les containers se retrouvent dans le périmètre du développeur. Par exemple, une montée de version du serveur nginx dans un container passera par la fourniture d’une nouvelle image construite et validée par les développeurs qui intégrera cette nouvelle version. LINKBYNET, de par son expertise sur les couches middleware et serveurs d’applications, peut néanmoins résoudre ce problème. Nous apportons du conseil, de l’expertise et de l’accompagnement auprès des agences de développement pour mieux appréhender, configurer, fine tuner et faire évoluer ces composants qui constituent un nouveau périmètre historiquement non présent dans le développement d’application (fourniture de code répondant à des attentes métier).

L’illustration des périmètres entre le monde VM et le monde Container. Il illustre au passage, les différences techniques entre une machine virtuelle et un container (partage de l’OS linux pour les containers) montrant qu’un container est plus léger qu’une VM et permet potentiellement une mutualisation et une consolidation plus importante des infrastructures.