new Blog( perso );

Google vient d'annoncer un nouveau runtime pour les containers OCI (les images Docker quoi) : gVisor.

Décryptage. (je pique les illustrations de la page gVisor parce que j'ai la flemme de les refaire)

Linux n'a pas de concept natif de "container", contrairement à BSD avec ses Jails ou à Solaris avec ses Zones. Ce qu'on appelle un "container" n'est donc que l'émergence d'en empilement de divers mécanismes de sécurisation et d'isolation. En un sens c'est pratique parce qu'on peut tuner tout ça et désactiver deux ou trois trucs quand on en a besoin, mais quid de la sécurité du machin en termes de "sandbox" qui permet d'exécuter du code arbitraire sans risquer d'exposer la machine ?

Le runtime à la Docker (containerd) met en place l'arsenal mis à disposition par les noyeau Linux : isolation de visibilité des ressources (namespaces), restrictions (cgroup) et filtres sur les appels noyeau (capabilities, seccomp, apparmor, SELinux). En gros, on sait imposer que telle application a droit d'accéder à tels fichiers, uniquement en lecture, et avec un débit I/O de xx maximum, ce qui permet aux autres application d'avoir aussi des ressources I/O et de placer leur propres données sur le même disque sans risque.

Configuré correctement - la conf par défaut étant déjà pensée pour permettre tout ce qui est raisonnable à une application standard, et bloquer tout ce qui clairement n'est pas justifié - on est en principe à l'abris de tout débordement de la part d'une application malveillante / malcodée / lesdeuxmoncapitaine.


Notons au passage que le support du user-namespace dans Docker est encore minimal (et désactivé par défaut). C'est lui qui permet d'être "root" dans le container mais en fait non, utilisateur non-privilégié sur le système hôte. Idéalement chaque container devrait tourner avec un user ID distinct, comme on fait tourner les divers services d'un système Unix avec des uid/gid différents pour bien isoler qui a droit de faire quoi. Fin de la parenthèse

Bon ça c'est en théorie, parce qu'évidemment tout ça repose sur la solidité de ces mécanismes, et donc sur l'absence de bug dans le noyau. On a pu voir passer quelques articles détracteurs, à charge contre Docker, qui mettent en lumière un problème de partage de ressources au niveau du noyau lorsqu'un container a un comportement particulier, et qu'il finit par pénaliser les autres. On ne parle pas d'escalade de permission ou de fuite d'information, mais c'est déjà un soucis. Dans les articles que j'ai lu le problème était résolut en faisant une mise à jour du noyau (!). Bref, tout repose sur les épaules du noyau et de ses mécanismes de partage équitable et de protection des resources. Et même avec toute la bonne volonté du monde on se doute qu'il y a toujours un risque.

D'où l'idée de ne pas partager le noyau entre containers, et d'avoir un noyau par container. C'est le principe de KataContainers, la fusion des projets ClearContainer (intel) et runV (hyper). Dans les deux cas, on utilise un hyperviseur KVM et un noyau minimal dédié à chaque container. Ce n'est pas magique, ici aussi la machine hôte doit assurer un partage équitable et sécurisé des ressources entre les différentes machines virtuelles + container. Mais en ajoutant cette indirection on limite le risque qu'un bug donné dans le noyau expose significativement la machine hôte.


La partie "virtual hardware" est là où le bâs blesse : Si vraiment on émule le CPU, les disques, la mémoire ... on va se retrouver avec les performances d'un MO5 (c'est d'ailleurs comme ça qu'on fait un émulateur MO5 sur PC, mais c'est une toute autre histoire).

Vous vous doutez bien vu l'utilisation massive de VMs dans le Cloud que ça ne fonctionne pas comme ça : le "hardware" exposé à la machine virtuelle est une version pré-machée, super facile à utiliser, et qui fait passe plat avec les drivers du système hôte. Le noyau de la VM hébergée dispose lui aussi du driver qui va bien pour utiliser ce "hardware" tellement simple que le code fait quelques lignes (bon, quelques centaines, ça reste du code C :P).
On gagne en simplicité - donc on limite les risques de bugs => faille de sécurité - et en performances.

Cette technique de "para-virtualisation" (virt-io) permet de conserver une certaine isolation sans renoncer à la performance. Elle est parfois implémentée niveau hardware, en particulier par le CPU - sans quoi les machines virtuelles râmeraient dur dur, mais aussi sur certaines architectures par le contrôleur mémoire ou encore l'interface réseau...

Bref, les VMs ça marche (non, sans blague ?) et ça permet d'avoir ceinture + bretelle, ce qui est la tenue préférée de l'expert sécurité (sous son gilet pare-balle).

Ok donc qu'est-ce que gVisor vient faire là dedans ?

gVisor veut lui aussi séparer le noyau utilisé par un container du noyau hôte. Pour cela il utilise une technique qui n'est pas nouvelle : User Mode Linux avait déjà exploré la même approche, et le fait que le site soit sur sourceforge vous donne une idée de son ancienneté.

L'idée est de démarrer un process classique en user-space (pas root quoi) qui va servir de noyau à un sous-système hébergé, mais sans couche de virtualisation comme le propose un hyperviseur. Les appels systèmes que l'application fait au noyau hébergé sont alors implémentés sur la base des resources légitimes allouées au process.

Soucis principal : comment faire pour qu'un process standard intercepte les appels systèmes (qui par définition sont ... au coeur du systèmes donc dans le noyau). L'approche utilisée par UML et gVisor est de détourner ptrace, outil de debug Posix, qui permet en gros d'avoir un point d'arrêt sur tout appel système et de répondre à la place du noyau. Un bon gros hack quoi. Ca marche, mais c'est pas gratuit en termes de performances. Sans surprise d'ailleurs, c'est conçu pour du debug !

gVisor par ailleurs utilise un noyau développé en Go par Google. Alors je veux bien croire qu'ils sont très, très bon et que gVisor ne sort pas d'un chapeau, mais celle là je l'avais pas vue venir. Quand je parlais de re-coder Jenkins en Rust c'était pour la blague, coder un noyau OS en Go c'est, heu ... disruptif ?

Mais bon, admettons. Après tout ce "noyau" n'est là que pour filtrer ce qu'on veut bien exposer au container et produire une implémentation simple puisqu'il se base non pas sur du hardware mais sur un système Linux avec tout ce qu'il faut.

Malgré tout je reste perplexe : Certes ce pseudo-noyau permet d'expose quelque chose de plus propre au conteneurs que le fait un runtime Docker :

D'un côté de "vrai" mounts (bien camouflés quoi), de l'autre des montages qui montrent bien le runtime sous-jacent.

Certes ce noyau écrit exprès pour ça peut mettre en oeuvre des choses qui n'auraient aucun sens dans le noyau Linux upstream. Certes Google a une expérience sur le sujet qui lui permet d'être crédible. Il n'en reste pas moins que ça me semble étrange de développer une pile réseau dans ce Go-noyau là où Linux propose des pile réseau virtuelles (veth) depuis des lustres, et qui a priori donne satisfaction à tout le monde. Il y a donc une volonté de prendre le contrôle sur certains détails très fins de ces aspects, qui ne sont pas (encore) documentés

Ce qui m'amène au point principal, plutôt que de débattre des choix techniques : quel est le cas d'utilisation qui justifie tout ça ? Clairement ce n'est pas prévu pour un usage mainstream par Mme Sysadmin-Michu. Et ça, je l'ai pas trouvé dans la doc.

Mon hypothèse, indéniablement fausse, mais je la propose quand même :

Un noyau linux complet, même utilisant virt-io, est bien trop complexe et "intelligent" pour un contexte aussi trivial qu'une mono-application dans son conteneur, ce qui augmente les risques de bugs. L'idée de Google est donc d'avoir un noyau débile épuré qui n'expose que le strict nécessaire, avec une logique interne ultra-simple pour limiter les failles, puis de passer la main à un "adulte" pour ce qui est de la gestion plus délicate du vrai hardware.


Ce qui m'embête c'est que ce cahier des charges c'est ... celui de seccomp :-/ Ce serait donc une approche alternative pour ne pas se baser sur seccomp qui

1. tourne en espace noyau
2. ne permet de filtrer que partiellement les paramètres des appels (valeurs directes). Limitation que n'a pas Landlock qui lui succédera peut-être ?

Je ne pense pas qu'on ai du gVisor en production tout de suite (!). Il n'en reste pas moins que l'approche pose des questions, et que je n'arrive pas à trouver des réponse satisfaisantes. Autant dire que je ne vous ai sans doute pas donné la réponse que vous attendiez peut être dans cet article. Poussez-moi des commentaires si vous avez lu des infos intéressantes dessus ou un avis sur la question.

Autre point noir : gVisor n'a pas de logo, et ça c'est nul quand on cherche une illustration pour un billet de blog. Du coup tant pis pour vous, je vous met un David Gageot à la place.

Don't bind-mount docker.sock !

securityContext: 
    privileged: true 

Privileged ?

So, is DinD such a bad idea ?

As new maintainer for this plugin, I just released 0.17. You should see it in Jenkins update center within few hours.

Plugin used to have version 0.xx as the internal API might change at any time, but has been adopted by thousands people, so I think it's time to get a 1.0. That being said, for my first release I preferred to not break everything at once, and only made few fixes and improvements. I plan to have some more 0.x fix versions if required, but next one should be 1.0.

What's new ?
First, I migrated to docker-commons for credentials management (docker API and registry). If you use docker-pipeline this is something you're familiar with. As a side effect you might need to reconfigure your jobs and/or agent templates.

I also introduced an experimental "attached" agent launcher.
Jenkins require a communication channel for the master to control the agent. Any transport protocol is fine, so depending your infrastructure you might rely on SSH or JNLP. But Docker offers an alternative : you probably are used to run docker CLI in interactive, "attached" mode



Here Docker CLI uses the plain Docker API an upgrade HTTP protocol to establish a long running terminal session with the container. Jenkins can rely on this stdin/stdout transport to setup required Jenkins remoting channel.

This feature relies on docker-java support for attached mode, my experiments so far demonstrated it works well, but only tests at scale will prove it really works as expected. So please give it a try and let me know :P

What's next in docker-plugin ?

Major point I want to address is lack of support for docker swarm mode. This one would offer Jenkins a scalable build infrastructure. But this will also require some tweaks, as Docker service API is way less powerful than the plain container API. It can't for sample inject some content in a container, or exec inside a container to run some additional commands. So probably this will introduce some constraints, but need to experiment more to know the actual options we have here.

C'est l'été, et ce blog va donc - une fois n'est pas coutume - me permettre d'exprimer une petite critique cinéma.

générique.




Je suis donc allé voir Valérian, l'occasion de partager un moment avec mes deux grands, de leur parler de cette BD qui a bercé mon enfance et que j'ai adoré et relu de nombreuses fois (merci à la BDThèque de Brest).

---

Avant d'entrer dans la salle obscure, j'ai lu des critiques plutôt négatives sur le film, et j'avoue ne pas m'y reconnaitre après séance.

Comprenez bien que ce n'est pas une transcription de la BD à l'écran, ce qui aurait été très différent. D'une part la BD a elle même beaucoup évolué dans son style entre le premier album et le dernier opus, ensuite le rythme et le type de narration n'ont pas grand chose à voir dans ces deux formats. Le film est un vrai film, avec la dynamique liée au format "image grand format", avec un scénario taillé pour un format de 2h, mariant action, sentiments, humour, etc.

Je vois deux pièges possibles dans ce genre d'adaptation

1. le pur fan-service : le film que seuls les amoureux de l'oeuvre originale peuvent comprendre.
Le ire du genre : Final Fantasy Advent Children. Si t'as pas joué au jeu vidéo tu pige juste rien

2. le foutage de gueule hollywoodien : le film qui raconte un truc avec plein de références empruntés à l'oeuvre originale mais qui la dénature pour tenter de tenir un scénario.
Typiquement: Mission Impossible (qui fait de Jim Phelps un traitre ... sans commentaire)


Valérian évite ces deux écueils, en proposant un vrai film qui reprend les éléments de l'univers de la BD, quelques personnages clés, mais surtout la diversité biologique qui caractérise cette fiction, jusque dans le détail d'une humanité à l'origine de la station Alpha "des milles planètes" et pourtant en plein déclin, et qui craint de s'en faire exclure.

Niveau casting, j'étais sceptique du choix de Dane DeHaan, un peu trop "ado" a mon avis pour ce role, mais au final ça passe bien. Quand a Cara Delevingne elle incarne une parfaite Laureline : sexie mais pas bimbo, fière, déterminée, vaillante... et la doublure voix Française lui donne un charme fou.



Niveau image, on navigue dans un environnement graphique élégant, riche et régulièrement renouvelé, qui reproduit très fidèlement l'imaginaire de la BD en terme de "diversité biologique". On a aussi droit à une bonne dose d'images 3D, surtout dans les scènes d'action aux travelings improbables, sans pour autant se perdre dans des plans séquence épileptiques à la Tranformers.

J'avoue être un peu partagé sur la présence de Rhianna au casting, dont le rôle est au final un peu artificiel : même s'il permet d'apporter un moment différent dans le rythme du film qui n'est pas du tout inutile, la sortie du personnage est un peu rapidement balayée par la suite des événements. Ce serait peut être le seul reproche que j'aurais à faire.



J'ai pu lire des reproches sur les similitudes avec Blade Runner, Star Wars ou Avatar. Ce serait peut être oubliée que la BD a commencé en 1967 et que c'est plutôt elle qui a inspiré (directement ou indirectement) les réalisateurs de ces films - lire cet article.

Idem pour le look des Pearl, habitants de Mül, qui rappellent forcément Avatar. Mais bon, nos canons de beauté étant assez limités il est difficile d'éviter ce stéréotype dans un film grand public : grands, minces, des traits doux et lisses, une relation harmonieuse avec la nature ... ce que l'humanité aimerait être quoi. Alors oui, ils auraient pu avoir de petites ailes dans le dos. 

One also have to create a JSON descriptor for the plugin. There's various options in this file, but for this simple plugin descriptor is trivial:

{
  "Description": "Authorization plugin for Docker",
  "Documentation": "https://github.com/ndeloof/authobot/blob/master/README.md",
  "Entrypoint": [
    "/bin/authobot"
  ],

  "Interface": {
    "Socket": "authobot.sock",
    "Types": [
      "docker.authz/1.0"
    ]
  }
}

We can now register this plugin on docker daemon and enable it

docker plugin create authobot .
docker plugin enable authobot

Here, the funny thing is that the plugin is enabled, but not in use. #plugin channel on Docker slack was a great assistance for me to understand the issue. Thanks a lot to Brian Goff for taking time to assist a noob :P

Authorization plugins have to be explicitly set as docker daemon options, and can't be enabled/disabled from the API. It makes sense as one could then use the API to disable authorization :-\ but makes the code/deploy/test cycle bit more slow and annoying.

So let's now actually enable the plugin :

sudo vi /var/lib/boot2docker/profile

(adjust to your docker installation if you don't use a boot2docker VM)

Add --authorization-plugin=authobot to docker daemon arguments

restart daemon :

sudo /etc/init.d/docker restart

Step 5 : Done!

My docker daemon now accepts the few API I've whitelisted, but nothing much

$ docker run -it ubuntu echo 'hello world!'
hello world!

$ docker ps
Error response from daemon: plugin authobot:latest failed with error: AuthZPlugin.AuthZReq: /v1.30/containers/json is not authorized

J'écris ce billet en réponse à l'article "filmer le web" de Thomas Gasc, vu que son blog ne permet pas de laisser de commentaires :P


J'ai déjà vu un meetup ne capter que les slides et le son, et ne pas filmer le speaker. Ben au final la vidéo est tout aussi utile, même si elle manque inévitablement de vie.

2. Ne pas être intrusif. Exemple type : l'éclairage. Oui, pour filmer, il faut de la lumière. Et oui, pour que les slides soient lisibles, il en faut le moins possible. 

En tant qu'orga, je privilégie les gens qui sont venu physiquement au meetup, donc si la lumière les dérange je demanderai de la couper, tant pis pour la captation (de toute façon, voir 1.)

En tant que speaker, un spot dans la tronche ce n'est pas non plus très agréable. Un speaker chevronné sera un peu plus habitué, mais un novice peut être déstabilisé.

Le meilleur setup c'est de pouvoir décaler le speaker par rapport à l'écran, et de l'éclairer de côté avec deux projos plutôt directionnels et équipés de coupe-flux (les 4 plaques autour d'un projecteur de cinéma). Ca évite de tout lui balancer dans la tronche, ça fait une lumière plus jolie (la lumière de face écrase les ombres du visage) et les brise flux permettent d'épargner l'écran. 

Pour le BreizhCamp on a sorti les projecteurs de théâtre de 500W mais bien sur c'est €€€ et pas très portable, à la place sans investir beaucoup on peut bricoler un truc avec des petits projos LED.

Même règle de ne pas venir déranger le meetup pour ce qui est de la captation son (cf 1.) ou de la captation des slides, d'ailleurs ...

3. Capter les slides. Un speaker • euse qui parle avec les mains c'est sympa, mais un live coding sans voir le code c'est pas terrible. Filmer "large" pour capturer aussi l'écran de projection pose plein de problèmes, d'une part de luminosité, d'autre part de "piqué" (en général, c'est difficilement lisible).

La solution de facilité c'est le petit soft de capture qu'on installe sur le PC speaker. On va par contre à l'encontre de la règle 1., mais bon si le speaker est prévenu à l'avance ça peut être jouable.

Sinon, pour capter le signal HDMi on trouve aujourd'hui du matos adapté pour pas top cher. En gros, une carte blackmagic dans un boitier extension PCI sur USB-C, et on a un système de captation portable.

Attention à bien respecter le point 2: parfois le speaker a un setup exotique (un PC Windows 10 4k par exemple) et la captation merde. Dans ce cas, à meetup -2 minutes il faut accepter de laisser tomber la captation pour que le public puisse profiter du meetup, tant pis c'est la vie voilà.


4. Collaborer. J'avais dit qu'on ne parlerais pas matos et pourtant j'ai pas arrêté. Du coup se pose une question simple : les organisateurs de meetup - qui ont la plupart du temps des sponsors - peuvent-ils contribuer à l'achat de matériel ? Un éclairage soigné du speaker est nécessaire pour la captation mais peut être aussi utile de manière plus générale pour baisser la lumière générale et avoir des slides bien nets tout en gardant un speaker bien visible même du fond de la salle. 

De ce que je comprend (j'ai pas eu l'occasion d'en discuter de visu) Thomas débarque dans un meetup et se propose de filmer. Cool. Par contre les contraintes techniques apparaissent du coup au dernier / mauvais moment. En discutant plus en amont avec les orgas pour aménager un peu le meetup il est possible de mieux gérer tout ça et d'éviter ces mauvaises surprises. 


Bref  si vous voulez filmer un meetup, déjà essayez ! Ce qui précède ce ne sont que des conseils après plusieurs années de merdages répétés et de mauvais choix. Ne soyez pas forcément trop ambitieux, mais gardez les règles ci-dessus en tête. Je vous propose d'ailleurs cette progression :

1. Commencer par un bon enregistrement son. Accompagné du lien slideshare ça peut déjà être sympa. Style podcast. Si vous êtes courageux vous pouvez alors faire un montage slides + son. Ajoutez un écran d'intro avec la photo du speaker ça lui fera plaisir :P
2. Essayer de capturer la sortie vidéo ou de trouver un soft acceptable par vos speakers. J'ai pas de recommandation, perso j'ai horreur de ça (j'ai eu un gros plantage une fois, merci).
3. Filmez le speaker et faite un joli montage picture-in-picture comme les pros. 

Le 11 Juillet, JFrog organise le Jenkins Community Day à Paris, une excellente opportunité pour rencontrer ceux qui font Jenkins et découvrir toutes les nouveautés et tendances dans le monde du Continuous Delivery.



J'y serais présent en tant que speaker pour vous présenter l'évolution du couple Jenkins + Docker ces dernières années, et les pistes pour l'avenir - le tout en mode "Back to the Future", parce qu'on peut parler de choses sérieuse sans s'y prendre sois-même aux. (si vous connaissez une tournure correcte pour cette phrase sans répéter "sérieux" je suis preneur)



Si vous voulez m'y rejoindre, passez par ici pour obtenir une réduction sur votre inscription.

Chose promise, chose due

Voici donc la première vidéo qui marque le retour de "Quoi d'neuf Docker". J'y parle de Docker et de la Sécurité, un thème qui amène de nombreuses questions et pas mal de fantasmes. Je compte d'ailleurs faire une vidéo "follow-up" pour répondre à vos réactions/questions/corrections, donc n'hésitez pas à pousser un commentaire (sur YouTube).

Je vous annonçais dans un billet de décembre (décidément, ce blog n'est plus très prolifique...) mettre un terme à ma chaine Youtube "Quoi d'neuf Docker". Cet article avait fait suite à plusieurs mois à tenter de me motiver pour sortir une vidéo sur Docker Swarm, qui aurait fait suite à son lancement à la DockerCon'16. Enregistrée deux fois, la vidéo manquait du peps que je veux insuffler dans mes vidéos, le texte était bancal, les tentatives de montage laborieuse (si tu as de la merde en entrée...)

BREF, j'ai baissé les bras, à contre coeur, mais constatant mon incapacité à avancer

Depuis, j'ai reçu de nombreux messages d'encouragement ou de remerciement, qui paradoxalement me laissent un gout amer : j'ai merdé.

Vous m'avez fait confiance, vous m'avez encouragé, vous m'avez soutenu, y compris financièrement, et plouf je baisse les bras, c'est pas très classe.

Par ailleurs, merde j'aimais bien faire ces vidéos. D'une part j'ai appris plein de choses en les préparant - il y a une énorme différence entre faire un truc et savoir l'expliquer - mais aussi je me suis bien amusé sur les montages, tentatives d'effets spéciaux plus ou moins réussis, et ça c'est un truc qui me botte. D'autant qu'il y a une marge de progression gigantesque dans ce domaine.

En en discutant avec mes copains du BreizhCamp, j'ai réussi à embarquer sans avoir besoin d'insister Yoann et Sylvain pour me prêter main forte. Essentiellement pour me botter le cul, mais aussi pour relire les textes (qui du coup sont plus préparés) et me pousser des idées.

Je suis donc heureux de vous annoncer le retour de Quoi d'neuf Docker


Et comme vous l'aurez compris, le côté "vidéo" m'éclate bien, donc j'ai embauché l'équipe pour un trailer.

Cet article est une réaction à cet autre article.

Dans l'article en question, l'auteur - que je ne connais pas, de toute évidence une star dans son domaine vu son propos, moi désolé jamais entendu parler - énonce 10 points qui l'horripilent lorsqu'il intervient dans une conférence.
Etant à la fois speaker et organisateur, je vous propose ma vision des choses...

Forcing a slide template on people

Asking for slides in advance

Asking for slides after the talk

Screens that are only 4:3

Badly prepared rooms

Conference laptops are (usually) painful

Not covering T&E is a massive no-no

Bad hotels are bad

Not allowing me to arrange my own flights

Not treating conferences as a mutually-beneficial relationship