Opfield 2.12.3
Uso de disco acotado en cada nodo, alertas de disco, una protección de consola para agentes de IA, reglas de acceso ordenables, orden de conmutación para bases de datos, registro en S3 y mejores builds de Git.
Por el equipo de Opfield4 min de lectura
Ya está disponible Opfield 2.12.3. La mayor parte del trabajo de esta versión se centró en tres cosas: que los discos no se llenen, que el acceso de los agentes sea más seguro y pulir detalles de los builds de Git, Pages y las bases de datos gestionadas. Estos son los cambios que notará la mayoría de los usuarios. La lista completa está en el registro de cambios.
Los discos ya no crecen sin límite
Un plano de control que maneja builds, imágenes y logs en muchos servidores puede llenar un disco sin que nadie lo note. En la 2.12.3, todo lo que crece tiene un límite.
- El registro interno guarda dos builds por contenedor, borra los builds de las fuentes eliminadas y deja de aceptar builds nuevos cuando su disco llega al 90 %.
- Los nodos Docker eliminan las imágenes que nadie ha usado en 12 horas. Cada contenedor conserva la imagen con la que se ejecuta y otra para volver atrás.
- Los logs de contenedores en los nodos Docker tienen un tamaño acotado, también los de contenedores creados antes de Opfield o fuera de él. Los nodos nginx mantienen los logs de rutas dentro de un límite y borran los de rutas eliminadas.
- El WAL y los slots de replicación de Postgres ya no llenan el disco de una base de datos.
- Housekeeping mantiene acotados los datos propios de Opfield incluso cuando está desactivado, y se ejecuta al momento cuando un disco de Opfield llega al 90 %. Además muestra qué ocupa cada disco: las tablas más grandes, Redis, los logs de contenedores y las imágenes antiguas de cada nodo.
Nuevas alertas integradas avisan a tiempo: alerta de disco al 85 % para cada disco de datos de un nodo, disco de Opfield lleno, discos de bases de datos llenos y Housekeeping detenido.
Una protección para la consola de los agentes
El asistente y los clientes MCP pueden ejecutar comandos en la consola de un nodo. Se ejecutan como root, para que un agente pueda reparar un nodo de verdad. Docker, containerd y Podman están ocultos en esa consola: un comando que usa Docker se rechaza y la respuesta indica la herramienta de Opfield que hay que usar en su lugar.
Es una protección contra errores, no una barrera de seguridad. Evita que un agente cambie por descuido un contenedor gestionado a espaldas de Opfield. Además, los agentes ya no pueden ejecutar comandos por SSH en hosts que son nodos de Opfield.
Si aun así alguien detiene, cambia o elimina a mano un contenedor gestionado, salta la nueva alerta integrada «Container changed outside Opfield», que explica qué implica el cambio.
Reglas de acceso en orden
Las reglas de una lista de acceso se evalúan de arriba abajo y gana la primera que coincide. Hasta ahora no se podía cambiar el orden, así que una regla de permiso añadida después de una denegación amplia nunca llegaba a aplicarse. Ahora las reglas se pueden reordenar desde la interfaz, la API y MCP, y las que nunca pueden coincidir quedan marcadas.
Orden de conmutación para bases de datos y almacenamiento
En Postgres gestionado, almacenes clave-valor, ClickHouse y almacenamiento S3 con disponibilidad, ahora puedes definir el orden de conmutación: qué servidor toma el relevo primero cuando falla el principal.
Registro en S3
El registro interno puede guardar sus datos en S3 en lugar del disco del host de Opfield. Al cambiar de almacenamiento se comprueba cada imagen que el registro conserva para las cargas de trabajo.
Pages y páginas de error
Los proyectos de Pages sirven su propio 404.html para las rutas que no existen, con estado 404.
Todas las páginas que genera el propio nginx (errores, clientes denegados, upstreams inaccesibles, el servidor por defecto) son ahora páginas de Opfield. Las páginas de error de tus aplicaciones pasan sin cambios.
Fuentes de Git
- Un contenedor con fuente de Git puede volver a su build anterior desde la pestaña Source, la API o MCP.
- Un build fallido muestra el paso del Dockerfile que falló y su código de salida, y la fuente explica por qué un build falló o no desplegó nada.
- Las variables de entorno, los secretos y los volúmenes se pueden configurar antes del primer build, y el primer build arranca enseguida.
- La política de seguridad de builds puede bloquear solo las vulnerabilidades que tienen corrección, para los paquetes de la aplicación o para todos los paquetes.
También en esta versión
Las rutas detrás de Cloudflare ven la IP real del cliente en las listas de acceso, los límites de peticiones y los logs. Postgres gestionado funciona con imágenes propias de Opfield, y PostGIS y pgRouting se instalan bajo demanda desde la pestaña Extensions.
Antes de actualizar, ten en cuenta que los archivos de contenedores usan ahora el formato de Opfield (.ofca). Los archivos exportados con versiones anteriores no se pueden importar.
Las instalaciones autoalojadas se actualizan como siempre. Las instalaciones gestionadas en la nube se actualizan en su ventana de mantenimiento.