Aller au contenu

Se connecter à un conteneur personnalisé

Chemins de connexion interne et externe vers un conteneur personnalisé Stack Harbor PaaS — liens, DNS, répartiteur partagé, endpoints, IP publique.

Un conteneur personnalisé sur le Stack Harbor PaaS est joignable dans deux directions : depuis d’autres conteneurs au sein de la plateforme (connexion interne) et depuis l’internet public (connexion externe). Chaque direction propose plusieurs mécanismes aux compromis différents. Cette page les présente pour faciliter le choix.

Connexions internes

Chaque conteneur reçoit une IP interne et un ensemble de noms DNS internes à la création. Les conteneurs d’un même environnement — et les conteneurs d’environnements liés — peuvent se joindre via ce réseau interne.

Via un lien entre conteneurs

La façon recommandée de câbler deux paliers d’un même environnement. Définissez un lien sur le palier consommateur, aliasez le palier cible, et les conteneurs source reçoivent les variables d’environnement de connexion de la cible plus un alias DNS pour la cible.

Bénéfices : aucun port exposé à l’extérieur, la configuration voyage avec la topologie, les changements de variables se propagent automatiquement.

Par nom DNS interne

Si un lien est trop de mécanique pour votre besoin — vous connaissez déjà le nom d’hôte de la cible et voulez la joindre depuis du code ou de la configuration applicative — le DNS interne de la plateforme résout directement :

  • node${nodeId}-${envName}.${platformDomain} pour un conteneur précis.
  • ${nodeGroup}.${envName}.${platformDomain} pour un palier entier.
  • Les formes courtes (node${nodeId}, ${nodeGroup}) fonctionnent dans le même environnement.

Les conventions de nommage sont documentées dans Noms DNS pour connexion directe aux conteneurs.

Par IP interne

L’IP interne de tout conteneur est visible au tableau de bord — dépliez Additionally sur la ligne du conteneur. L’IP est stable pendant la vie du conteneur, mais un redéploiement ou une migration peut la changer ; mieux vaut traiter les IP internes comme un repli pour les outils qui ne résolvent pas le DNS.

La même information est reflétée dans le courriel de création du conteneur envoyé au propriétaire du compte : Access URL est le nom DNS interne, IP est l’adresse interne.

Connexions externes

Trois mécanismes, du moins coûteux opérationnellement au plus.

1. Open in Browser via le répartiteur partagé

Si le conteneur expose un service HTTP sur le port 80, le répartiteur partagé de la plateforme y route le trafic automatiquement via le domaine par défaut de l’environnement. Cliquez sur Open in Browser près du conteneur ou de l’environnement, et le navigateur ouvre ce domaine dans un nouvel onglet.

Pour les conteneurs sans IP publique écoutant sur un port TCP personnalisé, la plateforme exécute aussi une redirection automatique de port : les requêtes entrantes sur le domaine par défaut sont transférées vers un port d’écoute détecté à l’intérieur du conteneur. Cela rend la plupart des déploiements ponctuels joignables dès qu’ils sont actifs.

Pour désactiver la redirection, configurez les règles pare-feu du conteneur.

2. Endpoints (mappage de port via le répartiteur partagé)

Pour une exposition plus délibérée — un service non-HTTP, un port TCP custom, un port que l’auto-redirect n’attrape pas — utilisez la fonction Endpoints dans les Settings de l’environnement.

Un endpoint mappe un port privé d’un conteneur choisi vers un port public assigné aléatoirement sur le répartiteur partagé. Le tableau de bord affiche l’Access URL résultante avec le port ; cette URL est ensuite joignable depuis l’internet public.

Les endpoints sont utiles quand vous voulez exposer un port précis sans brûler une IP publique, et quand vous pouvez vivre avec le numéro de port assigné par la plateforme.

3. IP publique

Attacher une IP publique donne au conteneur sa propre adresse routable. Le conteneur peut alors écouter sur n’importe quel port — pas de mappage via le répartiteur partagé, pas d’auto-redirect, pas de surprise de translation de port.

Une IP publique débloque aussi des fonctions absentes des chemins partagés :

  • TLS personnalisé avec votre propre certificat.
  • Connexions concurrentes illimitées — le répartiteur partagé applique des limites par plateforme que le chemin IP publique n’a pas.
  • Accès direct aux protocoles non standards (SMTP, TCP custom, tout ce qui ne tient pas dans HTTP/S).

Les IP publiques sont une option payante. Le coût s’affiche au survol dans l’assistant de topologie, et dans l’onglet Quotas & Pricing > Pricing > Options du tableau de bord.

Choisir un chemin

BesoinÀ utiliser
Le palier app a besoin des coordonnées BDLien entre conteneurs
Appel HTTP app vers app dans un envDNS interne
Interface web rapide d’un serviceRépartiteur partagé, Open in Browser
Exposer un port unique non-HTTPEndpoints
TCP complet / TLS perso / sans limites partagéesIP publique

Voir aussi