Ceci est une ancienne révision du document !
Ansible
Étant très motivée pour l'utiliser1), 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
.
├── ansible.cfg
├── hosts
├── password.yml
├── playbooks
│ ├── ping.yml
│ └── sudols.yml
├── scripts
│ └── createuser.sh
└── vars
└── users
├── alice.yml
├── lapin.yml
└── lievre.yml
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
- hosts
[hyperviseur_local] hyperviseur Proxy VM1 [hyperviseur_local:vars] ansible_python_interpreter=/usr/bin/python3
- 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.
- ansible.cfg
[defaults] inventory = hosts retry_files_enabled = False timeout = 10 ask_vault_pass = true
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 :
become: true
vars_files:
- password.yml
On ajoute aussi ask_vault_pass = true dans la section [defaults] de ansible.cfg.
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.
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é à 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.
