¿Puedes revertir la imagen de un contenedor sin perder los datos de la aplicación?
Sí, puedes revertir una imagen de contenedor sin perder los datos de la aplicación cuando el estado persistente se encuentra fuera del contenedor y sigue siendo compatible con la versión anterior.
En un NAS doméstico, reemplazar la imagen normalmente recrea solo el entorno de ejecución de la aplicación, mientras que los volúmenes con nombre o los montajes vinculados conservan las bases de datos, la configuración y los archivos de usuario. El límite peligroso son los cambios de esquema: una imagen más reciente puede migrar la base de datos o reescribir la configuración de una forma que la imagen anterior no pueda leer. Antes de revertir, captura los montajes actuales, la identidad de la imagen, la configuración, los secretos y una copia de seguridad coherente de los datos.
Congela el estado actual antes de cambiar la imagen
Detén las actualizaciones automáticas de imágenes y registra la etiqueta actual de la imagen, el resumen inmutable, la configuración del contenedor, las variables de entorno, las redes, los puertos, los montajes, la política de reinicio y la comprobación de estado. Guarda el archivo de Compose o la configuración exportada por separado del contenedor.
Un flujo de trabajo de reversión de contenedores en un NAS recomienda conservar una imagen anterior conocida en lugar de depender de una etiqueta cambiante como latest. El punto de recuperación utilizable es la versión específica de la imagen anterior, junto con la configuración con la que se ejecutaba.
Realiza una copia de seguridad o una instantánea coherente de la base de datos de la aplicación antes de detener la versión más reciente. No des por hecho que el volumen existente es una copia para la reversión, porque quizá ya contenga cambios de esquema o de datos realizados por la actualización.
Confirma que los datos de la aplicación están fuera de la capa escribible
Asigna cada volumen con nombre y cada montaje vinculado, e identifica cualquier base de datos, carga, complemento, certificado, caché o configuración que todavía esté almacenado únicamente en la capa escribible del contenedor.
El almacenamiento persistente sobrevive al reemplazo del contenedor solo cuando el nuevo contenedor vuelve a conectarse a la misma ubicación de datos externa. El flujo de trabajo de SynoForum para cambiar la versión de una imagen comprueba explícitamente que los datos del volumen permanezcan en el almacenamiento del NAS antes de recrear un contenedor a partir de otra imagen.
Si los datos críticos existen únicamente en la capa escribible, cópialos o expórtalos antes de eliminar el contenedor actual. Trata esa extracción como un paso de recuperación, no como un motivo para mantener indefinidamente un contenedor sin versionar.
Fija la imagen anterior exacta en lugar de reutilizar latest
Descarga o localiza la última etiqueta o resumen conocido como funcional y actualiza únicamente la referencia de la imagen. Verifica la arquitectura, la edición de la aplicación y las variables de entorno necesarias antes de recrear el servicio.
Los usuarios que revierten servicios gestionados con Compose suelen volver a una versión anterior explícita de la imagen en lugar de pedirle a Docker que revierta un contenedor en ejecución. Una conversación práctica sobre reversiones se centra en cambiar la etiqueta fijada de la imagen de Compose y recrear el servicio.
No uses una imagen antigua almacenada en caché cuya identidad desconozcas. Registra el resumen después de descargarla para evitar que otra reconstrucción seleccione silenciosamente un binario diferente con la misma etiqueta mutable.
Comprueba si la versión más reciente cambió la base de datos
Lee las notas de la versión de la aplicación y los registros de migración correspondientes a las versiones entre el objetivo de la reversión y la imagen actual. Busca cambios de esquema irreversibles, configuraciones reescritas, cambios en las claves de cifrado o actualizaciones de complementos.
Revertir una base de datos es más difícil que revertir una imagen porque el código de la aplicación y el esquema deben seguir siendo compatibles. Octopus describe las migraciones compatibles con versiones anteriores como un requisito cuando las versiones antigua y nueva de una aplicación pueden coexistir o revertirse, lo que convierte la compatibilidad del esquema entre versiones en el límite decisivo de la reversión.
Si la imagen anterior no puede leer la base de datos migrada, restaura la copia de seguridad de la base de datos previa a la actualización en lugar de apuntar el código antiguo al estado nuevo. Conserva la base de datos actual por separado, por si fuera necesario revertir también esta operación.
Recrea el servicio con las mismas rutas persistentes
Detén y recrea el contenedor de la aplicación usando la imagen anterior, conservando los mismos volúmenes con nombre o montajes vinculados verificados. No uses comandos ni opciones de la interfaz que eliminen los volúmenes.
Mantén coherentes los nombres de red, los alias del servicio, los puertos publicados, las asignaciones UID/GID, los secretos y los destinos del proxy inverso, salvo que la versión anterior requiera una diferencia documentada. Un contenedor que se inicia correctamente con montajes incorrectos puede crear una aplicación nueva y vacía y parecer una pérdida de datos.
Inspecciona la lista de montajes y los registros de la aplicación antes de iniciar sesión o permitir que se ejecuten tareas en segundo plano. Si la aplicación inicializa una base de datos nueva, detenla de inmediato y corrige la ruta de datos en lugar de importar datos en la ubicación equivocada.
Valida la reversión y conserva una vía de recuperación futura
Prueba el inicio de sesión, las lecturas y escrituras de la base de datos, las cargas, las tareas programadas, las integraciones y un reinicio controlado. Compara una muestra de registros y archivos con el inventario previo a la reversión.
El flujo de trabajo de ZimaSpace para las instantáneas de datos de aplicaciones antes de las actualizaciones proporciona el paso de preparación más seguro para futuras actualizaciones.
La reversión solo se completa cuando la imagen anterior utiliza los datos persistentes previstos, el esquema es compatible o se ha restaurado, y el servicio sobrevive a otra recreación. Conserva la imagen más reciente, su copia de seguridad de datos y las notas de la reversión hasta que la versión anterior se haya mantenido estable durante el periodo normal de carga de trabajo.
Productos recomendados
Soporte y Consejos
Más para leer
¿Puede Plex compartir una GPU con otro contenedor de Docker?
Plex y otro contenedor suelen poder acceder a la misma GPU, pero debes probar la compatibilidad de los controladores, la asignación de dispositivos, la...
Cómo saber si un error de Plex proviene del cliente o del servidor
Reproduce el mismo elemento en otro cliente, compara la ruta de la sesión y recopila pruebas del servidor solo después de que el alcance...
Cómo configurar la caché de Plex y el almacenamiento temporal para la transcodificación
Protege el estado persistente de Plex mientras colocas los archivos temporales de transcodificación en un almacenamiento local adecuado; después, verifica la limpieza, el espacio...
