Introduction

Ansible est un outil d’automatisation de la configuration, du déploiement et de la gestion des systèmes informatiques.

Ansible utilise une architecture client-serveur basée sur SSH pour exécuter des tâches sur des hôtes distants. Il est écrit en Python et est open source.

La syntaxe d’ansible :

ansible cible -m module [-a arg] [-i inv]

La commande ansible est utilisée pour automatiser le déploiement et la gestion de configurations sur un ensemble de machines distantes, appelées cibles (hosts).

Voici une explication des différentes parties de la commande :

• cible : spécifie la ou les machines cibles sur lesquelles exécuter l’action. Il peut s’agir d’une adresse IP, d’un nom d’hôte ou d’un groupe de machines défini dans un fichier d’inventaire.

• -m module : spécifie le module Ansible à utiliser pour effectuer l’action sur la cible. Les modules sont des scripts Python préconçus pour effectuer une tâche spécifique, telle que la copie de fichiers, la gestion de packages ou la configuration de services.

• -a arg: spécifie les arguments à passer au module Ansible. Les arguments sont spécifiques au module utilisé. Par exemple, pour le module de copie de fichiers, les arguments pourraient inclure le chemin du fichier source et le chemin de destination.

• -i inv: spécifie le fichier d’inventaire à utiliser pour déterminer les machines cibles. L’inventaire est un fichier de configuration qui décrit les machines cibles et leurs attributs, tels que les adresses IP, les noms d’hôtes, les groupes, etc.

En utilisant cette commande, Ansible exécutera l’action spécifiée sur la ou les machines cibles en utilisant le module spécifié avec les arguments fournis.

Exemple 1:

ansible all -m ping -i servers

Dans cette commande, all spécifie que tous les hôtes de l’inventaire doivent être vérifiés, -m ping indique que le module ping doit être utilisé pour effectuer la vérification et -i servers spécifie l’inventaire à utiliser pour trouver les hôtes.

Exemple 2 :

ansible web_servers -m copy -a "src=/path/to/config/file dest=/etc/myapp.conf" -i servers

Dans cette commande, “web_servers” spécifie les hôtes cibles (qui doivent être spécifiés dans l’inventaire), -m copy indique que le module “copy” doit être utilisé pour copier le fichier, -a spécifie les arguments à passer au module (dans ce cas, la source et la destination du fichier) et -i servers spécifie l’inventaire à utiliser.

L’inventaire

Utilisation

[-i inventaire]

Par défaut, Ansible recherche l’inventaire dans le fichier /etc/ansible/hosts. Ce fichier est considéré comme l’inventaire global de la machine.

Il est également possible de définir un inventaire par défaut dans le fichier de configuration d’Ansible (/etc/ansible/ansible.cfg) dans le home directory du user en utilisant la directive inventory. Par exemple, vous pouvez ajouter la ligne suivante à votre fichier ansible.cfg pour définir un inventaire par défaut dans un fichier hosts situé dans votre répertoire de travail :

inventory = ./hosts

Inventaire statistique

Voici un exeple simple d’inventaire statique :

[defaults]
inventory=/home/ansible/hosts

la ligne inventory=/home/ansible/hosts indique que l’inventaire par défaut pour l’environnement Ansible est situé dans le fichier /home/ansible/hosts. Cela signifie que lorsqu’une commande Ansible est exécutée sans spécifier un fichier d’inventaire, Ansible utilisera automatiquement ce fichier comme source d’inventaire.

Les groupes d’hôtes

Dans Ansible, un groupe d’hôtes est une collection d’hôtes qui partagent des caractéristiques ou des fonctions communes. Les groupes d’hôtes peuvent être définis dans l’inventaire et sont souvent utilisés pour organiser les hôtes en fonction de leur rôle ou de leur emplacement.

Les groupes d’hôtes sont définis dans le fichier d’inventaire Ansible en utilisant la syntaxe suivante :

[backend]
serveur1.formation.remote
serveur2.formation.remote

[database]
db1.formation.remote
db2.formation.remote

[front]
serveur3.formation.remote

[linux:children]
backend
front

[windows:children]
database

Inventaire dynamique

Pour créer des inventaires dynamique on a la possibilité des scripts Python, Shell, Go etc avec une sortie au format JSON Deuxième possibilité est d’utiliser des plugins ansible d’inventaire dédié comme aws_ec2, virtualbox etc. Les noms des fichiers d’inventaire doivent se terminer par vbox.yml pour le plugin virtualbox et aws_ec2.yml pour le plugin aws_ec2.

Visualiser l’inventaire en mode graph on utilise l’option --graph :

 ansible-inventory -i aws_ec2.yml --graph

Visualiser l’inventaire en mode list (json) on utilise l’option --list :

 ansible-inventory -i aws_ec2.yml --list

Les variables d’inventaire

Les variables dans les inventaires statiques

• variables associées aux cibles :

[backend]
serveur1.formation.remote  ansible_connection=ssh ansible_user=user1

• variables associées aux groupes d’hôtes :

[all:vars]
ansible_connection=ssh

[backend:vars]
ansible_user=user1

[front:vars]
ansible_user=user2

Pour appeler ces variables au niveau des playbook on utilise la syntaxe suivante :'{{web_file}}'

Les variables dans les inventaires dynamiques

Pour les inventaires dynamiques, il faut créer deux répertoires goup_vars contient les variables dans des fichiers cibles. les fichiers portent les noms des serveurs cibles, et dans chaque fichier on peut créer nos variable au format clé: valeur :

├── goup_vars
│   ├── all
│   ├── backend
│   └── front
├── host_vars
│   └── database
├── playbook.yml
└── .gitignore

C’est tout a fait possible de récupérer des variables d’une hote1 depuis Hote2.

Exemple :

On peut récupérer les valeurs et des informations sur le serveur database depuis le serveur backend grâce à host_vars.

host_vars est un tableau associatif qui fait référence à toutes les variables de toutes les machines

Exemple :

 ansible backend -m debug -a "var=hostvars['database']"

Le Playbook

Un playbook Ansible est un fichier qui contient une séquence d’étapes à exécuter sur un ou plusieurs hôtes cibles

Exécution

ansible-playbook playbook.yml

Les options :

-v

Mode verbeux :

--syntax-check

Teste la validité du fichier :

--check

Passer un variable en ligne de commande -e pour extras variables :

ansible-playbook playbook.yml -e nom_variable=valeur

Lancer en mode dry-run : cela veut dire que le playbook va être exécuté en mode simulation et on va réellement lancer le playbook.

---
- name: Installation des serveurs web
  hosts: web
  vars:
    apache_port: 80
    tomcat_port: 8080
    apache_max_keepalive: 25
    remote_user: ansible
    become: yes
  tasks:
    - name: Install du package apache
      yum:
        name: httpd
        state: latest
    - name: Start du service apache
      service:
        name: httpd
        state: started
    - name: enable selinux
      command: /sbin/setenforce 1
    - name: debug
      debug:
        msg: "Ceci n'apparait qu'avec l'option -vv+"
      verbosity: 2
      tags:
        - debug

Explications:

Ce fichier YAML Ansible décrit une tâche qui installe Apache sur les serveurs Web, démarre le service Apache, active SELinux et utilise le module de débogage Ansible pour afficher un message si l’option de verbosité est définie à 2 ou plus. Les variables définies au niveau du playbook sont utilisées pour configurer les ports d’Apache, le nombre maximal de connexions simultanées et le compte d’utilisateur distant.

Les boucles

with_items

On utilise le mot clé with_items pour boucler dans un variable {{item}}

Exemple de playbook avec une boucle :

---
- hosts: all
  remote_user: ansible
  vars:
    files: [fic1, fic2, fic3]
    dirs:
      - rep1
      - rep2
      - rep3
  tasks:
    - name: create files for Redhat
      file:
        dest: "/home/ansible/{{item}}"
        state: touch
      with_items: "{{files}}"
      when: ansible_os_family  ==  "RedHat"
    - name: create directories for Redhat
      file:
        dest: "/home/ansible/{{item}}"
        state: directory
      with_items: "{{dirs}}"
      when: ansible_os_family  ==  "RedHat"

Explications :

Ce fichier YAML Ansible décrit une tâche qui crée des fichiers et des répertoires sur les hôtes cibles à l’aide du module de fichier Ansible. Les fichiers à créer sont définis dans la variable files, et les répertoires à créer sont définis dans la variable dirs. Le playbook utilise une condition pour exécuter la tâche uniquement sur les hôtes Redhat. Le compte d’utilisateur distant est défini comme étant ansible.

Itérer dans un tableau de clé:valeur :

---
- hosts: all
  remote_user: ansible
  vars:
    servers:
      windows:
        win10:
          function: ad
          environment: prod
        win7:
          function: sql
          environment: test
      linux:
        redhat:
          function: web
          environment: test
        debian:
          function: db
          environment: prod
  tasks:
    - name: iterate over windows array
      file:
        name: "/home/ansible/{{item.key}}-{{item.value.function}}"
        state: touch
      with_dict: "{{servers.windows}}"
    - name: iterate over linux array
      file:
        name: "/home/ansible/{{item.key}}-{{item.value.function}}"
        state: touch
      with_dict: "{{servers.linux}}"
      when: 'item.value.environment == "prod"'

Explications :

Ce fichier YAML Ansible décrit une tâche qui itère sur un tableau de clés/valeurs pour créer des fichiers à l’aide du module de fichier Ansible. Les clés sont les noms des serveurs, les valeurs sont les propriétés de chaque serveur. Le playbook utilise une condition pour exécuter la tâche uniquement sur les serveurs ayant un environnement de production. Le compte d’utilisateur distant est défini comme étant ansible.

Les rôles

introduction

Un rôle Ansible est une unité organisationnelle qui permet de regrouper des tâches, des fichiers de configuration, des variables et des modèles en une seule entité. Il s’agit d’une méthode de réutilisation de code qui permet de décomposer une infrastructure complexe en tâches plus petites et plus faciles à gérer. Chaque rôle peut être réutilisé dans différents projets ou déploiements.

Les rôles peuvent être créés à partir de zéro ou peuvent être téléchargés depuis des sources externes, comme Ansible Galaxy, qui est une bibliothèque en ligne de rôles prêts à l’emploi. Les rôles sont également conçus pour être modulaires, de sorte que les parties spécifiques peuvent être réutilisées dans d’autres rôles ou projets.

Structure

la liste des répertoires :

my-role
├── defaults
│   └── main.yml
├── files
│   ├── config-file-1.conf
│   └── config-file-2.conf
├── handlers
│   └── main.yml
├── meta
│   └── main.yml
├── README.md
├── tasks
│   └── main.yml
├── templates
│   └── template-1.j2
├── tests
│   ├── inventory
│   └── test.yml
└── vars
└── main.yml

• defaults : Contient les valeurs par défaut pour les variables utilisées dans le rôle.
• files/: Contient les fichiers à copier sur les machines cibles avec le module copy. handlers/: Contient les handlers, qui sont des tâches qui seront déclenchées par les autres tâches lorsque nécessaire.
• meta/: Contient des informations sur le rôle, telles que les dépendances à d’autres rôles.
• tasks/: Contient les tâches à effectuer sur les machines cibles.
• templates/: Contient les fichiers de modèles (Jinja2) à utiliser pour générer des fichiers sur les machines cibles.
• tests/: Contient les tests pour le rôle.
• vars/: Contient les variables utilisées dans le rôle.
• README.md: Fichier optionnel contenant des informations sur l’utilisation et le but du rôle.

Pour créer cette l’arborescence, ansible propose une commande pour le faire.

Exemple de creation d’un role create_user :

 ansible-galaxy init create_user

Pour exécuter ce rôle, vous pouvez créer un playbook qui inclut ce rôle dans la section roles. Voici un exemple de playbook:

---
- name: Test my_role
  hosts: all
  roles:
    - my_role

Dans cet exemple, nous avons un playbook nommé main.yml qui inclut le rôle my_role. Nous exécutons ce playbook en utilisant la commande ansible-playbook main.yml. Cette commande exécutera le rôle sur tous les hôtes définis dans le fichier d’inventaire.

Gestions des secrtes avec Vault

introduction

Pour sécuriser les mots de passe sur Ansible, vous pouvez utiliser des variables cryptées ou des fichiers de variables sécurisés.

L’utilisation de variables cryptées vous permet de stocker les informations sensibles, telles que les mots de passe, de manière sécurisée. Ansible prend en charge plusieurs méthodes de chiffrement, notamment Ansible Vault, qui vous permet de stocker les variables cryptées dans des fichiers YAML.

Les points forts d’Ansible Vault

• Chiffrement robuste : Ansible Vault utilise un chiffrement solide pour protéger les données sensibles telles que les mots de passe, les clés SSH, les jetons d’API, etc.

• Utilisation facile : Ansible Vault offre une interface utilisateur simple et intuitive pour crypter et décrypter les données sensibles.

• Intégration transparente : Ansible Vault est intégré de manière transparente dans l’écosystème Ansible, ce qui facilite l’utilisation des secrets dans les playbooks et les rôles.

• Gestion fine des accès : Ansible Vault permet de définir des politiques d’accès granulaires pour contrôler qui peut accéder aux secrets.

• Gestion centralisée : Ansible Vault peut être utilisé avec des systèmes de stockage de secrets centralisés tels que HashiCorp Vault, permettant une gestion centralisée des secrets.

• Versioning des secrets : Ansible Vault permet de versionner les secrets, ce qui facilite la gestion des changements et la traçabilité des accès aux secrets.

Creer un coffre-fort de secrets

Voici un exemple simple pour crypter les secrets. On va reprendre notre inventaire avec les 3 groupes de serveurs : backend, database et front. Pour facilier la gestions des secrets on va greer un dossier group_var qui va lui meme contenir 3 dossiers (pour les 3 groupes de serveurs).

Voici un exemple de structure pour utiliser Ansible Vault et stocker les secrets dans les fichiers de variables de groupe (group_vars) :

group_vars
├── backend
│   ├── vars.yml
│   └── vault.yml
├── front
│   ├── vars.yml
│   └── vault.yml
└── database
    ├── vars.yml
    └── vault.yml

Créer un dossier group_vars à la racine du projet Ansible. Ce dossier contiendra les fichiers de variables pour chaque groupe de serveurs (backend, database et front.).

Créer un fichier deux fichiers pour chaque groupe de serveurs, en utilisant la syntaxe suivante pour stocker les variables sensibles :

Le premier fichier : vars.yml

---
password: "{{mot_de_passe}}"

Le deuxieme fichier vault.yml qu’on va le crypter à l’aide de Vault:

---
mot_de_passe: "Toto123"

vous pouvez générer en le mot de passe crypté a l’aide de la commande suivante :

ansible-vault encrypt vault.yml

Voici un exemple de fichier YAML crypté avec Ansible Vault :

# group_vars/backend/vault.yml

$ANSIBLE_VAULT;1.1;AES256
36373935666438333530646433613737623561366264336164376365343230313961313166346632
3366346566303534613339356266653562343062663331340a366432633462656336333836386335

Astuce

Il est possible de modifier les secrets dans un fichier chiffré sans avoir à le déchiffrer en utilisant les commande :

ansible-vault edit group_vars/backend/vault.yml

Une fois que vous avez remplacé l’ancienne valeur du secret par la nouvelle valeur chiffrée, enregistrez le fichier et quittez l’éditeur.

Le secret a été modifié avec succès dans le fichier chiffré, sans que vous ayez eu à le déchiffrer.

Vous devez avoir la clé de chiffrement correcte pour le fichier que vous souhaitez modifier.

On peut aussi visualiser les secrets grace a la commande :

ansible-vault view group_vars/backend/vault.yml

Pour decrypter le fichier :

ansible-vault decrypt group_vars/backend/vault.yml

Les variables & débogage

Variables

Il existe plusieurs façons de déclarer des variables avec Ansible. Voici les deux méthodes les plus couramment utilisées :

Déclaration de variables dans un fichier de variables Dans un fichier de variables, vous pouvez déclarer des variables en tant que paires clé-valeur :

# variables.yml

nom: "John Doe"
age: 25
email: "johndoe@example.com"

Vous pouvez ensuite inclure ce fichier de variables dans votre playbook ou rôle à l’aide de l’option “vars_file” :

# playbook.yml

- hosts: webservers
  vars_file:
    - variables.yml

  tasks:
    - name: Exemple de tâche utilisant des variables
      debug:
        msg: "Bonjour, mon nom est {{ nom }} et j'ai {{ age }} ans."

Dans cet exemple, nous avons inclus le fichier de variables variables.yml dans notre playbook et utilisé les variables définies dans ce fichier dans la tâche debug (on va voir par la suite les diffirents techniques de débogages).

Déclaration de variables dans un playbook ou un rôle Vous pouvez également déclarer des variables directement dans votre playbook ou rôle en utilisant l’option “vars” :

# playbook.yml

- hosts: webservers
  vars:
    nom: "John Doe"
    age: 25
    email: "johndoe@example.com"

  tasks:
    - name: Exemple de tâche utilisant des variables
      debug:
        msg: "Bonjour, mon nom est {{ nom }} et j'ai {{ age }} ans."

Dans cet exemple, nous avons déclaré les variables nom, age et email directement dans notre playbook et utilisé les variables définies dans la tâche debug.

Ces deux méthodes vous permettent de déclarer des variables dans Ansible et de les utiliser dans vos playbooks et rôles pour rendre votre configuration plus modulaire et réutilisable.

débogage

Pour déboguer des problèmes avec Ansible, il existe plusieurs outils et techniques que vous pouvez utiliser. Voici quelques-uns des outils les plus couramment utilisés :

1. Utilisation de la commande ansible-playbook avec les options -v, -vv ou -vvv :

ansible-playbook playbook.yml -vv

Cette commande augmentera le niveau de verbosité de l’exécution du playbook, ce qui permettra d’obtenir des informations plus détaillées sur les tâches en cours d’exécution et de déterminer où se situent les problèmes.

Exemple :

# playbook.yml

- hosts: webservers

  tasks:
    - name: Exemple de tâche utilisant des variables
      debug:
        msg: "Bonjour, pour voir ce message il faut utiliser l'option -vv"
        verbosity: 2

2. Utilisation de la commande ansible-lint :

ansible-lint playbook.yml

Cette commande détectera les erreurs de syntaxe et les problèmes de style dans le playbook “playbook.yml” et affichera des messages d’erreur s’il y en a.

3. Utilisation de l’option debug dans votre playbook :

- name: Exemple de tâche avec débogage
  debug:
    msg: "La variable X a pour valeur {{ X }}"

Cette tâche affichera la valeur de la variable “X” lors de l’exécution du playbook.

4. Utilisation de l’option -check lors de l’exécution d’un playbook :

ansible-playbook playbook.yml —check

Cette commande vérifiera si le playbook “playbook.yml” fonctionnerait correctement sans effectuer de modifications.

1. Utilisation du module assert :

- name: Vérifier que la variable X est égale à 5
  assert:
    that: X == 5

Cette tâche vérifiera si la variable “X” a pour valeur 5 et affichera un message d’erreur si ce n’est pas le cas.

5.Utilisation de l’option --start-at-task :

ansible-playbook playbook.yml —start-at-task “Configurer le serveur web”

Cette commande spécifiera que l’exécution du playbook doit commencer à la tâche “Configurer le serveur web”.

6. Utilisation du module debug :

- name: Exemple de tâche avec débogage
  debug:
  msg: "La variable X a pour valeur {{ X }}"

Cette tâche affichera la valeur de la variable “X” lors de l’exécution du playbook.

7. Utilisation du module pause :

- name: Demander à l'utilisateur s'il souhaite continuer
  pause:
    prompt: "Voulez-vous continuer (oui/non) ?"

Cette tâche interrompra l’exécution du playbook et demandera à l’utilisateur s’il souhaite continuer.