Industrie Mag - Le journal de l'industrie.

Docker, on le sait, est un format de conteneurs applicatifs qui permet d’automatiser le déploiement d’applications. Empaquetés dans des conteneurs virtuels, celles-ci peuvent être exécutées sur n’importe quel serveur sous Linux, et bientôt sous Windows. Ce qui a pour résultat d’étendre leur flexibilité et leur portabilité d’exécution sur une machine locale ou mieux encore sur un cloud privé ou public.

En outre, contrairement aux machines virtuelles traditionnelles, les conteneurs Docker n’incluent pas de système d’exploitation, et s’appuient sur les fonctionnalités de l’OS de la machine hôte. Ils occupent donc moins de place en mémoire que les images des machines VM, et sont plus rapides à créer et à démarrer.

Ces avantages font de Docker une technologie parfaitement en phase avec DevOps et les méthodes agiles, car toutes deux répondent aux mêmes objectifs poursuivis par un nombre toujours croissant d’entreprises : automatiser et industrialiser le déploiement et la configuration des applications, en gagnant à la fois en rapidité, en sécurité et en souplesse. Rien d’étonnant donc que cette technologie devienne peu à peu un standard, en particulier pour les architectures micro services dans les grands comptes, et même pour la livraison des applications par les éditeurs.

Définir clairement la répartition des responsabilités

Reste que la mise en œuvre d’une architecture Docker n’est pas exempte de risques, spécialement du point de vue des équipes des hébergeurs dans le cloud.

En effet, par essence, elle accorde une large autonomie aux équipes de développement, qui sont seules responsables du choix des composants applicatifs – code, librairies et binaires – qui figurent dans les conteneurs. Ceci a pour conséquence un déport de responsabilités par rapport à une architecture classique, où ce sont les équipes système ou celles de l’hébergeur qui sont responsables de ces éléments. Ce qui peut rapidement entraîner des risques potentiels de sécurité. De fait, en cas d’existence d’une faille de sécurité sur un composant, l’hébergeur ne peut pas intervenir de son propre chef, d’une part parce qu’il n’a pas une connaissance précise des composants figurant dans le conteneur, d’autre part parce qu’il n’a qu’un pouvoir de préconisation.

Le risque pour l’hébergeur est donc d’être confronté en production à une population croissante de conteneurs non maîtrisés.

Pour l’éviter, il est nécessaire que la répartition des responsabilités soit clairement définie dès le départ entre les équipes de développement et celles de l’hébergeur. Des échanges d’informations doivent être instaurés entre elles au quotidien, allant au-delà des échanges contractuels au sein des comités de suivi et de pilotage. Les méthodes agiles peuvent évidemment y contribuer, dans le cadre de cycles d’amélioration continue.

Pas encore d’outils efficaces de supervision

Ces échanges sont d’autant plus nécessaires que l’environnement Docker manque encore d’outils efficaces de supervision, permettant de référencer automatiquement les composants figurant dans les conteneurs. Certes, certains existent déjà, mais ils sont encore perfectibles, et d’autres apparaissent régulièrement.

Ceci met en lumière un paramètre supplémentaire à prendre en compte pour les entreprises. La maîtrise de la technologie Docker exige toujours des compétences élevées et une bonne expérience du monde et de la communauté open source. L’écosystème Docker est en effet un environnement très dynamique, en évolution rapide, où de nouveaux composants apparaissent régulièrement. Les équipes doivent donc rester constamment à l’écoute de la communauté, et être prêtes à remplacer un composant par un autre s’il s’avère plus performant dans une configuration donnée. Un élément différenciant lorsqu’il s’agit d’évaluer le choix d’un prestataire ou un retour sur investissement.

http://www.docker.com/