snippet: Lancer des commandes sans les installer via Docker

Lancer un container Docker avec la dernière version d’Ansible, avec ~/.ssh de monté :

docker run -ti --rm --user $(id -u):$(id -g) -v ~/.ssh:/root/.ssh -v $(pwd):/apps -w /apps alpine/ansible bash

https://hub.docker.com/r/alpine/ansible

Lancer Telnet, si jamais : docker run --rm -it busybox telnet host port

On peut aussi en faire des alias dans son Bashrc.

---

L’intérêt de passer par Docker, en particulier pour Ansible (mais ça s’applique à tout), c’est qu’Ansible dépends de versions spécifique de Python et sur la machine hôte, et sur la machine cible. Passer par Docker (ou Podman !) nous permet d’avoir tout l’environnement nécessaire d’un coup, sans rien installer sur sa machine.

Le niveau au dessus, c’est de passer par Distrobox ou Toolbx, qui permettent de définir tout un environnement de dev dans un container, et d’utiliser un terminal comme Ptyxis, qui offre la possibilité de lancer un shell dans ces containers. (À noter que c’est une des approches recommandée sur les distros Universal-Blue (Aurora, Bluefin, Bazzlite, uCore)).

Je mentionne aussi à nouveau Nix et Guix (voir même leur distribution système entière, NixOS/GuixSD), qui prennent cette idée littéralement à cœur et installent chaque paquet avec les dépendances exactes  dont la version installée a besoin. Cependant ces outils sont moins accessible (mème si il y a des outils comme devenv ou Flox), et je trouve que Distrobox est un très bon entre-deux vers le concept d’environnements de dev reproductibles.)

Je le mentionne aussi au cas où : les containers Docker ne sont pas une défense contre les malwares, et Distrobox encore moins : il lance ses containers avec un accès quasi complet au système. L’intérêt, c’est d’isoler l’installation des outils sur le système, pas d’isoler les outils du système.