Introduction

Ansible est un système d'automatisation.

Ses principales caractériques sont :

  • l'idempotence, c'est à que le résultat du lancement d'un playbook ne dépends pas :
    • de l'état de la machine cible
    • du nombre de fois que le playbook est lancé autrement dit, le résultat final du lancement d'un playbook sera toujours le même (à condition que le playbook soit bien écrit)
  • il est sans agent
  • tout s'écrit en yaml
  • écrit en python
  • utilise SSH comme protocole de transport et de sécurisation des échanges

C'est un logiciel soutenu par Red-Hat.

Configuration préalable des machines

La configuration des serveurs Nos Oignons peut ne pas permettre de lancer des rôles ansible. Pour pouvoir les executer, il suffit d'éditer

/etc/sudoers.d/00_defaults

Defaults:%adm !requiretty

Cela permet l'allocation d'un tty pour l'élevation de privilèges sans autoriser la connexion en tant que root

Pour le configurer simplement, le fichier étant écraser par ansible, vous pouvez lancer ce oneliner :

ssh -t $HOST sudo bash -c $(printf '%q' 'echo Defaults:%adm !requiretty >> /etc/sudoers.d/00_defaults')

Cette modification n'est nécessaire qu'avant le premier lancement d'ansible

Installation des paquets ansible

Pour pouvoir lancer des playbooks, il faut installer ansible sur la machine depuis laquelle les playbooks seront lancés.

Le plus simple est d'installer ansible avec pip, dans un venv:

mkdir -p ~/.local/venv/
cd ~/.local/venv/
virtualenv ansible
source ansible/bin/activate
pip install --user ansible ansible-core

On rajoute ensuite le répertoire d'installation pip dans $PATH:

PATH=$PATH:$HOME/.local/venv/ansible/bin

Clone du dépôt ansible Nos Oignons

Clonez le dépôt :

git clone ssh://git@bulbe.nos-oignons.net/ansible

Toutes les commandes lancées dans la suite seront lancée à partir de ce dépôt.

Le chemin du dépôt sera indiqué ci dessous comme $ANSIBLE_PATH

Pensez à bien pull le dépot avant de lancer un playbook.

Configuration des hôtes SSH

Pour qu'Ansible puisse se connecter aux machines ciblées, il convient de configurer son ~/.ssh/config pour y renseigner les informations de connexions aux machines :

  • clée utilisée
  • nom d'utilisateur
  • éventuel nom d'hôte

D'une manière générale, si l'hôte est renseigné dans le DNS, pas besoin de renseigner son nom d'hôte. Si votre nom d'utilisateur est le même que l'utilisateur de votre machine, pas besoin non plus Pareil pour la clé, si c'est la même que votre clé par défaut, pas besoin.

Notez que le nom renseigné dans votre ~/.ssh/config doit être identique à celui renseigné dans l'inventaire ansible ($ANSIBLE_PATH/inventory)

Alternativement, l'inventaire peut contenir certaines informations, comme l'hôte qu'il faut contacter

Pour tester que la configuration est correcte (si votre utilisateur est déjà présent sur le système ciblé), tentez de vous connecter en ligne de commande.

Pour tester la connexion à la machine de cet inventaire:

[nodes]
bulbe

Lancez :

$ ssh bulbe -q exit; echo $?

Si le retour est 0, tout est bien configurer. Alternativement une connexion simple suffit :

$ ssh bulbe

Récupération du mot de passe du vault ansible

Pour chiffrer des secrets, on utilise ansible-vault. Ce système permet de chiffrer les fichiers ansible, pour ainsi pouvoir publier le dépôt sur internet sans craindre de fuiter des informations confidentielles

La clé du vault est dans keyringer :

$ keyringer oignons-admin decrypt ansible_vaultkey.asc

Lancement d'un playbook

Pour lancer le plabook tor_node.yml, qui configure intégralement un nœud Tor:

cd $ANSIBLE_PATH
ansible-playbook --diff -v playbooks/tor_node.yml --ask-vault-pass

Il est possible de limiter l'exécution à un rôle contenu dans le playbook. Par exemple, le rôle users, qui crée, ajoute les clés SSH, configure les mots de passe, peut être ciblé avec son tag :

ansible-playbook --diff -v playbooks/tor_node.yml --ask-vault-pass -t users

On peut également tester le résultat du playbook sans l'appliquer : Je recommande fortement de lancer le playbook au moins une fois avec -v --diff --check pour vérifier qu'il n'y a pas de modification aberrante

ansible-playbook --diff -v playbooks/tor_node.yml --ask-vault-pass -t users --check

Pour se faciliter la vie, on peut utiliser ces alias la :

alias ap='ansible-playbook --diff -v -J'
alias aplaybook='ansible-playbook --diff -v -J'

De la sorte, lancer le playbook en ciblant le role utilisateur devient :

ap playbooks/tor_node.yml -t users