Jérôme Petazzoni lors du TIAD

Docker, et d’une façon plus générale les containers, ont largement contribué à rédéfinir le paysage de l’IT et la façon dont les applications sont distribuées. Jérôme Petazzoni, ingénieur Docker, répond à nos questions sur le positionnement de Docker dans ce nouvel éco-système de l’IT.

Comment Docker répond à cette nouvelle façon de faire de l’IT, impulsée par le cloud et le continuous delivery ?

Docker fournit un outil qui permet de répondre facilement aux enjeux actuels de l’IT. Nous sommes aujourd’hui tous conscients de la nécessité d’automatiser tout ce qui est répétitif, soit toute tâche qui doit être faite plus d’une fois. Le challenge auquel répond Docker, c’est de rendre cela possible pour ceux qui ne sont pas des développeurs ou des OPS chevronnés. L’objectif est de pouvoir aider ceux qui font du développement, du déploiement, quel que soit leur niveau d’expérience.

Comment se positionne Docker par rapport à des produits concurrents ?

On peut considérer qu’il y a deux “fronts” : la virtualisation classique, et le configuration management : Chef, Puppet, Ansible, Salt… Sur le sujet de la comparaison avec VMware et les VM traditionnelles, je citerai un très bon article de mon collègue Eric Windisch : la question n’est pas container ou VM, mais container ET VM. En matière de sécurité on ne choisit jamais une seule solution, mais un ensemble de couches que l’on ajoute pour se protéger. Les VMs apportent une isolation très forte, robuste, éprouvée dans le temps, et les containers servent de mécanisme de livraison de mon code. De la même façon que je peux déployer des packages, je peux déployer des images de containers embarquant toutes les dépendances dont j’ai besoin pour tourner. Mais je continue de tourner dans des VM.

Certains veulent faire de la très haute densité, se débarasser du surcoût des VMs et utiliser des containers. Pourquoi pas ? Il faut cependant être conscient de ce qui est enlevé, et pouvoir le remplacer. Des mécanismes de sécurité existent, mais ils sont loin d’être triviaux à mettre en place : SE linux (SecurityEnhanced Linux), secure computing… Ces mécanismes permettent de blinder les containers, mais aujourd’hui pour être capable de se passer de VM, il faut vraiment savoir ce qu’on fait.

Ensuite, le configuration management. Dans ce contexte, il y a en effet une partie du travail du configuration management qui va être faite par Docker. Installation des dépendances et bibliothèques de mon application, installation et compilation de mon application…de plus en plus, ces tâches vont etre gérées avec des Dockerfile. Pour les développeurs, il est plus facile de raisonner et maintenir un Dockerfile que de faire du configuration management. Pour un ops ou un sysadmin aguerri, la question ne se pose pas. S’il utilise Ansible, pourquoi changer? Et pour ceux qui ont déjà du configuration management en place, pas de raison de changer non plus. Par contre, dans l’optique de rendre les développeurs plus autonomes, de faire en sorte qu’ils ne sollicitent pas les ops à chaque fois changement de déploiement ou ajout de dépendances…ce périmètre peut alors être confié à Docker. Que Docker empiète un peu sur le territoire du configuration management n’est pas une mauvaise chose : cela va rendre la stack dans son ensemble plus maintenable, car elle sera opérable par plus de gens.

Quels seront les métiers et technologies de demain ? Pourquoi se diriger vers Docker par exemple ?

Les raisons pour lesquelles les gens utilisent docker sont variées en fonction du contexte. Dans les grosses usines logicielles avec de nombreux développeurs et beaucoup de projets, l’onboarding (le temps nécessaire pour qu’un développeur soit opérationnel sur un projet) est quelque chose que Docker adresse très bien. Par exemple chez Wordline, l’onboarding a été réduit de 2 jours à 2 heures grâce au dockerfile et à Fig. C’est énorme, surtout dans le cas de projets où le développeur ne vient que pour une petite fonctionnalité ou un correctif de bug. Imaginez s’il n’y a qu’une journée de travail: le gain d’on-boarding est plus que significatif. L’onboarding est un enjeu capital, particulièrement pour les grosses structures.

Autre cas de figure, du développement pur web sur une technologie comme Drupal, Plone ou une pile Django préconfigurée : il est alors possible de tirer parti de Docker dans la mesure où toutes les technologies citées disposent souvent d’un mécanisme de gestion de version de déploiement (Composer, Build Out….). Utiliser des Dockerfiles permet de simplifier la donne, d’avoir un outil aussi efficace que ceux spécifiques existants pour chacune de ces stacks, mais qui a le mérite d’être transverse. Apprendre Composer pour déployer du PHP ne m’aidera pas à déployer une appli Python. Ou Build Out ne m’aidera pas non plus pour déployer du Java. Docker offre un couteau suisse qui va répondre à la très grande majorité du besoins et sera portable d’un projet à l’autre, au lieu d’être spécifique à une technologie.

Et le consultant IT, doit-il devenir un couteau suisse ? Est-ce la fin de l’ère des spécialistes ?

Je ne suis pas certain d’être bien placé pour en juger. Durant mon parcours, j’ai appris beaucoup de technologies différentes dans des contextes différents. Je pense que l’hyper-spécialisation est toujours dangereuse en termes d’employabilité, surtout sur des technologies en évolution. On aura toujours besoin d’un spécialiste Cobol, mais pour quelqu’un qui est spécialisé en PHP4, c’est peutêtre plus compliqué. Je n’ai pas vraiment de réponse instruite, mais j’ai envie de répondre que oui, il faut continuer à apprendre et à explorer, c’est la seule façon de remettre en question les choses et le fameux “On a toujours fait comme ça avant”, qui est une des phrases les plus dangereuses de notre langage.

Formations Docker à Paris