Blaskow David

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é.

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.

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.

Nos interactions avec les ordinateurs (et autres smartphones) sont dignes du Moyen Âge. Qu'est-ce qui a réellement changé en la matière, ces 50 dernières années ? Rien : nous avons juste remplacé notre bon vieux clavier mécanique par un clavier virtuel, la belle affaire ! Pourtant, nous pouvons faire mieux, et nous devons faire mieux : bienvenue dans l'ère des assistants vocaux virtuels ! Nous allons découvrir ensemble ce qu'ils sont, et créer notre première application vocale.

J'aime par-dessus tout les choses simples et, selon moi, si je dois faire la même chose deux fois, c'est qu'il est temps d'automatiser. Quand je développe une application, j'ai régulièrement besoin de la déployer et de la tester ; aussi, j'ai mes astuces. Mais depuis quelque temps, je dois aussi conteneuriser cette même application, et voilà maintenant que je dois également la kuberneteuriser. Et mxxxx !

Combien de fois m'avez-vous entendu dire « nous allons utiliser kubeadm pour faire ceci ou faire cela », et puis boum, un kubeadm init plus tard, tout est prêt ? Souvent ? Très souvent ? Trop souvent ? Alors pour une fois, pourquoi ne pas consacrer un article entier à ce merveilleux projet ?

Il y a tout un tas d'expressions qui prêtent à réfléchir, comme : il n'y a rien de mieux que de ne rien faire, ou il n'y a que ceux qui ne font rien qui ne se trompent pas. C'est plus ou moins ce qui est mis en application dans une chaîne de CI/CD : au moindre commit, une foule de petits robots se mettent en branle pour faire tout le nécessaire au déploiement de nos applications. Et si nous nous penchions sur toute cette machinerie ?

Les dissidents ont mon oreille. J'ai toujours aimé les articles qui prenaient les modes à contre-pied, comme d'imaginer abandonner Docker et Kubernetes pour revenir à LXC. Cependant, je ne suis pas convaincu par ce retour en arrière, tant il est possible d'à peu près tout faire avec Kubernetes, comme d'y faire tourner des machines virtuelles !