Aller au contenu

TLS et domaines Mis à jour le 2026-05-27

Plusieurs domaines sur un environnement

Héberger plusieurs noms de domaine sur un seul environnement Stack Harbor PaaS avec IP publique — DNS, configuration d'hôtes virtuels sur Tomcat et le piège du redéploiement.

Parfois la bonne forme pour un environnement est de servir plusieurs domaines distincts depuis le même jeu de ressources de calcul — plusieurs sites pour des campagnes marketing différentes, des applications sœurs qui partagent l’infrastructure, un déploiement multi-locataire d’un même code source. Le PaaS supporte ce cas avec une IP publique et la configuration d’hôtes virtuels native du serveur applicatif.

L’exemple ci-dessous utilise Tomcat parce que sa configuration est concrète et claire ; le même motif s’applique à GlassFish, Jetty, NGINX, Apache HTTPD et aux applications Node.js qui utilisent un routeur d’hôte au niveau du framework.

Pourquoi un environnement, plusieurs domaines

  • Efficacité des ressources. Deux domaines n’ont pas besoin de deux paliers base de données, deux répartiteurs, deux jeux de règles de scaling.
  • Simplicité opérationnelle. Un environnement, un pipeline de déploiement, une empreinte de supervision.
  • Marketing ou UX différenciés. Des domaines distincts routés vers des racines de documents différentes au sein du même serveur applicatif permettent de tester des marques, de segmenter les populations d’utilisateurs ou de mettre en scène du contenu par audience sans dupliquer l’infrastructure.

Prérequis

  • Un environnement avec une IPv4 publique attachée au serveur applicatif (ou au répartiteur en façade).
  • Des enregistrements A chez votre registrar pour chaque domaine, pointant sur cette IP publique.
  • L’accès administratif à chaque domaine.

Tomcat multi-domaines — pas à pas

  1. Créer l’environnement. Dans l’assistant de topologie, choisissez Tomcat, activez Public IPv4 sur le nœud Tomcat, nommez l’environnement et créez.

  2. Récupérer l’IP publique. Dans le tableau de bord, déroulez le nœud Tomcat — l’IP publique est dans la liste déroulante.

  3. Pointer les domaines vers l’IP publique. Chez votre registrar, ajoutez un enregistrement A par domaine (premierdomaine.com → 198.51.100.10, seconddomaine.com → 198.51.100.10, etc.).

  4. Déployer les applications. Téléversez vos fichiers WAR dans le Deployment Manager et déployez chacun dans un contexte distinct. Le chemin de contexte exact compte car la configuration d’hôte virtuel ci-dessous référence l’emplacement sur disque.

  5. Configurer les hôtes virtuels dans server.xml. Cliquez Config sur le nœud Tomcat, allez dans le dossier server, ouvrez server.xml, et ajoutez un bloc <Host> par domaine dans l’élément <Engine> :

<Host name="premierdomaine.com" appBase="webapps/premier">
  <Alias>premierdomaine.com</Alias>
  <Context path="" docBase="."/>
</Host>

<Host name="seconddomaine.com" appBase="webapps/second">
  <Alias>seconddomaine.com</Alias>
  <Context path="" docBase="."/>
</Host>

<Host name="troisiemedomaine.com" appBase="webapps/troisieme">
  <Alias>troisiemedomaine.com</Alias>
  <Context path="" docBase="."/>
</Host>

Les champs clés :

  • name — le domaine que Tomcat compare à l’en-tête Host entrant.
  • appBase — le dossier (sous $CATALINA_HOME, en général webapps/) contenant l’application pour ce domaine.
  • <Alias> — noms d’hôtes supplémentaires routés vers le même appBase (par exemple www.premierdomaine.com).
  • <Context path="" docBase="."/> — contexte racine de l’application à . relatif à appBase.
  1. Enregistrer et redémarrer Tomcat. Utilisez l’action de redémarrage du tableau de bord pour que le nouveau server.xml soit pris en compte.

Chaque domaine résout maintenant vers sa propre racine de documents sur la même instance Tomcat.

Piège du redéploiement

Si vous redéployez une application sur un nœud Tomcat dont server.xml contient déjà des blocs <Host> personnalisés, le déploiement peut échouer ou être réécrit parce que l’étape de déploiement essaie de gérer webapps/ elle-même.

Le contournement est simple :

  1. Commentez le bloc <Host> concerné dans server.xml.
  2. Redéployez.
  3. Décommentez le bloc.
  4. Redémarrez Tomcat.

Pour les environnements où les redéploiements sont fréquents, envisagez d’externaliser la configuration d’hôte dans des fichiers conf/Catalina/<hostname>/ plutôt que d’éditer server.xml directement — Tomcat traite chaque fichier par hôte comme autoritaire et l’étape de déploiement les laisse tranquilles.

Autres serveurs applicatifs

Le même motif général fonctionne ailleurs :

  • GlassFish / Payara — serveurs virtuels dans la console d’admin, mappés sur les applications déployées.
  • NGINX — blocs server { server_name ...; root ...; }, un par domaine.
  • Apache HTTPD — blocs <VirtualHost> avec ServerName et DocumentRoot.
  • Node.js — un routeur niveau framework (Express, Fastify) basé sur req.hostname.

Voir aussi