TP – Versionner et appliquer la configuration de deux serveurs

BTS SIO SISR 2e année – Bloc 2 – S08 – binôme : un tape, l'autre lit ; on échange les rôles à chaque partie

Note

But. Tu versionnes une configuration avec Git, tu décris l'état voulu de deux serveurs web avec Ansible, tu l'appliques, tu constates l'idempotence, puis tu provoques et détectes une dérive.

Durée : 2 h 40 (parties A à E), plus le bilan. Prérequis : cours S08 lu ; S06 ; trois VM Debian.

Note

Comment ce TP fonctionne. Avant de manipuler, tu écris ce que tu anticipes, puis tu testes et tu notes ce que tu constates. Un bilan de compétences clôt la séance.

Binôme : ____________ / ____________

Le laboratoire

Machine	Rôle	Adresse
CTRL	Contrôleur Ansible	192.168.10.10/24
web1	Serveur cible	192.168.10.11/24
web2	Serveur cible	192.168.10.12/24

Les trois VM sont sur le même réseau interne (modèle de S06) ; une carte NAT temporaire sert à installer les paquets. Le compte utilisateur existe sur chacune, avec sudo et SSH.

Partie A – Git : versionner avant d'automatiser (≈ 35 min)

Sur CTRL :

sudo apt update && sudo apt -y install git ansible
git config --global user.name "Prénom NOM"
git config --global user.email "prenom.nom@exemple.fr"
mkdir -p ~/infra/templates && cd ~/infra
git init
echo "# Configuration de l'infrastructure du TP S08" > README.md
git add README.md && git commit -m "Initialiser le dépôt"

1. Modifie le README.md (ajoute une ligne), puis observe :

git diff
git commit -am "Décrire le périmètre du dépôt"
git log --oneline

2. Provoque une erreur et reviens en arrière :

echo "ligne fautive" >> README.md
git commit -am "Ajout par erreur"
git revert --no-edit HEAD
git log --oneline
cat README.md

J'anticipe. Après le git revert, la ligne fautive a-t-elle disparu de l'historique ? du fichier ? ______________________

Éléments de réponse

Elle a disparu du fichier, mais l'historique garde les deux commits (l'ajout et son annulation) : git revert crée un nouveau commit qui annule le précédent, ce qui préserve la traçabilité. Le journal montre trois ou quatre lignes, dont « Revert "Ajout par erreur" ».

Je comprends. Pourquoi ne jamais enregistrer un mot de passe dans le dépôt, même si on le supprime ensuite ? ______________________

Éléments de réponse

Git conserve l'historique : le mot de passe reste lisible dans les anciens commits. Il faut alors le changer (il est compromis), pas seulement le supprimer du fichier.

Partie B – Inventaire et premier contact (≈ 25 min)

1. Prépare l'accès SSH par clé depuis CTRL vers les cibles :

ssh-keygen -t ed25519 -N "" -f ~/.ssh/id_ed25519
ssh-copy-id utilisateur@192.168.10.11
ssh-copy-id utilisateur@192.168.10.12

2. Crée dans ~/infra les fichiers ansible.cfg et inventaire.ini :

# ansible.cfg
[defaults]
inventory = inventaire.ini
host_key_checking = False
interpreter_python = auto_silent

# inventaire.ini
[web]
web1 ansible_host=192.168.10.11
web2 ansible_host=192.168.10.12

[web:vars]
ansible_user=utilisateur

3. Teste le contact et une commande :

ansible web -m ping
ansible web -m command -a "uptime"
ansible-inventory --list | head -20

Point de contrôle : ping répond "ping": "pong" pour web1 et web2.

Je comprends. Que représente [web:vars] ? ______________________

Éléments de réponse

Des variables communes à tout le groupe web : ici l'utilisateur de connexion SSH. Les définir une fois évite de les répéter pour chaque machine.

Partie C – Écrire et appliquer le playbook (≈ 50 min)

1. Crée templates/index.html.j2 :

<!DOCTYPE html>
<html lang="fr"><head><meta charset="utf-8"><title>{{ inventory_hostname }}</title></head>
<body><h1>Serveur {{ inventory_hostname }}</h1>
<p>Configuré par Ansible ({{ ansible_managed }}).</p></body></html>

2. Crée site.yml :

---
- name: Configurer les serveurs web
  hosts: web
  become: true
  vars:
    paquets: [apache2, curl]
  tasks:
    - name: Installer les paquets
      ansible.builtin.apt:
        name: "{{ paquets }}"
        state: present
        update_cache: true
        cache_valid_time: 3600

    - name: Déployer la page d'accueil
      ansible.builtin.template:
        src: index.html.j2
        dest: /var/www/html/index.html
        owner: root
        group: root
        mode: "0644"
      notify: Recharger Apache

    - name: Interdire la connexion SSH de root
      ansible.builtin.lineinfile:
        path: /etc/ssh/sshd_config.d/50-durcissement.conf
        regexp: "^#?PermitRootLogin"
        line: "PermitRootLogin no"
        create: true
        mode: "0644"
      notify: Recharger SSH

    - name: Apache démarré et activé
      ansible.builtin.service:
        name: apache2
        state: started
        enabled: true

  handlers:
    - name: Recharger Apache
      ansible.builtin.service:
        name: apache2
        state: reloaded

    - name: Recharger SSH
      ansible.builtin.service:
        name: ssh
        state: reloaded

3. Vérifie la syntaxe, simule, puis applique (le mot de passe sudo est demandé avec -K) :

ansible-playbook site.yml --syntax-check
ansible-playbook site.yml --check -K
ansible-playbook site.yml -K

4. Relance la même commande :

ansible-playbook site.yml -K

Exécution	`ok`	`changed`
1re application
2e application

J'anticipe. Que vaudra changed à la deuxième application ? Pourquoi ? ______________________

Éléments de réponse

changed=0 : les tâches décrivent un état (paquet présent, fichier conforme, service démarré) ; les deux machines étant déjà conformes, rien n'est modifié. C'est l'idempotence. À la première exécution, changed est supérieur à zéro (paquets installés, fichiers créés, service démarré).

5. Vérifie le résultat depuis CTRL :

curl -s http://192.168.10.11 ; curl -s http://192.168.10.12

Point de contrôle : chaque page affiche le nom de sa machine (web1, web2).

Je comprends. À quoi sert le notify ? Que se passe-t-il à la deuxième exécution ? ______________________

Éléments de réponse

notify déclenche un handler (ici recharger Apache ou SSH) uniquement si la tâche a changé quelque chose. À la deuxième exécution, rien ne change, donc aucun rechargement : on évite de perturber le service pour rien.

Partie D – Provoquer et détecter une dérive (≈ 30 min)

1. Sur web2, modifie la configuration à la main :

echo "<p>modifié à la main</p>" | sudo tee -a /var/www/html/index.html
sudo sed -i 's/PermitRootLogin no/PermitRootLogin yes/' /etc/ssh/sshd_config.d/50-durcissement.conf

2. Depuis CTRL, détecte la dérive sans rien modifier :

ansible-playbook site.yml --check --diff -K

J'anticipe. Quelles tâches Ansible va-t-il signaler comme changed, et sur quelle machine ? ______________________

Éléments de réponse

Sur web2 uniquement : la page d'accueil (le contenu a changé) et la règle SSH (PermitRootLogin n'est plus à no). Les tâches de web1 restent ok. Avec --diff, Ansible montre les lignes en désaccord.

3. Corrige en réappliquant, puis vérifie :

ansible-playbook site.yml -K
ansible-playbook site.yml -K       # doit revenir à changed=0

Je comprends. Pourquoi est-il préférable de corriger via le playbook plutôt que de rééditer le fichier à la main sur web2 ? ______________________

Éléments de réponse

La correction à la main est non tracée et non reproductible ; elle recrée de la dérive. Le playbook dans Git garde qui a changé quoi et pourquoi, et reproduit le même résultat sur toutes les machines, y compris une machine neuve.

Partie E – Enregistrer le travail (≈ 20 min)

cd ~/infra
printf "*.retry\n" > .gitignore
git add ansible.cfg inventaire.ini site.yml templates .gitignore
git commit -m "Configurer les serveurs web (Apache, page d'accueil, SSH sans root)"
git log --oneline

Ajoute ensuite une tâche de ton choix (par exemple installer vim-tiny ou créer un utilisateur audit), applique, constate changed, relance, constate changed=0, puis commit avec un message qui explique pourquoi.

Pour aller plus loin

Découpe le playbook en rôle (ansible-galaxy init web).
Chiffre une variable secrète avec Ansible Vault.
Teste ansible-lint si disponible.

Retour en entreprise (si ta situation le permet)

Observer : les configurations des serveurs sont-elles versionnées ? Sinon, comment sait-on ce qui a été modifié ?
Documenter : liste les trois configurations qui, selon toi, devraient être décrites en code.

Rendu

Compte rendu PDF, nommé RENDU-B2A2-S08-NOM.pdf, contenant : le git log --oneline, l'inventaire et le playbook, les récapitulatifs (PLAY RECAP) des deux applications, la sortie de --check --diff après la dérive, les réponses aux questions.

Bilan de la séance

Niveau : Non maîtrisé, Maîtrise partielle, Bonne maîtrise ou Excellente maîtrise, ou Non évalué.

Compétence du référentiel	Ce que j'ai fait dans cette séance	Niveau
B2.2 – Installer, tester et déployer une solution d'infrastructure réseau
B2.3 – Exploiter, dépanner et superviser une solution d'infrastructure réseau

Note

Les codes sont ceux du référentiel.

Je sais faire, sans aide :

Versionner des fichiers avec Git et revenir en arrière ;
Écrire un inventaire et un playbook simples ;
Appliquer un playbook et constater l'idempotence ;
Détecter une dérive avec --check --diff ;
Expliquer pourquoi le dépôt est la source de vérité.

Ce que je dois reprendre : ______________________

Ma question à poser à l'enseignant : ______________________