Modelo de recursos y propiedad

Los recursos de Opfield tienen identidades estables, distintas de los nombres de ejecución cambiantes o de los ID de contenedor.

Identidades estables

Los permisos, las vinculaciones, los ajustes de origen, la configuración de estado, el historial de operaciones y el estado de las migraciones se asocian a la identidad de un recurso de Opfield. Los nombres de ejecución, los ID de proceso, los ID de contenedor, las direcciones IP y la ubicación pueden cambiar sin que se cree un nuevo recurso del producto. Esta distinción permite a Opfield recrear o mover los objetos de ejecución compatibles conservando las relaciones que los operadores configuraron intencionadamente.

Recrear una carga de trabajo gestionada conserva su identidad en Opfield y, por tanto, mantiene las relaciones compatibles con Routes, vinculaciones, concesiones y orígenes. Duplicar una carga de trabajo crea un recurso separado con su propio acceso e historial de ciclo de vida. La eliminación explícita borra las concesiones que pertenecen al recurso eliminado, de modo que un recurso posterior con el mismo nombre visible no hereda autoridad por accidente.

Usa los ID estables de recursos y operaciones para correlacionar respuestas de la API, Tasks, eventos, logs y registros de auditoría. Los nombres son para los operadores y pueden cambiar o coincidir entre nodos o carpetas. Que un nombre coincida no basta para demostrar que un objeto de ejecución recién observado sea el recurso que Opfield gestionaba antes.

Límites de propiedad

• Un Compose Project es propietario de los contenedores de sus servicios, sus volúmenes con nombre y sus redes no externas.
• Un Deployment blue/green es propietario de sus dos slots de ejecución y de su estado de despliegue.
• Una base de datos gestionada es propietaria de su contenedor de base de datos y de la identidad de propietario del motor.
• Una vinculación de base de datos es propietaria de una identidad de aplicación separada con el mínimo privilegio.
• Una Route o una Additional Route pueden ser propietarias de su vinculación de Secure Link.
• Los contenedores internos propiedad de Opfield quedan fuera de las API de ciclo de vida de los usuarios.

Estos límites impiden que una API de nivel inferior eluda el ciclo de vida de nivel superior que creó el recurso. Un hijo puede ser visible para el diagnóstico sin poder modificarse de forma independiente. Por ejemplo, los slots de un Deployment se inspeccionan a través del Deployment, los servicios de Compose a través del Compose Project y un Secure Link propiedad de una Route a través de la Route que lo creó.

La propiedad no se extiende automáticamente a las dependencias referenciadas. Una Route que usa un certificado o una Access List reutilizables no es propietaria de esos recursos ni los elimina. Una carga de trabajo colocada en un nodo no es propietaria del nodo. Una Route de Pages apunta a un Tag sin ser propietaria del despliegue inmutable seleccionado por ese Tag. Antes de eliminar o migrar, inspecciona tanto los hijos propios como las dependencias referenciadas, porque sus reglas de limpieza son distintas.

Opfield también crea objetos de ejecución internos para implementar el comportamiento del producto. Sus etiquetas, nombres de ejecución, redes, volúmenes, credenciales, conectores y registros de Tasks son detalles de implementación salvo que una acción compatible los exponga explícitamente. Eliminarlos o renombrarlos directamente con las herramientas de Docker del host puede romper la conciliación, el enrutamiento, la conectividad privada o la reversión.

Estado deseado, informado y en ejecución

El recurso del producto guarda en Opfield un estado deseado duradero. El daemon propietario informa del inventario, las capacidades, el estado y los resultados de las operaciones. El entorno de ejecución del host contiene el proceso real, la configuración, el almacenamiento y la conexión de red. Estas vistas pueden discrepar temporalmente durante una operación, un reinicio, una desconexión o un fallo.

Guardar correctamente significa que se aceptó el estado deseado, no necesariamente que el propietario lo haya aplicado. Sigue el Task duradero y espera a un estado informado nuevo. Si un nodo está desconectado, Opfield puede mostrar los últimos datos conocidos depurados, pero bloquea los cambios que requieren la propiedad o una capacidad actuales. Restablece el propietario y deja que se produzca la conciliación antes de decidir que hay que recrear a mano un objeto de ejecución que falta.

Carpetas y navegación

Las carpetas organizan los recursos compatibles y pueden intervenir en el acceso limitado por ámbito. No cambian la red de ejecución, la ubicación ni la propiedad del ciclo de vida. Mover o agrupar un recurso en la navegación no mueve su ejecución ni transfiere sus recursos dependientes.

Los recursos que pertenecen a una app están en los entornos de la app y no aparecen en las listas generales; ábrelos desde la app. Un usuario sin apps:view sigue viendo una app cuando puede ver uno de sus miembros gracias a sus propias concesiones, pero solo los entornos que contienen esos miembros y solo esos miembros.

Los resultados de la búsqueda y de la paleta de comandos llevan a la página canónica del recurso de Opfield en lugar de a los hijos de implementación. Así, las acciones, el historial de auditoría, los recursos relacionados y los controles de recuperación quedan anclados a la identidad estable que es propietaria del ciclo de vida.

Recursos externos

Los Compose Projects creados externamente se pueden descubrir a partir de las etiquetas canónicas de Docker. Opfield puede mostrar sus servicios, su estado, su salud, sus logs y su inventario, pero los proyectos externos siguen siendo de solo lectura hasta que un operador los adopta explícitamente con el YAML completo y los permisos necesarios. La adopción transfiere la gestión futura a Opfield solo tras la validación y la preparación de una revisión inmutable; Opfield no se fía de una ruta del host indicada en una etiqueta como configuración de origen.

Las bases de datos externas siguen siendo gestionadas por el operador. Opfield guarda cifrados sus ajustes de conexión, prueba la conectividad y puede ofrecer las herramientas permitidas, pero no es responsable de las actualizaciones del motor, del almacenamiento, de la disponibilidad ni de la eliminación. En Personal y superiores, las copias de seguridad de bases de datos pueden respaldarlas. Del mismo modo, las imágenes globales de Docker y los recursos de Compose intencionadamente externos o compartidos quedan fuera de la limpieza de hijos propiedad del proyecto.

Cambios y eliminación seguros

Antes de cambiar un recurso, identifica su propietario, sus hijos propios, sus dependencias referenciadas, la operación activa, el candidato de reversión y los datos persistentes. Haz un único cambio de ciclo de vida a través del propietario de nivel más alto y verifica el estado, las relaciones y el estado informado resultantes. No mezcles cambios directos en el host con una operación activa de Opfield.

La eliminación no es lo contrario de la creación. Puede borrar concesiones, identidades del motor, enlaces propiedad de Routes, historial de revisiones o slots de reversión, mientras conserva intencionadamente certificados y Access Lists reutilizables, recursos externos o volúmenes persistentes. Lee la confirmación, desvincula o migra las dependencias, conserva los datos necesarios y sigue el Task de eliminación hasta que termine la limpieza. Si la limpieza se interrumpe, conserva el registro de Opfield y usa su estado de operación para la recuperación en lugar de forzar la eliminación de los objetos hijos.