Florian Vasseur

Pourquoi un environnement isolé, et pas les serveurs de production ?

• Protéger la production. Installer des logiciels à l'essai peut provoquer des conflits, ouvrir des failles de sécurité ou ralentir les serveurs que les équipes utilisent tous les jours.
• Valider avant de déployer. En entreprise, une solution se teste d'abord dans un espace séparé. On ne la met en production qu'une fois qu'elle a fait ses preuves.
• Pouvoir se tromper sans conséquence. Sur une VM, un snapshot permet de revenir en arrière en quelques minutes. Sur un serveur de production, une erreur touche directement les utilisateurs.
• Un environnement reproductible. La même VM peut être recréée pour tester plusieurs solutions dans les mêmes conditions.

Ce que j'ai fait

• Création d'une machine virtuelle sous Hyper-V, déjà utilisé dans l'entreprise, donc sans nouvel outil à intégrer.
• Ressources volontairement modestes pour pouvoir reproduire la VM sur n'importe quel poste.
• Installation d'Ubuntu Server sur la VM.
• Réseau en Default Switch d'Hyper-V : l'accès à Internet suffit aux installations, et la VM reste coupée du réseau interne.

La machine

Hyperviseur

Hyper-V

Mémoire

4 Go de RAM

Stockage

20 Go

Système

Ubuntu Server

Réseau

Default Switch

Contrôle

ping vers le réseau interne : aucune réponse

Ce que j'ai fait

• Mise à jour des paquets, puis installation de Docker depuis les dépôts officiels de Docker Inc. pour avoir une version stable et suivie.
• Vérification du service, puis d'un conteneur de test. Cela valide le moteur, le téléchargement depuis Docker Hub et l'exécution.
• Ajout de l'utilisateur courant au groupe docker, pour travailler sans compte administrateur.
• Snapshot de la VM avant toute modification importante, pour revenir en arrière rapidement.

Installer Docker (Ubuntu Server)

# 1. mettre à jour le système : évite les conflits de versions
$ sudo apt update && sudo apt upgrade -y

# 2. ajouter la clé et le dépôt officiels de Docker :
#    version stable, mises à jour de sécurité suivies
$ sudo apt install -y ca-certificates curl
$ sudo install -m 0755 -d /etc/apt/keyrings
$ sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg \
    -o /etc/apt/keyrings/docker.asc
$ echo "deb [signed-by=/etc/apt/keyrings/docker.asc] \
    https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo $VERSION_CODENAME) stable" \
    | sudo tee /etc/apt/sources.list.d/docker.list
$ sudo apt update

# 3. installer le moteur Docker et ses outils (dont Compose)
$ sudo apt install -y docker-ce docker-ce-cli containerd.io \
    docker-buildx-plugin docker-compose-plugin

# 4. vérifier que le service tourne
$ systemctl status docker

# 5. tester : télécharge une image et lance un conteneur
$ sudo docker run hello-world

# 6. travailler sans root (se reconnecter ensuite)
$ sudo usermod -aG docker $USER

À quoi ça sert

• Mise à jour + dépôt officiel : on installe une version récente, signée et maintenue, plutôt qu'un paquet ancien de la distribution.
• docker-ce : le moteur qui crée et exécute les conteneurs. docker-compose-plugin : décrit une application dans un fichier YAML (utilisé pour Homarr).
• hello-world : valide d'un coup le moteur, le téléchargement depuis Docker Hub et l'exécution.
• Groupe docker : évite d'utiliser root à chaque commande, ce qui limite les risques.

Ce que j'ai fait

• Tableau comparatif de quatre solutions, avec des critères pondérés définis avec la DSI.
• Choix de Homarr, déployé dans un conteneur sur la VM Linux.
• Compte administrateur, trois rôles (technicien support, développeur, administrateur) et un tableau de bord par service.
• Intégration de Zabbix, de Graylog et des applications métier.
• Droits au plus juste : un technicien accède à la supervision et aux logs, un développeur n'accède pas aux outils internes du support. Tests de validation sur les accès.

Rôles et accès

Technicien support

supervision, logs

Développeur

sans accès aux outils internes du support

Administrateur

gestion des comptes et des rôles

Ce que j'ai fait

• Choix d'un script Bash plutôt que de Zabbix ou de Prometheus avec Grafana, trop lourds pour un simple environnement de test.
• Mesure du processeur à partir du noyau, de la mémoire vive avec free, du disque avec df.
• Exécution en boucle toutes les 5 secondes, sortie écrite dans un fichier de logs horodaté pour garder l'historique.
• Test avec une charge processeur simulée et des applications gourmandes en mémoire : les variations ont bien été enregistrées.

Ce que le script lit

# processeur
/proc/stat

# mémoire vive
$ free

# espace disque
$ df

# test de charge
$ stress