Bonjour à tous ! Aujourd’hui voici un nouveau tutoriel sur la mise en place d’Ansible. Cet outil vous permet de faciliter la gestion de votre parc de serveurs si vous possédez un grand nombre d’instance de VM. D’autres articles seront par la suite dédiés à la configuration de templates plus complexes.

Pré Requis pour ce tutoriel :

Posséder un serveur Master ainsi que 2 serveurs Clients nommés respectivement :

• Ansible Master
• Ansible Slave 01
• Ansible Slave 02
• Tous mes serveurs sont sur Debian 10.X
• Posséder un accès SSH sur chacun des serveurs clients, les clients doivent avoir le même mot de passe (on peut imaginer un compte de service avec les accès root par exemple).
• Posséder un accès root sur chacun des serveurs clients.

Etape 1 : Installation de Ansible (sur Ansible Master) :

• Ouvrir le fichier « /etc/apt/souces.list » avec l’éditeur de votre choix, personnellement j’utilise Nano, attention, ouvrir le fichier en tant qu’utilisateur root ou ayant des droits d’administrateur                  

sudo nano /etc/apt/sources.list

• Ajouter la clé correspondante au serveur contenant le paquet Ansible avec la commande suivante :

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 93C4A3FD7BB9C367

• Mettre à jour la liste des paquets disponibles pour la distribution :

sudo apt update

• Installation du paquet Ansible :

sudo apt install ansible

Etape 2 : Vérification de la connexion SSH sur les deux machines clientes :

Pour pouvoir vérifier qu’Ansible aura bien accès en SSH à nos machines, mais également échanger les clés privées publiques entre les machines, il est important de lancer une connexion SSH sur les machines clientes à partir de la machine « Ansible Master », ce qui nous donne quelque chose comme ça :

Pour plus d’informations concernant la configuration de l’authentification SSH par couple de clé privée / publique, je vous invite à consulter cet article : https://le-guide-du-secops.fr/index.php/2020/09/25/configurer-le-service-ssh-avec-uniquement-lauthentification-par-paire-de-cles-privee-publique-linux/

Puis, il nous faut entrer « yes » au moment de l’échange de clé, puis, en entrant notre mot de passe, on arrive sur la machine cliente.

Etape 3 : Modification du fichier hosts d’Ansible :

Sur Ansible Master, nous allons donc à présent lui renseigner ses cibles (machines clientes), sur lesquelles il va jouer différents playbooks en réalisant différentes actions :

sudo nano /etc/ansible/hosts

Dans ce fichier, vous trouverez des exemples de configuration de groupes de machines. Ranger les machines par groupe peut s’avérer plus qu’utile lorsque l’on dépasse la taille d’un simple lab.

Par exemple, en fin de fichier afin de conserver les exemples, j’ai créé un groupe lab comme suit :

Les lignes non commentées sont celles qui seront prises en compte par Ansible.

On voit dans la capture ci-dessus que je spécifie un utilisateur qui a des accès root sur la machine, il est important de le préciser dans notre cas.

Bien penser à sauvegarder le fichier avant de quitter 😉

Etape 4 : Le grand test !!

Désormais, nous allons pouvoir tester notre configuration à l’aide d’une commande ansible qui effectue un test (comme un ping) sur la machine distante afin de vérifier si toute la configuration est OK !

La commande est la suivante :

ansible all -m ping –ask-pass

Mais que fais cette commande ?

Ansible à spécifie que l’on appelle le programme Ansible

all spécifie que tous les hôtes contenus dans le fichier hosts (modifié ci-dessus) sont concernés, on aurait pu spécifier « LAB » afin que le test ne soit effectué que sur les machines dont l’IP est renseignée dans le fichier.

–m ping spécifie que le but va être de pinguer les instances.

-ask-pass Demande à l’utilisateur le mot de passe pour la connexion SSH. D’où l’importance de mettre le même mot de passe pour les connexions SSH en root sur les machines clientes.

Voici le résultat obtenu :

Étant donné qu’il est écrit success, nous pouvons voir que notre master arrive bien à se connecter aux machines clientes et que les tests d’Ansible se sont déroulés correctement.

Ci-dessous quelques Playbooks testé et fonctionnels :

• Playbook pour mettre à jour les serveurs (équivalent à un apt update && apt upgrade)

- hosts: LAB
  become: true
  become_user: root
  tasks:
    - name: Update apt repo and cache on all Debian/Ubuntu boxes
      apt: update_cache=yes force_apt_get=yes cache_valid_time=3600
    - name: Upgrade all packages on servers
      apt: upgrade=dist force_apt_get=yes
    - name: Check if a reboot is needed on all servers
      register: reboot_required_file
      stat: path=/var/run/reboot-required get_md5=no
    - name: Reboot the box if kernel updated
      reboot:
        msg: "Reboot initiated by Ansible for kernel updates"
        connect_timeout: 5
        reboot_timeout: 300
        pre_reboot_delay: 0
        post_reboot_delay: 30
        test_command: uptime
      when: reboot_required_file.stat.exists

Ce playbook a été lancé avec la commande suivante :

ansible-playbook « nom du playbook ».yml --ask-pass

Cette commande sert à lancer n’importe quel playbook.

Exemple de résultat de lancement d’un playbook réussi :

• Playbook pour supprimer un paquet (équivalent à apt remove)

- hosts: LAB
  become: true
  become_user: root
  tasks:
  - name: Remove "foo" package
    apt:
      name: foo #remplacer avec le nom du package
      state: absent

• Playbook pour mettre à jour une distribution (équivalent à un apt dist-upgrade)

- hosts: LAB
  become: true
  become_user: root
  tasks:
  - name: Upgrade the OS (apt-get dist-upgrade)
    apt:
      upgrade: dist

J’espère que ce tutoriel vous aura permis de comprendre le fonctionnement d’Ansible de manière générale et le lancement de Playbooks.

++

Benjamin pour le guide du sysops