Ansible est un outil d'automatisation de configuration et gestion de serveurs : il permet le déploiement de logiciels et l'execution de tâches via une connexion SSH.
Ansible fonctionne sans agent sur les serveurs (*agent-less*) et selon le concept d'**[idempotence](https://fr.wikipedia.org/wiki/Idempotence)** : on décrit l'état d'un serveur et des actions seront executées dans le but de rendre le serveur conforme à cette description.
Options utiles pour [ansible-playbook](https://manpages.debian.org/cgi-bin/man.cgi?query=ansible-playbook&apropos=0&sektion=0&manpath=Debian+unstable+sid&format=html&locale=en) :
L'utilisation d'Ansible se fait principalement avec un **playbook**. C'est l'élément clé, qui peut suffir à réaliser des tâches utiles. Il s'agit d'un fichier qui décrit la succession d'une ou plusieurs séries d'actions (des *plays*). Chaque **play** indiques quelques réglages généraux comme le groupe de serveurs concernés, la manière de devenenir administrateur, quels fichiers de variables charger…
Les actions peuvent être listées dans la partie **tasks** du playbook et peuvent être aussi déportées dans un fichier et inclus dans le playbook.
Les **handlers** sont des actions qui ne sont exécutées que si une autre action en a fait la demnde, via l'attribut `notify`.
Lorsqu'on a besoin d'utiliser des fichiers ou _templates_ à copier, des variables avec des valeurs par défaut, des handlers… on peut organiser tout cela dans un **role** en respectant une structure conventionnelle :
```
foo
├── defaults
│ └── main.yml
├── files
├── handlers
│ └── main.yml
├── meta
│ └── main.yml
├── README.md
├── tasks
│ └── main.yml
├── templates
├── tests
│ ├── inventory
│ └── test.yml
└── vars
└── main.yml
```
La partie **inventory** correspond à la description de l'inventaire des serveurs à configurer et inclus un mécanisme de configuration individuel et par groupe. Nous y revenons plus loin.
*`lineinfile`: si `regexp:` n'est pas matché… il insère quand même la ligne ! avec `lineinfile``regexp` n'est pas une condition pour l'insertion mais une condition pour remplacer au lieu d'insérer !
* avec `lineinfile`: sauf cas tordus, `regexp` doit matcher `line` (sinon il va insérer la valeur de `line` à l'infini !)
*`lineinfile`: va 1. regarder si `regexp` existe et il remplace la dernière ligne, 2. si `regexp` n'existe pas, il ajoute `line` (sans d'autre condition… même si elle existe déjà)
*`replace`: il va remplacer uniquement si `regex` est matché, logique (comme la commande `sed`)
* si l'on veut utiliser une référence (`\1`) dans `line` avec `lineinfile`, ça donne une erreur, il faut utiliser `replace`
* avec `lineinfile` + `backrefs: yes` c'est pour utiliser une référence au sein de `regexp` (et non pas au sein de `line`)
Les variables peuvent être définies à de multiples niveaux, chacun ayant une certaine précédence (extrait de la [documentation](http://docs.ansible.com/ansible/playbooks_variables.html#variable-precedence-where-should-i-put-a-variable)) :
Pour gérer de nombreuses variables dans un projet, on peut stocker toutes celles qui correspondent à un groupe de serveur dans un fichier portant le nom du groupe, ainsi que toutes celle d'un serveur en particulier dans un fichier du nom du serveur. Voici l'arborescence conseillée :
Dans des rôles longs, il est conseillé de purger les handlers de temps en temps (en fin de groupe d'action). En effet, si un playbook est interrompu les handlers ne sont pas forcément exécutés alors que l'action qui les a déclenchés a bien eu lieu. On insère alors l'action suivante :
`register` est un attribut d'action que l'on peut rajouter pour tout type de tâche et qui initialisera la variable (par le nom donné) avec les valeurs retour du module.
Pour `shell`, on a le droit à `.stdout`, `.stderr`, `.rc`… Mais cela dépend bien des valeurs de retour du module.
Il est possible de consulter le contenu détaillé de la variable avec `debug` :
Permet d'indiquer la liste des machines concernées par Ansible (peut être limité lors de l'exécution de la commande par l'option `-l`) et de pouvoir les regrouper dans des groupes.
*`machine[01:57].evolix.net` : on peut indiquer une [pseudo-]expression régulière - ici ajoutera les machines _machine01.evolix.net_, _machine02.evolix.net_, _machine03.evolix.net_… _machine57.evolix.net_
*`alias ansible_port=2222 ansible_host=192.168.1.50` : la machine _alias_ n'a pas un vrai FQDN mais pointera vers _192.168.1.50_ car on a indiqué des variables propres à Ansible. Il est existe aussi `ansible_connection` (local ou ssh) ou `ansible_user` (le nom de l'utilisateur de la machine distante avec lequel Ansible se connectera en ssh)
*`host1 http_port=80 maxRequestsPerChild=808` : des variables qui seront automatiquement auto-completées liées à _host1_
*`[commercant:vars]` : des variables qui seront liées au groupe _commercant_. On peut aussi créer des groupes de groupes en utilisant `:children`
On peut aussi découper le fichier "inventory" selon les groupes et les variables : [<http://docs.ansible.com/ansible/intro_inventory.html#splitting-out-host-and-group-specific-data>].
Les variables propres à Ansible : [<http://docs.ansible.com/ansible/intro_inventory.html#list-of-behavioral-inventory-parameters>]
*`display_args_to_stdout` : mettre à `True` si on veut voir tout le contenu du _tasks_ executé pour chaque étape écrit sur _stdout_
*`display_skipped_hosts` : mettre à `False` si on ne veut pas voir affiché sur _stdout_ l'information d'un _task_ qui n'est pas exécuté _(le nom de variable est confu - mais il s'agit bien de l'affichage du task)_
*`error_on_undefined_vars` : mettre à `True` pour être sûr que le script Ansible s'arrête si une variable n'est pas définie (alors qu'il y a utilisation de cette dernière dans une _task_)
*`hosts` : accès vers les _hosts_ par défaut (`all`)
*`private_key_file` : le chemin pour la clé pem
*`remote_port` : le port ssh par défaut (`22`)
*`remote_user` : l'utilisateur pour la connexion ssh par défaut (`root`)
*`retry_files_enabled` : mettre à `True` pour la création de fichier `.retry` après une failure de ansible pour reprendre le travail précédent - ajouté en argument dans l'appel de la commande
Vérifier bien la syntaxe du document qui est référé pour cette erreur. Cela peut être un guillemet mal fermé (ou mélange simples/doubles guillemets), ou encore histoire de crochet devenant une parenthèse…
fatal: [test.evolix.net]: UNREACHABLE! => {"changed": false, "msg": "SSH encountered an unknown error during the connection. We recommend you re-run the command using -vvvv, which will enable SSH debugging output to help diagnose the issue", "unreachable": true}
~~~
Malheureusement, cela arrive souvent sur certaines machines (une?), mais pas de solutions pour le moment -> boire du café - beaucoup de café.
Du côté de la machine distante, dans le fichier `/var/log/auth.log`:
Mais si tentative de déploiement Ansible juste après la session supprimée (par ex la 182), c'est à ce moment là qu'on se retrouve avec des *UNREACHABLE* -> savoir pourquoi sshd supprime la session ssh…
Il est de toute façon préférable de ne pas mettre *all* dans le champs *hosts* dans le playbook pour éviter un - _possible_ - oubli de "limite" de machines.
Pour éviter que les différentes tâches s'appliquent une par une sur tout les hosts impliqués par l'exécution du playbook, on peut utiliser l'option `strategy` à la valeur `free` pour que chaques tâches sur un host puisse continuer dès la fin de son exécution sans attendre l'état des autres hosts concernés en cours.
_Note: Ne plus se fier au texte `host changed` après texte de la tâche, car il pourrait s'agir d'une autre tâche affiché plus en haut dans le texte de l'historique_
*`serial` en en-tête contenant une valeur numérique qui représente le nombre de machines pour chaque tour d'éxecution de playbook, ou un pourcentage par rapport à la liste inventory concerné.
S'il manque une valeur pour la suite du script, soit on le gère en mettant une erreur, ou une valeur par défaut, mais sinon on peut aussi demander une saisie clavier :
Malheureusement pour le moment, doit se situer avant `tasks`.
Si on veut utiliser cette variable dans une tâche, il faut simplement utiliser le nom de la variable, et si on veut l'utiliser (explicitement) pour un play ne se trouvant pas dans le même fichier (donc ici la variable dans autre.yml s'appelera _prenom_de_autre_ et non prenom) :
En indiquant l'attribut `creates` indiquant le chemin de fichier lors de l'utilisation du module shell, cette tâche ne s'executera que si le fichier indiqué par `creates` n'existe pas.
Le corollaire est possible avec l'attribut `removes` qui empêche l'exécution si le fichier n'existe pas.
Ces attributs sont disponibles pour certains modules (comme `shell`).
Si cet attribut est utilisé avec `delegate_to`, alors cette machine sera la seule à exécuter cette tâche. Sinon, c'est la première dans la liste de l'inventaire.
Par défaut, l'utilisateur se connectant sur le serveur distant l'utilisateur UNIX courant. On peut soit le préciser dans le fichier de conf principal d'Ansible avec `remote_user: michu`, dans l'inventaire pour un groupe ou un serveur précis ou encore en l'indiquant en argument lors de l'éxecution du playbook.
* [Documentation officielle](http://docs.ansible.com/ansible/) (voir notamment la partie [Best Practices](http://docs.ansible.com/ansible/playbooks_best_practices.html))
* Vidéos [ansible-best-practices](https://www.ansible.com/ansible-best-practices) et [ansible-tips-and-tricks](https://www.ansible.com/ansible-tips-and-tricks)