Tres réplicas de proxy detrás de una única puerta de traducción pueden seguir exponiendo una sola salida pública. Las direcciones privadas de los contenedores no determinan la identidad visible en el destino.

client → published service → proxy replica → egress/NAT → destination

Siga el dibujo en dos partes. El servicio publicado elige cómo llega un cliente a una réplica. La ruta de salida y el NAT eligen la dirección de origen de la conexión posterior de esa réplica.

La malla de enrutamiento de Docker Swarm acepta tráfico en un puerto de servicio publicado y lo envía a una tarea activa. Eso admite la distribución de entrada y los cambios de ubicación de tareas; no asigna una salida pública distinta a cada réplica.

Si se necesitan salidas distintas, diseñe sus rutas y direcciones reales, como hosts enrutados por separado o puertas de salida asignadas, y luego cuente las identidades salientes observadas.

Sustituir una réplica también sustituye sus flujos activos

Un túnel CONNECT establecido pertenece a un solo proceso de proxy. Otra tarea no puede recrear de forma transparente el estado TCP y TLS del destino cuando sustituye ese proceso. Planifique reconexiones y vacíe las conexiones de larga duración para el mantenimiento.

Lleve también la autenticación de clientes y las políticas de destino a las réplicas. La comprobación de puerto correcta de un balanceador es más estrecha que un cliente permitido que negocia el protocolo de proxy requerido. La capacidad, la identidad de salida y la supervivencia de las conexiones son requisitos separados que hay que evaluar.

Artículos relacionados