Publica una aplicación de principio a fin

Este recorrido lleva un artefacto de aplicación aprobado hasta un endpoint HTTPS público: la carga de trabajo, su comprobación de estado, el dominio y el certificado TLS, la Route y la prueba de aceptación.

El resultado buscado es un servicio que esté en buen estado desde la perspectiva del usuario, accesible a través del dominio previsto, observable en Opfield, protegido por la política de acceso esperada y reversible sin reconstruir el plano de control.

Si es tu primer despliegue, prepara un nodo Docker, revisa los modelos de recursos de Docker y ten a mano Publica tu primera Route para el paso del tráfico entrante.

Decide el modelo de carga de trabajo

Elige el recurso que corresponda a la propiedad del ciclo de vida:

• Usa un Container para un servicio independiente sencillo en el que la sustitución sea una operación explícita de recreación.
• Usa un Deployment cuando se requieran un despliegue blue/green con comprobación de estado y un slot de reversión conservado.
• Usa un Compose Project cuando varios servicios, redes y volúmenes formen una sola aplicación y deban pasar por un único ciclo de vida de revisiones inmutables.

No modeles una aplicación de varios servicios como contenedores independientes sin relación solo para que cada hijo se pueda editar directamente. Eso descarta la propiedad del proyecto y hace más difícil razonar sobre la reversión, la deriva y los cambios dependientes.

Antes de continuar, aprueba el digest exacto de la imagen o el commit de Git, los límites de recursos esperados, los orígenes de los secretos, la política de copias de seguridad de los volúmenes, las dependencias de bases de datos, el endpoint de estado, el nombre de host público y el destino de reversión.

1. Prepara la capacidad y la propiedad

Registra o selecciona un nodo Docker en línea para la carga de trabajo y un nodo Ingress en línea para el tráfico público. Confirma que cada nodo tiene el rol correcto, una versión compatible, las capacidades necesarias y margen suficiente. Que un nodo esté en verde no demuestra que una imagen grande quepa en el disco ni que un puerto solicitado esté disponible.

Asigna los ámbitos antes de la versión. El desarrollador puede necesitar visibilidad del código y de los builds, el operador de la plataforma acceso al ciclo de vida de la carga de trabajo y el operador del tráfico entrante acceso a las Routes. Evita conceder el rol de administrador del sistema solo porque el flujo de trabajo abarque varios tipos de recursos.

Para las cargas de trabajo con estado, confirma dónde están los datos persistentes y cómo se restauran. La reversión de un Deployment cambia el entorno de ejecución de la aplicación; no deshace las escrituras en la base de datos ni repara un volumen modificado por la nueva versión.

2. Crea o conecta la carga de trabajo

Crea el Container, el Deployment o el Compose Project elegido. Configura el digest inmutable de la imagen o el origen Git aprobado, el comando, el entorno, los secretos protegidos, el comportamiento de reinicio, los límites de recursos y los volúmenes gestionados.

Prefiere volúmenes gestionados o almacenamiento externo aprobado explícitamente. Los bind mounts del host atan la carga de trabajo a un host y no son portables mediante los flujos normales de archivo o migración. No pongas secretos en valores de entorno ordinarios, en el código de Compose, en argumentos de build ni en etiquetas de imagen.

Si la aplicación usa una base de datos, crea la vinculación antes de la validación final de la versión para que se pruebe la misma configuración de ejecución. Una vinculación gestionada da a la carga de trabajo una identidad dedicada en la base de datos y puede requerir una recreación o un despliegue normales para aplicar su entorno y su red privada.

3. Demuestra el estado de la aplicación antes del tráfico público

Define el estado en términos relevantes para el usuario. Que un proceso esté presente o que un puerto TCP acepte conexiones es una prueba más débil que un endpoint HTTP que confirma que la aplicación y sus dependencias críticas están listas.

Para un Deployment, configura la ruta de estado, el rango de códigos esperado, la coincidencia opcional del cuerpo, el tiempo de espera, el intervalo y el umbral de lentitud. Mantén disponible el slot anterior hasta que el nuevo haya superado la comprobación de estado y la verificación externa. Para un Container o un servicio de Compose, inspecciona el estado de ejecución real, los logs y la respuesta de la aplicación antes de crear la Route pública.

No enrutes tráfico de producción a una aplicación que todavía está migrando datos salvo que la estrategia de migración lo admita explícitamente. Las migraciones largas o destructivas necesitan su propio plan de reversión y de compatibilidad.

4. Prepara el dominio y TLS

Crea o selecciona el dominio, colócalo en el nodo Ingress previsto y asegúrate de que el DNS autoritativo apunta a su dirección de servicio pública. Emite, importa o selecciona un certificado que cubra el nombre de host exacto o un comodín adecuado.

La separación de la propiedad ayuda aquí: cambiar el DNS no debería requerir cambiar la carga de trabajo, y revertir la carga de trabajo no debería requerir sustituir el certificado. Confirma quién renueva los certificados subidos y quién recibe las notificaciones de caducidad.

5. Crea la Route

Crea una Route para el dominio y selecciona la carga de trabajo gestionada como su upstream. Para un Container Docker, un servicio de Compose o un Deployment, Opfield puede establecer un Secure Link para que el tráfico entrante llegue a la carga de trabajo a través de Relay sin un puerto de la aplicación publicado en el host solo para esta ruta.

Elige el puerto de la aplicación y el esquema del upstream que realmente sirve la carga de trabajo. Activa TLS público y Force HTTPS según sea necesario. Activa WebSockets, el comportamiento de prefijos, cambios de búfer, tiempos de espera personalizados o plantillas personalizadas solo cuando el contrato de la aplicación lo requiera; cada excepción amplía la superficie que hay que probar.

Espera a que la configuración de la Route y de Ingress se concilien correctamente. No edites directamente la configuración de nginx generada: Opfield es la fuente de verdad y concilia el estado gestionado.

6. Prueba de aceptación

Camino del usuario

• El DNS se resuelve correctamente desde una red externa.
• TLS es de confianza y cubre el nombre de host.
• La página principal o el endpoint de la API devuelven la versión esperada.
• El inicio de sesión, los callbacks, las subidas, el streaming y los WebSockets funcionan cuando corresponde.
• Las respuestas de mantenimiento y de acceso denegado son intencionadas y tienen la imagen esperada.

Camino de la plataforma

• La carga de trabajo informa del digest o el commit aprobados.
• El estado de ejecución, los logs y el uso de recursos son estables.
• El estado de la Route y del Secure Link es correcto.
• Los logs de acceso y de errores de Ingress muestran las peticiones de aceptación sin fallos repetidos del upstream.
• Un reinicio de la carga de trabajo no pierde los datos persistentes ni la configuración de la vinculación.
• Las notificaciones llegan al responsable esperado para un evento de prueba controlado.

Camino de gobierno

• Los usuarios con el mínimo privilegio solo pueden operar los recursos que tienen asignados.
• La versión, el cambio de la Route y las operaciones relacionadas aparecen en Tasks o en la actividad reciente y en el historial de auditoría.
• La cobertura de las copias de seguridad incluye los volúmenes con estado y las dependencias externas, no solo la definición del contenedor.

7. Reversión y límite del incidente

Registra el último destino que se sabe que funciona antes de la promoción. Para un Deployment, verifica que el slot anterior sigue en buen estado. Para un Container, conserva el digest inmutable anterior de la imagen y la configuración. Para Compose, conserva la revisión inmutable anterior. Para la entrega desde Git, conserva el build aprobado y el commit exacto del código.

Si la versión falla pero el tráfico entrante está en buen estado, revierte la carga de trabajo en lugar de eliminar el dominio, el certificado o la Route. Usa el mantenimiento de la Route cuando haya que detener el tráfico conservando el recurso y su configuración. Si una migración ya ha cambiado los datos, revertir solo la aplicación puede no ser seguro; sigue el plan de recuperación de datos.

Tras la reversión, repite las pruebas de cara al usuario e inspecciona los logs en busca de peticiones que puedan haber llegado a la revisión fallida. Conserva el artefacto fallido y las pruebas de la operación hasta que termine la revisión del incidente.

Mapa de diagnóstico

Síntoma	Comprueba primero	Guía detallada
La carga de trabajo nunca está lista	Task propietario, logs de la aplicación, puerto y comprobación de estado	Visión general de Docker
La Route no se publica	DNS, TLS, aplicación en nginx, estado de la Route y upstream	Solución de problemas del tráfico entrante
El Secure Link no está disponible	Ambos nodos, Relay, carga de trabajo de destino y operación del conector	Upstreams seguros
La nueva versión está en mal estado	Revierte la carga de trabajo propietaria; deja la Route intacta	Deployments blue/green
Una migración cambió los datos	Detén las escrituras y sigue el plan de recuperación de datos aparte	Actualizaciones y copias de seguridad