Partage de script Ansible

a marqué ce sujet comme résolu.

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 !

+0 -0

Proposer un script Ansible est peut-être une bonne idée, mais remplacer la documentation par un script Ansible certainement pas. Je vois deux raisons assez simples : d’une part ne pas avoir de documentation rend plus compliqué la modification du programme, à l’opposé donc de la mentalité d’un projet open-source, et par ailleurs, certains administrateurs système ne souhaitent pas utiliser Ansible, et il n’y a pas de raison de leur imposer. Aussi, la documentation permet d’expliquer ce que fait le script, pourquoi il installe tel ou tel truc, pourquoi il veut ouvrir tel ou tel port sur la machine, etc.

Ta question me fait beaucoup penser aux personnes qui remplacent leur documentation d’installation par un gros conteneur Docker, et à chaque fois que je tombe sur un projet de la sorte, j’abandonne l’idée de l’installer, car je ne vais pas me taper une formation Docker pour installer leur truc, et il est hors de question que je lance un truc sur une machine sans comprendre un minimum ce qu’il fait. Je crois que ma réaction serait la même en voyant du Ansible : je ne souhaite pas me former sur cet outil aujourd’hui, et lire un fichier de configuration Ansible n’est pas dans mes cordes.

Enfin, si je ne raconte pas de bêtises, Ansible est configuré pour un système en particulier, ce qui n’est donc pas rendre service aux personnes qui utilisent un autre système que toi (Debian vs. RHEL par exemple). Pour faire court : Ansible est un bon outil, mais il ne remplace pas une documentation d’installation correcte, qui donne les étapes pour un système cible donné, en expliquant pourquoi je devrais lancer telle ou telle commande.

Salut !

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 ?

En effet, les étapes pour faire tourner un soft localement sont encore ce qui se fait de plus exploitable pour les gens qui n’utilisent pas le même système que toi.

La raison profonde, c’est qu’il n’y a pas qu’Ansible. Les gens peuvent aussi bien vouloir utiliser Salt, ou Chef, ou encore déployer un système conteneurisé avec docker-compose ou dans un cluster Kubernetes avec helm

Pour moi, ce qui a le plus de sens, c’est d’inclure dans ton repo le script ou la configuration qui te permet de déployer le système sur l’infrastructure que tu utilises. Par exemple, j’inclus systématiquement une config Kubernetes ou un chart helm dans mon repo, puisque c’est de ça que je me sers pour déployer mon projet personnellement, et que c’est d’abord à moi que mes projets sont utiles1.

Du coup, suivant cette logique, ça aurait du sens d’inclure ta conf Ansible dans tes repos git. Il faut juste faire attention à ne pas y inclure de secrets, et rester conscient que ça ne remplace pas une documentation.

PS : par contre, je voudrais tempérer le passage un peu réac' sur les conteneurs de mon VDD.

  • Un programme conteneurisé est isolé du reste de la machine, donc le risque de compromettre sa machine avec un conteneur inconnu est anecdotique.
  • Tout l’intérêt de distribuer un Dockerfile2 et d’expliquer comment lancer le conteneur est justement que l’on n’a plus qu’à expliquer aux administrateurs un ensemble homogène de points de configuration, quel que soit le système :
    • Quelles variables d’environnement utiliser pour surcharger la conf,
    • Le cas échéant dans quel répertoire le conteneur ira lire sa conf,
    • Quels sont ses besoins en termes de volumes de disque persistants,
    • Sur quels ports le conteneur va servir quoi.

Autrement dit, fournir une image de conteneur et documenter le comportement du conteneur est une façon standardisée de documenter l’installation et l’opération d’un soft, totalement indépendante de la plateforme qui le fait tourner. Si ne pas fournir cette doc est problématique, ne pas s’en contenter quand elle est là l’est tout autant. Et il n’y a pas besoin de "se taper une formation" pour cela. Simplement être au courant des bonnes pratiques en place depuis une décennie, notamment les 12-factor apps. Personnellement ce qui me fait hurler, c’est surtout les projets qui ne respectent pas ces 12-factors.


  1. Je n’ai pas la prétention que mes logiciels aient un intérêt pour quiconque d’autre. S’ils en ont un, tant mieux, et les gens peuvent le réutiliser, c’est open, mais soyons réalistes : le premier utilisateur de mon code, c’est moi. :)
  2. C’est un point de vocabulaire important : un conteneur c’est un processus. On ne fournit pas un conteneur mais, au choix : une image de conteneur (sur un registry comme DockerHub ou quay.io), ou un Dockerfile qui permet de construire l’image du conteneur. Le cas le plus fréquent est ce dernier, et dans ce cas précis, un Dockerfile n’est pas grand chose de plus qu’un script d’installation qui décrit des étapes dans une syntaxe shell tout ce qu’il y a de plus banale…
+1 -0

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.

à chaque fois que je tombe sur un projet de la sorte, j’abandonne l’idée de l’installer, car je ne vais pas me taper une formation Docker pour installer leur truc, et il est hors de question que je lance un truc sur une machine sans comprendre un minimum ce qu’il fait. Je crois que ma réaction serait la même en voyant du Ansible : je ne souhaite pas me former sur cet outil aujourd’hui, et lire un fichier de configuration Ansible n’est pas dans mes cordes.

Stalone

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.

+1 -0

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.

Amaury

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.

  • Un programme conteneurisé est isolé du reste de la machine, donc le risque de compromettre sa machine avec un conteneur inconnu est anecdotique.
nohar

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.

+1 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte