Travail pratique 2 - Transformation de scripts en infrastructure automatisée avec Ansible

Contexte

Vous êtes technicien en infrastrcucture chez GameNeuve Québec Inc., une entreprise qui loue des serveurs Minecraft à des écoles et camps de jour. En effet, votre compagnie possède plusieurs serveurs Minecraft hébergés dans des centres de données à travers le Canada, et loue ces serveurs à des écoles et camps de jour qui souhaitent offrir à leurs étudiants une expérience d'apprentissage ludique et interactive.

Comment fonctionne Minecraft? Minecraft est un jeu vidéo populaire qui permet aux joueurs de construire et d'explorer des mondes virtuels en utilisant des blocs. Afin de jouer en ligne avec d'autres joueurs, votre jeu doit être connecté à un serveur Minecraft. Ces serveurs hébergent les mondes de jeu et gèrent les interactions entre les joueurs. Il est possible de louer des serveurs Minecraft auprès de diverses compagnies, ou de configurer et héberger son propre serveur Minecraft sur un ordinateur personnel ou un serveur dédié.

Pour déployer et gérer ces serveurs Minecraft, votre compagnie utilise 3 scripts écrits en bash. Ces scripts fonctionnent bien, mais ils présentent plusieurs inconvénients :

  • Ils prennent du temps à exécuter, car ils doivent être lancés manuellement sur chaque serveur.
  • Les scripts doivent absolument être lancés dans un ordre précis, ce qui peut entraîner des erreurs si un administrateur oublie une étape.
  • Ils ne sont pas facilement réutilisables pour d'autres projets ou environnements.

Pour améliorer l'efficacité et la fiabilité de la gestion des serveurs Minecraft, votre équipe a décidé de migrer ces scripts vers une infrastructure automatisée en utilisant Ansible. Votre tâche est de transformer les scripts bash existants en rôles Ansible réutilisables et modulaires.

Remise

  • Ce laboratoire compte pour 25% de la note finale du cours et est à réaliser individuellement.
  • La remise de ce laboratoire se fait par la boîte de remise Léa prévue à cet effet. Des instructions de remise sont disponibles à la fin de ce document.
  • La date limite de remise est :
    • Le 10 décembre 2025 à 23h59 pour le groupe 2 (groupe du mercredi matin)
    • Le 15 décembre 2025 à 23h59 pour le groupe 1 (groupe du lundi matin)

Une pénalité de 10% par jour de retard s'applique. Après 5 jours, cette pénalité est de 100%.

Plagiat et tricherie

Ce travail est à réaliser individuellement.

Ce qui est autorisé:

  • L'entraide entre étudiants sous forme de conseils, d'explications de concepts, de résolution de problèmes techniques.
  • La consultation de ressources en ligne pour comprendre les concepts et les commandes nécessaires à la réalisation des tâches.

Ce qui n'est pas autorisé:

  • Copier le travail d'un autre étudiant, que ce soit partiellement ou en totalité.
  • Partager votre travail avec un autre étudiant.
  • Utiliser des scripts, playbook, ou tout autre code trouvés en ligne sans les comprendre. Si vous remettez du code que vous n'avez pas écrit vous-même, vous devez être capable de l'expliquer en détails et de justifier chaque ligne de code. Si le professeur a des doutes sur votre compétence à comprendre le code soumis, il se réserve le droit de vous interroger oralement sur le contenu de votre travail.

Fichiers fournis

Les fichiers nécessaires pour ce laboratoire peuvent être téléchargés ici : Lien GitHub pour scripts Bash

  1. install_base.sh : Installe les dépendances nécessaires pour faire fonctionner un serveur Minecraft.
  2. deploy_minecraft.sh : Télécharge et configure un serveur Minecraft.
  3. setup_backup.sh : Configure un système de sauvegarde pour le serveur Minecraft.

Attention! Ne modifiez pas ces scripts originaux. Vous devez créer vos rôles Ansible en vous basant sur ces scripts, mais sans les modifier. Ils ne seront pas corrigés.

Préparation de l'environnement

Pour ce travail, vous devez disposez de 2 machines virtuelles (VM) :

  • 1 VM contrôleur Ansible : C'est la machine à partir de laquelle vous allez exécuter vos playbooks Ansible. Elle doit avoir Ansible installé.
  • 1 VM cible : C'est la machine sur laquelle Ansible va déployer et configurer le serveur Minecraft. Elle doit être une installation propre d'Ubuntu 22.04 LTS.

Vous pouvez utiliser les mêmes fichiers .ova que celles utilisées en classe pour Ansible. Si vous avez déjà une machine de contrôle Ansible, vous pouvez la réutiliser. Cependant, assurez-vous que votre VM cible est une installation propre d'Ubuntu 22.04 LTS, sans aucune configuration préalable (il est recommandé de réimporter une nouvelle VM pour ce TP à partir du même .ova).

Voici les liens pour télécharger les .ova:

Préparer le terrain

Avant de commencer à créer vos rôles Ansible, vous devez d'abord vous assurer que les scripts bash fournis fonctionnent correctement sur votre machine cible. Cela vous permettra de comprendre le fonctionnement des scripts et de vérifier que vos rôles Ansible produisent les mêmes résultats.

  1. Démarrez votre machine virtuelle cible, ainsi que votre machine contrôleur Ansible. Obtenez les adresses IP de vos machines avec la commande ip a. Les machines virtuelles ne sont qu'en ligne de commande, vous pouvez utiliser ssh pour vous y connecter depuis votre machine hôte.
  2. Testez la connection SSH depuis votre machine hôte vers chacune de vos machines virtuelles pour vous assurer que tout fonctionne correctement. Par exemple:
    ssh ansible@machine_ip

Le nom d'utilisateur est ansible et le mot de passe est Ansible123!.

Maintenant, il est temps de tester les scripts bash fournis. Vous pouvez suivre les instructions au lien suivant: Instructions pour exécuter les scripts bash.

Architecture imposée

Votre tâche est de créer trois rôles Ansible distincts, chacun correspondant à un des scripts bash fournis. Chaque rôle doit être autonome et réutilisable, ce qui signifie qu'il doit inclure toutes les tâches, variables et fichiers nécessaires pour accomplir sa fonction spécifique. Voici la structure que vous devez suivre pour votre projet Ansible:

TP2_[numero_etudiant]/
├── README.md                           # Documentation principale
├── inventory.ini                       # Inventaire avec votre serveur
├── ansible.cfg                          # Configuration Ansible
├── deploy.yml                          # Playbook principal
├── group_vars/
    ├── gameservers.yml                  # Variables spécifiques aux serveurs de jeux
│   └── all.yml                         # Variables globales
└── roles/
    ├── common/                         # Correspond à install_base.sh
    │   └── [vos fichiers ici pour le rôle common]
    ├── minecraft/                      # Correspond à deploy_minecraft.sh
    │   └── [vos fichiers ici pour le rôle minecraft]
    └── backup/                         # Correspond à setup_backup.sh
        └── [vos fichiers ici pour le rôle de backup]

Attention:

  • Vous devez absolument respecter cette structure de répertoires.
  • Assurez-vous de bien renommer votre projet avec votre numéro d'étudiant (ex: TP2_12345678/ si votre numéro d'étudiant est 12345678).
  • La structure interne de chaque rôle doit suivre les bonnes pratiques vues en cours (des points seront attribués pour cela). Il est inutile de créer des dossiers ou fichiers qui ne sont pas nécessaires pour le rôle (des points seront retirés pour cela).

Restrictions

  • Il est interdit d'utiliser les modules command ou shell dans vos rôles, à l'exception de la tâche qui affiche la version de Java installée. Vous devez utiliser les modules Ansible indiqués pour chaque tâche, et trouver les propriétés appropriées pour chaque module.
  • Il est possible d'ajouter des tâches supplémentaires à celles décrites ici si vous jugez cela nécessaire pour le bon fonctionnement de vos rôles. Cependant, assurez-vous que le numéro des tâches principales demandées reste inchangé et dans le bon ordre.
  • Il est également possible de définir des variables supplémentaires si nécessaire.

Explications des rôles

Rôle common (20 points)

Le rôle common est responsable de l'installation des dépendances nécessaires pour faire fonctionner un serveur Minecraft. Cela inclut l'installation de Java, wget, et préparer la structure de répertoires. Il doit remplacer le script install_base.sh.

Ouvrez le script install_base.sh et lisez les explcations ci-dessous pour comprendre ce que ce rôle doit accomplir:

  1. Lignes 8-9: Met à jour la liste des paquets.
  2. Lignes 11-21: Installation de 4 paquets: openjdk-17-jre-headless, screen, wget, et curl.
  3. Lignes 23-26: Création du répertoire principal /opt/gameservers
  4. Lignes 28-31: Création du répertoire de backups /opt/backups/minecraft
  5. Lignes 33-38: Configuration des limites système en ajoutant des lignes au fichier /etc/security/limits.d/minecraft.conf.
  6. Lignes 40-44: Affichage de la version de Java installée.

Requis pour ce rôles:

  • Création de 6 tâches distinctes pour chaque étape décrite ci-dessus. Le nom de la tâche doit commencer par "Tâche X: " où X est le numéro de l'étape, suivi d'une description (ex: "Tâche 1: Met à jour la liste des paquets"). Les tâches doivent utiliser les modules suivants:
    • Tâche 1: apt (avec l'option update_cache: yes)
    • Tâche 2: apt (avec une boucle pour installer les 4 paquets)
    • Tâche 3: file (pour créer le répertoire principal)
    • Tâche 4: file (pour créer le répertoire de backups)
    • Tâche 5: copy (pour copier les lignes au fichier de limites système)
    • Tâche 6: command (pour afficher la version de Java installée). Cette tâche devra être suivie d'une option register pour capturer la sortie, et d'une tâche supplémentaire utilisant le module debug pour afficher cette sortie.
  • Utilisation d'une boucle pour installer les paquets dans la tâche 2 (au lieu de 4 tâches séparées).
  • Attention d'utiliser les bonnes permissions pour les dossiers créés (voir le script bash pour référence).
  • La tâche d'affichage de la version de Java ne doit pas être considérée comme "changed".
  • Les valeurs suivantes doivent être stockées dans des variables définies à différent niveaux:
    • common_packages : La liste des paquets à installer dans le fichier defaults/main.yml du rôle (mettre les 4 paquets par défaut).
    • gameservers_base_dir: Le répertoire principal dans le fichier defaults/main.yml du rôle (/opt/gameservers) et surchargé dans group_vars/all.yml (/opt/gameservers).
    • backups_base_dir: Le répertoire de backups dans le fichier defaults/main.yml (/opt/backups/minecraft) et surchargé dans group_vars/all.yml (/opt/backups/minecraft).
  • En plus des tâches et autres fichiers nécessaires pour le rôle, vous devez également inclure un fichier README.md dans le répertoire du rôle common/ qui explique:
    • Le but du rôle
    • Une explication des tâches du rôle.
    • La liste des variables utilisées dans le rôle avec une brève description de chacune, leur valeur par défaut et leur location (dans quel fichier ils se trouvent).
    • Une explication des dépendances avec d'autres rôles (si applicable).
    • Un exemple d'utilisation du rôle dans un playbook, incluant la surcharge des variables nécessaires.
    • Toute autre information pertinente pour comprendre et utiliser le rôle

Critères d'évaluation

Critère Points Détails
Structure correcte 3 Répertoires nécessaires et README.md présent (aucun autre répertoire ou fichier superflu)
6 tâches présentes dans l'ordre 5 Noms commençant par "Tâche X :", tâches répondent aux exigences
Boucle utilisée pour les paquets 3
Variables définies dans defaults 3
La tâche d'affichage n'est pas considérée comme "changed" 2
Permissions correctes 2
README.md complet 2 Description, variables, utilisation

Rôle minecraft (40 points)

Le rôle minecraft est responsable du déploiement et de la configuration du serveur Minecraft. Il doit télécharger le serveur Minecraft, configurer les paramètres nécessaires, et s'assurer que le serveur est prêt à être lancé. Il doit remplacer le script deploy_minecraft.sh.

Important de comprendre: Ce rôle sera exécuté trois fois, une fois pour chaque serveur Minecraft à déployer (survival, creative, adventure). Le nom du serveur et les paramètres de configuration varieront à chaque exécution. Vous devez donc vous assurer que votre rôle est suffisamment flexible pour accepter ces paramètres via des variables.

Ouvrez le script deploy_minecraft.sh et lisez les explcations ci-dessous pour comprendre ce que ce rôle doit accomplir:

  1. Lignes 34-35: Création d'un utilisateur système
  2. Lignes 37-40: Création des répertoires nécessaires pour le serveur Minecraft
  3. Lignes 43-46: Téléchargement du fichier JAR du serveur Minecraft
  4. Lignes 48-50: Création du fichier eula.txt pour accepter l'EULA de Minecraft
  5. Lignes 52-66: Création du fichier server.properties avec les configurations du serveur (utiliser un template Jinja2)
  6. Lignes 68-84: Création d'un service systemd pour gérer le serveur Minecraft (utiliser un template Jinja2)
  7. Lignes 86-89: Activation et démarrage du service systemd

Requis pour ce rôle:

  • Création de 7 tâches distinctes pour chaque étape décrite ci-dessus. Le nom de la tâche doit commencer par "Tâche X: " où X est le numéro de l'étape, suivi d'une description (ex: "Tâche 1: Création d'un utilisateur système"). Les tâches doivent utiliser les modules suivants:
    • Tâche 1: user
    • Tâche 2: file (avec une boucle pour créer les deux répertoires nécessaires)
    • Tâche 3: get_url
    • Tâche 4: copy
    • Tâche 5: template (pour créer le fichier server.properties)
    • Tâche 6: template (pour créer le service systemd)
    • Tâche 7: service
  • Les valeurs suivantes doivent être stockées dans des variables définies à différent niveaux:
    • minecraft_server_name : Le nom du serveur (SERVER_NAME dans le script Bash) dans le fichier defaults/main.yml du rôle ("default_server" par défaut).
    • gameservers_base_dir: Le répertoire principal des serveurs de jeux dans le fichier group_vars/all.yml (déjà fait pour le rôle common).
    • minecraft_port: Le port d'écoute (25565 par défaut) du serveur Minecraft dans le fichier defaults/main.yml du rôle.
    • minecraft_memory_min et minecraft_memory_max: La mémoire minimum (1G) et maximum allouée (2G) au serveur dans le fichier defaults/main.yml du rôle.
    • minecraft_max_players: Le nombre maximum de joueurs (20)dans le fichier defaults/main.yml du rôle.
    • minecraft_gamemode: Le mode de jeu (survival, creative, adventure, spectator) dans le fichier defaults/main.yml du rôle (survival par defaut)
    • minecraft_jar_url: L'URL de téléchargement du JAR Minecraft dans le fichier defaults/main.yml du rôle.
    • Ainsi que toutes les autres variables nécessaires pour configurer les deux templates (fichier server.properties et service systemd) avec les valeurs par défaut suivantes:
      • minecraft_difficulty: "normal"
      • minecraft_view_distance: 10
      • minecraft_pvp: "true"
      • minecraft_enable_command_block: "false"
      • minecraft_spawn_protection: 16
      • minecraft_motd: "Serveur Minecraft Ansible"
      • minecraft_online_mode: "true"
  • Utilisation d'une boucle pour la tâche 2
  • Utilisation d'une condition pour la tâche 3 (téléchargement du JAR) afin de ne pas retélécharger le fichier s'il est déjà présent (vous pouvez créer une tâche supplémentaire avant la tâche 3 pour vérifier cela avec le module stat et register).
  • Utilisation de templates Jinja2 pour les fichiers server.properties et le service systemd (fournis, voir ci-dessous).
  • Un handler doit être créé. Il doit utiliser le module systemd avec l'option daemon_reload: true qui est appelé par la tâche 6. Attention: Ce handler doit être appelé avant de démarrer le service (tâche 7). Il faudra donc forcer l'ordre d'exécution des handlers si nécessaire.
  • En plus des tâches et autres fichiers nécessaires pour le rôle, vous devez également inclure un fichier README.md dans le répertoire du rôle minecraft/ qui explique:
    • Le but du rôle
    • Une explication des tâches du rôle.
    • La liste des variables utilisées dans le rôle avec une brève description de chacune, leur valeur par défaut et leur location (dans quel fichier ils se trouvent).
    • Une explication des templates utilisés et des variables qu'ils contiennent.
    • Une explication des handlers utilisés.
    • Une explication des dépendances avec d'autres rôles (si applicable).
    • Un exemple d'utilisation du rôle dans un playbook, incluant la surcharge des variables nécessaires.
    • Toute autre information pertinente pour comprendre et utiliser le rôle

Fichiers templates fournis

Fichier : roles/minecraft/templates/server.properties.j2

# Configuration du serveur Minecraft
# Générée automatiquement par Ansible pour {{ minecraft_server_name }}
# Date de génération : {{ ansible_date_time.iso8601 }}

server-port={{ minecraft_port }}
max-players={{ minecraft_max_players }}
gamemode={{ minecraft_gamemode }}
difficulty={{ minecraft_difficulty }}
view-distance={{ minecraft_view_distance }}
pvp={{ minecraft_pvp }}
enable-command-block={{ minecraft_enable_command_block }}
spawn-protection={{ minecraft_spawn_protection }}
motd={{ minecraft_motd }}
online-mode={{ minecraft_online_mode }}

Fichier : roles/minecraft/templates/minecraft.service.j2

[Unit]
Description=Minecraft Server - {{ minecraft_server_name }}
After=network.target

[Service]
Type=simple
User={{ minecraft_server_name }}
WorkingDirectory={{ gameservers_base_dir }}/{{ minecraft_server_name }}/server
ExecStart=/usr/bin/java -Xms{{ minecraft_memory_min }} -Xmx{{ minecraft_memory_max }} -jar server.jar nogui
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

Critères d'évaluation - Partie 2 (40 pts)

Critère Points Détails
Structure correcte 4 tasks/, handlers/, templates/, defaults/, README.md
7 tâches dans l'ordre 8 Numérotation "Tâche X :" respectée, tâches répond aux exigences
stat + when utilisés correctement 4 Tâche 3b avant tâche 3, condition when appropriée
Boucle pour les répertoires 3 loop avec 2 chemins
Template server.properties 5 Toutes les variables présentes
Template minecraft.service 5 Service systemd fonctionnel
handler défini et appelé au bon moment 4
notify utilisé correctement 3 Sur tâches 5 et 6
Variables 3 Toutes les variables listées présentes aux bons endroits
README.md complet 1 Toutes les sections présentes

Rôle backup (25 points)

Le rôle backup est responsable de la configuration du système de sauvegarde pour le serveur Minecraft. Il doit configurer une tâche cron pour effectuer des sauvegardes régulières du serveur Minecraft. Il doit remplacer le script setup_backup.sh. Ouvrez le script setup_backup.sh et lisez les explcations ci-dessous pour comprendre ce que ce rôle doit accomplir:

  1. Lignes 27-67: Création d'un script de sauvegarde
  2. Lignes 74-75: Permissions d'exécution pour le script de sauvegarde
  3. Lignes 77-95: Création d'une tâche cron pour exécuter le script de sauvegarde

Requis pour ce rôle:

  • Création de 2 tâches distinctes pour les étapes 1 et 3 ci-dessus. Le nom de la tâche doit commencer par "Tâche X: " où X est le numéro de l'étape, suivi d'une description (ex: "Tâche 1: Création d'un script de sauvegarde"). Les tâches doivent utiliser les modules suivants:
    • Tâche 1: template (pour créer le script de sauvegarde)
    • Tâche 2: cron (pour créer la tâche cron)
  • Utilisation d'un template Jinja2 pour le script de sauvegarde (voir ci-dessous).
  • Les valeurs suivantes doivent être stockées dans des variables définies à différents niveaux:
    • minecraft_server_name: Le nom du serveur Minecraft dans le fichier defaults/main.yml du rôle.
    • backup_enabled: Un booléen pour activer ou désactiver les sauvegardes dans le fichier defaults/main.yml (true par défaut) et surchargé dans le fichier group_vars/all.yml (true également).
    • backup_hour: L'heure de la journée (0-23) pour exécuter la sauvegarde dans le fichier defaults/main.yml (2 par défaut).
    • backup_retention_days: Le nombre de jours à conserver les sauvegardes dans le fichier defaults/main.yml (7 par défaut).
  • Utilisation d'une condition pour la tâche 2 (cron) afin de ne créer la tâche cron que si les sauvegardes sont activées (variable booléenne définie dans defaults/main.yml).
  • En plus des tâches et autres fichiers nécessaires pour le rôle, vous devez également inclure un fichier README.md dans le répertoire du rôle minecraft/ qui explique:
    • Le but du rôle
    • Une explication des tâches du rôle.
    • La liste des variables utilisées dans le rôle avec une brève description de chacune, leur valeur par défaut et leur location (dans quel fichier ils se trouvent).
    • Une explication des templates utilisés et des variables qu'ils contiennent.
    • Une explication des dépendances avec d'autres rôles (si applicable).
    • Un exemple d'utilisation du rôle dans un playbook, incluant la surcharge des variables nécessaires.
    • Toute autre information pertinente pour comprendre et utiliser le rôle

Fichier : roles/backup/templates/backup-script.sh.j2

#!/bin/bash
# Script de backup automatique pour {{ minecraft_server_name }}
# Généré par Ansible le {{ ansible_date_time.iso8601 }}

SERVER_NAME="{{ minecraft_server_name }}"
SERVER_DIR="{{ gameservers_base_dir }}/${SERVER_NAME}/server"
BACKUP_DIR="{{ backups_base_dir }}/${SERVER_NAME}"
RETENTION_DAYS={{ backup_retention_days }}
DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_FILE="${BACKUP_DIR}/backup_${DATE}.tar.gz"

# Création du répertoire de backup
mkdir -p "${BACKUP_DIR}"

# Vérification que le serveur existe
if [ ! -d "$SERVER_DIR" ]; then
    echo "ERREUR: Le serveur $SERVER_NAME n'existe pas dans $SERVER_DIR"
    exit 1
fi

echo "Début du backup de $SERVER_NAME à $(date)"

# Création de l'archive
cd "$SERVER_DIR"
tar -czf "${BACKUP_FILE}" world server.properties 2>/dev/null

# Vérification que le backup a réussi
if [ $? -eq 0 ]; then
    echo "Backup créé: ${BACKUP_FILE}"
    
    # Nettoyage des anciens backups
    echo "Nettoyage des backups de plus de ${RETENTION_DAYS} jours..."
    find "${BACKUP_DIR}" -name "backup_*.tar.gz" -type f -mtime +${RETENTION_DAYS} -delete
    
    echo "Backup terminé avec succès à $(date)"
else
    echo "ERREUR: Le backup a échoué"
    exit 1
fi

Critères d'évaluation - Partie 3 (25 pts)

Critère Points Détails
Structure correcte 3 tasks/, templates/, defaults/, README.md
2 tâches présentes 5 Tâche 1 et 2 avec bons noms
Template backup script 8 Script bash fonctionnel avec toutes les variables
Module cron correctement configuré 5 Tous les paramètres (minute, hour, job, user)
condition when utilisée 2 Condition sur tâche cron
Variables dans defaults 1 3 variables définies
README.md complet 1 Toutes les sections

Projet principal (15 points)

Dans le projet principal, vous devez créer un fichier d'inventaire inventory.ini, des fichiers de variables globales group_vars/all.yml et group_vars/gameservers.yml, un fichier de configuration Ansible ansible.cfg, et le playbook principal deploy.yml qui utilise les trois rôles que vous avez créés.

Fichier d'inventaire inventory.ini

Votre fichier d'inventaire doit définir une seule machine cible (votre VM Ubuntu 22.04 LTS) sous un groupe nommé gameservers. Utilisez l'adresse IP de votre VM cible, ainsi que les variables nécessaires pour la connexion SSH.

Fichier de variables globales group_vars/all.yml

Rappel: votre fichier group_vars/all.yml doit contenir les variables suivantes:

  • répertoire principal pour le serveurs de jeux
  • répertoire principal pour les backups
  • activer les backups (true/false)

Fichier de variables spécifiques aux serveurs de jeux group_vars/gameservers.yml

Votre fichier group_vars/gameservers.yml doit contenir les variables spécifiques pour chaque serveur Minecraft que vous allez déployer. Ce fichier vous est fourni (et doit être utilisé tel quel, en remplaçant uniquement VOTRE_CODE_ETUDIANT et VOTRE_NOM par vos informations réelles):

---
# Variables spécifiques aux hôtes du groupe [gameservers]

minecraft_servers:
  - name: "survival-VOTRE_CODE_ETUDIANT"
    port: 25565
    memory_min: "1G"
    memory_max: "2G"
    max_players: 20
    gamemode: "survival"
    difficulty: "hard"
    motd: "Serveur Survival - VOTRE_NOM"
  - name: "creative-VOTRE_CODE_ETUDIANT"
    port: 25566
    memory_min: "512M"
    memory_max: "1G"
    max_players: 10
    gamemode: "creative"
    difficulty: "peaceful"
    motd: "Serveur Creative - VOTRE_NOM"
  - name: "minigames-VOTRE_CODE_ETUDIANT"
    port: 25567
    memory_min: "2G"
    memory_max: "3G"
    max_players: 30
    gamemode: "adventure"
    difficulty: "normal"
    motd: "Serveur Minigames - VOTRE_NOM"

Fichier de configuration Ansible ansible.cfg

Votre fichier ansible.cfg doit contenir les configurations nécessaires pour exécuter vos playbooks correctement.

Playbook principal deploy.yml

Vous devez créer un playbook principal nommé deploy.yml à la racine de votre projet qui utilise les trois rôles que vous avez créés (common, minecraft, backup). Le playbook doit cibler la machine virtuelle cible et inclure les rôles dans l'ordre suivant:

  1. common
  2. minecraft
  3. backup

Le playbook principal doit:

  • Inclure 3 plays distincts, un pour chaque rôle.
  • Le premier play doit inclure le rôle common et doit s'exécuter avec des privilèges élevés.
  • Le deuxième play doit inclure le rôle minecraft, et doit s'effectuer trois fois, une pour chaque serveur Minecraft défini dans l'inventaire. Il doit également utiliser les variables spécifiques à chaque serveur Minecraft (toutes les variables listées dans l'inventaire pour chaque serveur Minecraft doivent être utilisées ici).
  • Le troisième play doit inclure le rôle backup, doit s'exécuter trois fois, une pour chaque serveur Minecraft défini dans l'inventaire. Il ne doit s'exécuter que si les backups sont activés dans le fichier group_vars/all.yml.

Note sur l'utilisation des boucles: Pour les plays minecraft et backup, vous devez utiliser une boucle pour itérer sur la liste des serveurs Minecraft définie dans le fichier group_vars/gameservers.yml. Cela permettra de déployer et configurer chaque serveur Minecraft en utilisant les variables spécifiques à chaque serveur. Vous devrez utiliser les directives loop pour indiquer sur quelle liste itérer, et loop_control pour définir les variables temporaires utilisées dans chaque itération.

Critères d'évaluation - Partie 4 (15 pts)

Critère Points Détails
inventory.ini correct 1
group_vars/gameservers.yml présent 2 Variables spécifiques aux serveurs présentes
group_vars/all.yml présent 1 Variables globales définies
deploy.yml avec 3 plays 5 Structure en 3 étapes qui répond aux exigences
boucles fonctionnelles 5 2 boucles fonctionnelles (minecraft + backup)
condition sur le backup 1

Tests

Pour tester votre infrastructure Ansible, vous devez exécuter le playbook principal deploy.yml depuis votre machine de contrôle Ansible. Assurez-vous que votre playbook s'exécute sans erreurs et que les serveurs Minecraft sont correctement déployés et configurés sur votre machine cible.

Vérification des services minecraft

  • Vérifiez que les serveurs Minecraft sont en cours d'exécution avec la commande:
systemctl status minecraft-survival-[VOTRE_CODE]
systemctl status minecraft-creative-[VOTRE_CODE]
systemctl status minecraft-minigames-[VOTRE_CODE]

La sortie doit indiquer que les services sont actifs (running).

  • Vérifiez que les ports d'écoute sont corrects avec la commande:
ss -tuln | grep 2556

La sortie doit montrer que les ports 25565, 25566, et 25567 sont en écoute.

  • Vérifiez les crons jobs avec la commande:
sudo crontab -l

Vérification de la structure des répertoires

  • Vérifiez que les répertoires des serveurs Minecraft ont été créés correctement:
ls -l /opt/gameservers/

Vous devriez voir les répertoires survival-[VOTRE_CODE], creative-[VOTRE_CODE], et minigames-[VOTRE_CODE] avec les permissions appropriées (le propriétaire et le groupe doivent être l'utilisateur correspondant à chaque serveur).

Vérification des backups

  • Exécution des backups:
sudo /usr/local/bin/backup-survival-[VOTRE_CODE].sh
sudo /usr/local/bin/backup-creative-[VOTRE_CODE].sh
sudo /usr/local/bin/backup-minigames-[VOTRE_CODE].sh
  • Vérifiez que le répertoire de backups a été créé correctement:
sudo ls -l /opt/backups/minecraft/

Vous devriez voir les répertoires survival-[VOTRE_CODE], creative-[VOTRE_CODE], et minigames-[VOTRE_CODE].

Instructions de remise

Pour remettre votre travail, vous devez compresser le répertoire TP2_[numero_etudiant]/ en un fichier ZIP ou TAR.GZ et le soumettre via le formulaire de remise indiqué au début de ce document.

  1. Assurez-vous que votre archive contient tous les fichiers et répertoires nécessaires, et que la structure du projet est respectée.
  2. Créez une archive de votre projet avec les commandes suivantes (remplacez [numero_etudiant] par votre numéro d'étudiant):
cd ~ #ou le repertoire parent de votre projet
tar -czvf TP2_[numero_etudiant].tar.gz TP2_[numero_etudiant]/
  1. Vérifiez que l'archive a été créée correctement et qu'elle contient tous les fichiers nécessaires.
tar -tf TP2_[numero_etudiant].tar.gz
  1. Transférez l'archive compressée (TP2_VOTRE_NUMERO_ETUDIANT.tar.gz) de votre VM contrôleur vers votre machine hôte (votre ordinateur principal). Sur un terminal de votre machine hôte, utilisez la commande scp suivante (remplacez controller_machine_ip, et /path/to/destination par vos informations réelles):
scp ansible@controller_machine_ip:~/TP2_[numero_etudiant].tar.gz /path/to/destination/
  1. Soumettez l'archive via la boîte de remise Léa prévue à cet effet avant la date limite indiquée.