Portfolio — BTS SIO SISR

Blog

  • Un serveur de jeu ARK autonome : VPN maillé, automatisation et sauvegardes

    Compétences du Bloc B1 : B1.1 — Gérer le patrimoine informatique · B1.2 — Répondre aux incidents et aux demandes d’assistance et d’évolution · B1.5 — Mettre à disposition des utilisateurs un service informatique

    Le contexte et l’objectif

    Dans un cadre personnel, j’ai conçu et déployé pour un groupe d’amis une infrastructure complète autour d’un serveur de jeu ARK: Survival Ascended, hébergé sur ma machine. L’objectif dépassait le simple « faire tourner un serveur » : je voulais un service entièrement autonome, que n’importe quel membre du groupe puisse démarrer ou arrêter sans mon intervention et sans compétences techniques, avec la garantie que la sauvegarde du monde est toujours la plus récente, qu’aucune double instance ne tourne à l’insu du groupe, et que le serveur est toujours à jour.

    Le besoin technique

    Les exigences que je me suis fixées ressemblent à un vrai cahier des charges d’exploitation : accès réservé aux seuls membres du groupe, sans exposer ma machine sur Internet ; démarrage et arrêt « presse-bouton » par n’importe quel membre ; détection préalable d’une instance déjà en cours, localement ou chez un autre membre ; synchronisation systématique de la sauvegarde avant lancement et après arrêt ; et configuration identique quel que soit l’hébergeur du moment.

    La solution mise en œuvre

    L’architecture réseau repose sur Tailscale, un VPN maillé fondé sur WireGuard : chaque membre rejoint un réseau privé chiffré, et tous les appareils communiquent comme en réseau local. J’aurais pu ouvrir les ports du jeu sur ma box, mais ce choix aurait exposé mon adresse publique en permanence ; le VPN restreint l’accès aux seuls membres du réseau privé — plus sûr, et plus simple à maintenir.

    L’automatisation a été construite par preuves de concept successives : chaque brique (lancement du serveur avec tous ses paramètres, détection d’une instance en cours, synchronisation de la sauvegarde) a d’abord été développée et testée isolément, puis les briques validées ont été assemblées en scripts complets. La détection d’instance illustre bien la démarche : le script vérifie d’abord localement qu’aucun serveur ne tourne, puis interroge chaque machine du réseau privé sur le port du jeu avec un délai court, pour s’assurer qu’aucun autre membre n’héberge déjà la partie. La sauvegarde du monde et les fichiers de configuration sont centralisés sur un espace cloud partagé et synchronisés automatiquement : n’importe quel membre peut héberger, la partie reprend toujours là où elle s’était arrêtée. À l’arrêt, une commande d’administration distante ordonne d’abord la sauvegarde propre du monde, puis le serveur est arrêté et la sauvegarde renvoyée vers le cloud.

    Le service a ensuite évolué en réponse à un problème d’exploitation récurrent : à chaque mise à jour du jeu, un serveur resté sur l’ancienne version refuse les connexions des joueurs à jour, et il fallait intervenir manuellement. J’ai donc fait évoluer le script de démarrage : il vérifie désormais, avant chaque lancement, si une mise à jour du serveur est disponible et l’applique automatiquement le cas échéant — puis enchaîne les contrôles habituels (détection d’instances, synchronisation de la sauvegarde) avant de démarrer. Cette évolution a fait disparaître la première cause de demandes d’assistance du groupe.

    La dimension sécurité

    Trois choix structurent la sécurité du service : aucune ouverture de port sur Internet, tout l’accès passant par le réseau privé chiffré ; une administration distante du serveur protégée par mot de passe et limitée au réseau local de l’hôte ; et une stratégie de sauvegarde systématique, synchronisée avant et après chaque session, qui protège les données du groupe contre la panne ou la fausse manipulation d’un hôte.

    Ma plus-value personnelle

    Ce projet est probablement celui qui ressemble le plus à de l’exploitation réelle : des utilisateurs non techniciens, un service qui doit fonctionner sans moi, des incidents (versions, doubles instances, sauvegardes divergentes) qu’il a fallu transformer en évolutions du service. J’y ai appris à concevoir pour les autres : les scripts sont « clé en main », prévoient les cas d’erreur et affichent des messages compréhensibles. La démarche par preuves de concept, la synchronisation cloud en ligne de commande, l’administration à distance et la supervision multi-machines sont autant de réflexes que j’ai directement réinvestis pendant mon stage.

    La procédure technique détaillée, avec l’ensemble des scripts commentés, est disponible en téléchargement au format PDF ci-dessous.

  • Héberger ce blog : WordPress conteneurisé avec Docker sur mon VPS

    Compétences du Bloc B1 : B1.3 — Développer la présence en ligne de l’organisation · B1.1 — Gérer le patrimoine informatique

    Le contexte et l’objectif

    Le site que vous êtes en train de lire est lui-même un projet du portfolio. Pour l’épreuve E5, j’avais besoin d’un espace de publication régulière : des articles présentant mes réalisations, classés par compétences du Bloc B1, enrichis au fil de la formation, avec des documents téléchargeables (les procédures techniques en PDF). Ce besoin éditorial — publication fréquente, taxonomie, gestion de médias, back-office — justifie cette fois pleinement un CMS, là où mon projet de site vitrine avait, pour un besoin inverse, justifié un site statique. J’ai choisi WordPress, le CMS le plus répandu, et je l’ai déployé sous forme conteneurisée avec Docker sur mon VPS personnel (Debian 12), qui héberge déjà d’autres services derrière Apache.

    Le besoin technique

    Le cahier des charges que je me suis fixé : une pile LAMP complète (Apache, MySQL, PHP) portant WordPress ; une cohabitation propre avec les services déjà en production sur le VPS, sans conflit de ports ni dépendances entremêlées ; des données strictement séparées du moteur applicatif, pour pouvoir mettre à jour ou reconstruire les conteneurs sans jamais toucher au contenu ; une exposition publique uniquement en HTTPS ; et une stratégie de sauvegarde complète et testée — un blog de portfolio qui perdrait ses articles la veille de l’épreuve serait un comble.

    La solution retenue : la conteneurisation

    Docker répond exactement à la problématique de cohabitation. Plutôt que d’installer PHP et MySQL directement sur le système — au risque d’entrer en conflit avec l’existant et de compliquer chaque mise à jour — la pile WordPress vit dans deux conteneurs isolés, décrits dans un unique fichier de composition : un conteneur applicatif (Apache + PHP + WordPress, l’image officielle) et un conteneur de base de données MySQL. Les données persistantes (base de données d’un côté, fichiers du site de l’autre) résident dans des volumes Docker dédiés, indépendants du cycle de vie des conteneurs : détruire et recréer la pile ne touche pas au contenu.

    L’intégration au VPS suit une architecture de production classique : le conteneur WordPress n’écoute que sur l’interface locale de la machine, jamais directement sur Internet ; c’est l’Apache déjà en place sur le VPS qui joue le rôle de mandataire inverse (reverse proxy) et publie le blog sur son sous-domaine, avec un certificat TLS Let’s Encrypt renouvelé automatiquement. La base de données, elle, n’est joignable que depuis le réseau interne des conteneurs — elle n’expose aucun port, ni sur Internet, ni même sur le VPS.

    Enfin, conformément à l’exigence de sauvegarde, un script automatisé exporte chaque nuit les trois composants vitaux — la base de données (export logique cohérent), les fichiers du site (thèmes, extensions, médias) et la configuration de la pile — avec une rotation des archives, et la procédure de restauration associée a été rédigée et testée : une sauvegarde dont on n’a jamais vérifié la restauration n’offre aucune garantie.

    La dimension sécurité

    La sécurité du déploiement repose sur la réduction de la surface exposée : un seul point d’entrée public (le reverse proxy en HTTPS), un conteneur applicatif confiné à l’interface locale, une base de données invisible de l’extérieur, et des secrets (mots de passe de la base) stockés dans un fichier d’environnement exclu de toute publication — jamais en dur dans la configuration. La conteneurisation apporte aussi une hygiène de maintenance : les mises à jour de WordPress, de PHP ou de MySQL se font en remplaçant les images, de façon réversible, les données étant hors des conteneurs. Les sauvegardes chiffrables et externalisables complètent le dispositif en couvrant le dernier risque : la perte du serveur lui-même.

    Ma plus-value personnelle

    Ce projet boucle la boucle du portfolio : l’outil qui présente mes compétences est lui-même une démonstration de ces compétences. J’y ai fait des choix d’architecture argumentés (conteneurisation pour la cohabitation, reverse proxy pour l’exposition, volumes pour la persistance) plutôt qu’une installation par défaut, et j’ai traité la sauvegarde comme une exigence de premier rang, avec script, planification, rotation et test de restauration. C’est aussi une réponse assumée à mon propre article sur le site vitrine : le bon choix technique dépend du besoin — statique quand le contenu est figé, CMS conteneurisé quand la publication est vivante. Savoir défendre les deux, c’est précisément ce que j’attends de moi en tant que futur administrateur.

    La procédure technique détaillée pas à pas (déploiement Docker, reverse proxy, HTTPS) ainsi que la procédure complète de sauvegarde et de restauration sont disponibles en téléchargement au format PDF ci-dessous.