Derniers messages sur Zeste de Savoirhttps://zestedesavoir.com/forums/2021-05-05T12:37:50+02:00Les derniers messages parus sur le forum de Zeste de Savoir.Partage de script Ansible, message #2340542021-05-05T12:37:50+02:00nohar/@noharhttps://zestedesavoir.com/forums/sujet/15311/partage-de-script-ansible/?page=1#p234054<blockquote>
<p>et le conteneur revient à exécuter du code sur la machine avec les droits root.</p>
</blockquote>
<p>Ce n’est plus le cas avec une install par défaut de Docker sous Ubuntu, <a href="https://docs.docker.com/engine/security/rootless/">la plupart des autres distributions demandant quand même une manip</a> pour le rendre <em>rootless</em>, certes, ni avec podman (qui est d’ailleurs plus tatillon niveau sécu, et généralement moins mal fichu à ce niveau que Docker).</p>
<p>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.</p>Partage de script Ansible, message #2340532021-05-05T12:35:35+02:00entwanne/@entwannehttps://zestedesavoir.com/forums/sujet/15311/partage-de-script-ansible/?page=1#p234053<figure><blockquote>
<ul>
<li>Un programme conteneurisé est isolé du reste de la machine, donc le risque de compromettre sa machine avec un conteneur inconnu est anecdotique.</li>
</ul>
</blockquote><figcaption><a href="https://zestedesavoir.com/forums/sujet/15311/partage-de-script-ansible/?page=1#p234037">nohar</a></figcaption></figure>
<p>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.</p>
<p>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.</p>
<p><a href="https://wiki.archlinux.org/title/Docker#Installation">Certaines distributions</a> avertissent même sur ce que représente le fait de donner à un utilisateur le droit d’exécuter des conteneurs docker.</p>Partage de script Ansible, message #2340512021-05-05T12:11:42+02:00firm1/@firm1https://zestedesavoir.com/forums/sujet/15311/partage-de-script-ansible/?page=1#p234051<figure><blockquote>
<p>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 <code>ansible.builtin.apt</code> sur Debian-like, <code>ansible.builtin.dnf</code> sur CentOS/RH/Fedora, etc. Idem pour les localisations des fichiers qui peuvent être définies dans des <code>group_vars</code> ou des <code>host_vars</code>.</p>
<p>Cela dit, ce n’est pas quelque chose qu’Ansible permet de plus facilement automatiser que ça.</p>
</blockquote><figcaption><a href="https://zestedesavoir.com/forums/sujet/15311/partage-de-script-ansible/?page=1#p234044">Amaury</a></figcaption></figure>
<p>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 <code>ansible.builtin.apt</code> ont va déjà essayer de voir si le module <a href="https://docs.ansible.com/ansible/latest/collections/ansible/builtin/package_module.html">package</a> (qui est un <em>wrapper</em> 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.</p>
<p>Tout comme on va éviter d’utiliser le module <code>systemd</code> au premier abord et préférer d’abord l’utilisation du module <code>service</code>.</p>
<p>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.</p>Partage de script Ansible, message #2340442021-05-05T09:57:43+02:00Amaury/@Amauryhttps://zestedesavoir.com/forums/sujet/15311/partage-de-script-ansible/?page=1#p234044<p>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 <code>ansible.builtin.apt</code> sur Debian-like, <code>ansible.builtin.dnf</code> sur CentOS/RH/Fedora, etc. Idem pour les localisations des fichiers qui peuvent être définies dans des <code>group_vars</code> ou des <code>host_vars</code>.</p>
<p>Cela dit, ce n’est pas quelque chose qu’Ansible permet de plus facilement automatiser que ça.</p>Partage de script Ansible, message #2340422021-05-05T09:46:41+02:00sgble/@sgblehttps://zestedesavoir.com/forums/sujet/15311/partage-de-script-ansible/?page=1#p234042<blockquote>
<p>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.</p>
</blockquote>
<p>Eh non ! Typiquement, tu vas déjà utiliser le module <a href="https://docs.ansible.com/ansible/latest/collections/ansible/builtin/apt_module.html"><code>ansible.builtin.apt</code></a> pour installer tes packages sous Debianoïdes tandis que ça sera le module <a href="https://docs.ansible.com/ansible/latest/collections/ansible/builtin/dnf_module.html"><code>ansible.builtin.dnf</code></a> chez CentOS/RH/Fedora.</p>
<p>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.</p>
<p>À 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é).</p>Partage de script Ansible, message #2340402021-05-05T09:31:12+02:00Migwel/@Migwelhttps://zestedesavoir.com/forums/sujet/15311/partage-de-script-ansible/?page=1#p234040<figure><blockquote>
<p>à 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.</p>
<p></p>
</blockquote><figcaption><a href="https://zestedesavoir.com/forums/sujet/15311/partage-de-script-ansible/?page=1#p234036">Stalone</a></figcaption></figure>
<p>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.</p>
<p>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.</p>
<p>Conclusion: je pense que je vais quand même m’y essayer et partager ma configuration mais garder une documentation d’installation.</p>Partage de script Ansible, message #2340392021-05-05T09:24:39+02:00sgble/@sgblehttps://zestedesavoir.com/forums/sujet/15311/partage-de-script-ansible/?page=1#p234039<p>Je rejoins globalement les idées énoncées.</p>
<p>Je peux voir au moins un avantage à inclure les <em>playbooks</em>, à 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 <em>stack</em>. 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 <em>playbooks</em>, éventuellement).</p>
<p>Ces <em>playbooks</em> 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 <em>stack</em> dans l’histoire.</p>Partage de script Ansible, message #2340372021-05-05T08:53:13+02:00nohar/@noharhttps://zestedesavoir.com/forums/sujet/15311/partage-de-script-ansible/?page=1#p234037<p>Salut ! </p>
<blockquote>
<p>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 ?</p>
</blockquote>
<p>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.</p>
<p>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 <code>docker-compose</code> ou dans un cluster Kubernetes avec <code>helm</code>…</p>
<p>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 <em>sur l’infrastructure que <strong>tu</strong> utilises</em>. 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 utiles<sup id="fnref-1-Cc484KDhCZ"><a href="#fn-1-Cc484KDhCZ" class="footnote-ref">1</a></sup>.</p>
<p>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 <em>pas</em> une documentation.</p>
<p>PS : par contre, je voudrais tempérer le passage un peu réac' sur les conteneurs de mon VDD. </p>
<ul>
<li>Un programme conteneurisé est isolé du reste de la machine, donc le risque de compromettre sa machine avec un conteneur inconnu est anecdotique.</li>
<li>Tout l’intérêt de distribuer un Dockerfile<sup id="fnref-2-Cc484KDhCZ"><a href="#fn-2-Cc484KDhCZ" class="footnote-ref">2</a></sup> 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 : <ul>
<li>Quelles variables d’environnement utiliser pour surcharger la conf,</li>
<li>Le cas échéant dans quel répertoire le conteneur ira lire sa conf,</li>
<li>Quels sont ses besoins en termes de volumes de disque persistants,</li>
<li>Sur quels ports le conteneur va servir quoi.</li>
</ul></li>
</ul>
<p>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 <em>ne pas</em> fournir cette doc est problématique, <em>ne pas</em> 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 <a href="https://12factor.net/">12-factor apps</a>. Personnellement ce qui me fait hurler, c’est surtout les projets qui ne respectent pas ces 12-factors.</p>
<div class="footnotes">
<hr>
<ol>
<li id="fn-1-Cc484KDhCZ">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. <img src="/static/smileys/svg/smile.svg" alt=":)" class="smiley"><a href="#fnref-1-Cc484KDhCZ" class="footnote-backref" title="Retourner au texte de la note 1">↩</a></li>
<li id="fn-2-Cc484KDhCZ">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…<a href="#fnref-2-Cc484KDhCZ" class="footnote-backref" title="Retourner au texte de la note 2">↩</a></li>
</ol>
</div>Partage de script Ansible, message #2340362021-05-05T08:49:47+02:00Lika Kavkasidze/@Lika%20Kavkasidzehttps://zestedesavoir.com/forums/sujet/15311/partage-de-script-ansible/?page=1#p234036<p>Proposer un script Ansible est peut-être une bonne idée, mais <em>remplacer</em> 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 <em>open-source</em>, 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.</p>
<p>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.</p>
<p>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 <em>expliquant</em> pourquoi je devrais lancer telle ou telle commande.</p>Partage de script Ansible, message #2340322021-05-04T23:08:16+02:00Migwel/@Migwelhttps://zestedesavoir.com/forums/sujet/15311/partage-de-script-ansible/?page=1#p234032<p>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).</p>
<p>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.</p>
<p>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 ?</p>
<p>Merci d’avance !</p>