Azim404 fait tourner une dizaine de projets sur un seul serveur privé virtuel : le portail azim404.com, mon portfolio, des jeux, une médiathèque culturelle, un bot Discord et quelques applications de démonstration. Louer un serveur par projet coûterait cher et multiplierait les mises à jour. Un VPS unique, bien découpé, suffit largement pour des sites qui reçoivent quelques centaines de visites par jour.

Un conteneur Docker par site

Chaque projet vit dans son propre dépôt Git et se lance avec son propre fichier docker-compose. Le site ne connaît que son dossier, ses variables d’environnement et sa base de données. Si un projet plante ou consomme trop de mémoire, les autres continuent de répondre. Les conteneurs n’écoutent que sur l’adresse locale du serveur, sur un port qui leur est réservé : aucun d’eux n’est joignable directement depuis Internet.

Le déploiement est automatique. Un push sur la branche principale déclenche une action GitHub qui se connecte au serveur, récupère le code, reconstruit l’image puis bascule sur la nouvelle version. Le service courant n’est coupé qu’au moment de la bascule, ce qui laisse quelques secondes d’interruption au pire. Les fichiers persistants (données, certificats, variables privées) restent en dehors du dépôt et survivent à chaque mise à jour.

nginx en façade

Devant tous les conteneurs, un seul nginx installé sur l’hôte reçoit les requêtes HTTPS, termine le chiffrement TLS et transmet chaque domaine au bon port local. C’est lui qui applique les en-têtes de sécurité communs : HSTS, protection contre l’affichage dans un cadre, politique de référent et politique de sécurité du contenu. Centraliser ces règles évite d’oublier un site lors d’un durcissement.

  • un bloc server par domaine, qui pointe vers le port local du conteneur ;
  • une redirection systématique de http:// vers https:// ;
  • un certificat Let’s Encrypt par domaine, renouvelé automatiquement ;
  • un journal JSON de toutes les requêtes, relu par la console pour les statistiques.

Des sous-domaines créés depuis la console

Ajouter un projet demandait autrefois une série de commandes à la main : créer l’enregistrement DNS, écrire le bloc nginx, demander le certificat, tester la configuration puis recharger le serveur. La console Azim404 le fait désormais en un formulaire. Comme elle tourne elle-même dans un conteneur sans aucun droit sur l’hôte, elle se contente de déposer une demande dans un dossier partagé.

Un petit assistant lancé par systemd sur l’hôte lit ces demandes, vérifie le nom et le port, crée l’enregistrement DNS chez OVH, écrit la configuration nginx, la teste et la recharge. Si le test échoue, l’ancienne configuration est remise en place. Si le DNS n’est pas encore propagé, la demande est reprise chaque minute pendant un quart d’heure avant que le certificat ne soit demandé.

Superviser sans s’y perdre

Le même assistant écrit régulièrement l’état du serveur : mémoire, disque, charge et conteneurs actifs. La console l’affiche à côté des statistiques de fréquentation de chaque site, calculées sans cookie à partir du journal nginx et d’un petit script de mesure. Les adresses IP ne sont pas conservées : un visiteur est compté une fois par jour grâce à une empreinte hachée avec un sel renouvelé à minuit.

Cette organisation reste volontairement simple. Pas d’orchestrateur, pas de cluster : un serveur, des conteneurs isolés, un nginx bien réglé et une console qui automatise les gestes répétitifs. Pour un développeur qui publie régulièrement de nouveaux projets, c’est le meilleur compromis entre coût, sécurité et temps passé à l’administration.

Ce que je referais autrement

Avec le recul, deux choix méritent d’être pris dès le premier jour. D’abord, garder toutes les données hors des dépôts, dans un dossier par projet monté dans les conteneurs : une remise à zéro du code ne touche alors jamais aux bases ni aux fichiers envoyés par les visiteurs. Ensuite, ne jamais exposer un port de conteneur au monde, même temporairement : tout passe par nginx, qui reste le seul point d’entrée à surveiller et à durcir.