Différences

Ci-dessous, les différences entre deux révisions de la page.

--- pratique:informatique:ansible [09/05/2025 17:08] – Zatalyz
+++ pratique:informatique:ansible [09/05/2025 19:46] (Version actuelle) – envoyé sur https://khaganat.net/wikhan/fr:ansible Zatalyz
@@ Ligne 1: / Ligne 1: @@
-====== Ansible ======
-Étant très motivée pour l'utiliser((Non.)), mieux vaut que je note la mise en place.
-===== Syntaxe =====
-Dans les playbooks et la configuration
-  * Commentaires avec ''#'' : retour à la ligne avant le commentaire
-Dans les appels en ligne de commande (plus de détails avec ''man ansible-playbook'') :
-  * ''-K'' : renseigner le mot de passe sudo
-  * ''-l'' ("limit") : appliquer uniquement au host. ''-l vm1''
-  * ''--step'' : confirmer chaque étape avant de passer à la suivante
-  * ''--syntax-check'' : vérifie la syntaxe sans exécuter le playbook
-  * ''-e'' ("extra-vars") : précise des variables additionnelles à utiliser dans le playbook. Par exemple ''-e "user=marcelle"''.
-===== Rangement =====
-<code>.
-├── ansible.cfg
-├── hosts
-├── password.yml
-├── playbooks
-│   ├── ping.yml
-│   └── sudols.yml
-├── scripts
-│   └── createuser.sh
-└── vars
-    └── users
-        ├── alice.yml
-        ├── lapin.yml
-        └── lievre.yml</code>
-Dans la racine du dossier les trucs qui tiennent de la configuration d'ansible (hosts et ansible.cfg). J'ai aussi mis password.yml parce qu'il y en a toujours besoin.
-  * Playbooks : sans doute que ça va mériter encore une autre organisation. Lors d'un appel à une variable ou un script, penser à remonter dans les chemins : ''../scripts''.
-  * Scripts : c'est pas du yaml ni de l'ansible. Bash, c'est bien. Surtout je n'ai aucun doute sur la maintenance de bash et je l'utilise abondament : au pire les scripts seuls me suffisent.
-  * vars : les diverses variables à utiliser. Par exemple les "users" : le nom de chacun, les groupes dont il fait partie, les clés publiques ssh, etc.
-===== Fichiers de base =====
-Créer (dans un dossier lambda) :
-  * hosts : liste des serveurs qu'on contacte, regroupés par grappe
-  * ansible.cfg : paramètres pour ansible sur cet usage
-<code bash hosts>
-[hyperviseur_local]
-hyperviseur
-Proxy
-VM1
-[hyperviseur_local:vars]
-ansible_python_interpreter=/usr/bin/python3
-</code>
-  * Je reprends les noms renseignés dans mon ~/.ssh/config : ça permet de prendre l'utilisateur, le port, la clé etc en compte.
-  * La partie "vars" précisent des variables affectant tout le groupe : ici, déclarer le chemin de python afin d'éviter un warning sans grand intérêt.
-<code bash ansible.cfg>
-[defaults]
-inventory = hosts
-retry_files_enabled = False
-timeout = 10
-ask_vault_pass = true
-</code>
-Voir [[https://docs.ansible.com/ansible/latest/reference_appendices/config.html]] pour les diverses options.
-==== Stockage du mot de passe sudo ====
-Créer un fichier chiffré où stocker des infos sensibles :
-  ansible-vault create password.yml
-Il faut définir un mot de passe pour ouvrir le fichier en question.
-Dans le fichier en question, pour stocker le mot de passe sudo :
-  ansible_become_pass: "mot_de_passe_sudo"
-Pour éditer :
-  ansible-vault edit password.yml
-Dans les playbooks, chaque fois qu'on a besoin de sudo, on aura ces lignes au début :
-<code>  become: true
-  vars_files:
-    - password.yml</code>
-On ajoute aussi ''ask_vault_pass = true'' dans la section ''[defaults]'' de ''ansible.cfg''.
-<WRAP center round help 100%>
-J'ai pas trouvé comment simplement faire qu'il demande le mot de passe sudo quand il en a besoin. Enfin, si, ajouter "-K" (ou ''<nocode>--ask-become-pass</nocode>'' à l'exécution du playbook, par exemple :
-  ansible-playbook sudols.yml -K
-Donc : soit on ajoute -K, soit on déclare un password.yml.
-</WRAP>
-===== Serveurs distants =====
-Installer python3 dessus. Sinon ça ne marchera pas.
-C'est tout !
-===== Ansible ou bash ? =====
-Ansible est intéressant pour faire les mêmes choses sur plusieurs serveurs. D'un autre côté sa syntaxe particulière demande un apprentissage. Et je passe parfois un temps fou à trouver comment réaliser un truc avec Ansible, alors qu'avec bash, c'est 2 lignes de commandes.
-Pour un certain nombre de tâches, Bash a un avantage indéniable. Il s'appuie sur les outils du système, il est robuste, et c'est rare que les syntaxes changent. Et il donne des retours directement. Couplé à [[https://gnome-terminator.org/|Terminator]] qui permet de répéter la même commande dans plusieurs terminaux, il a une force de frappe impressionnante.
-Parfois, Ansible ressemble à un tank sorti pour écraser une mouche. Parfois, c'est Bash. Pour chaque type d'action, ça mérite de se demander lequel va être le plus adapté, ou si une combinaison des deux sera l'idéal.
-{{tag>Automatisation Sysadmin}}
-[[https://creativecommons.org/publicdomain/zero/1.0/deed.fr|{{ https://liev.re/imagesweb/licences/cc-zero.png?100 | Ce texte est placé sous licence CC0}}]]