Ansible-Galaxy

Enregistrement vidéo du cours: Lien vers la vidéo

Le site et l'outil Ansible-Galaxy permettent de partager et réutiliser des rôles et des collections Ansible.

Préparation de l'environnement

Pour ces manipulations, assurez-vous d'avoir un environnement Ansible fonctionnel avec une machine géré Linux. Vous pouvez utiliser les .ova de la semaine 10.

Manipulation 1 : Installation d'un rôle depuis Ansible-Galaxys

Sur votre machine de contrôle (Ansible Controller), exécutez la commande ansible-galaxy pour vérifier son bon fonctionnement et son emplacement de stockage par défaut.

# Affiche la version d'Ansible-Galaxy
ansible-galaxy --version

Ensuite, nous allons explorer la configuration des rôles Ansible-Galaxy.

# Affiche la liste des rôles installés
ansible-galaxy role list

Si vous obtenez un message d'erreur indiquant que le chemin des rôles n'existe pas, ce n'est pas un problème. Ces dossiers seront créés automatiquement lors de l'installation d'un rôle. Prenez note de l'emplacement par défaut des rôles, généralement /home/ansible/.ansible/roles,/etc/ansible/roles ou ~/.ansible/roles.

Nous allons maintenant installer un rôle depuis Ansible-Galaxy. Par exemple, installons le rôle geerlingguy.apache pour configurer un serveur Apache.

ansible-galaxy role install geerlingguy.apache

Une fois l'installation terminée, vérifiez que le rôle a été installé correctement :

ansible-galaxy role list

Vous remarquerez l'endroit où le rôle a été installé, qui devrait correspondre à l'un des chemins notés précédemment. Dans mon cas, il est installé dans /home/ansible/.ansible/roles, donc ce sera l'emplacement à utiliser pour référencer ce rôle dans nos playbooks. Si le vôtre est différent, adaptez-le en conséquence.

Le rôle geerlingguy.apache est maintenant installé et prêt à être utilisé dans vos playbooks Ansible.

Explorons maintenant le contenu du rôle installé. Les rôles Ansible sont généralement organisés en plusieurs répertoires, notamment tasks, handlers, templates, files, vars, et defaults, comme nous l'avons vu précédemment.

ls -l /home/ansible/.ansible/roles/geerlingguy.apache

Entre autres, vous pouvez explorer:

  • tasks/main.yml : Contient les tâches principales pour configurer Apache. Le dossier tasks contient également d'autres fichiers YAML pour des hôtes spécifiques.
  • defaults/main.yml : Contient les variables par défaut utilisées par le rôle.

Utilisation du rôle dans un playbook

Créez un projet Ansible et créez fichier de playbook nommé install_apache.yml avec le contenu suivant :

---
- name: Utilisation du role geerlingguy.apache
  hosts: webservers
  become: true

  vars:
    apache_listen_port: 8080
    apache_vhosts:
      - servername: "example.com"
        documentroot: "/var/www/html"
  
  roles:
    # Référence au rôle que nous venons de télécharger
    - geerlingguy.apache
  tasks:
    - name: Créer une page d'accueil personnalisée
      copy:
        content: |
          <html>
            <head><title>Site déployé avec Ansible Galaxy</title></head>
            <body>
              <h1>Apache installé via un rôle Galaxy!</h1>
              <p>Rôle utilisé: geerlingguy.apache</p>
            </body>
          </html>
        dest: /var/www/html/index.html
        mode: '0644'

Créez un fichier d'inventaire inventory.ini pour définir vos hôtes Linux :

[webservers]
web01 ansible_host=IP_ADDRESS 

[all:vars]
ansible_user=ansible
ansible_password=Ansible123!
ansible_become_pass=Ansible123!

Créez ensuite un fichier ansible.cfg pour configurer Ansible à utiliser cet inventaire par défaut :

[defaults]
inventory = ./inventory.ini
host_key_checking = False

Enfin, exécutez le playbook pour installer et configurer Apache sur votre hôte Linux :

ansible-playbook install_apache.yml

Ce qui se passe :

  1. Le rôle geerlingguy.apache s'exécute en premier
  2. Il installe et configure Apache selon les variables fournies
  3. Les tasks supplémentaires s'exécutent ensuite

Manipulation 2: Gestion des dépendances de rôles avec requirements.yml

Ansible-Galaxy permet également de gérer les dépendances entre rôles via un fichier requirements.yml. Cela facilite l'installation de plusieurs rôles nécessaires pour un projet. Créez un fichier requirements.yml avec le contenu suivant :

# requirements.yml

# 1. Spécifier le rôle (src) et une version (optionnel mais recommandé pour la stabilité)
- src: geerlingguy.apache
  version: "3.2.0" 
  name: mon_serveur_web_apache

# 2. Installer un rôle directement depuis un référentiel Git (pour les rôles privés ou personnalisés)
- src: https://github.com/geerlingguy/ansible-role-mysql.git
  name: mon_role_mysql 
  # On peut aussi spécifier un tag, une branche, ou un commit spécifique avec 'version'
  # version: main

Nettoyez les rôles précédemment installés pour cette manipulation :

ansible-galaxy role remove geerlingguy.apache

Assurez-vous que les rôles ont été supprimés :

ansible-galaxy role list

Installez les rôles spécifiés dans le fichier requirements.yml :

ansible-galaxy role install -r requirements.yml

Vérifiez que les rôles ont été installés correctement :

ansible-galaxy role list

C'est la méthode recommandée pour gérer les rôles dans des projets Ansible, car elle permet de versionner et de documenter les dépendances de manière claire. Lorsque vous initialisez un nouveau projet, vous pouvez simplement exécuter la commande ci-dessus pour installer tous les rôles nécessaires à partir du fichier requirements.yml.

Manipulation 3 : Création et publication de votre propre rôle sur Ansible-Galaxy

Nous avons vu au cours précédent comment créer un rôle Ansible manuellement, soit en créant les dossiers et les fichiers nécessaires. Nous allons maintenant voir comment créer un rôle d'une manière plus automatisée en utilisant la commande ansible-galaxy init.

ansible-galaxy init webapp 

Explorez la structure du rôle créé :

tree webapp

Note: Si la commande tree n'est pas disponible, vous pouvez utiliser ls -R webapp pour lister récursivement les fichiers et dossiers.

La structure devrait ressembler à ceci:

webapp/
├── README.md
├── defaults
│   └── main.yml
├── files
├── handlers
│   └── main.yml
├── meta
│   └── main.yml
├── tasks
│   └── main.yml
├── templates
├── tests
│   ├── inventory
│   └── test.yml
└── vars
    └── main.yml

Créons une tâche simple dans tasks/main.yml pour simplement montrer que le rôle fonctionne :

---
- name: Afficher un message
  debug:
    msg: "Le rôle webapp a été exécuté avec succès!"

Ajoutons ce rôle à un playbook site.yml :

---
- name: Exécuter le rôle webapp
  hosts: localhost
  roles:
    - webapp

Exécutez le playbook pour tester le rôle localement :

ansible-playbook site.yml

Vous devriez voir le message de débogage s'afficher, indiquant que le rôle a été exécuté avec succès.

Les collections

Ansible-Galaxy permet également de gérer les collections, qui sont des ensembles de rôles, modules, plugins et autres contenus Ansible regroupés pour une distribution facile. Quelques collections populaires :

  • community.general : Une collection contenant une grande variété de modules et de plugins pour diverses tâches.
  • amazon.aws : Fournit des modules pour gérer les services AWS.
  • cisco.ios : Contient des modules pour gérer les équipements Cisco IOS.

Installation d'une collection

Pour installer une collection depuis Ansible-Galaxy, utilisez la commande suivante :

ansible-galaxy collection install community.docker

Vérifiez que la collection a été installée correctement :

ansible-galaxy collection list

Vous pouvez maintenant utiliser les modules, roles et plugins fournis par la collection community.docker dans vos playbooks Ansible.

Utilisation d'une collection dans un playbook

Utilisation d'un module d'une collection

Pour utiliser une collection dans un playbook, vous devez spécifier la collection dans la section collections du playbook. Voici un exemple utilisant la collection community.docker pour gérer des conteneurs Docker :

---
- name: Utilisation des modules de la collection community.docker
  hosts: linux_servers
  become: true
  
  tasks:
    - name: Demarrer un conteneur (utilisation du FQCN)
      # FQCN (Fully Qualified Collection Name) : namespace.collection_name.module_name
      community.docker.docker_container:
        name: mon_conteneur_test
        image: busybox
        state: started
        command: "sleep 3600"
        
    - name: Inspecter l'etat du conteneur
      community.docker.docker_container_info:
        name: mon_conteneur_test
      register: container_info
      
    - name: Afficher le statut du conteneur
      debug:
        msg: "Le conteneur est dans l'etat : {{ container_info.containers[0].State.Status }}"

Explications:

  • La tâche Demarrer un contenur (utilisation du FQCN) utilise le module docker_container de la collection community.docker pour démarrer un conteneur Docker nommé mon_conteneur_test avec l'image busybox.
  • La tâche Inspecter l'etat du conteneur utilise le module docker_container_info pour récupérer des informations sur le conteneur, et enregistre ces informations dans la variable container_info.
  • La tâche Afficher le statut du conteneur affiche l'état actuel du conteneur en utilisant le module de débogage et en accédant à la variable enregistrée.
  • Nous remarquons qu'ici, nous utilisons le FQCN (Fully Qualified Collection Name) pour référencer les modules de la collection, ce qui est une bonne pratique pour éviter les conflits de noms entre différents modules. Dans les semaines précédentes, nous utilisions souvent des modules sans spécifier la collection (exemple: apt), mais il est recommandé d'utiliser le FQCN pour une meilleure clarté et compatibilité (exemple: ansible.builtin.apt).

Utilisation d'un rôle d'une collection

De la même manière, vous pouvez utiliser des rôles fournis par une collection. Voici un exemple utilisant un rôle de la collection community.general pour configurer un serveur NTP :

---
- name: Utilisation du role ntp de la collection community.general
  hosts: linux_servers
  become: true
  
  collections:
    - community.general
  
  roles:
    - ntp

Explications:

  • La section collections indique que nous utilisons la collection community.general dans ce playbook.
  • Le rôle ntp est référencé directement, car il fait partie de la collection spécifiée.

Comme nous n'avons pas vu les plugins dans ce cours, nous n'aborderons pas leur utilisation ici, mais sachez qu'ils peuvent également être utilisés de manière similaire en spécifiant la collection appropriée.

Publication de votre propre rôle ou collection sur Ansible-Galaxy

Ansible-Galaxy permet également de publier vos propres rôles et collections pour les partager avec la communauté. Pour ce faire, voici les étapes générales :

  1. Créer un compte GitHub : Ansible-Galaxy utilise GitHub pour héberger les rôles et collections.
  2. Créer un compte Ansible-Galaxy : Si vous n'en avez pas déjà un, créez un compte sur Ansible-Galaxy.
  3. Préparer votre rôle ou collection : Assurez-vous que votre rôle ou collection suit les bonnes pratiques de structure et de documentation.
  4. Publier sur GitHub : Poussez votre rôle ou collection dans un dépôt public sur GitHub.
  5. Importer dans Ansible-Galaxy : Utilisez les commandes Ansible-Galaxy pour importer votre rôle ou collection depuis GitHub vers Ansible-Galaxy:
ansible-galaxy role import USERNAME REPO_NAME

ou pour les collections :

ansible-galaxy collection import USERNAME REPO_NAME
  1. Gérer les versions : Utilisez les tags Git pour gérer les versions de votre rôle ou collection, ce qui facilitera leur utilisation par d'autres utilisateurs.