Ayant récemment migré mon PC personnel sous Bazzite, j’ai dû changer certaines habitudes et en particulier pour tout ce qui est dev .Net. Je n’utilise plus Visual Studio et Docker a été remplacé par Podman. D’autres contraintes se posent avec le système très cloisonné de Bazzite où, en gros, les applications tournent chacune dans leur propre container avec accès limité au reste du système et où je ne suis pas root. C’est très pratique d’un point de vue sécurité et isolation des composants mais cela peut poser des soucis d’interactions.
Le guide ci-dessous a été élaboré sur Bazzite mais devrait tourner sans souci avec les autres images Universal Blue comme Aurora ou Bluefin.
Mon setup
De manière générale, pour pouvoir faire du dev dans une image Universal Blue comme Bazzite, il est préconisé d’installer la plupart des outils dans un container. J’ai installé tous mes IDE dans un container Ubuntu (pourquoi Ubuntu : parce que je connais et parce que c’est bien supporté par la plupart des éditeurs d’IDE). En l’occurrence Rider de JetBrains.
Une fois Rider installé et configuré, je peux le lancer sans problème comme n’importe quelle autre application : raccourcis dans le menu Démarrer, temps de chargement, accès aux disques durs, etc… tout est transparent.
Maintenant, pour gérer mes containers de dev, comme une base PostgreSQL ou une instance Redis, j’utilise Podman Desktop. Lui tourne dans une sandbox dédiée avec accès au système de fichiers de la machine. Je lance mon appli depuis mon IDE, elle peut accéder aux containers, tout va bien.

Testcontainers
Côté tests en revanche, ça coince. Ils utilisent Testcontainers et j’ai une belle stack en les lançant :
DotNet.Testcontainers.Builders.DockerUnavailableException
Docker is either not running or misconfigured. Please ensure that Docker is running and that the endpoint is properly configured.
You can customize your configuration using either the environment variables or the ~/.testcontainers.properties file.
For more information, visit: https://dotnet.testcontainers.org/custom_configuration/.
Testcontainers, au-delà de l’utilisation de Podman/Docker, crée et détruit des containers à la volée depuis le test runner. Dans mon cas, le test runner est exécuté depuis l’IDE qui tourne donc dans un container Ubuntu. Il faut donc pouvoir faire communiquer tout le monde avec les bons droits afin que mes tests puissent créer et détruire des containers dans Podman.
Procédure à suivre
- On veut trouver où est la socket sur laquelle Podman écoute en lançant dans un terminal :
echo $XDG_RUNTIME_DIR. Mettons qu’il s’agisse de /run/user/1000. - Comme suggéré dans la stack d’erreur, on crée un fichier .testcontainers.properties à la racine du home (ex : /home/username). Dedans on met les 3 lignes suivantes :
docker.host=unix:///run/user/1000/podman/podman.sock
docker.socket.override=/run/user/1000/podman/podman.sock
ryuk.container.privileged=false
Cette dernière ligne signifie que Ryuk, le gestionnaire de ressources de Testcontainers dont un des buts principaux est de cleaner les containers qui auraient pu mal être fermés (ex : test qui crashe un peu violemment). Par défaut il tourne avec des privilèges root, ce qui n’est pas possible dans notre cas. - On lance, si ce n’est pas déjà fait, le service podman afin qu’il puisse tourner sans avoir besoin de lancer Podman Desktop :
systemctl --user enable --now podman.socket - Dans un terminal du container faisant tourner Rider, on vérifie que la socket podman est bien accessible :
ls -la /run/user/1000/podman/podman.sock - Lancer Rider et lancer les tests utilisant Testcontainers.
Conclusion
Voilà, ce n’est pas grand-chose mais ayant passé du temps dans la doc de Podman et de Testcontainers tout en voulant conserver l’utilisation de Ryuk, je me suis dit que j’en ferai un mini-article. Si jamais cela peut aider…
Software developer since 2000, I try to make the right things right. I usually work with .Net (C#) and Azure, mostly because the ecosystem is really friendly and helps me focus on the right things.
I try to avoid unnecessary (a.k.a. accidental) complexity and in general everything that gets in the way of solving the essential complexity induced by the business needs.
This is why I favor a test-first approach to focus on the problem space and ask questions to business experts before even coding the feature.
