Dar a un contenedor su propia dirección en la red: qué ganas, qué pagas

La disposición por defecto es esta: el contenedor comparte la dirección de la máquina y tú llegas a él por un número de puerto. Es simple, es seguro y para la mayoría del trabajo basta.

Hay casos en que no basta, y son previsibles.

Cuándo un número de puerto no basta

Dos aplicaciones quieren el mismo número. Mueves una a otro número, y luego los enlaces que esa aplicación genera por su cuenta no llevan ese número y las cosas se enredan.

La aplicación se anuncia en la red. Encontrar impresoras, encontrar reproductores, encontrar dispositivos de casa inteligente: eso funciona con mensajes que se anuncian solos. Esos mensajes no sobreviven al mapeo de puertos. La aplicación se anuncia, pero la dirección que anuncia es la de la máquina, y el otro lado no llega a ella.

Quieres ver la aplicación en la lista de dispositivos del router. Para darle una dirección fija, escribir una regla de cortafuegos aparte, ver su tráfico por separado. Con mapeo de puertos esa aplicación no existe para la red; solo existe la máquina.

El otro camino: darle al contenedor su propia identidad

El contenedor aparece en la red con su propia dirección de hardware, toma su propia dirección del router y figura en la lista de dispositivos como un aparato físico.

La primera reacción suele ser "por qué no lo hace todo el mundo así". La respuesta está en el precio.

Precio uno: la máquina no llega a su propio contenedor

Esta es la parte que más sorprende, y suele descubrirse con el trabajo ya terminado.

Todos los dispositivos de la red llegan a ese contenedor. La máquina que lo aloja no.

La razón tiene sentido: ambos usan la misma interfaz física, y el tráfico no vuelve desde el conmutador. La máquina envía el paquete fuera, y el paquete no regresa a su propia tarjeta.

Las consecuencias son cotidianas: una comprobación de salud que corre en la máquina no llega a la aplicación, otro contenedor de la misma máquina no puede conectarse, un script que escribiste no funciona. Todo eso mientras la red parece impecable vista desde fuera.

Hay solución, pero es una pieza extra: abrir en la máquina una segunda interfaz virtual conectada a la misma tarjeta y pasar por ahí la ruta hacia la dirección del contenedor. Una vez instalada el problema desaparece, pero como es un añadido, si se olvida nadie entiende nada.

Precio dos: gastas una dirección real

Cada contenedor consume una dirección de tu red. Diez aplicaciones son diez direcciones. En una red pequeña llegas al límite enseguida.

Además, si la dirección es un préstamo puede cambiar. Cuando cambia, todo lo que estaba fijado a ella, incluida una regla que escribiste, apunta en silencio al sitio equivocado.

Precio tres: la tarjeta de red y el cortafuegos

La tarjeta tiene que aceptar más de una dirección de hardware. La mayoría de las conexiones inalámbricas no lo hacen, y algunos entornos virtuales vienen con eso desactivado. No decidas sin probar.

Y tu cortafuegos ahora ve en la red un dispositivo que no conoce. Para ti es un contenedor; para quien escribe las reglas es un aparato normal. No es un problema, pero si se deja sin decir, algún día confundirá a alguien.

Con la dirección no basta, también hace falta un nombre

Una aplicación con dirección y sin nombre es la mitad de la ganancia. Nadie quiere memorizar una dirección.

Para que el nombre se anuncie en la red, algo tiene que hacer ese trabajo. La propia imagen de la aplicación normalmente no lleva esa pieza, y no hay razón para que la lleve: una imagen de base de datos no tiene por qué anunciarse en una red.

La regla

Un mapeo de puertos le da número a una puerta. Una identidad de red concede ciudadanía.

Concede la ciudadanía solo cuando la red tenga que tratar de verdad a esa aplicación como un dispositivo. Si no, un número de puerto es a la vez más simple y más seguro.

Qué hace Atlas

Al montar esto, Atlas no toca la imagen propia de la aplicación. Abre a su lado un pequeño ayudante, y el ayudante comparte la pila de red de la aplicación. El ayudante es quien pide la dirección al router y quien anuncia el nombre en la red.

Ese enganche es deliberado y aporta dos cosas. La imagen de la aplicación no necesita llevar ni un cliente de direcciones ni un anunciador de nombres. Y como la pila de red pertenece a la aplicación, cuando la aplicación se detiene el ayudante cae con ella, sin dejar atrás un contenedor huérfano.

Para el problema de que la máquina no llega a su propio contenedor se instala el puente descrito arriba, y se instala como servicio, de modo que se reconstruye cuando la máquina reinicia.

Lo que de verdad merece contarse es un fallo hallado en ese puente durante una prueba en condiciones reales.

El puente abría una ruta hacia la dirección del contenedor. Pero no borraba la ruta de un contenedor desaparecido. Tras un reinicio, la ruta de una dirección temporal se había quedado colgando. La consecuencia: si más tarde otro dispositivo toma esa dirección, el tráfico destinado a él se desvía al puente. Así que el fallo no golpea al contenedor, golpea a un tercero inocente de la red.

La corrección fue dejar de que el puente sea algo que solo añade rutas, y hacerlo algo que borra las rutas que ya no corresponden a un contenedor vivo.

La lección general vale también fuera de la red: añadir es la mitad fácil. Una ruta, una regla, un mapeo es una afirmación que haces sobre el mundo. Cuando el mundo cambia, una afirmación que nadie retiró se convierte en mentira, y suele golpear no a ti sino a alguien que no tiene nada que ver contigo.