Les environnements d'execution Ansible

L’automatisation est au cœur de la gestion moderne des infrastructures, et Ansible est un outil incontournable pour y parvenir. Cependant, pour assurer la reproductibilité et la portabilité de vos tâches d’automatisation, il est indispensable de maîtriser les environnements d’exécution Ansible. Ces environnements permettent d’encapsuler toutes les dépendances nécessaires, assurant ainsi que vos playbooks fonctionnent de manière cohérente, que ce soit en développement, en test ou en production.

Qu’est-ce qu’un Environnement d’Exécution Ansible ?

Un environnement d’exécution Ansible est un conteneur léger qui encapsule toutes les dépendances nécessaires pour exécuter des playbooks Ansible de manière cohérente et reproductible. Ces dépendances incluent la version d’Ansible, les collections Ansible, les rôles, ainsi que les modules Python spécifiques.

Ces environnements sont définis à l’aide de fichiers YAML, où vous spécifiez les versions exactes des composants requis. Une fois configuré, cet environnement peut être exécuté sur n’importe quelle machine ou est installé Docker ou Podman, garantissant que vos tâches Ansible fonctionnent toujours de manière identique, quel que soit le système sous-jacent.

En pratique, cela signifie que vous n’avez plus besoin d’installer manuellement différentes versions d’Ansible ou de gérer les conflits de versions de dépendances sur votre machine de développement. Tout est préemballé dans un conteneur unique, prêt à être utilisé, ce qui simplifie considérablement la gestion des projets Ansible complexes.

Pré-requis

Avant de plonger dans la création et l’utilisation des environnements d’exécution Ansible, il est important de s’assurer que vous disposez des outils nécessaires et de certaines connaissances de base.

Connaissances de base

Une compréhension générale des concepts de conteneurisation est recommandée, en particulier si vous travaillez avec Docker ou Podman. Vous devez également être à l’aise avec la ligne de commande, car de nombreuses configurations et commandes seront exécutées via le terminal.

Enfin, il est utile de connaître les principes de base d’Ansible, notamment la manière dont les playbooks fonctionnent, car les environnements d’exécution seront souvent configurés et utilisés pour exécuter ces playbooks de manière cohérente et reproductible.

Avec ces pré-requis en place, vous serez bien équipé pour suivre ce guide et tirer le meilleur parti des environnements d’exécution Ansible.

Outils nécessaires

Tout d’abord, vous devez avoir installé Docker ou Podman, car ces outils sont essentiels pour créer et gérer des environnements conteneurisés. Docker est le plus couramment utilisé, mais Podman offre une alternative sans démon, utile dans certains contextes de sécurité.

Ensuite ansible-builder doit être installé en utilisant pip :

pip install ansible-builder

Création d’un Environnement d’Exécution Ansible

Pour créer un environnement d’exécution Ansible, vous devez définir les dépendances spécifiques nécessaires à vos projets Ansible dans un fichier de configuration YAML, puis construire cet environnement à l’aide de ansible-builder. Voici comment procéder, avec une explication détaillée de chaque champ du fichier de configuration et des fichiers supplémentaires comme bindep.txt et requirements.txt.

Le Fichier execution-environment.yml

Le fichier execution-environment.yml est au cœur de la création de votre environnement d’exécution. Voici un exemple typique :

version: 3

dependencies:
  galaxy: requirements.yml
  python: requirements.txt
  system: bindep.txt

images:
  base_image:
    name: ghcr.io/ansible-community/community-ee-minimal:2.16.0-1

additional_build_steps:
  prepend_base:
    - RUN yum install -y git
  append_final:
    - RUN groupadd --gid 1000 vscode
    - RUN adduser --home-dir /vscode --create-home --gid 1000 --uid 1000 vscode

Explication des Champs :

1. version : Ce champ spécifie la version du schéma que vous utilisez pour créer votre environnement d’exécution. Il est recommandé d’utiliser la version 3, qui offre plus de fonctionnalités et de flexibilité.
2. dependencies : Ce bloc définit les dépendances nécessaires pour votre environnement. Il se subdivise en trois catégories :
   • galaxy : Indique un fichier YAML (souvent nommé requirements.yml) qui spécifie les collections Ansible à installer.
   • python : Un fichier texte (requirements.txt) listant les modules Python nécessaires, similaires à ceux utilisés pour des projets Python standards.
   • system : Ce fichier (bindep.txt) liste les paquets système à installer, comme les bibliothèques C ou les outils de ligne de commande requis pour vos tâches Ansible.
3. images : Ce champ indique l’image de base à utiliser pour créer l’environnement d’exécution. Par exemple, ici, nous utilisons une image minimale de Red Hat basée sur RHEL 8, spécialement conçue pour Ansible.
4. additional_build_steps : Ce champ vous permet d’ajouter des étapes supplémentaires au processus de construction. Par exemple, ici, nous installons Git avant de construire l’image finale. Les autres valeurs possibles :
   • prepend_base : Commandes à insérer avant la construction de l’image de base.
   • append_base : Commandes à insérer après la construction de l’image de base.
   • prepend_galaxy : Commandes à insérer avant la construction de l’image de la galaxy.
   • append_galaxy : Commandes à insérer après la construction de l’image de la galaxy.
   • prepend_builder : Commandes à insérer avant la génération de l’image du générateur.
   • append_builder : Commandes à insérer après la construction de l’image du générateur.
   • prepend_final : Commandes à insérer avant la construction de l’image finale.
   • append_final : Commandes à insérer après la construction de l’image finale

Les autres options :

options:
    container_init:
        package_pip: dumb-init>=1.2.5
        entrypoint: '["dumb-init"]'
        cmd: '["csh"]'
    package_manager_path: /usr/bin/microdnf
    relax_password_permissions: false
    skip_ansible_check: true
    workdir: /myworkdir
    user: bob

additional_build_files : Cette section vous permet d’ajouter n’importe quel fichier au répertoire de contexte de génération.

Chaque élément de liste doit être un dictionnaire contenant les clés suivantes (non facultatives) :

• src : Spécifie le ou les fichiers sources à copier dans le répertoire de contexte de génération.
• dest : Spécifie le chemin au sous-répertoire qui doit contenir le(s) fichier(s) source(s)

container_init : Un dictionnaire avec des clés qui permettent la personnalisation du conteneur et des directives (et des comportements associés).

• cmd : Valeur littérale pour la directive Containerfile. La valeur par défaut est .CMD[“bash”]
• entrypoint : Valeur littérale pour la directive Containerfile.
• package_pip : Package à installer via pip pour la prise en charge des points d’entrée. Ce package sera installé dans l’image de build finale. La valeur par défaut est .dumb-init==1.2.5

package_manager_path : Chaîne avec le chemin d’accès au gestionnaire de paquets (dnf ou microdnf) à utiliser.

skip_ansible_check : Cette valeur booléenne contrôle si la vérification d’une installation d’Ansible et Ansible Runner est exécuté sur l’image finale.

relax_passwd_permissions : Cette valeur booléenne contrôle si le groupe (GID

1. est explicitement accordé.

workdir : Répertoire de travail par défaut pour les nouveaux processus démarrés sous le conteneur final image.

user : Cela définit le nom d’utilisateur ou l’UID à utiliser comme utilisateur par défaut pour l’image de conteneur finale. Valeur par défaut 1000

Le Fichier bindep.txt

Le fichier bindep.txt est utilisé pour spécifier les paquets système nécessaires à l’exécution des tâches Ansible. Par exemple, si vous avez besoin de libssl ou d’autres bibliothèques pour des connexions sécurisées, vous les listerez ici :

libssl-dev [platform:dpkg]
openssl [platform:rpm]

Ce fichier permet de garantir que tous les paquets requis sont installés indépendamment de la distribution Linux utilisée.

Le Fichier requirements.txt

Le fichier requirements.txt liste les modules Python spécifiques nécessaires à votre environnement. Voici un exemple simple :

ansible==2.16.3
psycopg2-binary==2.9.9
pyvmomi=8.0.3.0.1

Ce fichier garantit que vous utilisez les versions exactes des modules Python nécessaires à votre projet, évitant ainsi les conflits de version ou les incompatibilités.

Construction de l’Environnement

Une fois ces fichiers configurés, vous pouvez construire votre environnement d’exécution avec ansible-builder :

ansible-builder build --tag mon-environnement

Cette commande génère une image Docker contenant toutes les dépendances spécifiées. Vous pouvez ensuite utiliser cette image pour exécuter vos playbooks Ansible dans un environnement propre, isolé et reproductible.

En résumé, la création d’un environnement d’exécution Ansible à l’aide de ansible-builder vous permet de gérer de manière efficace et isolée toutes les dépendances nécessaires à vos projets Ansible, en vous assurant que votre environnement de développement reste propre et bien organisé.

Utilisation de l’Outil ansible-runner

ansible-runner est un outil puissant conçu pour faciliter l’exécution et la gestion des tâches Ansible dans des environnements d’exécution isolés. Il est particulièrement utile lorsque vous travaillez avec des conteneurs ou dans des environnements CI/CD.

Présentation de ansible-runner

ansible-runner permet de lancer des playbooks Ansible tout en isolant les processus, ce qui signifie que vos tâches s’exécutent dans un conteneur spécifique, sans interférer avec le reste du système. Cela garantit que les dépendances et configurations spécifiques à un projet n’affectent pas les autres projets ou le poste de travail.

Cet outil est également capable de capturer des journaux détaillés et de gérer des événements en temps réel, ce qui en fait un choix idéal pour les environnements de production où le suivi et le débogage sont indispensables.

Installation et Configuration

Vous pouvez installer ansible-runner via pip :

pip install ansible-runner

Une fois installé, vous pouvez utiliser ansible-runner pour exécuter des playbooks Ansible dans un environnement d’exécution spécifique, en utilisant l’image Docker que vous avez créée avec ansible-builder.

Exécution d’un Playbook avec ansible-runner

Pour exécuter un playbook, placez-vous dans le répertoire du projet contenant le playbook et lancez la commande suivante :

ansible-runner run ./ --inventory ansible_inventory --container-image mon-environnement:latest -p init-cluster.yml

Voici une explication des options :

• run ./: Indique à ansible-runner d’exécuter les fichiers présents dans le répertoire courant.
• --inventory ansible_inventory: Indique quel inventaire utiliser.
• --container-image mon-environnement: Indique l’image Docker à utiliser, qui contient toutes les dépendances et configurations nécessaires.
• -p init-cluster.yml: Spécifie le nom du playbook à exécuter. conteneur pour exécuter le playbook.

Ce qui est intéressant, c’est de voir qu’il génère un dossier artifacts contenant tout ce qui s’est passé durant l’exécution du playbook. Et c’est là qu’entre jeu un autre outil ansible qui répond au nom d’ansible-navigator.

Conclusion

ansible-runner offre une flexibilité impressionnante, avec des options de sécurisation, de gestion des artefacts, et d’exécution à distance. Pour explorer ses possibilités, je vous recommande de consulter sa documentation officielle ↗.

De plus l’utilisation des DevContainers avec les images produites par ansible-builder permet de créer un environnement de développement isolé, parfaitement aligné avec vos environnements de production. Grâce à ces DevContainers, chaque développeur travaille dans un contexte identique, réduisant les erreurs dues aux différences d’environnement.

L’intégration d’ansible-builder et d’ansible-runner dans vos pipelines CI/CD garantit que les mises à jour de dépendances n’affectent pas la stabilité de votre infrastructure. En ajoutant des outils comme Renovate et Terraform, vous pouvez créer des pipelines de tests solides qui valident automatiquement la compatibilité de vos infrastructures avec les nouvelles versions de votre code Ansible.