Upstreams seguros

Un upstream seguro permite que una Route pública llegue a una carga de trabajo gestionada privada sin publicar el puerto del host de esa carga de trabajo. Un Secure Link es el transporte privado autenticado de Opfield entre el lado de Ingress y el lado de la carga de trabajo a través de Relay. La carga de trabajo no mantiene ningún puerto abierto en el host, y la Route sigue la identidad gestionada de la carga de trabajo a través de reinicios y recreaciones.

Úsalo cuando la aplicación deba ser pública solo a través del tráfico entrante de Opfield. La autenticación y el estado de la aplicación siguen siendo responsabilidad de la aplicación. La configuración está completa cuando la carga de trabajo no tiene ningún puerto público innecesario, el Link está listo y una petición real tiene éxito a través del nombre de host canónico.

Selecciona un destino Docker gestionado en el editor de la Route o de la Additional Route. Opfield valida la propiedad de la carga de trabajo, tu acceso al destino Docker y el servicio o puerto seleccionado, crea el Secure Link propiedad de la Route y concilia el estado del conector a través de Relay.

Las vinculaciones propiedad de una Route siguen el ciclo de vida de la Route. Se pueden inspeccionar, pero no eliminar por separado. Las vinculaciones adicionales gestionadas por el usuario están pensadas para configuraciones avanzadas de nginx y tienen su propio ciclo de vida.

Una vinculación adicional también puede apuntar a un almacenamiento de objetos gestionado listo (Managed S3 storage): S3 privado a través de Relay, sin una red Docker compartida ni un puerto S3 publicado. Los clientes siguen necesitando credenciales de S3. Haz referencia a ella en la configuración avanzada como {{additionalSecureLinks.<name>}}, que ya incluye el esquema, por ejemplo proxy_pass {{additionalSecureLinks.<name>}};; una vinculación a la que la configuración avanzada todavía hace referencia no se puede eliminar. Para crearla se necesita acceso de edición a la Route y acceso de visualización al almacenamiento, y el almacenamiento gestionado no puede ser el upstream principal de una Route.

Verifica el estado del conector, el estado de la Route y el comportamiento de la aplicación. Cuando se recrea una carga de trabajo, Opfield vuelve a conectar el enlace por la identidad estable del recurso. Cuando se elimina una Route, Opfield retira la vinculación que le pertenece.

No sortees un enlace fallido publicando un puerto interno de la carga de trabajo hasta entender el fallo. Comprueba primero el estado de Relay, las conexiones de ambos nodos, la identidad del destino, la autorización del ámbito y los logs del conector.

Requisitos previos

• Los nodos Ingress y Docker están en línea y son compatibles con el contrato actual de Relay.
• El Container, Deployment o servicio de Compose de destino es propiedad de Opfield y tiene una identidad de recurso estable.
• El puerto de aplicación seleccionado es el puerto en el que realmente escucha el proceso, no un puerto publicado del host sin relación.
• Quien hace la llamada puede leer el destino y modificar la Route.
• Relay está en buen estado y ambos nodos pueden llegar a su endpoint de Relay asignado.

Crea un upstream gestionado

1. Abre el editor de la Route o de la Additional Route.
2. Elige el tipo de destino Docker gestionado.
3. Selecciona el nodo y el recurso en lugar de escribir una dirección efímera de contenedor.
4. Selecciona el servicio o el puerto de la aplicación y el protocolo. Con un daemon de Docker 2.11, el diálogo rellena el puerto en el que realmente escucha el contenedor, también para imágenes que no declaran ningún puerto (sin EXPOSE); los daemons más antiguos solo ofrecen los puertos declarados.
5. Guarda la Route y espera tanto a la conciliación del Secure Link como a la validación de la configuración de nginx.
6. Verifica la insignia del destino, la telemetría de Link Runtime, el estado de la Route y una petición externa.

El contenedor conector que se usa para el tráfico de nginx a la carga de trabajo es propiedad de Opfield. Está oculto a las operaciones de ciclo de vida ordinarias y se publica junto con Relay. Recrear la carga de trabajo de la aplicación no debe transferir la propiedad de ese conector ni requerir una Route nueva.

Comportamiento del ciclo de vida

• Reiniciar o recrear la carga de trabajo mantiene el enlace, porque la Route apunta al recurso estable de Opfield.
• La promoción de un Deployment actualiza la carga de trabajo activa detrás de la misma identidad de Deployment.
• Al aplicar Compose, el servicio seleccionado se resuelve a partir de la revisión activa del proyecto.
• Desactivar una Route deja de servirla, pero conserva su configuración y la relación de propiedad.
• Eliminar una Route retira, tras la conciliación, la vinculación que le pertenece.
• Una vinculación adicional gestionada por el usuario tiene un ciclo de vida independiente y debe eliminarse explícitamente. Su eliminación se rechaza mientras la configuración avanzada o en bruto de la Route, o la configuración avanzada de una Additional Route, sigan haciendo referencia a ella, ya sea mediante su variable {{additionalSecureLinks.<name>}} o por su nombre de upstream generado.

Diagnóstico de fallos

Si la Route se guarda pero el tráfico falla, comprueba en este orden:

1. que la Route está activada y no está en mantenimiento;
2. que la revisión de la configuración de nginx está aplicada;
3. la disponibilidad de Relay;
4. la conectividad de los nodos Ingress y Docker;
5. el estado de ejecución del recurso de destino y el puerto seleccionado;
6. el estado del conector del Secure Link y los errores de admisión;
7. los logs de la aplicación y el comportamiento del protocolo.

Publica un puerto del host solo cuando el acceso público o directo sea en sí mismo un requisito del producto, no como un mecanismo de recuperación sin documentar.

Implicaciones de seguridad y propiedad

Un upstream gestionado evita exponer la carga de trabajo en un puerto ordinario del host, pero no hace que la aplicación sea fiable automáticamente. La Route sigue definiendo el límite de las peticiones públicas, nginx sigue terminando o reenviando el protocolo seleccionado y la aplicación debe autenticar las peticiones cuando su contrato de producto lo exija. El Secure Link protege el transporte privado y la selección del destino; no es una capa de autorización de la aplicación.

El conector generado y sus credenciales son propiedad de Opfield. Los operadores no deben recrear, renombrar, adjuntarse a ese conector ni usarlo a través de las API ordinarias de ciclo de vida de Docker. El acceso al recurso de la carga de trabajo no concede la propiedad del recurso de transporte. Esta separación impide que un operador de cargas de trabajo sustituya la imagen del conector o lea material de transporte que pertenece al plano de control.

Concede a los usuarios solo los ámbitos de Route y de carga de trabajo que necesiten para su trabajo. Alguien que puede modificar tanto la Route pública como la carga de trabajo de destino puede redirigir el tráfico de producción aunque no tenga acceso directo a las interioridades del conector, así que trata esa combinación de permisos como autoridad de despliegue en producción.

Procedimiento de cambio y recuperación

Antes de recrear o promover un destino, registra la Route, el recurso estable seleccionado, el puerto de la aplicación y el estado actual del enlace. Haz la operación sobre la carga de trabajo a través de su propietario, espera a que el nuevo entorno de ejecución esté listo y confirma después que el Secure Link se ha conciliado con la misma identidad estable. Verifica una petición externa; una insignia verde en la carga de trabajo no demuestra por sí sola que la ruta de la Route funcione.

Si la conciliación sigue fallando cuando ambos nodos y Relay están en buen estado, conserva la operación fallida y los logs del conector y reintenta después la acción de conciliación compatible. Recrear la Route es el último recurso, porque cambia la propiedad y elimina un historial útil. Si el tráfico de los clientes debe seguir sin estar disponible durante la reparación, usa el modo de mantenimiento en lugar de publicar el puerto privado.