Visión general del tráfico entrante

Opfield usa nodos nginx gestionados como punto de entrada público. Un servicio público completo combina un dominio, un certificado, una Route, un upstream, una política de estado y la ubicación en un nodo.

Las Routes pueden hacer de proxy, redirigir o devolver 404. Los upstreams de proxy pueden ser direcciones manuales, contenedores independientes, Deployments, servicios de Compose o Pages Tags listos. Las Additional Routes asocian prefijos de ruta literales, como /api, a upstreams distintos.

Usa el modo nginx managed cuando Opfield deba ser responsable de una configuración base que se sabe que funciona. Usa el modo integrate cuando una instalación de nginx existente deba conservar su configuración base y cargar los includes gestionados por Opfield.

En la operación, verifica el DNS, la distribución de certificados, la validación de la configuración generada, el estado de la Route y el comportamiento público después de cada cambio de ubicación o de TLS. Una configuración no está completa solo porque se haya guardado correctamente.

Propiedad de los recursos

Los recursos de tráfico entrante tienen ciclos de vida separados, aunque aparezcan como una sola aplicación pública:

• un Domain es responsable del nombre de host y de la ubicación en nginx;
• un SSL Certificate es responsable del material del certificado y del estado de renovación;
• una Route es responsable del comportamiento de las peticiones, de la política de estado y de su upstream principal;
• una Additional Route es responsable de una sustitución por un prefijo de ruta literal;
• una Access List es una política reutilizable que se puede asociar a más de una Route;
• un Secure Link que pertenece a una Route sigue a la Route y no se puede eliminar por separado.

Eliminar un recurso no debe eliminar silenciosamente otro recurso reutilizable. Antes de eliminar, inspecciona los recursos vinculados y decide si la acción que buscas es desactivar, poner en mantenimiento, desvincular, migrar o eliminar de forma permanente.

Orden de creación recomendado

1. Registra y valida el nodo Ingress de destino.
2. Registra el dominio y confirma la ubicación prevista.
3. Emite o sube el certificado TLS.
4. Crea la Route y selecciona su upstream.
5. Añade política de acceso, cabeceras, WebSockets, reescrituras o ajustes de tiempo de espera solo cuando sea necesario.
6. Activa la Route y espera a que se valide la configuración de nginx.
7. Prueba HTTP y HTTPS desde un cliente externo.
8. Confirma el historial de estado, los logs de acceso y la distribución del certificado.

Reglas de operación segura

• Mantén un único responsable canónico para cada nombre de host; no crees fuera de Opfield Routes que compitan por el mismo host.
• Trata la configuración nginx en bruto como una vía de escape para expertos. Desactiva parte de la validación y de las funciones de ciclo de vida gestionadas.
• No publiques un puerto privado de una carga de trabajo solo porque un Secure Link esté temporalmente en mal estado.
• Usa el modo de mantenimiento para trabajos deliberados visibles para los clientes, y desactiva una Route solo cuando el tráfico deba detenerse por completo.
• Migra la ubicación con el flujo de trabajo explícito para que los dominios, las Routes, los certificados, el estado y los cambios de DNS sigan coordinados.

Responsabilidades de Opfield y del operador

Opfield valida y distribuye la configuración de nginx, sigue la ubicación deseada, gestiona los flujos de certificados compatibles y registra las operaciones que cambian el tráfico público. No controla un proveedor de DNS externo salvo que una integración configurada sea responsable de esa zona, no abre el cortafuegos de un upstream ni hace que una aplicación en mal estado esté lista. Esas dependencias siguen siendo responsabilidad del operador.

Esta distinción importa durante los incidentes. Un nodo Ingress en buen estado demuestra que el daemon y nginx están disponibles; no demuestra que el DNS público apunte a ese nodo, que todas las Routes tengan un upstream accesible ni que una red externa permita el tráfico. A la inversa, una comprobación de estado fallida de una aplicación no exige reconstruir el host de nginx. Diagnostica la cadena de recursos desde el nombre de host público hacia la aplicación y cambia solo la capa que ha fallado.

Para la propiedad en producción, registra quién puede cambiar el DNS, los certificados, las Routes, las Access Lists y las versiones de las aplicaciones. Mantén el acceso de emergencia a Opfield independiente del nombre de host de la aplicación que se está operando. Revisa los certificados y las Access Lists compartidos antes de cambiarlos, porque una sola edición puede afectar a varias Routes.

Aceptación en producción

Antes de declarar listo un nombre de host, verifícalo desde una red ajena a los hosts gestionados. Confirma las respuestas DNS, el comportamiento de redirección HTTP, la cadena de certificados HTTPS y el nombre de host, la respuesta esperada de la aplicación y el comportamiento de WebSocket cuando se use. Después compara esa petición con el historial de estado de Opfield y los logs de acceso de nginx.

Mantén disponible la ubicación DNS anterior o la revisión anterior de la aplicación durante un cambio, cuando sea posible. Si la aceptación falla, restaura el upstream o la ubicación que se sabe que funcionaba en lugar de eliminar los recursos nuevos. La eliminación borra el estado deseado y el historial de operaciones, que son útiles, y rara vez es la reversión más segura.

Continúa con Dominios, Routes y TLS para la configuración, Upstreams seguros para destinos privados de Docker y Solución de problemas del tráfico entrante para el diagnóstico de fallos.