Ansible pour gérer ses machines

Ansible est un logiciel libre (licence GNU v3) permettant de déployer et lancer des tâches sur une partie ou l’ensemble d’un parc informatique. Grâce à Ansible, vous pourrez notamment installer un logiciel, mettre à jour des fichiers de configuration, configurer un service sur l’ensemble de vos machines et cela, de manière automatique et à distance. L’exploitation commerciale d‘Ansible est, depuis 2015, la propriété de Red Hat.
Même si l’outil est prévu pour un parc informatique, il peut être intéressant de l’utiliser chez soi, et ce, à partir d’un nombre restreint de machines. En effet, Ansible pourra alors permettre de dupliquer la configuration des logiciels ou même du système, sur ces machines. Par exemple, Ansible permet d’avoir une même configuration des outils sur deux machines utilisées pour du développement et de mettre à jour cette configuration sans pour autant effectuer les manipulations sur les machines en question.

I-A. Configuration de test▲

Ansible est distribué sous la forme d’un paquet Python et s’installe donc avec la commande :

pip install ansible

Ansible doit uniquement être installé sur la machine de contrôle. Quant aux machines gérées par Ansible, elles ne nécessitent qu’une installation de Python pour exécuter le code généré par Ansible et un compte utilisateur auquel il est possible de se connecter au travers de SSH.

II-A. Configuration d’un nÅ“ud Windows▲

Ansible vient avec son propre vocabulaire. Ainsi, vous serez rapidement confronté aux mots suivants :

• machine de contrôle : la machine qui exécute Ansible et qui va envoyer des ordres aux autres machines ;
• machine gérée : une machine gérée par Ansible, qui va donc exécuter les tâches envoyées par Ansible. En « mode pull », la machine gérée est aussi la machine de contrôle ;
• inventaire (« inventory ») : la liste de machines gérées par Ansible ;
• playbook : un recueil de tâches à effectuer ;

Le parc informatique devant être géré par Ansible doit être décrit dans un fichier (pouvant être au format INI ou YAML) nommé inventaire (« inventory »). Les tâches à effectuer sur les machines du parc sont décrites dans un fichier (au format YAML) appelé « playbook ». Grâce à ses informations, Ansible se connectera donc aux machines mentionnées dans l’inventaire, grâce à SSH, pour lancer les tâches voulues.

Pour débuter avec Ansible, la première étape sera de créer un inventaire puis une tâche simple à exécuter. Le rôle de cette première tâche sera de joindre et d’obtenir une réponse des machines gérées par Ansible. Le but est multiple :

• créer un premier inventaire ;
• créer une première tâche ;
• vérifier que la connexion entre les machines, spécifiquement entre la machine de contrôle et les machines gérées est fonctionnelle ;

IV-A. Inventaire▲

[group1]
192.168.100.20
192.168.100.21

group1:
  hosts:
    computer1:
      ansible_host: 192.168.100.20
    computer2:
      ansible_host: 192.168.100.21

ansible-inventory -i inventory.ini --list

ansible group1 -m ping -i inventory.ini

computer1 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3.12"
    },
    "changed": false,
    "ping": "pong"
}
computer2 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3.12"
    },
    "changed": false,
    "ping": "pong"
}

computer1 | UNREACHABLE! => {
    "changed": false,
    "msg": "Failed to connect to the host via ssh: ssh: connect to host 192.168.100.20 port 22: Connection refused",
    "unreachable": true
}

computer2 | UNREACHABLE! => {
    "changed": false,
    "msg": "Failed to connect to the host via ssh: alexandre@192.168.100.21: Permission denied (publickey,password).",
    "unreachable": true
}

computer2 | FAILED! => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false,
    "module_stderr": "Shared connection to 192.168.100.21 closed.\r\n",
    "module_stdout": "/bin/sh: line 1: /usr/bin/python3: No such file or directory\r\n",
    "msg": "The module failed to execute correctly, you probably need to set the interpreter.\nSee stdout/stderr for the exact error",
    "rc": 127
}

IV-B. Tâche▲

- name: Hello World
  hosts: group1
  tasks:
   - name: Ping my hosts
     ansible.builtin.ping:

   # Une deuxième tâche:
   - name: Print message
     ansible.builtin.debug:
      msg: Bonjour monde

ansible-playbook -i ./inventory.yml ./ping-playbook.yml

PLAY [Hello World] *************************************************************

TASK [Gathering Facts] *********************************************************
ok: [computer1]
ok: [computer2]

TASK [Ping my hosts] ***********************************************************
ok: [computer1]
ok: [computer2]

TASK [Print message] ***********************************************************
ok: [computer1] => {
    "msg": "Bonjour monde"
}
ok: [computer2] => {
    "msg": "Bonjour monde"
}

IV-C. Les modules Ansible▲

- name: Copy some files
  hosts: group1
  tasks:
   - name: Copy a file in tmp
     ansible.builtin.copy:
      src: /home/alexandre/fichier
      dest: /tmp/fichier

- name: Copy some files
  hosts: group1
  tasks:
   - name: Copy a file
     ansible.builtin.copy:
      src: /home/alexandre/stamp
      dest: /etc/stamp
     become: yes

TASK [Copy a file in tmp] ******************************************************
fatal: [computer2]: FAILED! => {"msg": "Missing sudo password"}

ansible-vault create root_passwords.yaml

ansible_become_password: MotDePasse

- name: Copy some files
  hosts: group1
  vars_files:
    - root_passwords.yaml
  tasks:
   - name: Copy a file in tmp
     ansible.builtin.copy:
      src: /home/alexandre/stamp
      dest: /etc/stamp
     become: yes

ERROR! Attempting to decrypt but no vault secrets found

ansible-playbook --ask-vault-pass -i ./inventory.yml ./tasks/copy_file_root-2.yml

- name: Fetch file
  hosts: group1
  tasks:
   - name: Fetch fstab
     ansible.builtin.fetch:
      src: /etc/fstab
      dest: /tmp/out

- name: Fetch file
  hosts: group1
  tasks:
   - name: Fetch fstab
     ansible.builtin.fetch:
      src: /etc/fstab
      dest: /tmp/out/
      flat: yes

- name: Get file hosted online
  hosts: group1
  tasks:
   - name: Get some good hosts
     ansible.builtin.get_url:
      url: https://sebsauvage.net/hosts/hosts
      dest: /tmp/hosts

- name: Get godot
  hosts: group1
  tasks:
   - name: Get latest godot sources
     ansible.builtin.git:
      repo: https://github.com/godotengine/godot.git
      dest: /tmp/godot

- name: Fetch Google
  hosts: group1
  tasks:
   - name: Make request
     ansible.builtin.command: curl www.google.com --output /tmp/website.html

Ansible permet de créer des variables. Celles-ci peuvent être définies au travers d’un playbook, d’un inventaire, en les passant en option lors du lancement d’Ansible ou encore, dans un fichier à inclure (comme vu avec les coffre-forts). Une tâche peut aussi produire une nouvelle variable (en utilisant le mot clé register). La documentation indique dans la section « return values », les différentes variables produites par un module. Voici un exemple d’utilisation de register :

- name: Récupération d’un fichier en ligne
  hosts: group1
  tasks:
   - name: Récupération d’un fichier hosts
     ansible.builtin.get_url:
      url: https://sebsauvage.net/hosts/hosts
      dest: /tmp/hosts
     register: get_hosts

   # Utilisation de la variable précédemment créée
   - name: Debug
     ansible.builtin.debug:
      msg: "Taille : {{ get_hosts.size }}"

Le nom d’une variable est sujet à quelques restrictions : le nom ne peut contenir que des lettres, des chiffres et des soulignés. Plus précisément, le nom d’une variable ne peut pas commencer par un chiffre et ne peut pas être un mot clef du langage Python ou des playbooks.

Voici un autre exemple, où la variable est définie dans le playbook :

- name: variable test in playbook
  hosts: group1
  vars:
    my_var: "Developpez.com"
  tasks:
   - name: Simple variable test
     ansible.builtin.debug:
      msg: "Hello {{ my_var }}"

La même chose peut être réalisée, mais en définissant la variable dans l’inventaire :

group1:
  hosts:
    computer1:
      ansible_host: 192.168.100.20
      my_var: "Developpez.com"
    computer2:
      ansible_host: 192.168.100.21
      my_var: "Developpez.net"

Ce qui permet d’avoir une variable spécifique à la machine l’exécutant.

Finalement, la variable peut être définie lors de l’exécution de la commande avec l’option -e ou --extra-vars. Les différentes variables doivent être séparées par une espace :

ansible-playbook -e "my_var=World" -i ../inventory.yaml ./var-test.yaml

Par conséquent, il est possible que votre variable soit définie à deux endroits différents. La documentation officielle indique l’ordre de précédence.

- name: Test de boucle
  hosts: group1
  vars:
    a_list:
     - "Developpez.com"
     - "Developpez.net"
  tasks:
   - name: Say hi
     ansible.builtin.debug:
      msg: "Hello {{ item }}"
     loop: "{{ a_list }}"

TASK [Say hi] ******************************************************************
ok: [computer1] => (item=Developpez.com) => {
    "msg": "Hello Developpez.com"
}
ok: [computer1] => (item=Developpez.net) => {
    "msg": "Hello Developpez.net"
}
ok: [computer2] => (item=Developpez.com) => {
    "msg": "Hello Developpez.com"
}
ok: [computer2] => (item=Developpez.net) => {
    "msg": "Hello Developpez.net"
}

Ansible fournit un ensemble de variables, appelées « faits » (facts), qu’il est possible de consulter de deux manières différentes :

• avec une ligne de commande :

   

  Sélectionnez

  ansible -m setup group1 -i ../inventory.yaml

• avec un playbook :

- name: Debug
  hosts: group1
  tasks:
   - name: Afficher les variables
     ansible.builtin.debug:
      var: ansible_facts

Ansible propose aussi le mot clef when permettant d’ajouter une condition à l’exécution d’une tâche. La tâche suivante ne s’exécute que sur les machines non Windows :

- name: Test de condition
  hosts: group1
  tasks:
   - name: Tâche pour Linux, mais pas Windows
     ansible.builtin.debug:
      msg: "Hello Linux"
     when: ansible_facts['os_family'] != "Windows"

Les template permettent d’utiliser un fichier modèle pour générer un fichier sur les machines gérées. En effet, les variables utilisées dans le modèle seront remplacées par leur valeur telle que connue par Ansible. Ce mécanisme repose sur un langage spécifique : Jinja2. De plus, pour transformer un fichier modèle vers son état final, il est nécessaire d’utiliser le module Ansible template (et win_template pour Windows), qui, de manière globale, possède les mêmes fonctionnalités que le module copyCopier un fichier.

Avec le fichier Jinja 2 suivant :

Welcome on {{ machine_name }}

Et ce playbook :

- name: Send customized motd
  hosts: group1
  tasks:
   - name: Greetzs
     ansible.builtin.template:
      src: motd.j2
      dest: /tmp/motd

Vous obtiendrez, sur les machines gérées, le fichier suivant :

Welcome on Ordinateur 2

lorsque la variable machine_name est définie à « Ordinateur 2 ». Dans le cas présent, une telle variable serait certainement définie pour chaque machine de l’inventaire.

La documentation officielle de Jinja2 permet d’en apprendre plus sur les possibilités de ce langage.

Ansible propose un mécanisme, sous le nom de « handler », permettant d’effectuer une tâche uniquement si la machine gérée a été modifiée (état « changed »). Plus précisément, un « handler » est une tâche placée dans une section dédiée : handlers. Pour que le « handler » soit exécuté, une tâche classique doit en faire la demande avec le mot clef notify. Voici un exemple, reprenant le playbook pour récupérer un fichier en ligne :

- name: Get file hosted online
  hosts: group1
  tasks:
   - name: Get some good hosts
     ansible.builtin.get_url:
      url: https://sebsauvage.net/hosts/hosts
      dest: /tmp/hosts
     notify:
      - Debug handler

  handlers:
    - name: Debug handler
      ansible.builtin.debug:
        msg: "File successfully downloaded"

Une telle tâche pourra être à l’origine de la sortie suivante :

PLAY [Get file hosted online] **************************************************

TASK [Gathering Facts] *********************************************************
ok: [computer1]
ok: [computer2]

TASK [Get some good hosts] *****************************************************
ok: [computer2]
changed: [computer1]

RUNNING HANDLER [Debug handler] ************************************************
ok: [computer1] => {
    "msg": "File successfully downloaded"
}

PLAY RECAP *********************************************************************
computer1                  : ok=3    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
computer2                  : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Ici, seul « computer1 » a exécuté le « handler ». En effet, sur « computer2 », le fichier à récupérer était déjà présent, faisant qu’aucun changement n’a été effectué sur cette machine. Par conséquent, le « handler » n’a pas été exécuté.
Un cas classique d’utilisation des « handlers » est de redémarrer un service après la modification d’un fichier de configuration.

Les rôles d‘Ansible sont des ensembles de fichiers pouvant définir des tâches, des « handlers », des variables, des templates ou des fichiers quelconques. L’objectif est de mettre en place un ensemble de fichiers pouvant être utilisés dans une ou plusieurs tâches.

Les rôles se définissent au travers de la hiérarchie de fichiers suivante :

roles/
    common/             
        tasks/          
            main.yml    
        handlers/       
            main.yml    
        templates/      
            ntp.conf.j2 
        files/          
            bar.txt     
            foo.sh      
        vars/           
            main.yml    
        defaults/       
            main.yml    
        meta/           
            main.yml    
        library/        
        module_utils/   
        exemple_plugins/

Dans une telle hiérarchie, le nom du rôle est défini par le nom du dossier dans le dossier roles, ici :common. Ansible cherchera un fichier main.yml dans chacun des sous dossiers. Les sous dossiers d’un rôle sont les suivants :

• tasks : les tâches définies par ce rôle ;
• handlers : les « handlers » définis par ce rôle ;
• templates : les fichiers de modèles que ce rôle utilise ;
• files : les fichiers quelconques que ce rôle utilise ;
• vars : les variables définies par ce rôle ;
• defaults : d’autres variables, ayant une priorité faible, définies par ce rôle ;
• meta : permet d’appeler un autre rôle lors de l’inclusion de ce rôle (telle une dépendance). Peut aussi contenir des méta-données pour GalaxyGalaxy ;
• library : des modules personnalisés ;
• module_utils : du code supplémentaire pour les modules ;
• exemple_plugins : pour stocker des données spécifiques aux extensions, ici appelées « exemple ».

Avec la particularité que tout dossier est optionnel et peut-être absent si vous n’en avez pas besoin. Un rôle est valide s’il contient au moins un de ces dossiers.

Les rôles doivent être placés dans le dossier du playbook, ou un chemin relatif à celui-ci ou dans le dossier défini par roles_path. Il est aussi possible, lors de l’utilisation d’un rôle de spécifier un chemin complet.

Ci-dessous, un exemple d’un rôle, appelé test et définissant un unique fichier tasks/main.yml :

- name: Une tâche sans intérêt
  ansible.builtin.debug:
   msg: "Hello"

Et un playbook utilisant ce rôle :

- name: Role test
  hosts: group1
  roles:
   - role: test
  tasks:
   - name: Récupération d’un bon fichier hosts
     ansible.builtin.get_url:
      url: https://sebsauvage.net/hosts/hosts
      dest: /tmp/hosts

La tâche définie par le rôle est exécutée avant la tâche du playbook. Il est à noter que le playbook aurait aussi pu uniquement contenir :

- name: Role test
  hosts: group1
  roles:
   - role: test

Exécutant uniquement la ou les tâches définies dans le rôle.

VIII-A. Galaxy▲

ansible-galaxy role install namespace.role_name

Maintenant que les fonctionnalités principales d‘Ansible ont été expliquées, il est temps de mettre en place des tâches utiles.

La création d’une tâche suit généralement le processus suivant :

• expérimentation manuelle pour déterminer les étapes nécessaires de la tâche ;
• lecture de la documentation afin de trouver les modules adéquats pour réaliser les étapes ;
• écriture du playbook et des fichiers associés en se reposant sur la page de documentation dédiée à chaque module ;
• vérification du playbookVérification d’un playbook ;
• test du playbook sur une machine virtuelle de test. Cela est d’autant plus facile sachant que la machine virtuelle peut figurer dans un groupe spécifique de l’inventaire ;
• déploiement.

IX-A. Configuration de git▲

utilisateurs:
  - utilisateur:
      login: "utilisateur1"
      username: "Developpez Com"
      email: "utilisateur1@example.com"
  - utilisateur:
      login: "utilisateur2"
      username: "Developpez Net"
      email: "utilisateur2@example.com"

- name: Configure un nouvel utilisateur et prépare sa configuration Git
  hosts: group1
  vars_files:
   - users.yml
   - root_passwords.yml
  tasks:
   - name: Création de l’utilisateur
     ansible.builtin.user:
       name: "{{ item.utilisateur.login }}"
       # group: developers
       # password: https://docs.ansible.com/ansible/latest/reference_appendices/faq.html#how-do-i-generate-encrypted-passwords-for-the-user-module
     loop: "{{ utilisateurs }}"
     become: yes

   - name: Configuration du username Git
     ansible.builtin.git_config:
       name: utilisateur.name
       scope: global
       value: "{{ item.utilisateur.username }}"
     loop: "{{ utilisateurs }}"
     become: yes
     become_user: "{{ item.utilisateur.login }}"

   - name: Configuration de l’email Git
     ansible.builtin.git_config:
       name: utilisateur.email
       scope: global
       value: "{{ item.utilisateur.email }}"
     loop: "{{ utilisateurs }}"
     become: yes
     become_user: "{{ item.utilisateur.login }}"


   - name: Récupération des sources de Godot
     ansible.builtin.git:
      repo: https://github.com/godotengine/godot.git
      dest: ~/godot
     loop: "{{ utilisateurs }}"
     become: yes
     become_user: "{{ item.utilisateur.login }}"

IX-B. Installation et configuration d’un logiciel▲

- name: Installation et configuration de fzf
  hosts: group1
  vars_prompt:
    - name: "ansible_become_pass"
      prompt: "Mot de passe su"
  tasks:
   - name: Update (pacman)
     community.general.pacman:
       update_cache: true
       upgrade: true
     when: ansible_facts['os_family'] == "Archlinux"
     become: yes
     become_user: root
     become_method: su

   - name: Installation (pacman)
     community.general.pacman:
       name: fzf
       state: present
     when: ansible_facts['os_family'] == "Archlinux"
     become: yes
     become_user: root
     become_method: su

   - name: Update (apt)
     ansible.builtin.apt:
       upgrade: dist
       update_cache: yes
     when: ansible_facts['os_family'] == "Debian"
     become: yes
     become_user: root
     become_method: su

   - name: Installation (apt)
     ansible.builtin.apt:
       name: fzf
       state: present
     when: ansible_facts['os_family'] == "Debian"
     become: yes
     become_user: root
     become_method: su

   - name: Active fzf dans Bash
     ansible.builtin.lineinfile:
       path: ~/.bashrc
       search_string: eval "$(fzf --bash)"
       line: eval "$(fzf --bash)"
     when: ansible_facts['user_shell'] == "/bin/bash"

   - name: Active fzf dans zsh
     ansible.builtin.lineinfile:
       path: ~/.zshrc
       search_string: source <(fzf --zsh)
       line: source <(fzf --zsh)
     when: ansible_facts['user_shell'] == "/bin/zsh"

IX-C. Déploiement de point de montage réseau▲

[Install]
WantedBy=multi-user.target
[Unit]
Description=SMB Server

[Mount]
What=//mon-server.example.com/server
Where=/mnt/server
Options=_netdev,credentials=/root/smb.pass,x-systemd.automount,uid=1000,gid=1000
Type=cifs
TimeoutSec=300

[Automount]
Where=/mnt/server

username={{ username }}
password={{ server_password }}
domain=WORKGROUP

- name: Configuration d’un automount systemd
  hosts: group1
  vars:
    username: "developpez"
    server_password: "super_mot_de_passe"
  vars_files:
   - root_passwords.yml
  tasks:
   - name: Copie des informations de connexion
     ansible.builtin.template:
       src: ./smb.pass
       dest: /root/smb.pass
     become: yes

   - name: Copie des fichiers automount
     ansible.builtin.copy:
       src: ./mnt-server.mount
       dest: /etc/systemd/system/mnt-server.mount
     become: yes

   - name:  Copie des fichiers automount
     ansible.builtin.copy:
       src: ./mnt-server.automount
       dest: /etc/systemd/system/mnt-server.automount
     become: yes

   - name: Activation au démarrage de la machine
     ansible.builtin.systemd:
       daemon_reload: yes
       name: mnt-server.automount
       enabled: yes
     become: yes

   - name: Montage
     ansible.builtin.systemd:
       name: mnt-server.automount
       state: started
     become: yes

X-A. Vérification d’un playbook▲

ansible-playbook --check -i ./inventory.yaml ./ping.yaml

X-B. Linter▲

pip install ansible-lint

ansible-lint ./ping.yaml

WARNING  Listing 1 violation(s) that are fatal
yaml[indentation]: Wrong indentation: expected 6 but found 8
ping.yaml:9

Read documentation for instructions on how to ignore specific rule violations.

# Rule Violation Summary

  1 yaml profile:basic tags:formatting,yaml

Failed: 1 failure(s), 0 warning(s) on 1 files. Last profile that met the validation criteria was 'min'.

Ansible est un outil puissant, utile pour gérer un parc informatique, mais pouvant aussi être pratique dans un environnement plus modeste, tel que celui à la maison.
Cet article a permis de découvrir les différentes fonctionnalités d’Ansible et détaille la mise en place de tâches simples. Libre à vous de réutiliser ces connaissances et d’étendre les différents playbooks afin de gérer la configuration de vos machines.

Merci à Franck Talbart et Christophe pour leurs suggestions. Merci également à ALT pour sa relecture orthographique.