Lista de verificación previa a la actualización para contenedores y dependencias de Home Assistant

Antes de actualizar Home Assistant Container, capture el contrato del contenedor en ejecución, verifique una copia de seguridad fuera del contenedor, compruebe que las dependencias estén listas y conserve una imagen de reversión probada.

La configuración persistente puede sobrevivir a la recreación del contenedor, pero las radios USB, los servicios de base de datos, los modos de red, los secretos, las integraciones personalizadas o los contenedores complementarios pueden no hacerlo. Elabore la lista de comprobación a partir del despliegue actual exacto, no de un ejemplo genérico de Compose. No descargue la nueva imagen ni reinicie hasta que la copia de seguridad pueda localizarse fuera del contenedor, se haya confirmado el espacio libre necesario y pueda restaurarse la referencia de la imagen anterior.

Registre el contrato del contenedor en ejecución

Capture el resumen o la versión exactos de la imagen de Home Assistant, los argumentos del contenedor, el modo de red, los puertos publicados, las variables de entorno, la política de reinicio, la zona horaria, las opciones de seguridad, la comprobación de estado, las rutas montadas y las asignaciones de dispositivos. Exporte la definición actual de Compose u orquestación y compárela con el contenedor en ejecución para detectar desviaciones.

Las migraciones de contenedores suelen depender de algo más que del directorio de configuración visible. Una experiencia de la comunidad sobre el traslado de Home Assistant OS a contenedores destaca la existencia de definiciones independientes para Zigbee2MQTT, el bróker y la pila, lo que demuestra por qué debe inventariarse la pila completa de contenedores.

APROBADO significa que otro administrador podría recrear el contenedor actual a partir del registro sin hacer suposiciones. RECHAZADO significa que un montaje, dispositivo, secreto o comando existe únicamente en el estado de ejecución. Reconcilie el archivo de despliegue antes de actualizar; de lo contrario, la reversión podría recrear un entorno diferente.

Verifique la copia de seguridad fuera del contenedor

Cree la copia de seguridad prevista, cópiela o almacénela fuera del sistema de archivos del contenedor y, preferiblemente, fuera del mismo dominio de fallo del host; después, registre su fecha y hora y su tamaño. Confirme que incluya la configuración persistente, los registros de almacenamiento ocultos, los secretos necesarios para la restauración y cualquier copia de seguridad de la base de datos externa que requiera la arquitectura elegida.

Una conversación sobre la restauración en Docker recomienda explícitamente conservar las copias de seguridad fuera del contenedor y copiar la copia más reciente antes de eliminar la instancia antigua. Esa regla de la copia de seguridad fuera del contenedor evita que la sustitución del contenedor elimine la única copia de recuperación.

APROBADO significa que el archivo se puede leer desde el entorno de recuperación y que se han verificado su contenido o una restauración de prueba. RECHAZADO significa que la copia de seguridad existe únicamente en el volumen que se va a modificar o depende de credenciales no documentadas. Detenga la actualización hasta que la recuperación sea independiente del contenedor nuevo.

Compruebe las dependencias de la base de datos, el almacenamiento y la radio

Registre el motor y la versión de la base de datos, las versiones del bróker y el puente, las rutas de los dispositivos USB, el estado del firmware de la radio, las direcciones de red, los nombres DNS y el estado de cada servicio complementario necesario. Compruebe el espacio libre actual para las capas de imagen, el trabajo de migración de la base de datos, los registros y la copia de reversión.

Un flujo de trabajo práctico para actualizar contenedores advierte que la migración del esquema de la base de datos puede retrasar la disponibilidad de la API y que reiniciar repetidamente puede interrumpir el progreso. La secuencia de una actualización de Docker con reversión respalda la definición de un periodo de observación de la migración antes de modificar la imagen en ejecución.

APROBADO significa que todas las dependencias están saludables, son accesibles, son compatibles con la versión objetivo y están incluidas en la planificación de la reversión. RECHAZADO significa que una ruta de radio es inestable, una base de datos ya está en mal estado o el espacio libre es escaso. Repare primero la línea base para no atribuir un fallo preexistente a la actualización.

-15% OFF

ZimaBoard 2 - Mini servidor doméstico para tu gran idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Revise las integraciones personalizadas y el riesgo de la versión

Haga una lista de las integraciones personalizadas, los recursos del frontend, los temas, las automatizaciones que llaman a servicios obsoletos y los componentes complementarios fijados a versiones concretas. Compruebe su estado de mantenimiento y su compatibilidad con la versión objetivo. No desactive nada de forma predeterminada; en su lugar, identifique qué componente opcional puede aislarse primero si el arranque falla.

Los usuarios de Home Assistant que planean actualizar Docker suelen verificar los pasos de copia de seguridad y reversión antes de cambiar una versión que lleva mucho tiempo en ejecución. Una conversación sobre la preparación de la actualización del contenedor muestra por qué la imagen antigua y los datos persistentes deben permanecer disponibles conjuntamente.

APROBADO significa que los riesgos de compatibilidad conocidos tienen un orden de aislamiento y que ninguno bloquea el control local esencial. RECHAZADO significa que se necesita un componente personalizado sin mantenimiento, pero no se ha probado. Aplace la actualización, pruebe la imagen objetivo con una copia o acepte un modo degradado documentado antes de programar la interrupción del servicio en producción.

Defina el criterio de actualización y el desencadenante de reversión

Escriba el orden exacto de detención, los pasos para descargar la imagen y recrear el contenedor, las señales de migración esperadas, la lista de comprobación de validación, la duración máxima de la interrupción y el comando de reversión. Conserve el resumen de la imagen antigua y no modifique manualmente los datos persistentes durante el periodo de observación del primer arranque. Elija una ventana de mantenimiento con control manual local disponible.

Utilice la lista de comprobación para una migración segura de ZimaSpace para incluir las radios, el almacenamiento, la configuración de red, las integraciones y una alternativa de recuperación probada que vaya más allá del propio contenedor.

Continúe únicamente cuando todos los criterios anteriores estén aprobados. Después de la actualización, verifique los registros, Recorder, las integraciones esenciales, una automatización local, una ruta remota, la creación de una copia de seguridad y un segundo reinicio. Revierta cuando los errores de migración se repitan, el control esencial supere el límite de interrupción o el contenedor nuevo no pueda reproducir el contrato registrado.