Visión general de Docker

En Opfield, una carga de trabajo Docker es un recurso, no solo un contenedor en ejecución. El recurso guarda su configuración, las concesiones de acceso, el historial de ciclo de vida, las relaciones y el estado deseado, y Opfield concilia ese estado tras una interrupción.

Elige el ciclo de vida de nivel más alto que se ajuste a la aplicación:

Container: un entorno de ejecución gestionado directamente, con una configuración y un ciclo de vida concretos.
Deployment: una identidad de aplicación estable con dos slots de ejecución para versiones blue/green condicionadas al estado y con reversión.
Compose Project: una aplicación externa descubierta o una aplicación de un solo nodo gestionada por Opfield, con configuración validada, revisiones inmutables, operaciones de ciclo de vida, logs, Routes y vinculaciones de bases de datos.
Origen Git: una entrada de entrega para Containers, Deployments y Pages. No es una entidad de aplicación separada.

Workload Availability (HA) está disponible en Business y Enterprise para los Containers, Deployments y Compose Projects completos que cumplan los requisitos y no tengan montajes. Añade a la identidad del recurso existente una replicación con un número fijo de copias o una conmutación por error con una sola copia sirviendo entre nodos Docker independientes.

Elige el modelo operativo

La decisión trata sobre todo de propiedad y recuperación, no del número de campos de un formulario.

Necesidad	Modelo recomendado	Contrapartida principal
Un servicio con un ciclo de vida sencillo	Container	Directo y flexible, pero las versiones y la reversión las gestiona el operador
Versiones condicionadas al estado con un candidato de reversión conservado	Deployment	Mayor seguridad en las versiones, con dos slots de ejecución gestionados
Varios servicios que deben cambiar como una sola aplicación	Compose Project	Un único límite de revisión y operación, un nodo por ubicación; Availability opcional del proyecto completo en Business/Enterprise
Artefactos reproducibles desde el control de código fuente	Origen Git más un recurso propietario	Añade la procedencia del build; la seguridad del despliegue sigue viniendo del Container, el Deployment, Compose o Pages

Elige el propietario de nivel más alto que represente cómo debe cambiarse la aplicación durante una versión normal y cómo debe recuperarse durante un incidente. No modeles una aplicación de varios servicios como Containers sin relación solo para evitar Compose, y no elijas Deployment cuando la aplicación tenga un estado compartido con escritura que no pueda existir de forma segura entre los slots de versión.

El responsable de la plataforma debe definir quién es responsable del recurso de la aplicación, de sus datos, de sus Routes públicas, de su acceso a registros y de la decisión de reversión. Opfield registra y aplica esos límites, pero no puede decidir si una migración de datos a nivel de aplicación es reversible.

Límites de propiedad

Opfield es responsable de los metadatos y del estado deseado de los recursos que crea o adopta. El daemon de Docker de destino es responsable del proceso en ejecución, de la caché de imágenes, de la implementación del almacenamiento local y de la conexión de red. Por tanto, un recurso gestionado puede no estar disponible mientras su estado deseado sigue registrado; la recuperación empieza por restablecer la conectividad del daemon o del nodo y dejar después que Opfield concilie.

Algunos objetos de Docker pertenecen a un propietario de nivel superior. Los slots de un Deployment se controlan a través de su Deployment, y los contenedores con etiquetas de Compose se agrupan en el contexto del proyecto descubierto. No modifiques los hijos gestionados por su propietario a través de un ciclo de vida independiente: los cambios directos pueden crear deriva entre el estado real del daemon y la configuración registrada en Opfield.

Los contenedores que Opfield no creó también son visibles y operables. Un contenedor independiente iniciado con docker run se puede reiniciar e inspeccionar con permisos limitados por recurso sin adoptarlo, mientras que un proyecto Compose externo sigue siendo de solo lectura hasta que se adopta. Consulta Contenedores que Opfield no creó y Adopta un proyecto externo.

Los recursos internos gestionados por Opfield pueden incluir etiquetas, nombres de ejecución, redes, volúmenes, credenciales, artefactos de build y registros de Tasks. Trátalos como detalles de implementación salvo que una acción de Opfield los exponga explícitamente. Eliminarlos o renombrarlos con las herramientas de Docker puede romper la conciliación, el enrutamiento o una reversión futura.

Cómo se realiza el trabajo de ciclo de vida

Los cambios de larga duración se representan como Tasks u operaciones. Una operación registra la intención, avanza por el trabajo del daemon y termina con un resultado de éxito o fallo que se puede inspeccionar después. Iniciar una segunda acción en conflicto mientras hay una activa puede rechazarse o aplazarse; espera a que termine la operación actual antes de reintentar.

Antes de cambiar una carga de trabajo, revisa sus Routes dependientes, las vinculaciones de bases de datos, las concesiones, los volúmenes montados, los ajustes de origen y la política de reinicio. Antes de eliminarla, decide si sus datos y sus puntos de entrada públicos deben conservarse en otro lugar. Detener correctamente la ejecución no equivale a completar una eliminación.

Las cargas de trabajo llegan a las bases de datos de una de dos formas. Una base de datos gestionada se puede vincular a un Container, un Deployment o un servicio de Compose, y Opfield inyecta los valores de conexión de una identidad del motor dedicada. A una base de datos externa se llega mediante valores de conexión que guardas como secretos de la carga de trabajo. Consulta Bases de datos gestionadas y externas de un vistazo.

Secuencia de operación segura

Confirma que el nodo Docker seleccionado está en línea y tiene la capacidad de ejecución necesaria.
Inspecciona el propietario del recurso y los recursos relacionados antes de editar la configuración.
Haz un único cambio de ciclo de vida intencionado y sigue su Task hasta el final.
Verifica el estado, los logs de la aplicación y la Route o la conexión privada esperadas.
Conserva una imagen que se sepa que funciona o el slot anterior del Deployment hasta que pase la ventana de recuperación.

Si una operación falla, usa su diagnóstico para distinguir entre fallos de imagen, configuración, almacenamiento, puerto, permisos y conectividad del nodo. Corrige el requisito previo identificado y reintenta desde Opfield. No elimines objetos de Docker propiedad de Opfield como paso genérico de recuperación.

Criterios de éxito

Una carga de trabajo está lista cuando su estado deseado y el observado coinciden, la operación propietaria ha terminado, el estado y los logs son aceptables y la vía de acceso real funciona. Para las aplicaciones públicas, eso significa la Route; para las privadas, puede ser un Secure Link o una dependencia de base de datos. Un proceso en ejecución sin un acceso verificado no es un despliegue correcto.

Para cada carga de trabajo de producción, conserva un artefacto que se sepa que funciona, documenta los datos persistentes y quién es responsable de la recuperación, y define la ventana de reversión. Prueba la acción de recuperación antes de un incidente. Los detalles de los recursos para operadores y las reglas de limpieza se tratan en las páginas enlazadas a continuación.