Partage de script Ansible

Bonjour à tous, Pour mes petits projets personnels, j’utilise une Raspberry Pi que j’ai configurée et qui tourne chez moi. J’y ai installé Java, postgresql, etc.. J’ai une petite procédure que j’ai dans un fichier texte m’expliquant les étapes à effectuer si je voulais refaire pareil sur une Raspberry Pi neuve (j’ai déjà fait ça quand j’ai acheté un RPi avec 8Gb de RAM).

Comme ça demande beaucoup d’étapes manuelles, je me disais que je pourrais utiliser Ansible ou un outil du genre qui pourrait automatiser tout ça. Si je comprends bien, j’aurais juste à écrire ma procédure Ansible et si j’achète une nouvelle Raspberry Pi plus puissante ou si je voulais passer sur un VPS ou autre, je pourrais simplement réutiliser Ansible et adieu les procédure manuelles.

J’arrive enfin à ma question : les projets que j’ai créés son open-source et actuellement, ils expliquent les étapes à effectuer pour les faire tourner localement. Est-ce une bonne idée de remplacer ça parce un fichier Ansible et simplement dire "exécutez ce programme Ansible et vous êtes prêts" ? Je n’ai jamais vu une telle approche sur Github donc je me dis que ce n’est pas nécessairement une bonne idée et que je loupe une raison pour laquelle ce n’est pas plus répandu. Pouvez-vous éclairer ma lanterne ?

Merci d’avance !

Je rejoins globalement les idées énoncées.

Je peux voir au moins un avantage à inclure les playbooks, à savoir que ça peut aider à documenter l’environnement sur lequel le projet est supposé fonctionner, au moins pour avoir une idée objective de la stack. Cependant, cela n’est pas non plus prétexte à s’affranchir d’une documentation (sauf si le projet est vraiment 100 % perso et que tu commentes biens tes playbooks, éventuellement).

Ces playbooks bénéficient aussi, en principe, du versionnage inhérent à l’utilisation de git. Cela peut être intéressant pour comparer plusieurs versions de la stack dans l’histoire.

A vrai dire j’ai plutôt la réaction inverse. Il m’est souvent arrivé de vouloir contribuer à un projet mais les installations étaient si complexes et demandaient énormément de modifications pour plus ou moins fonctionner sur ma propre machine que ça m’a bien rebuté. Cela dit, je pensais qu’Ansible (et programmes similaires) étaient plus ou moins génériques et fonctionneraient quelle que soit la cible (Debian ou REHL ou autre comme tu le dis) mais il semble que ce n’est pas le cas, ce qui perd un peu de son intérêt dans ce cadre.

En dehors de ça, merci pour vos réponses ! Ce qui m’ennuie avec la documentation est que je n’ai que ma bonne foi pour garantir qu’elle reste à jour. Si je pouvais documenter ça dans le code directement (via Ansible donc), j’aurais la garantie que ma documentation (i.e. mon script Ansible) est la réalité et n’est jamais obsolète.

Conclusion: je pense que je vais quand même m’y essayer et partager ma configuration mais garder une documentation d’installation.

Cela dit, je pensais qu’Ansible (et programmes similaires) étaient plus ou moins génériques et fonctionneraient quelle que soit la cible (Debian ou REHL ou autre comme tu le dis) mais il semble que ce n’est pas le cas, ce qui perd un peu de son intérêt dans ce cadre.

Eh non ! Typiquement, tu vas déjà utiliser le module ansible.builtin.apt pour installer tes packages sous Debianoïdes tandis que ça sera le module ansible.builtin.dnf chez CentOS/RH/Fedora.

Ensuite, tu vas décrire avec Ansible l’état du système que tu veux. Donc par exemple que tel fichier se trouve à tel emplacement. Là encore, c’est propre à chaque système, l’emplacement peut changer d’une distribution à une autre.

À ma connaissance, il n’existe pas de mécanisme Ansible pour gérer plus d’un système à la fois (sauf écrire deux livres de recettes différents, un pour chaque système supporté).

Il est possible de faire un playbook universel, car Ansible expose l’OS détecté dans les playbooks, donc on peut, avec des exécutions conditionnelles, exécuter ansible.builtin.apt sur Debian-like, ansible.builtin.dnf sur CentOS/RH/Fedora, etc. Idem pour les localisations des fichiers qui peuvent être définies dans des group_vars ou des host_vars.

Cela dit, ce n’est pas quelque chose qu’Ansible permet de plus facilement automatiser que ça.

J’ajouterai même que un bon playbook est un playbook qui ne dépend pas de ton système cible. Typiquement plutot que d’utiliser le module ansible.builtin.apt ont va déjà essayer de voir si le module package (qui est un wrapper au dessus des autres) ne permet pas déjà de faire ce qu’on veut. On n’utilisera apt que si on besoin d’utiliser des options spécifique.

Tout comme on va éviter d’utiliser le module systemd au premier abord et préférer d’abord l’utilisation du module service.

Bref, les playbooks universels existent (comme on en voit sur la galaxy ansible), mais ça demande de l’avoir en tête dans la conception.

Au contraire j’aurais plutôt conseillé d’éviter de foncer aveuglément vers un conteneur inconnu parce que c’est réputé être isolé et ne présenter aucun danger.

La commande de lancement du conteneur peut très bien monter tel ou tel répertoire (ce qui assez cryptique pour quelqu’un d’étranger à docker / docker-compose), et le conteneur revient à exécuter du code sur la machine avec les droits root.

Certaines distributions avertissent même sur ce que représente le fait de donner à un utilisateur le droit d’exécuter des conteneurs docker.

et le conteneur revient à exécuter du code sur la machine avec les droits root.

Ce n’est plus le cas avec une install par défaut de Docker sous Ubuntu, la plupart des autres distributions demandant quand même une manip pour le rendre rootless, certes, ni avec podman (qui est d’ailleurs plus tatillon niveau sécu, et généralement moins mal fichu à ce niveau que Docker).

Dans tous les cas, il est évidemment hors de question de faire les choses aveuglément. C’est juste que puisque l’on contrôle exactement quels volumes on monte dans le conteneur, alors on contrôle ce sur quoi le conteneur peut déborder sur la machine.