Introduction
Une fois que l'inventaire et l'accès sont opérationnels, une tâche courante consiste à déployer des fichiers de référence (baseline). Ces fichiers peuvent inclure des bannières, des extraits de configuration de service ou des marqueurs de conformité qui doivent être cohérents sur tous les hôtes, tout en conservant des valeurs spécifiques à chaque machine.
Dans ce laboratoire, vous allez créer un inventaire multi-hôtes, définir des variables de groupe, rédiger un modèle (template), exécuter un playbook et vérifier les fichiers de référence générés pour chaque hôte.
Créer le projet de déploiement de référence
Dans cette étape, vous allez créer un projet contenant l'inventaire, les modèles, les fichiers et les playbooks. Cette structure permet de séparer le contenu source réutilisable de la logique du playbook.
Créez le projet et accédez-y.
cd /home/labex/project
mkdir -p rhce-ansible/{inventory/group_vars,playbooks,files,templates,managed}
cd rhce-ansible
Créez le fichier ansible.cfg.
cat > ansible.cfg <<'EOF'
[defaults]
inventory = ./inventory/hosts
retry_files_enabled = False
interpreter_python = auto_silent
EOF
Les répertoires permettent de distinguer les rôles dans le flux de travail : files contient le contenu copié tel quel, templates contient le contenu rendu avec des variables, playbooks héberge la logique d'automatisation, et managed affichera le résultat final pour chaque hôte.
Créer l'inventaire et les variables de référence
Dans cette étape, vous allez définir deux alias d'hôtes gérés et des variables de référence partagées. Ces variables seront utilisées ultérieurement dans un modèle.
Avant d'exécuter les commandes de cette étape, retournez dans le répertoire du projet Ansible. Cela garantit la stabilité des commandes, même si LabEx exécute chaque étape séparément.
cd /home/labex/project/rhce-ansible
Créez l'inventaire.
cat > inventory/hosts <<'EOF'
[managed]
node1 ansible_connection=local
node2 ansible_connection=local
EOF
Ces deux alias permettent à un seul playbook de produire deux sorties gérées distinctes. Bien que les deux alias s'exécutent sur la même machine virtuelle, Ansible traite inventory_hostname différemment pour chaque hôte.
Créez les variables de groupe pour les hôtes gérés.
cat > inventory/group_vars/managed.yml <<'EOF'
baseline_owner: labex
baseline_environment: training
EOF
Ces variables s'appliquent à chaque hôte du groupe managed. Elles représentent des valeurs qui doivent être partagées dans la configuration de référence, tandis que le nom de l'hôte restera spécifique à chaque machine.
Créer le fichier source et le modèle
Dans cette étape, vous allez créer le contenu source. Le fichier brut sera copié sans modification. Le modèle Jinja2 utilisera des variables telles que inventory_hostname et baseline_environment pour générer une sortie spécifique à chaque hôte.
Avant d'exécuter les commandes de cette étape, retournez dans le répertoire du projet Ansible.
cd /home/labex/project/rhce-ansible
Créez un fichier de bannière partagé.
cat > files/banner.txt <<'EOF'
Managed by RHCE Ansible Prep
EOF
La bannière est un contenu source brut. Elle sera copiée exactement telle quelle, ce qui est utile pour le texte qui ne doit pas varier selon l'hôte.
Créez un modèle.
cat > templates/baseline.conf.j2 <<'EOF'
host={{ inventory_hostname }}
environment={{ baseline_environment }}
owner={{ baseline_owner }}
EOF
Le modèle contient des expressions Jinja2. Lorsqu'Ansible le traite, inventory_hostname devient node1 ou node2, tandis que les variables de référence proviennent de inventory/group_vars/managed.yml.
Rédiger le playbook de déploiement de référence
Dans cette étape, vous allez écrire un playbook qui crée un répertoire par alias d'hôte et déploie à la fois la bannière partagée et le modèle rendu. Comme le playbook est stocké dans playbooks, les chemins sources utilisent ../files et ../templates.
Avant d'exécuter les commandes de cette étape, retournez dans le répertoire du projet Ansible.
cd /home/labex/project/rhce-ansible
Créez le playbook.
cat > playbooks/deploy-baseline.yml <<'EOF'
---
- name: Deploy baseline files to managed aliases
hosts: managed
gather_facts: false
tasks:
- name: Create per-host baseline directory
ansible.builtin.file:
path: "/home/labex/project/rhce-ansible/managed/{{ inventory_hostname }}"
state: directory
mode: '0755'
- name: Copy shared banner
ansible.builtin.copy:
src: ../files/banner.txt
dest: "/home/labex/project/rhce-ansible/managed/{{ inventory_hostname }}/banner.txt"
mode: '0644'
- name: Render baseline configuration
ansible.builtin.template:
src: ../templates/baseline.conf.j2
dest: "/home/labex/project/rhce-ansible/managed/{{ inventory_hostname }}/baseline.conf"
mode: '0644'
EOF
Considérez ces trois tâches comme une séquence de déploiement complète. D'abord, le répertoire de destination est créé pour chaque alias d'hôte, puis la bannière statique est copiée, et enfin le modèle est rendu dans un fichier de configuration spécifique à l'hôte.
Effectuez une vérification de syntaxe.
ansible-playbook playbooks/deploy-baseline.yml --syntax-check
La vérification de syntaxe doit afficher une ligne playbook:. Cela confirme qu'Ansible peut analyser les chemins sources relatifs avant que le playbook ne crée des fichiers.
Exécuter et vérifier le déploiement de référence
Dans cette étape, vous allez exécuter le playbook et inspecter les fichiers générés. La configuration générée doit différer selon le nom de l'hôte tout en conservant les valeurs partagées pour l'environnement et le propriétaire.
Avant d'exécuter les commandes de cette étape, retournez dans le répertoire du projet Ansible.
cd /home/labex/project/rhce-ansible
Exécutez le playbook.
ansible-playbook playbooks/deploy-baseline.yml
La première exécution doit signaler des changements, car les répertoires et fichiers gérés n'existent pas encore. Un récapitulatif réussi avec failed=0 signifie que chaque alias d'hôte a bien reçu sa configuration de référence.
Inspectez les fichiers déployés.
find managed -maxdepth 3 -type f -print
cat managed/node1/banner.txt managed/node1/baseline.conf managed/node2/banner.txt managed/node2/baseline.conf
Les fichiers banner.txt doivent être identiques. Les fichiers baseline.conf doivent partager les mêmes valeurs pour environment et owner, mais différer sur la ligne host=.
Résumé
Vous avez déployé des fichiers de référence sur des alias d'hôtes gérés en utilisant des variables d'inventaire, un fichier source partagé et un modèle Jinja2. Cela constitue la base pour des changements d'état reproductibles sur des nœuds gérés.
