Imágenes, volúmenes y redes

Las imágenes, los volúmenes y las redes son recursos del daemon de Docker que pueden compartir varias cargas de trabajo. Opfield informa de los recursos compatibles y los gestiona, pero una limpieza segura sigue dependiendo de saber quién es su propietario y quién hace referencia a ellos. Trata el inventario de un nodo desconectado como la última información conocida hasta que se complete la sincronización.

Define la propiedad antes de limpiar

Estos recursos parecen inventario, pero conllevan riesgos distintos. Las imágenes afectan a la capacidad de arrancar o revertir software. Los volúmenes pueden contener la única copia de los datos de una aplicación. Las redes pueden formar parte del descubrimiento de servicios o de la conectividad privada. El responsable de la plataforma debe definir reglas de retención y de copias de seguridad para cada clase en lugar de aplicar una política genérica de «sin usar».

Una etiqueta unused significa que el inventario de Docker sincronizado actualmente no tiene ninguna conexión activa; no demuestra que el recurso se pueda eliminar con seguridad. Una carga de trabajo detenida, un slot de Deployment conservado, una migración pendiente, un runbook de recuperación o un flujo de trabajo externo de Compose pueden seguir dependiendo de él. Una limpieza correcta significa que se recuperó espacio de almacenamiento sin eliminar un artefacto de recuperación, un conjunto de datos o un límite de conectividad necesarios.

Imágenes

Las imágenes son inventario local de cada nodo. Descarga una imagen cuando una carga de trabajo la necesite, inspecciona su digest y su procedencia antes de usarla en producción y prefiere digests inmutables para las versiones. Los artefactos construidos desde un repositorio deben seguirse por digest y no por un tag mutable.

Antes de eliminar una imagen o ejecutar una purga, comprueba los Containers activos, los slots de reversión inactivos de los Deployments, los Tasks en curso y cualquier acción de recuperación prevista. Una limpieza local en un nodo puede hacer que un reinicio posterior falle hasta que la imagen se vuelva a descargar. Elimina solo las imágenes que se haya confirmado que no se usan y espera a la sincronización del daemon antes de juzgar si una limpieza ha terminado. Las imágenes que Opfield construyó desde Git para Containers, Deployments y Compose Projects que ya no existen se eliminan del nodo automáticamente; una imagen de build sin usar también se puede eliminar a mano, y si un contenedor del nodo todavía la usa, la eliminación se rechaza con 409 OPFIELD_INTERNAL_IMAGE.

Volúmenes

Los volúmenes locales gestionados por Opfield son el destino compatible para los nuevos montajes persistentes. Un volumen sobrevive a un Container salvo que se elimine por separado, lo que resulta útil para una recreación planificada, pero es peligroso cuando los datos ya no tienen copia de seguridad.

Renombrar, reetiquetar, redimensionar y adoptar un volumen requieren docker:volumes:edit, que se puede limitar a un volumen, un nodo o una carpeta. Una ruta del host escrita donde se espera el nombre de un volumen se rechaza con un mensaje claro, y todos los nombres de volumen se comprueban antes de crear ningún volumen.

Volúmenes de imagen de disco

En Personal y superiores, un volumen puede ser una Disk image: almacenamiento ext4 de capacidad fija que se puede ampliar más adelante. Los nuevos volúmenes de imagen de disco admiten escritura por parte de aplicaciones que no se ejecutan como root. Cada uno ocupa un dispositivo loop en su nodo Docker mientras existe, así que dimensiona en consecuencia el pool de dispositivos loop de un nodo Docker en LXC.

El daemon de Docker monta los volúmenes de imagen de disco antes de que arranque Docker, mediante un paso de arranque llamado opfield-volume-images (sustituye al anterior gateway-volume-images) que instala para systemd u OpenRC. Si la imagen de un volumen no se puede montar al arrancar, su punto de montaje recibe un marcador de posición vacío de solo lectura, de modo que un contenedor no escribe nada en el sistema de archivos raíz del nodo y, en su lugar, falla con Read-only file system. El daemon monta la imagen en cuanto puede, al arrancar o en su comprobación cada 10 minutos, y después reinicia los contenedores que usan el volumen para que vean sus datos. Un volumen que no se puede montar ya no desactiva los volúmenes de imagen de disco en todo el nodo.

Antes de mover, recrear, exportar o eliminar una carga de trabajo, identifica todos los volúmenes conectados y haz una copia de seguridad de los datos con estado adecuada al motor. Eliminar un volumen es destructivo y no se puede deshacer recreando la carga de trabajo. Las exportaciones de archivos de contenedores no incluyen el contenido de los volúmenes, por lo que la restauración de volúmenes es un paso de recuperación aparte.

Redes

Las redes proporcionan conectividad entre cargas de trabajo y pueden ser recursos de implementación privados. Una red creada por una carga de trabajo gestionada o por un propietario de nivel superior no debe eliminarse a mano: las Routes, las vinculaciones de bases de datos, el descubrimiento de servicios y la conciliación pueden depender de ella.

Conectar un contenedor a una red requiere acceso de edición a esa red. Los proyectos Compose y los archivos de contenedores importados no pueden usar la red del host ni las redes internas de Opfield: opfield-secure-links, las redes de enlace de bases de datos gestionadas opfield-db-*, las redes de almacenamiento gestionado opfield-storage-* y las redes de container links opfield-link-*. Las redes creadas antes de la 2.12.1 conservan sus nombres gateway- y se tratan igual. Estas redes internas están ocultas en la lista de redes: no se pueden conectar, desconectar, eliminar ni usar en contenedores nuevos, y una red nueva no puede tomar un nombre de esta forma. Las redes no externas propiedad de Compose siguen bajo el flujo de trabajo de Compose externo. Las redes externas o compartidas intencionadamente siguen siendo recursos globales y solo deben eliminarse cuando se hayan desconectado todas las cargas de trabajo que las referencian. Comprueba primero el estado del nodo y las referencias; que una red parezca sin usar en un nodo desconectado no basta para eliminarla.

Lista de comprobación para una limpieza segura

1. Espera a que el nodo Docker esté en línea y a que se sincronice el inventario actual.
2. Identifica al propietario del recurso y todas las referencias activas, de reversión o de recuperación.
3. Haz una copia de seguridad de los datos antes de cualquier cambio en un volumen.
4. Realiza una sola acción de limpieza a través de Opfield y sigue su Task.
5. Verifica después el estado esperado de las cargas de trabajo y las conexiones de almacenamiento y de red.

Si un Task de eliminación falla, no reintentes con una eliminación forzada a nivel del daemon. Lee el fallo, restablece el requisito previo que falta o desvincula la dependencia registrada y reintenta después la acción de Opfield prevista.

Detalles para operadores: purga y verificación

Ejecuta la purga solo sobre un nodo en línea con un inventario actualizado y revisa el conjunto de candidatos antes de confirmar. Los recursos internos de Opfield y los recursos hijos gestionados por su propietario están ocultos o protegidos cuando el producto puede identificarlos, pero los operadores siguen teniendo que revisar la propiedad externa y compartida. No programes una purga amplia como único mecanismo de retención en los nodos de producción.

Tras limpiar imágenes, verifica que las cargas de trabajo activas siguen en buen estado y que los artefactos de reversión necesarios que se sabe que funcionan todavía se pueden descargar o se conservan. Tras limpiar volúmenes, compara el tamaño recuperado y confirma que no ha desaparecido ningún montaje esperado. Tras limpiar redes, verifica el descubrimiento de servicios, el estado de Compose, las Routes y las vinculaciones de bases de datos que cruzan los límites entre cargas de trabajo.

Si la limpieza eliminó una imagen que se necesita después, restáurala por digest desde el registro de confianza. Un volumen eliminado requiere restaurar desde la copia de seguridad de la aplicación; volver a crear el nombre del volumen no restaura los datos. Una red compartida eliminada puede requerir recrear su configuración prevista y volver a conectar explícitamente a cada propietario, así que conserva sus ajustes antes de eliminarla.