Migraciones y archivos de contenedores

La migración mueve una carga de trabajo compatible entre nodos Docker conservando su identidad en Opfield y las concesiones de recursos compatibles. Un archivo GWCA empaqueta una carga de trabajo compatible para exportarla e importarla de forma controlada. Ambos flujos son cambios operativos, no copias de seguridad: los datos de los volúmenes con estado requieren su propio plan de copia de seguridad y restauración.

Elige el resultado correcto

Usa la migración cuando la misma carga de trabajo gestionada deba pasar a otro nodo Docker conservando su propiedad y sus relaciones en Opfield. Usa un Opfield Container Archive (GWCA) cuando haya que exportar la configuración de una carga de trabajo para una transferencia controlada o para importarla más adelante. Usa una copia de seguridad de la aplicación cuando el objetivo sea proteger o restaurar datos. Estos resultados se solapan en la operación, pero no son intercambiables.

El responsable de la carga de trabajo decide la ventana de mantenimiento y valida el comportamiento de la aplicación. El responsable de la plataforma confirma la capacidad del destino, la compatibilidad del entorno de ejecución, el acceso a las imágenes, la ubicación en la red y la limpieza. El responsable de los datos confirma la copia de seguridad y la restauración. Una migración correcta conserva la identidad gestionada y la vía de acceso en el destino; un archivo correcto demuestra que la configuración compatible se puede importar, no que las dependencias externas o los datos de los volúmenes estén disponibles.

Confirma antes la compatibilidad

La migración entre nodos realiza una comprobación previa de capacidad, la transferencia de artefactos y volúmenes, la verificación en el destino, el cambio final y la recuperación de la limpieza. El destino debe estar en línea, tener recursos suficientes, admitir el entorno de ejecución seleccionado y llegar a cualquier artefacto de registro necesario.

Las cargas de trabajo con GPU, las que usan un entorno de ejecución seguro, las que tienen bind mounts del host y los Compose Projects no son portables. Trátalo como un límite estricto y no como una condición que se pueda sortear alterando la configuración de ejecución propiedad de Opfield. Para poner una aplicación Compose existente bajo la gestión de Opfield en su nodo actual, adopta el proyecto Compose en su lugar.

La migración copia los datos de los volúmenes locales con nombre de la carga de trabajo y los crea en el destino con los mismos nombres. La comprobación previa detiene la migración si el destino ya tiene un volumen con el mismo nombre o si un volumen está compartido con otra carga de trabajo, no es local o está respaldado por una imagen de disco. Un Container o un Deployment con un enlace a una base de datos o a un almacenamiento no se puede migrar (MIGRATION_MANAGED_LINK_UNSUPPORTED): elimina el enlace, migra y vuelve a enlazarlo en el nodo de destino. Las versiones de Docker con sufijos de distribución, como 26.1.5+dfsg1 en Debian, se comparan por su número de versión.

Migra una carga de trabajo

1. Registra las Routes, las vinculaciones de bases de datos, las concesiones, las dependencias de volúmenes y la ventana de mantenimiento prevista.
2. Haz una copia de seguridad de los volúmenes con estado y confirma que el nodo de destino tiene la capacidad y el perfil de ejecución necesarios.
3. Inicia la migración desde la carga de trabajo y sigue la operación durante la transferencia y la verificación en el destino.
4. Espera al cambio final y verifica después el estado de ejecución, las Routes, los logs y las dependencias privadas de la aplicación en el destino.
5. Conserva el origen hasta que Opfield informe de que la limpieza ha terminado y haya pasado la ventana de verificación.

Si fallan la transferencia, el arranque en el destino o el cambio final, inspecciona la etapa de la operación. Usa las acciones de cancelación o de recuperación de la limpieza que se ofrecen; eliminar a mano objetos intermedios puede impedir que Opfield complete o reanude una limpieza segura.

Las cargas de trabajo en Docker Engine 20.10 a 28 se migran a nodos con motores más nuevos. Los ajustes que un motor más nuevo no puede conservar, como una dirección MAC fija o un límite de memoria del kernel, aparecen en la comprobación previa con el mismo mensaje con el que se detendría la migración; cuando el nodo de origen ejecuta un daemon de Docker más antiguo, la comprobación previa muestra una advertencia en su lugar. Una migración que esperó a que un nodo se volviera a conectar y luego terminó se muestra como completada, y una cancelada tras una espera así, como cancelada.

Exporta e importa archivos GWCA

Los archivos GWCA pueden ser autocontenidos o respaldados por un registro. Incluyen la configuración compatible del contenedor y, opcionalmente, los valores de entorno, los secretos y los cambios de la capa escribible. Nunca incluyen el contenido de los volúmenes. Al importar, cada volumen archivado se crea vacío con un nombre nuevo, o lo asignas a un volumen existente gestionado por Opfield.

La exportación admite un subconjunto portable de los ajustes del contenedor. Se rechazan los contenedores con bind mounts del host, volúmenes anónimos, modo privilegiado o capacidades modificadas, dispositivos o GPU, espacios de nombres del host, healthchecks, logging personalizado (el límite de logs predeterminado de Opfield no cuenta) u otros ajustes específicos del host, y el error enumera los ajustes no compatibles. Los contenedores que pertenecen a un proyecto Compose (cualquier contenedor con la etiqueta com.docker.compose.project) no se pueden exportar: la REST API y MCP los rechazan con DOCKER_ARCHIVE_COMPOSE_CONTAINER (HTTP 409) y la consola oculta Export archive. Gestiónalos a través de su Compose Project. También se rechazan los slots de los Deployments blue/green.

Un archivo nunca transporta las credenciales de los enlaces del contenedor a bases de datos o almacenamiento. Una importación no puede conectar el contenedor a la red del host, al espacio de nombres de red de otro contenedor ni a las redes internas de Opfield, y elimina las etiquetas de Compose y de Opfield. Los clientes MCP exportan e importan archivos mediante enlaces de un solo uso con un comando curl listo para usar (la operación link de download_docker_archive y upload_docker_container_archive) en lugar de fragmentos en base64 dentro de las llamadas a herramientas.

Antes de exportar, decide si es necesario incluir secretos y, si lo es, asegúrate de que el archivo se trata como material sensible. Antes de importar, revisa el nodo de destino, la disponibilidad de la imagen, la compatibilidad del entorno de ejecución, el mapeo de redes y los puertos ocupados. Restaura los volúmenes por separado y verifica después la carga de trabajo importada antes de enrutar tráfico hacia ella.

Consecuencias de la reversión y la limpieza

La reversión de una migración afecta a la ubicación y a la configuración de ejecución de la carga de trabajo; no deshace las escrituras que hizo la aplicación durante el cambio final. Conserva la copia de seguridad original del volumen y las pruebas del origen hasta que se demuestre que el destino está en buen estado. Eliminar un archivo no elimina una carga de trabajo, y eliminar el origen tras una migración solo debe hacerse a través del ciclo de vida completado de la migración.

Verificación y aceptación

Tras una migración, verifica la identidad del nodo de destino, el estado de ejecución y de salud, los volúmenes conectados, las Routes, las vinculaciones de bases de datos, las concesiones, los logs y una transacción real de un cliente. Confirma que el origen ya no sirve ni acepta escrituras antes de aprobar la limpieza. Conserva las pruebas del origen y las copias de seguridad hasta que termine la ventana de observación acordada.

Tras importar un archivo, compara el digest de la imagen, el comando, el entorno, el tratamiento de los secretos, los volúmenes, las redes, los puertos, el entorno de ejecución y los límites de recursos con lo que se pretendía exportar. No enrutes tráfico de producción hasta que se completen las dependencias específicas de la aplicación y la restauración de los datos.

Detalles para operadores: recuperación ante fallos

La migración se hace por etapas, de modo que un fallo antes del cambio final debería dejar el origen como la carga de trabajo que sirve. Conserva el registro de la operación y usa la cancelación o la recuperación de la limpieza compatibles. Si el destino arrancó pero la aceptación falló, determina si Opfield sigue considerando autoritativo el origen antes de hacer cambios manuales. No permitas nunca que ambas copias acepten escrituras salvo que la aplicación esté diseñada para ese estado.

Los archivos GWCA que incluyen secretos o cambios de la capa escribible son artefactos sensibles. Guárdalos con control de acceso, protección de integridad, límites de retención y un responsable. Si la importación falla, corrige la compatibilidad o los mapeos del destino y reintenta con el mismo archivo revisado; no edites el archivo de forma no auditada para eludir la política.