Publica tu primera Route

Una Route conecta uno o varios nombres de host públicos con una aplicación a través de un nodo Ingress. En el caso sencillo, eliges el dominio, la aplicación y el puerto, activas TLS y guardas; Opfield genera la configuración de nginx y la aplica en el nodo Ingress.

El criterio de éxito es una petición HTTPS que se resuelve al nodo Ingress asignado, presenta el certificado previsto, llega a la aplicación prevista y sigue siendo observable y reversible. No consideres que un formulario guardado es una publicación correcta.

Entiende los recursos implicados

Opfield mantiene separadas las responsabilidades:

• Un Domain registra el nombre de host y su ubicación en Ingress.
• Un SSL Certificate proporciona el material TLS y es responsable de la renovación.
• Una Route define el reenvío, el acceso, el mantenimiento y el comportamiento de estado.
• Un upstream es la aplicación que recibe la petición. Puede ser una dirección introducida a mano, un recurso Docker gestionado por Opfield al que se llega a través de un Secure Link, o un despliegue de Pages seleccionado mediante un Tag.

Esta separación te permite cambiar la revisión de una aplicación sin volver a crear el DNS ni el certificado. También significa que las cuatro piezas deben concordar antes de que la Route esté lista para producción.

Antes de crear la Route

Confirma que:

• un nodo Ingress está Online, es responsable de la dirección de servicio pública prevista y puede aceptar los puertos 80/443 cuando sea necesario;
• la aplicación existe y responde en el esquema y el puerto seleccionados;
• el nombre de host está aprobado y su responsable de DNS está disponible;
• hay un certificado coincidente activo o un camino claro para emitirlo;
• el operador tiene permiso para crear el dominio, seleccionar el certificado y crear la Route;
• se conocen la ruta de comprobación de estado esperada, el código de respuesta, si se necesitan WebSockets, los límites de las peticiones y la política de acceso.

Si el upstream es privado, decide si la Route debe usar un Secure Link gestionado por Opfield. Un Secure Link transporta el tráfico por el plano de datos de Relay sin publicar un puerto normal del host solo para el tráfico entrante. No repara una aplicación en mal estado ni elude la propiedad de la carga de trabajo.

Publica la Route

1. Abre Routes, luego la pestaña Domains, y añade el nombre de host.
2. Asígnalo al nodo Ingress que recibirá el tráfico público.
3. Configura el DNS mediante la integración con Cloudflare o crea el registro DNS externo necesario. Espera a que la respuesta autoritativa apunte a la dirección de servicio prevista.
4. Abre Certificates, luego la pestaña SSL, y emite, importa o selecciona un certificado que cubra el nombre de host exacto o un comodín adecuado.
5. Abre Routes y elige Add Route.
6. Selecciona el dominio y el destino del reenvío. Para un destino Docker gestionado, selecciona el recurso y el puerto de la aplicación; Opfield es responsable del ciclo de vida del Secure Link.
7. Selecciona HTTP o HTTPS para el upstream según lo que la aplicación sirva realmente. Este ajuste es independiente de la terminación TLS pública.
8. Activa TLS público y selecciona el certificado. Activa Force HTTPS cuando el HTTP sin cifrar deba redirigir en lugar de servir contenido.
9. Activa la compatibilidad con WebSocket solo cuando la aplicación use conexiones con upgrade. Aplica una Access List, una política de límite de peticiones o una plantilla personalizada solo cuando el servicio lo requiera y se sepa que la plantilla es compatible.
10. Guarda la Route y espera a que Opfield genere, valide y aplique la configuración de nginx.

Verifica el resultado

Comprobaciones de cara al usuario

• El DNS público se resuelve a la dirección de Ingress asignada desde más de una red.
• La respuesta HTTPS presenta un certificado de confianza que cubre el nombre de host.
• Se devuelve la página de la aplicación o la respuesta de la API esperada.
• HTTP redirige a HTTPS cuando Force HTTPS está activado.
• El inicio de sesión en el navegador, los callbacks, las respuestas en streaming y los WebSockets funcionan cuando la aplicación los usa.

Comprobaciones en Opfield

• La Route está activada y su estado coincide con una comprobación directa de la aplicación.
• El destino mostrado es el recurso y el puerto que querías, no un contenedor obsoleto ni una dirección manual.
• El nodo Ingress informa de una configuración de nginx aplicada y válida.
• Los logs de acceso y de errores muestran la petición de prueba y ningún fallo repetido del upstream.
• El Secure Link está en buen estado cuando el destino lo usa.
• La Access List y los límites de peticiones admiten y rechazan a los clientes esperados.

Una respuesta correcta de la aplicación no demuestra que la política sea correcta. Prueba un camino permitido y otro denegado cuando haya controles de acceso, y prueba una conexión WebSocket en lugar de solo el handshake HTTP inicial.

Modos de fallo y recuperación

El DNS se resuelve de forma incorrecta: corrige el registro autoritativo y espera a que caduquen las cachés con normalidad. No cambies el destino de la Route para compensar un error de DNS.

Se rechaza el certificado: verifica la cobertura del nombre de host, la cadena, el periodo de validez y el despliegue en el nodo Ingress seleccionado. No desactives la verificación TLS en los clientes como solución provisional.

Opfield no puede aplicar la configuración de nginx: inspecciona el error de validación antes de reintentar. Una plantilla personalizada, una opción incompatible, un nombre de host duplicado o un destino gestionado no disponible pueden hacer que la configuración deseada no sea válida. Opfield sigue siendo responsable del último estado aplicado; corrige la entrada en lugar de editar directamente los archivos de nginx generados.

El destino del Secure Link no está disponible: verifica que la carga de trabajo y los nodos implicados están en línea y que Relay está en buen estado. Publicar un puerto del contenedor como solución de emergencia cambia el modelo de seguridad y debe ser un cambio deliberado y revisado.

Hay una versión defectuosa en producción: activa el mantenimiento de la Route cuando corresponda o devuelve el upstream al último Deployment, digest de imagen, revisión de Compose o Pages Tag que se sabe que funcionaba. Normalmente no hace falta eliminar la Route ni el certificado para revertir una aplicación.

Para una explicación más detallada de los destinos privados, continúa con Upstreams seguros. Para un flujo completo desde la carga de trabajo hasta la URL pública, usa Publica una aplicación.