IaC avec Ansible

Article d’introduction à Ansible dans lequel on voit comment utiliser les Playbooks.

Introduction

Infrastructure as Code

L’Infrastructure as Code est un ensemble de mécanismes permettant de gérer, par des fichiers descripteurs ou des scripts, […] une infrastructure à part entière, de l’instance au réseau, […].
Souvent plébiscité dans le cadre du cloud computing, l’Infrastructure as Code offre aux développeurs la possibilité de pouvoir automatiser leurs déploiements, et ainsi éviter toute configuration manuelle ; tout en évitant de devoir écrire d’eux-mêmes les appels aux interfaces de programmation. Cette technologie est donc une réponse aux besoins des entreprises en termes de passage à l’échelle des applications, mais également pour l’automatisation et la simplification des infrastructures des projets informatiques. Également, l’Infrastructure as Code rentre dans la mouvance plus générale du DevOps.
Wikipédia

L’IaC est donc une étape intéressante pour la mise en place et maintenance de notre système d’information.

Problématiques

Rien n’est de plus embêtant que de faire la configuration initiale d’un serveur :

• Installation des applications de base
• Configuration SSH (ajout des clés…)

On fait tout le temps la même chose ! Cela déborde même en script !
Le problème des scripts est souvent de gérer les cas d’erreurs (L’ajout du repository de Docker s’est-il bien déroulé ? Dans le cas contraire, je vais installer la version des dépôts d’Ubuntu, ce que je ne souhaite pas car pas assez à jour)…

De plus, quand on met en place un service, on essaye tant bien que mal d’apporter une documentation sur comment cela a été mis en place pour pouvoir ainsi le refaire si nécessaire. L’utilisation de docker compose m’as fait comprendre l’importance de cela.

Toutes ces réflexions révèlent l’essence même de ce site.

Ansible

C’est en 2015 que Red Hat annonce le rachat d’Ansible et le met sur le devant de la scène. Ansible est un logiciel libre qui s’utilise notamment pour faire de l’IaC, de la gestion de configuration et l’exécution de tâches.

Un peu plus de détail sur la page Wikipédia et sur le site officiel.

Vous avez peut-être déjà entendu parler de ses concurrents :

• Chef
• Puppet
• SaltStack

Nous allons donc voir ici comment on peut utiliser efficacement ce logiciel pour nous faciliter notre vie de bidouilleur de l’informatique.

Découverte

Installation

On installe donc Ansible. Pour cela, on va ajouté le PPA, mettre à jour notre liste des paquets existants et installer le logiciel.

sudo apt-add-repository --yes --update ppa:ansible/ansible
sudo apt update
sudo apt install ansible

Vous pouvez aussi l’installer avec PIP :

pip install --user ansible

J’ai remarqué que mon Ansible utilisait Python 2.7.17 alors que j’ai bien la version 3.6.9 sur mon WSL…
Je préfère utiliser dès le début la version utilisant Python3 histoire de pas avoir d’ennuis plus tard à cause d’un fin de support ou autre.

J’ai alors désinstallé Ansible, installé PIP3 et ainsi Ansible :

# sudo apt remove ansible
sudo apt install python3-pip
pip install --user ansible

Bien sûr le lancement de la commande ansible --version ne fonctionne pas et me donne un joli “command not found”.

Cela est dû au fait que le dossier où Ansible s’est installé (~/.local/bin) n’est pas dans la variable PATH.
Mais en consultant le fichier ~/.profile, je vois bien la section correspondante.
Je remets donc à jour mon shell avec un source ~/.profile et voici donc le résultat d’une nouvelle exécution de la commande ansible --version :

$ ansible --version

ansible 2.9.6
  config file = /etc/ansible/ansible.cfg
  [...]
  python version = 3.6.9 (default, Nov  7 2019, 10:44:02) [GCC 8.3.0]

Test

Effectuons le test basique de ping :

$ ansible localhost -m ping

localhost | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

Ce test est un test en mode d’exécution ad hoc.
On utilise le module ping qui fait partie de la grande liste des modules d’Ansible.

Nous allons nous voir comment générer un ensemble de tâches a exécuter via ce qu’Ansible définit comme un Playbook.
On peut faire une analogie avec Docker où un docker run correspond au mode ad hoc et un docker compose au Playbook.

Playbook

Inventory

Il est possible d’ajouter sa liste d’hôtes dans le fichier /etc/ansible/hosts dans le format INI, mais on va plutôt le faire dans un fichier YAML.

Je me suis positionné dans un répertoire de travail ~/projets/ansible ou j’ai créer le fichier d’inventaire que j’ai nommé hotes.yaml

all:
  hosts:
    192.168.92.17:
    192.168.92.4:
    sadara.scrample.xyz:

Cet inventaire est l’exemple le plus simple que je peux proposé, si vous êtes déterminé, aller voir la section sur la documentation officielle.

Tasks

J’ai créé un fichier livres.yaml dont le contenu est le suivant :

- name: Installation du serveur
  hosts: all
  remote_user: root
  tasks:
    - name: Installation de Git
      apt: name=git update_cache=yes
    - name: Installation de Vim
      apt: name=vim
    - name: Add user "nagios"  
      user:
        name: nagios
        shell: /bin/bash
        append: yes
        comment: "Nagios User"
        state: present
      become: true
    - name: Add Nagios SSH Key
      authorized_key:
        user: "nagios"
        key: "ssh-ed25519 BHIwxeOQq6nTGgEJ0+7s5VHbubL29xPFij+rlxdgHBU= nagios@kaishin"
        state: present
    - name: Installation des plugins Nagios
      apt: name=nagios-plugins update_cache=yes

Le Playbook se lit donc de la manière suivante :

Je me connecte sur chaque serveur (all) en tant que root pour effectuer les actions suivantes :

• J’installe git via le gestionnaire apt en mettant au préalable le cache à jour (update_cache=yes) . J’installe aussi vim.
• J’ajoute un utilisateur “nagios” ayant pour shell de base /bin/bash.
• J’ajoute la clé publique ssh-ed25519 BHIwxeOQq6nTGgEJ0+7s5VHbubL29xPFij+rlxdgHBU= nagios@kaishin au fichier ~/.ssh/authorized_key de l’utilisateur nagios.
• J’installe les plugins nagios (nagios-plugins) via le gestionnaire apt.

Lancement

On lance donc le playbook avec la commande suivante :
ansible-playbook -i hotes.yaml livre.yaml

Il est important de noter qu’un Playbook est de nature idempotente. Cela veut dire que l’on peut lancer le Playbook plusieurs fois sans problème. Si les tâches sont déjà accomplies, on ne les refait pas. Dans le cas de l’exemple du dessus, on ne va pas réinstaller les paquets et recréer un utilisateur à chaque lancement du playbook.

Voyez ici le résultat d’un énième lancement d’un playbook :

Anglais ou français, il faut choisir…

On voit bien que dans le récapitulatif, il n’y a rien de modifié.

Conclusion

Nous avons donc vu une approche d’Ansible ainsi que de ces Playbook.
Il existe une bibliothèque communautaire en ligne nommée Ansible Galaxy qui permet de récupérer les scripts des autres.

Vous remarquerez que les Playbooks de la communauté suivent un format de fichiers structurés. Cet article étant une introduction à Ansible, je ne suis pas allé dans ce sens.

Si vous voulez un aperçu de cela, vous pouvez initier un nouveau projet :

ansible-galaxy init MonPB
tree MonPB