Aller au contenu

Réseautage et répartition de charge Mis à jour le 2026-05-29

Intégrer le Traffic Distributor à une application en cours d'exécution

Comment placer le Traffic Distributor devant une application qui sert déjà du trafic sur Stack Harbor PaaS — ajout du second backend, swap de domaines, swap d'IP publiques.

Le plus dur en plaçant le Traffic Distributor (TD) devant une application existante n’est pas le distributeur lui-même — c’est la bascule. Vous avez des utilisateurs en direct qui frappent un endpoint connu, et le nouveau point d’entrée doit prendre le relais sans perdre de connexions.

Cette page déroule les deux chemins de bascule valides, selon la façon dont le domaine personnalisé de l’application est lié.

Le décor

On part d’un environnement qui exécute l’application — appelons-le primary-env. Il a déjà un domaine personnalisé attaché.

1. Monter une seconde copie

TD a besoin d’un second backend vers lequel router. Deux options :

  • Cloner primary-env. La fonction de clonage d’environnement de la plateforme vous donne une copie identique avec la même configuration et les mêmes données déjà en place.
  • Créer à partir de zéro. Utiliser la même topologie et redéployer l’application — approprié quand la couche de données est externe ou déjà partagée.

Si vous clonez, parcourez la configuration pour les valeurs codées en dur — liens directs, IP, chaînes contenant le nom d’environnement — et corrigez-les pour le nom cloné.

Appelons le second environnement second-env.

2. Installer le Traffic Distributor

Depuis le Marketplace du tableau de bord, installez Traffic Distributor et passez-lui les deux environnements comme backends. TD démarre comme son propre environnement, prêt à traiter des requêtes.

Si votre plateforme expose plusieurs régions, migrez l’un des deux backends dans une autre région. Vous obtenez ainsi une vraie bascule au-delà des frontières matérielles — un backend peut tomber et TD continuera de servir depuis l’autre.

À ce stade TD est prêt, mais aucun trafic ne l’atteint encore. L’application sert toujours depuis primary-env directement.

3. Déplacer le point d’entrée vers TD

Pour faire passer les utilisateurs réels par TD, le domaine personnalisé qui pointe vers primary-env doit pointer vers l’environnement TD à la place. La bonne méthode dépend du type d’enregistrement DNS :

  • CNAME ou ANAME → swap de domaines
  • Enregistrement A → swap d’IP publiques

Chemin A : Swap de domaines (CNAME / ANAME)

Quand le domaine personnalisé est lié par CNAME ou ANAME, la fonction Swap Domains de la plateforme effectue le déplacement en une étape.

  1. Dans le tableau de bord, survolez primary-env et choisissez Settings.
  2. Sous Custom domains, ouvrez Swap Domains et sélectionnez l’environnement Traffic Distributor dans la liste déroulante.
  3. Cliquez sur Swap et confirmez.

En une minute, le domaine personnalisé est lié à l’environnement TD. Les deux backends deviennent joignables par ce domaine unique, et les règles de routage de TD décident sur lequel chaque requête atterrit.

Chemin B : Swap d’IP publiques (enregistrement A)

Quand le domaine personnalisé est lié par enregistrement A, le déplacement exige de changer l’IP derrière le domaine. La plateforme offre deux façons.

Option 1 : SwapExtIps en CLI

La bascule la plus propre. La commande CLI échange l’IP publique entre le nœud frontal de primary-env et le répartiteur NGINX de TD :

~/jelastic/environment/binder/swapextips \
  --envName primary-env \
  --sourceNodeId {primary-front-node-id} \
  --targetNodeId {td-balancer-node-id}

Aucun changement DNS nécessaire — votre enregistrement A pointe toujours vers la même IP, et cette IP vit désormais sur le répartiteur TD. Voir le document CLI : swap d’IP publiques pour la référence des paramètres et le comportement de redémarrage.

Option 2 : Mise à jour manuelle de l’enregistrement A

Si vous préférez travailler dans votre gestionnaire DNS :

  1. Vérifiez que le répartiteur NGINX de TD a une IP publique attachée. Copiez sa valeur depuis le tableau de bord.
  2. Ouvrez votre gestionnaire DNS et mettez à jour l’enregistrement A pour qu’il pointe vers la nouvelle IP.
  3. Attendez l’expiration du TTL DNS précédent. Tant qu’il n’est pas écoulé, certains résolveurs servent encore l’ancienne IP — c’est acceptable, ces requêtes continueront d’atteindre primary-env jusqu’à expiration.
  4. Une fois le trafic entièrement migré, détachez l’IP publique de primary-env pour cesser de payer une adresse inutilisée.

Auditez votre application pour les dépendances d’IP codées en dur avant la bascule — intégrations sortantes, listes blanches d’IP, sondes de supervision, tout ce qui cible l’ancienne IP doit apprendre la nouvelle.

Après la bascule

À partir de là, chaque requête vers le domaine personnalisé atteint d’abord TD. TD applique la règle de routage configurée — 100/0 pour un proxy pur, ratio pour A/B, primaire-avec-bascule pour haute disponibilité — et transmet à l’un des deux backends.

Vous pouvez ensuite ajouter des backends, modifier le ratio ou exécuter une mise en production blue/green sans retoucher au DNS.

Voir aussi