Comment héberger plusieurs sites web sur un seul VPS sans faire de désordre

Vous voulez héberger plus d'un site web, mais vous ne voulez pas que votre serveur se transforme en fourre-tout : dossiers mystérieux, domaines cassés, un projet qui met un autre hors ligne, et aucune idée claire de l'endroit où se trouve quoi que ce soit.

Cette crainte est légitime. Un seul serveur peut très bien faire tourner plusieurs sites. L'astuce est d'arrêter de le voir comme « une machine pour un seul site » et de commencer à le voir comme un petit immeuble avec de nombreuses pièces séparées.

Un serveur peut avoir plus d'une porte d'entrée

Un serveur n'est qu'un ordinateur sur internet. Comme votre ordinateur portable, il peut faire tourner plusieurs choses à la fois. Un site pourrait être un blog WordPress. Un autre une petite application web. Un autre encore un outil privé pour votre équipe.

Héberger plusieurs sites web sur un seul serveur, cela veut dire que chaque projet partage la même maison physique, mais garde tout de même sa propre porte d'entrée.

La porte d'entrée est en général un nom de domaine, comme example.com, shop.example.com ou another-site.com. Les visiteurs se moquent que ces noms aboutissent au même serveur. Ils tapent l'adresse, et le bon site apparaît.

Le désordre commence quand chaque projet est traité comme un seul gros tas. Les fichiers se mélangent. Les noms de domaine pointent au mauvais endroit. HTTPS fonctionne pour un site mais pas pour un autre. Réparer un projet casse par accident tous les autres.

Une configuration bien rangée donne à chaque projet une identité claire : son propre nom, sa propre destination, sa propre connexion sécurisée et son propre espace où vivre.

Les domaines sont des panneaux indicateurs, pas des sites web

Un domaine ne contient pas votre site web. Il ressemble plutôt à un panneau indicateur au bord de la route.

Quand quelqu'un visite votre domaine, internet vérifie vers où ce nom pointe. Ce système d'aiguillage s'appelle le DNS, abréviation de Domain Name System. Le DNS est le carnet d'adresses d'internet. Il relie un nom lisible au serveur qui doit répondre.

Si vous avez trois domaines sur un seul serveur, tous les trois peuvent pointer vers la même adresse de serveur. C'est normal.

Mais faire pointer le domaine n'est que la première moitié du travail. Cela amène le visiteur jusqu'à l'immeuble. Cela ne décide pas dans quelle pièce il doit entrer.

C'est pourquoi configurer le domaine et gérer le routage sur le serveur sont deux tâches différentes. Le DNS dit : « Va vers ce serveur. » Le routage dit : « Pour ce domaine, montre ce projet. »

Si vous voulez une explication du côté domaine en termes accessibles aux débutants, ce guide est un bon complément : Comment connecter un domaine à votre serveur.

Le routage est le réceptionniste à l'entrée

Une fois qu'un visiteur atteint votre serveur, quelque chose doit lire le domaine qu'il a demandé et l'envoyer vers le bon projet.

Ce « quelque chose » est souvent appelé serveur web ou reverse proxy. Un reverse proxy est un aiguilleur du trafic. Il se tient à l'entrée, regarde le domaine demandé et transmet le visiteur vers le bon site ou la bonne application en coulisses.

Voyez-le comme un réceptionniste dans un immeuble de bureaux.

Quelqu'un entre et dit : « Je viens pour le studio de design. » Le réceptionniste l'envoie à la suite 201. Une autre personne dit : « Je viens pour le comptable. » Elle va à la suite 304. Même immeuble, destinations différentes.

Sur votre serveur, example.com pourrait mener à un site marketing. app.example.com pourrait mener à une application web. blog.example.com pourrait mener à WordPress.

Un bon routage garde l'adresse publique simple tout en laissant chaque projet fonctionner à sa manière. Un site pourrait être composé de pages statiques. Un autre pourrait utiliser une base de données. Un autre encore pourrait tourner comme service applicatif. Les visiteurs ne voient pas cette complexité. Ils voient juste le bon site.

Si vous publiez une application plutôt qu'un site web classique, la même idée s'applique. L'application a besoin d'un endroit où tourner, et le domaine doit router vers elle. Nous traitons ce parcours dans Comment déployer une petite application web sans DevOps.

HTTPS est un cadenas pour chaque adresse

HTTPS est la version sécurisée de la connexion à un site web. C'est ce qui affiche aux visiteurs l'icône du cadenas dans leur navigateur et protège le trafic entre eux et votre site.

Quand vous hébergez plusieurs sites web, il vous faut en général HTTPS pour chaque domaine ou sous-domaine. Le cadenas appartient à l'adresse que les gens visitent, pas seulement au serveur dans son ensemble.

Cela signifie que example.com, shop.example.com et another-site.com doivent chacun être couverts correctement.

Sans cela, les visiteurs peuvent voir des avertissements inquiétants dans le navigateur. Ou un domaine peut afficher par accident un certificat destiné à un autre. Cela fait peu professionnel, et pour les formulaires, les connexions, les boutiques ou les pages d'administration, ce n'est pas facultatif.

La bonne nouvelle, c'est que HTTPS n'a pas à être coûteux ni mystérieux. Les certificats gratuits sont courants, et ils peuvent se renouveler automatiquement quand la configuration est propre. Le plus important est de s'assurer que chaque site a son propre chemin sécurisé, du navigateur jusqu'au bon projet.

Pour une explication en langage simple, voir Comment obtenir HTTPS gratuit sur votre propre serveur.

Gardez les projets dans des pièces séparées

Partager un serveur ne devrait pas vouloir dire tout partager.

Chaque site web ou application devrait avoir son propre espace. Au minimum, cela veut dire que vous savez quels fichiers, quel domaine, quelle base de données et quels services en arrière-plan appartiennent à quel projet. Si un site doit être supprimé plus tard, vous ne devriez pas avoir à faire de l'archéologie.

La séparation réduit aussi les accidents. Si vous mettez à jour un projet, les autres ne devraient pas s'en soucier. Si une application remplit son dossier d'envoi, elle ne devrait pas avaler en silence le serveur entier. Si un site a un problème, vous devriez pouvoir y réfléchir sans ouvrir tous les tiroirs de la maison.

Il existe différentes façons de créer cette séparation. Certaines personnes utilisent des dossiers et des utilisateurs séparés. D'autres utilisent des conteneurs, qui sont comme des boîtes-repas étiquetées pour les applications et leurs ingrédients. D'autres encore utilisent un mélange.

La méthode exacte importe moins que le résultat : chaque projet a une frontière.

Vous devriez aussi penser aux sauvegardes. Quand vous hébergez plusieurs projets sur un seul serveur, une seule mauvaise erreur peut toucher plus d'un site. Une sauvegarde utile, ce n'est pas juste « quelques fichiers quelque part ». C'est quelque chose que vous pouvez réellement restaurer. Si vous ne l'avez pas encore prévu, lisez Comment sauvegarder votre serveur — et pouvoir vraiment le restaurer.

Le raccourci

Tout ce qui précède est faisable à la main. Le hic, c'est que cela ne reste faisable que tant que vous vous souvenez de la façon dont vous avez tout branché — quel domaine pointe vers quoi, quel site a reçu quel certificat, quel dossier appartient à quel projet. Trois sites et quelques mois plus tard, cette mémoire est la première chose à disparaître, et c'est en général là qu'une petite modification casse discrètement quelque chose d'autre.

Server Manager est conçu pour garder ces détails à votre place. Quand vous ajoutez un site, il donne au projet son propre endroit où vivre, fait pointer le bon domaine vers lui et émet HTTPS pour cette adresse précise — le routage et les certificats propres à chaque site dont parlaient les sections ci-dessus, gérés en une seule passe au lieu de plusieurs étapes délicates, et renouvelés tout seuls pour qu'un cadenas n'expire jamais en silence. Chaque projet garde sa propre frontière, si bien que mettre à jour ou supprimer l'un ne va pas toucher aux autres, et un site qui remplit son disque ou qui tombe reste le problème de ce seul site.

Le véritable avantage, c'est que cela reste lisible. Des mois plus tard, vous pouvez l'ouvrir et voir d'un coup d'œil quel site répond à quel domaine et si chacun est sécurisé, au lieu de lire des fichiers de configuration et de deviner. Vous obtenez le résultat que vous vouliez au départ — plusieurs sites web sur un seul serveur, chacun derrière sa propre porte d'entrée — sans devenir la personne qui doit se rappeler chaque détail caché pour les faire tous tourner.

Votre victoire : un serveur, plusieurs sites bien rangés

Vous n'avez pas besoin d'un serveur séparé pour chaque petit site web ou application. Vous avez besoin d'étiquettes claires, de routes propres, d'adresses sécurisées et d'une séparation raisonnable.

Quand ces éléments sont en place, un seul serveur peut sembler calme au lieu d'encombré. Chaque projet a sa propre porte. Les visiteurs arrivent là où ils doivent. HTTPS fonctionne là où il le doit. Et quand vous y revenez des mois plus tard, la configuration a toujours du sens.