Introduction au dossier : Conteneurs : utilisation avancée & microservices

Voilà maintenant quelques années que nous entendons parler d’immutabilité, mais aussi de mise à l'échelle, et ce souvent dans les environnements conteneurisés, comme avec les workloads dans Kubernetes. Mais n'est-ce pas aussi de plus en plus le cas également avec les machines virtuelles ? Que ce soit lors de la configuration d'une machine virtuelle de bac à sable, par exemple pour tester de nouvelles fonctionnalités (chose que je dois faire au quotidien, et qui serait tout simplement insupportable si je n'automatisais pas le bootstrap de la machine), ou lors de la mise à l'échelle d'un workload, l'automatisation de la configuration n'est pas une option, mais une nécessité.

S'il y a bien une nouvelle à laquelle vous n'avez pas pu échapper fin 2020, c'est l'annonce que Docker était obsolète dans Kubernetes. Mais alors, s'il n'y a plus Docker, comment exécuter nos conteneurs ? Bienvenue à la Container Runtime Interface (CRI).

La vélocité, voici un concept phare qui a guidé l'innovation de ces dix dernières années. Mais qu'est-ce que la vélocité ? Certainement pas d'écrire son code plus vite, mais bien d'avoir la boucle de feedback la plus courte possible. Et pour obtenir ce résultat, il faut réduire le cycle de release à son strict minimum.

Le processus de créer une image Docker est toujours sujet à débat : il y a les pros Dockerfile et les antis, ceux qui pensent que c'est simple, et ceux qui ne comprennent pas pourquoi cette responsabilité devrait « shifter » vers eux. Et c'est vrai, créer une image Docker n'est pas si simple : on ne s'improvise pas expert en packaging du jour au lendemain. Par chance, il existe une alternative out-of-the-box au classique Dockerfile : les Buildpacks.