Enlaces entre contenedores

Un container link da a una carga de trabajo, el consumidor, acceso privado a un puerto TCP de otra carga de trabajo, el destino. El consumidor llega al destino como alias:port; el destino no necesita ningún puerto publicado y no se abre nada más. El consumidor y el destino pueden ser cada uno un Container, un Deployment o un servicio de Compose, en el mismo nodo Docker o en nodos distintos.

Usa un container link cuando una aplicación necesite llamar a un servicio interno de otra carga de trabajo, como una API, una cola o una caché, sin publicar ese servicio en el host ni compartir una red Docker entre ambas. Para las bases de datos gestionadas y el almacenamiento de objetos gestionado, usa en su lugar las vinculaciones de bases de datos y los enlaces de almacenamiento: además entregan las credenciales.

Requisitos

• Plan: Personal o superior. Los enlaces existentes siguen funcionando tras un cambio de licencia; crear un enlace requiere el plan vigente. Consulta Planes y derechos.
• Daemon de Docker: ambos nodos, el del consumidor y el del destino, necesitan el daemon de Docker 2.11.1 o posterior. Un enlace cuyo nodo ejecuta un daemon más antiguo muestra update required hasta que se actualiza el daemon.
• Permisos: en el consumidor, docker:containers:edit (docker:compose:manage para un servicio de Compose), más docker:containers:environment cuando el enlace define variables; en el destino, docker:containers:link (docker:compose:manage para un servicio de Compose). El responsable del destino concede docker:containers:link para que otras cargas de trabajo lleguen a él sin darles ningún otro acceso. Consulta la referencia de ámbitos.

Crea un enlace

1. Abre el consumidor: la pestaña Environment de un Container o un Deployment, o la pestaña Variables de un Compose Project.
2. En Links, selecciona Add link y después Container. Para un Compose Project, elige el Service consumidor.
3. Elige el Target type y la carga de trabajo de destino, en cualquier nodo Docker, y el Port TCP del destino que se va a abrir.
4. Revisa el Alias. Por defecto es el nombre del destino y es el nombre al que se conecta el consumidor: letras minúsculas, números y guiones, único entre los enlaces del consumidor.
5. Opcionalmente, rellena Environment variables para el host, el puerto o una URL (http://alias:port), por ejemplo API_HOST, API_PORT o API_URL. Definir variables recrea el consumidor una vez para que arranque con ellas; un enlace sin variables no reinicia el consumidor.
6. Guarda y espera a que el enlace muestre ready; después haz una petición real desde el consumidor a alias:port.

Incoming, en el bloque Links del destino, enumera las cargas de trabajo que llegan a él. Un enlace se elimina desde el bloque Links del consumidor; al eliminarlo desaparece el alias y, si el enlace definía variables, también se eliminan con una recreación más.

API y MCP

Acción	REST	MCP y asistente
Listar los enlaces de una carga de trabajo	GET /api/docker/container-links?nodeId=&type=&resourceId=&direction=outgoing|incoming	manage_container_link list
Crear un enlace	POST /api/docker/container-links	manage_container_link create
Leer un enlace y su estado de ejecución	GET /api/docker/container-links/{id} y /{id}/runtime	manage_container_link get_runtime
Eliminar un enlace	DELETE /api/docker/container-links/{id}	manage_container_link delete

Una carga de trabajo se identifica por su nodo, su tipo (container, deployment o compose_service) y su recurso: el nombre del contenedor, el ID del Deployment o <compose-project-id>:<service-name>. El estado de ejecución muestra las conexiones abiertas, las sesiones, el caudal y las conexiones rechazadas, igual que en los enlaces de bases de datos y almacenamiento.

Estados

Estado	Significado	Qué hacer
ready	El consumidor llega al destino.	Nada.
pending	El enlace está guardado; el consumidor lo toma en su siguiente arranque o despliegue.	Arranca el consumidor o termina su despliegue.
waiting	El destino no se está ejecutando o ninguna copia suya está sirviendo.	Arranca el destino; el enlace vuelve a servir por sí solo.
update required	El nodo del consumidor o del destino ejecuta un daemon de Docker anterior a la 2.11.1.	Actualiza el daemon de Docker en ese nodo.
error	No se pudo configurar el enlace; el mensaje indica el motivo.	Corrige la causa; Opfield reintenta el enlace por sí solo.

Cómo fluye el tráfico

Cada nodo Docker ejecuta un único conector de Secure Links compartido para todos sus enlaces. El consumidor se une a una pequeña red privada propia para el enlace, y el conector responde allí al alias. Las redes de enlace toman sus direcciones de un rango dedicado; consulta Conector compartido y redes de enlace.

• Mismo nodo: el conector pasa cada conexión directamente al destino.
• Nodos distintos: la conexión viaja a través del Relay hasta el nodo del destino, autenticada en ambos extremos, como cualquier otro Secure Link.

Un enlace abre exactamente un puerto del destino, en una sola dirección: el consumidor puede llegar a ese puerto y a nada más del destino. El destino no puede llegar al consumidor a través del enlace, y otras cargas de trabajo no pueden usarlo. La red de enlace pertenece solo al enlace.

Destinos con Availability

Cuando el destino se ejecuta con Workload Availability, el enlace sigue a las copias en buen estado:

• cada nodo consumidor prefiere una copia en su propio nodo y, si no la hay, usa otra copia en buen estado;
• cuando Availability considera que una copia está en mal estado, el enlace traslada sus conexiones a una copia en buen estado de inmediato;
• una copia que se recupera vuelve a recibir tráfico del enlace solo cuando Availability informa de que vuelve a superar sus comprobaciones de estado; una copia reiniciada cuyo estado aún no se conoce no cuenta como correcta;
• cuando ninguna copia está en buen estado, el enlace se queda en las copias que siguen sirviendo, igual que las Routes de Availability.

A un Deployment con Availability se llega a través de su router, que solo reenvía los puertos propios del Deployment. Por tanto, el puerto del enlace debe ser uno de los puertos del Deployment; de lo contrario, el enlace se rechaza al crearlo o pasa a error con el motivo cuando cambian los puertos del Deployment.

Solución de problemas

• El consumidor no puede resolver el alias: comprueba que el enlace está ready y que la aplicación usa el alias, no el nombre del contenedor de destino.
• Se rechazan las conexiones: comprueba que el destino escucha en el puerto del enlace dentro de su contenedor y que el puerto del enlace es el puerto del contenedor, no un puerto del host.
• update required: actualiza el daemon de Docker en el nodo que indica el mensaje; no hace falta cambiar nada más.
• waiting: el destino está detenido o ninguna copia de Availability está sirviendo; arranca o repara el destino.