Liens entre conteneurs

Un lien entre conteneurs donne à une charge de travail, le consommateur, un accès privé à un port TCP d’une autre charge de travail, la cible. Le consommateur joint la cible sous la forme alias:port ; la cible n’a besoin d’aucun port publié, et rien d’autre n’est ouvert. Le consommateur et la cible peuvent chacun être un Container, un Deployment ou un service Compose, sur le même nœud Docker ou sur des nœuds différents.

Utilisez un lien entre conteneurs lorsqu’une application doit appeler un service interne d’une autre charge de travail, comme une API, une file de messages ou un cache, sans publier ce service sur l’hôte ni partager un réseau Docker entre les deux. Pour les bases de données managées et le stockage objet managé, utilisez plutôt les liaisons de bases de données et les liens de stockage : ils fournissent aussi les identifiants.

Prérequis

Plan : Personal ou supérieur. Les liens existants continuent de fonctionner après un changement de licence ; la création d’un lien nécessite le plan actuel. Voir Plans et droits.
Démon Docker : les deux nœuds, celui du consommateur et celui de la cible, nécessitent le démon Docker 2.11.1 ou ultérieur. Un lien dont le nœud exécute un démon plus ancien affiche update required jusqu’à la mise à jour du démon.
Permissions : sur le consommateur, docker:containers:edit (docker:compose:manage pour un service Compose), plus docker:containers:environment lorsque le lien définit des variables ; sur la cible, docker:containers:link (docker:compose:manage pour un service Compose). Le propriétaire de la cible accorde docker:containers:link pour permettre à d’autres charges de travail de la joindre sans leur donner aucun autre accès. Voir la Référence des scopes.

Créer un lien

Ouvrez le consommateur : l’onglet Environment d’un Container ou d’un Deployment, ou l’onglet Variables d’un projet Compose.
Dans Links, sélectionnez Add link, puis Container. Pour un projet Compose, choisissez le Service consommateur.
Choisissez le Target type et la charge de travail cible, sur n’importe quel nœud Docker, ainsi que le Port TCP de la cible à ouvrir.
Vérifiez l’Alias. Par défaut, il s’agit du nom de la cible ; c’est le nom auquel le consommateur se connecte : lettres minuscules, chiffres et tirets, unique parmi les liens du consommateur.
Renseignez éventuellement des Environment variables pour l’hôte, le port ou une URL (http://alias:port), par exemple API_HOST, API_PORT ou API_URL. Définir des variables recrée une fois le consommateur afin qu’il démarre avec elles ; un lien sans variables ne redémarre pas le consommateur.
Enregistrez et attendez que le lien affiche ready, puis effectuez une vraie requête depuis le consommateur vers alias:port.

Incoming, dans le bloc Links de la cible, liste les charges de travail qui la joignent. Un lien se retire depuis le bloc Links du consommateur ; le retirer supprime l’alias et, lorsque le lien définissait des variables, les supprime au prix d’une recréation supplémentaire.

API et MCP

Action	REST	MCP et assistant
Lister les liens d’une charge de travail	`GET /api/docker/container-links?nodeId=&type=&resourceId=&direction=outgoing\|incoming`	`manage_container_link` `list`
Créer un lien	`POST /api/docker/container-links`	`manage_container_link` `create`
Lire un lien et son exécution	`GET /api/docker/container-links/{id}` et `/{id}/runtime`	`manage_container_link` `get_runtime`
Supprimer un lien	`DELETE /api/docker/container-links/{id}`	`manage_container_link` `delete`

Une charge de travail est identifiée par son nœud, son type (container, deployment ou compose_service) et sa ressource : le nom du conteneur, l’identifiant du Deployment ou <compose-project-id>:<service-name>. L’exécution affiche les connexions ouvertes, les sessions, le débit et les connexions refusées, comme pour les liens de bases de données et de stockage.

États

État	Signification	Que faire
ready	Le consommateur joint la cible.	Rien.
pending	Le lien est enregistré ; le consommateur le prend en compte à son prochain démarrage ou déploiement.	Démarrez le consommateur ou terminez son déploiement.
waiting	La cible ne s’exécute pas, ou aucune de ses copies ne sert.	Démarrez la cible ; le lien se remet à servir de lui-même.
update required	Le nœud du consommateur ou de la cible exécute un démon Docker antérieur à 2.11.1.	Mettez à jour le démon Docker sur ce nœud.
error	Le lien n’a pas pu être établi ; le message en indique la raison.	Corrigez la cause ; Opfield retente le lien de lui-même.

Circulation du trafic

Chaque nœud Docker exécute un seul connecteur secure-link partagé pour tous ses liens. Le consommateur rejoint un petit réseau privé propre au lien, et le connecteur y répond à l’alias. Les réseaux de liens prennent leurs adresses dans une plage dédiée ; voir Connecteur partagé et réseaux de liens.

Même nœud : le connecteur transmet chaque connexion directement à la cible.
Nœuds différents : la connexion transite par Relay jusqu’au nœud de la cible, authentifiée aux deux extrémités, comme pour tout autre Secure Link.

Un lien ouvre exactement un port de la cible, dans un seul sens : le consommateur peut joindre ce port, et rien d’autre de la cible. La cible ne peut pas joindre le consommateur via le lien, et les autres charges de travail ne peuvent pas l’utiliser. Le réseau du lien n’appartient qu’au lien.

Cibles Availability

Lorsque la cible s’exécute sous Workload Availability, le lien suit les copies saines :

chaque nœud consommateur privilégie une copie située sur son propre nœud et utilise sinon une autre copie saine ;
lorsqu’Availability juge une copie défaillante, le lien déplace immédiatement ses connexions vers une copie saine ;
une copie qui se rétablit ne récupère le trafic du lien qu’une fois qu’Availability la signale de nouveau comme réussissant ses vérifications de santé ; une copie redémarrée dont la santé n’est pas encore connue ne compte pas comme réussie ;
lorsqu’aucune copie n’est saine, le lien reste sur les copies qui servent encore, comme le font les routes d’Availability.

Un Deployment Availability est joint via son routeur, qui ne transmet que les ports propres au Deployment. Le port du lien doit donc être l’un des ports du Deployment ; sinon, le lien est refusé à sa création, ou passe en error avec la raison lorsque les ports du Deployment changent.

Dépannage

Le consommateur ne parvient pas à résoudre l’alias : vérifiez que le lien est ready et que l’application utilise l’alias, et non le nom du conteneur cible.
Les connexions sont refusées : vérifiez que la cible écoute sur le port du lien à l’intérieur de son conteneur, et que le port du lien est le port du conteneur, et non un port de l’hôte.
update required : mettez à jour le démon Docker sur le nœud indiqué par le message ; rien d’autre n’a besoin de changer.
waiting : la cible est arrêtée, ou aucune copie Availability ne sert ; démarrez ou rétablissez la cible.