Chaque conteneur sur le Stack Harbor PaaS reçoit un ensemble de noms DNS dès sa création. Ils pointent vers l’IP interne du conteneur, l’IP externe (quand elle est attachée), ou les deux. Savoir quel nom utiliser simplifie les connexions inter-paliers, l’outillage interne et la migration entre régions — le code applicatif n’a pas à connaître d’adresse IP, seulement des noms stables.
Cette page décrit les formats de noms d’hôte que la plateforme enregistre automatiquement.
Noms d’hôte de conteneurs individuels
Chaque conteneur est joignable par deux noms pleinement qualifiés équivalents :
node${nodeId}-${envName}.${platformDomain}node${nodeId}.${envName}.${platformDomain}
Les variables sont :
${nodeId}— un identifiant entier assigné par la plateforme à la création du conteneur. Stable pendant la vie du conteneur.${envName}— le nom d’environnement (pas l’alias d’affichage) choisi à la création.${platformDomain}— le nom de domaine de la région Stack Harbor PaaS.
Les deux formes se résolvent depuis l’intérieur de la plateforme et depuis l’internet public — utilisables pour les connexions internes et pour l’accès SSH ou HTTP externe, avec les considérations habituelles d’IP publique et de pare-feu.
Préfixes spécifiques aux stacks
Quelques stacks infogérés exposent aussi un nom d’hôte basé sur le nom du stack au lieu du préfixe générique node. Ces noms ne fonctionnent que sous les domaines de plateforme qui utilisent un tiret comme séparateur (forme tiret, pas forme point).
| Type de nœud | Stack | Nom d’hôte supplémentaire |
|---|---|---|
| Conteneur Docker personnalisé | — | docker${nodeId}-${envName}.${platformDomain} |
| Base de données | Cassandra | cassandra${nodeId}-${envName}.${platformDomain} |
| Base de données | CouchDB | couchdb${nodeId}-${envName}.${platformDomain} |
| Base de données | MariaDB | mariadb${nodeId}-${envName}.${platformDomain} |
| Base de données | Memcached | memcached${nodeId}-${envName}.${platformDomain} |
| Base de données | MSSQL | mssql${nodeId}-${envName}.${platformDomain} |
| Base de données | MySQL | mysql${nodeId}-${envName}.${platformDomain} |
| Base de données | Neo4j | neo4j${nodeId}-${envName}.${platformDomain} |
| Base de données | OrientDB | orientdb${nodeId}-${envName}.${platformDomain} |
| Base de données | PostgreSQL | postgres${nodeId}-${envName}.${platformDomain} |
| Base de données | Redis | redis${nodeId}-${envName}.${platformDomain} |
| VPS | — | vps${nodeId}-${envName}.${platformDomain} |
Ces noms sont équivalents à la forme générique node${nodeId}-… — une commodité de lecture humaine.
Nom d’hôte pour tout un palier
Pour résoudre tous les conteneurs d’un palier d’un seul coup (pratique pour des scripts qui parcourent un palier applicatif) :
${nodeGroup}.${envName}.${platformDomain}
${nodeGroup} est l’identifiant du palier. Les paliers par défaut portent des noms convenus — bl (répartiteur), cp (compute / serveur d’application), sqldb (base SQL), nosqldb (base NoSQL), cache, vds, storage, build. Les paliers supplémentaires ajoutés via l’assistant de topologie reçoivent des noms indexés — cp2, cp3, …, extra, extra2, ….
Le nom d’hôte se résout vers toutes les IP internes du palier. La plateforme met à jour l’entrée DNS automatiquement à l’ajout ou au retrait d’un conteneur.
Noms courts au sein d’un environnement
Depuis l’intérieur d’un conteneur, vous pouvez omettre les suffixes d’environnement et de domaine et adresser les voisins par nom court :
node${nodeId}— un conteneur précis.${nodeGroup}— un palier entier.
Ces noms courts ne se résolvent qu’au sein du même environnement. Ils rendent les fichiers de configuration applicatifs portables entre régions — un conteneur déplacé vers une nouvelle région prend transparentement son nouveau domaine de plateforme, parce que les noms courts ne l’encodent pas.
Noms d’hôte pour paliers liés
Quand deux paliers sont joints par un lien entre conteneurs, la plateforme enregistre des entrées DNS supplémentaires limitées à la paire liée. Pour un lien d’alias ${linkAlias} :
${linkAlias}_${N}— adresse un conteneur précis du palier cible. Le maître est toujours_1; les autres sont triés parnodeIDascendant et reçoivent_2,_3, ….${linkAlias}— round-robin sur tous les conteneurs du palier cible.
La forme indexée (${linkAlias}_N) ne se résout qu’en interne — entre les paliers source et cible liés. L’alias nu ne se résout aussi qu’entre les paliers liés. Ajouter le domaine d’environnement — ${linkAlias}.${envName}.${platformDomain} — produit un nom qui se résout aussi en externe, exposant le palier cible à l’internet (selon la configuration IP publique et pare-feu).
Exemple
Un palier cible contient trois conteneurs aux nodeID 123, 124 et 125, dont 124 est le maître. Après un lien d’alias app :
app_1→ conteneur 124 (le maître).app_2→ conteneur 123 (plus basnodeIDrestant).app_3→ conteneur 125.app(sans index) → round-robin sur les trois.