Una referencia de servicio que nunca se rompe, incluso antes de activar la red privada
El consejo habitual para las llamadas entre servicios es “usa el hostname interno, no el público” —razonable, hasta que los dos servicios terminan en hosts distintos, proveedores distintos o regiones distintas, y el hostname interno deja de resolverse. La mayoría de las plataformas resuelven esto obligándote a pensar en la topología de antemano. El enfoque de Railyard es hacer que la referencia se resuelva correctamente sin importar la topología, y cambiar lo que hay debajo a medida que la topología cambia.
Tres casos, una sola referencia
Cada app recibe <name>.railyard.internal, y a qué se resuelve ese nombre depende enteramente de dónde corre la otra app en relación a ella, no de nada que la app que llama tenga que saber:
- Mismo servidor: es un alias de la red de Docker, que resuelve directo al contenedor en su propio puerto. Sin configuración, sin red que armar.
- Servidor distinto, red privada apagada: la referencia sigue funcionando, solo que no es privada. Se resuelve a la dirección pública normal
https://de la app en vez de fallar del todo. Una referencia entre dos apps en servidores distintos se degrada a “funciona, pero por internet público”, en lugar de romperse. - Servidor distinto, red privada encendida: cada servidor del equipo se une a una malla WireGuard cifrada (
10.210.0.0/16), y el mismo nombre ahora se resuelve a donde sea que la app realmente corra, entre proveedores y regiones, enrutado por la malla en vez de por internet público.
Lo que vale la pena notar: una app que referencia ${{api.RAILYARD_PRIVATE_URL}} no cambia cuando cambia cualquiera de estas cosas. Mover api a otro servidor, conectar un servidor de un proveedor de nube totalmente distinto, activar la red privada por primera vez: la referencia sigue resolviéndose, solo que por un mecanismo distinto cada vez.
Por qué la degradación elegante gana sobre un requisito estricto
El diseño alternativo —la red privada es obligatoria, o las referencias simplemente fallan hasta que se configura— sería más “correcto” en algún sentido abstracto y peor en la práctica: un equipo chico con un solo servidor nunca necesita redes entre servidores, y no debería tener que configurar una malla WireGuard para desplegar dos apps que resultan estar en el mismo lugar. Que el fallback sea “sigue funcionando, por HTTPS público” en vez de “no funciona hasta que configures esto” significa que la misma configuración de app es válida el primer día con un servidor y sigue siendo válida después de escalar a cinco servidores en dos proveedores: nada que reescribir cuando crece la topología.
Qué cambia realmente al activarla
Servidores → Red privada → Activar (solo admin) es la única acción: cada servidor que ya está en el equipo se une a la malla, y los contenedores que ya están corriendo adoptan el nuevo resolver en su próximo despliegue o reinicio —no al instante, lo cual importa si una referencia es sensible a la latencia y en ese momento se está resolviendo por internet público. Desde ese punto, cada servidor que el equipo agregue después —en cualquier proveedor, en cualquier región— se une a la misma malla automáticamente, porque la malla es una propiedad del equipo, no algo que se configura servidor por servidor.
Referencia completa: Documentación de redes, Variables y secretos.