Ansible

Présentation

Ansible est une plateforme logicielle libre pour la configuration et la gestion des ordinateurs. Elle combine le déploiement de logiciels multi-nœuds, l'exécution des tâches ad-hoc, et la gestion de configuration. Elle gère les différents nœuds à travers SSH et ne nécessite l'installation d'aucun logiciel supplémentaire sur ceux-ci. Les modules communiquent via la sortie standard en notation JSON et peuvent être écrits dans n'importe quel langage de programmation. Le système utilise YAML pour exprimer des descriptions réutilisables de systèmes, appelés playbook. Elle permet :

• D'automatiser : déployer des applications, gérer des systèmes
• De gagner du temps : grâce aux playbooks, on peut résoudre les problèmes une fois et partager facilement la solution
• De collaborer : en créant une "culture de l'automatisation"
• D'intégrer plus facilement en automatisant les technologies que l'on utilise déjà.

Mise en place

Source :

https://www.tartarefr.eu/ansible-par-la-pratique-premiere-partie-les-bases/

J'utilise deux machines :

• Mon PC sous Ubuntu 18.10, sur lequel j'installe Ansible et sshpass
• Une VM Debian basique, qui sera ma cible (192.168.1.49)

Avant toute chose, il faut que notre VM soit dans les known_hosts de la machine Ansible. Il suffit de s'y connecter une fois en ssh pour ajouter la clef !

Je commence par installer Ansible sur mon PC. Ensuite, je peux commencer à lancer une commande via Ansible :

justine@Justine-pc:/etc/ansible$ ansible 192.168.1.49 -m ping

Mais ça ne fonctionne pas : Ansible ne connait pas la cible, et on a pas d'utilisateur sur celle-ci !

Dans mon dossier home, je créée deux répertoires : prod et preprod, et dans chacun d'entre eux je met un fichier hosts.ini vierge.

Ensuite, dans preprod/hosts.ini, je mets :

[server]
192.168.1.49

[ansible]
localhost

Je peux ensuite rééessayer en précisant le répertoire de notre environnement et un utilisateur et ça fonctionne :

justine@Justine-pc:~/Ansible$ ansible -i ~/Ansible/preprod/hosts.ini 192.168.1.49 --user user --ask-pass -m ping
SSH password:
192.168.1.49 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

Je peux tenter une commande :

justine@Justine-pc:~/Ansible$ ansible -i ~/Ansible/preprod/hosts.ini 192.168.1.49 --user user --ask-pass -a whoami
SSH password:
192.168.1.49 | CHANGED | rc=0 >>
user

Par défaut, Ansible utilise le même utilisateur que l'utilisateur local sur l'hôte distant. C'est pour cela qu'il faut bien gérer les utilisateurs. De plus, il faut penser que la connexion root en ssh est désactivée par défaut sur Debian !

Lancer une série de commandes

Le fichier permettant de lister les commande à lancer s’appelle un playbook. Il peut être monolithique ou divisé en plusieurs parties. Ansible recommande la séparation par rôle, ce qui permet de réutiliser les commandes d’un playbook et de les partager facilement avec la communauté.

Les rôles

Il faut bien réfléchir à la séparation des rôles qu'aura notre serveur, afin de garder une bonne modularité. Si on prend l'exemple d'un serveur web personnel qui contiendrait un blog Wordpress, un outil d'analyse de trafic web Piwik et du monitoring, on a déjà 3 rôles. Mais chacun de ces rôles en nécéssite d'autres (bdd, serveur web...), et que la machine doit rester à jour, on arrive a un grand nombre de rôles :

•     system: concernera la post-installation du système
  •         Mettre le système à jour
  •         Définition des pools ntp (fr)
  •         Définition du nom d’hôte
  •         Définition basique du firewall: SSH (22)
  •         Redirection des mails locaux vers une adresse externe
  •         etc…
•     pki: Concernera l’obtention et la mise à jour des certificats SSL
  •         Copie de nos clés privées
  •         Copies de nos fichiers et scripts gérant la pki (systemd)
•     webserver: Concernera l’installation et la configuration d’apache
  •         Installation et configuration d’apache
  •         Mise à jour des extensions (ex modsecurity), hors RPM (les paquets RPMs seront mis à jour avec le rôle system)
  •         Ajout des ports HTTP (80) et HTTPS (443) au firewall
•     database: Concernera l’installation et la configuration de mariadb
  •         Installation et configuration de mariadb
•     blog: Concernera l’installation et la configuration de wordpress
  •         Installation et configuration du blog
  •         définition de l’alias ou du vhost pour le webserver
  •         import de la sauvegarde si elle existe
  •         Mise à jour des extensions, hors RPM (les paquets RPMs seront mis à jour avec le rôle system)
•     webstat: Concernera l’installation et la configuration de piwik
  •         Installation et configuration de piwik
  •         définition de l’alias ou du vhost pour le webserver
  •         import de la sauvegarde si elle existe
•     monitoring: Concernera l’installation et la configuration du monitoring
  •         Installation et configuration des outils
•     ids: Concernera l’installation et la configuration des outils de détection et de vérification d’intrusion
  •         Installation et configuration des outils

Du coup, le changement d'un rôle impactera pas ou peu les autres, et on pourra facilement changer certaines choses. Changer de blog n'impactera pas le reste par exemple, mais changer de serveur web impactera les autres rôles.

Les Playbooks

Il s'agit de fichiers au format YAML, qui contient une succession de tâche à accomplir. Par défaut, une erreur sur l'une d'entre elles entraîne l'arrêt du processus. Il existe beaucoup de modules différents et la doc les présente tous :

https://docs.ansible.com/ansible/latest/modules/modules_by_category.html

Je vais essayer de créer un playbook qui installer une liste de package avec apt :