De février à avril 2026, j’ai effectué mon stage de BTS SIO SISR chez Rahona-Hosting, un hébergeur gérant des serveurs dédiés et des services cloud. Six semaines d’immersion directe dans une infrastructure professionnelle réelle, voilà ce que j’y ai fait.
L’entreprise
Rahona-Hosting propose des solutions d’hébergement qui repose sur de la virtualisation avec Proxmox VE. Il s’agit d’un hyperviseur open-source qui permet de faire tourner plusieurs serveurs virtuels sur une même machine physique.
Les missions de mon stage BTS SIO
Semaine 1 – Infrastructure de base et sauvegarde
Avant de pouvoir travailler sur quoi que ce soit, il fallait construire le socle. En effet, j’avais besoin d’un environnement de test isolé et fonctionnel pour la durée du stage.
J’ai donc installé Proxmox VE sur un serveur dédié Hetzner depuis le mode Rescue, configuré le réseau avec bridges public et interne, puis déployé un pare-feu OPNsense en VM avec un tunnel WireGuard pour l’accès sécurisé à distance.
La sauvegarde de l’hyperviseur
Proxmox Backup Server gère très bien les sauvegardes de VMs. En revanche, il ne sauvegarde pas l’hyperviseur lui-même : fichiers réseau, configuration firewall, certificats, bases de données PVE. Si le serveur tombe sans ces fichiers, tout est à reconfigurer manuellement.
J’ai donc mis en place un système de sauvegarde incrémentielle avec rsnapshot, ciblant les fichiers critiques (/etc/network/interfaces, clés SSH, configs firewall, etc.). Le script synchronise les sauvegardes vers une Storage Box Hetzner via SFTP, avec une politique de rétention sur 30 jours quotidiens, 4 hebdomadaires et 3 mensuels.
Semaine 2 – Supervision et automatisation
Supervision centralisée
Rahona avait besoin d’une visibilité centralisée sur son infrastructure : hyperviseur Proxmox, pare-feu OPNsense, serveur Plesk, conteneurs Docker. Sans monitoring, les problèmes ne se détectent qu’une fois que les clients ouvrent un ticket.
Plusieurs solutions ont ainsi été étudiées et testées : la stack ELK avec Fleet Server pour la centralisation des logs, et Checkmk en supervision hybride via l’API Proxmox. Après comparaison, Rahona a retenu Pulse, un dashboard open-source conçu pour Proxmox et Docker. Il se connecte directement à l’API Proxmox pour les nœuds et VMs, déploie des agents sur les hôtes Docker, et propose des alertes Discord/Slack avec un dashboard unifié en temps réel. Un guide complet d’installation de Pulse est disponible dans cet article dédié.
Automatisation de la livraison de VPS
Rahona livrait ses VPS à partir de templates Proxmox créés manuellement. Or, après 6 à 12 mois, les repos de certaines distributions se cassent et les paquets manquent. La livraison échoue alors sans que personne ne soit prévenu, jusqu’au ticket client.
J’ai donc développé deux scripts pour fiabiliser ce processus. Le premier, update-debian-13.sh, maintient les images cloud à jour via virt-customize. Le second, livraison-vps.sh, déploie une VM complète en une commande avec support Debian 13, Ubuntu 24 et AlmaLinux 9.
Semaine 3 – Migration DHCP vers Kea
J’ai migré le service DHCP depuis ISC DHCP Server, dont le support est arrêté, vers Kea DHCP. J’ai repris la configuration dual-stack IPv4/IPv6, et j’ai rédigé une documentation complète de l’API REST via Postman. Cette API sera ensuite intégrée dans le script de livraison VPS pour automatiser l’attribution des adresses réseau à chaque nouvelle VM.
Semaine 4 – Passerelle de consoles VMs et CI/CD
Passerelle noVNC/xterm.js
Pour accéder aux consoles des VMs Proxmox, il fallait jusqu’ici passer par l’interface web Proxmox, qui expose des informations d’administration. L’objectif était donc de créer une passerelle dédiée, accessible sans donner accès à toute l’interface.
J’ai ainsi développé une passerelle noVNC/xterm.js en Node.js permettant d’accéder aux consoles graphiques et série des VMs depuis un navigateur. Je l’ai déployée derrière Cloudflare avec WebSockets en SSL.
Pipeline GitLab CI/CD
J’ai ensuite mis en place une pipeline GitLab CI/CD complète pour automatiser le déploiement : build des images Docker, push vers le registry, déploiement automatique sur Dokploy et purge du cache Cloudflare à chaque push. J’ai également intégré Sentry pour le monitoring des erreurs, et configuré les headers CSP/CORS pour la sécurité.
Semaine 5 – Agent Python de provisionnement
Pour finir, j’ai développé un agent Python orchestré via RabbitMQ. Il automatise le provisionnement de l’infrastructure : gestion des baux Kea DHCP, configuration des bridges réseau Proxmox, création et livraison de VMs. Le tout piloté par API sans intervention manuelle.
Découverte & mise en pratique
En parallèle des missions principales, j’ai eu l’occasion de mener un projet concret de bout en bout : déployer WordPress en haute disponibilité totale sur l’infrastructure Rahona.
L’objectif était simple : aucun composant ne doit être un point de défaillance unique. Autrement dit, si un serveur tombe, le site reste en ligne.
Pour y arriver, j’ai empilé plusieurs briques. D’abord, Docker Swarm pour orchestrer 3 réplicas WordPress sur 3 nœuds distincts, avec Traefik comme reverse proxy. Ensuite, GlusterFS pour que les 3 réplicas partagent les mêmes fichiers en temps réel : uploads, thèmes, plugins. Puis MariaDB Galera pour répliquer la base de données sur 3 nœuds. Enfin, Cloudflare Zero Trust avec 3 réplicas cloudflared pour exposer le tout sans ouvrir un seul port entrant sur les serveurs. Le déploiement de cloudflared dans Docker Swarm est détaillé dans cet article dédié.
Résultat : on peut couper n’importe quel nœud, le site reste accessible.
En parallèle, j’ai découvert les fonctionnalités avancées de Cloudflare Pro : WAF managé, Transform Rules, headers de sécurité et pages d’erreur personnalisées.
Ce que ce stage m’a apporté
Six semaines qui couvrent un spectre large : virtualisation, réseau, sauvegarde, supervision, automatisation, CI/CD, sécurité, haute disponibilité. Chaque semaine posait les bases de la suivante.
Ce stage m’a confirmé que l’administration systèmes moderne, c’est autant du code que de la configuration : scripts bash, Python, pipelines CI/CD, agents de messaging.