Cómo migrar Home Assistant de un contenedor único a una pila de servicios resiliente

Eva Wong es la redactora técnica y manitas residente en ZimaSpace. Es una geek de toda la vida apasionada por los laboratorios domésticos y el software de código abierto, y se especializa en traducir conceptos técnicos complejos en guías prácticas y fáciles de seguir. Eva cree que alojar servicios propios debería ser divertido, no intimidante. A través de sus tutoriales, ayuda a la comunidad a desmitificar la configuración del hardware, desde montar su primer NAS hasta dominar los contenedores Docker.

Migra Home Assistant de un solo contenedor a una pila de servicios resiliente: primero conserva el estado actual de Home Assistant y luego separa los datos persistentes, los servicios complementarios, las rutas de red, las dependencias de inicio y las copias de seguridad en funciones explícitas. El objetivo no es crear más contenedores, sino reducir la probabilidad de que el fallo de un servicio deje fuera de servicio toda la casa inteligente.

Haz la migración por etapas. Mantén intactos el contenedor original y sus datos hasta que la nueva pila pueda iniciarse, superar las pruebas de control local, sobrevivir al reinicio del host y restaurarse desde una copia de seguridad. Una pila resiliente es aquella cuyo funcionamiento puedes comprender durante un fallo, no la que tiene el archivo Compose más largo.

Congela el contenedor en funcionamiento y mapea todas las dependencias

Antes de cambiar la topología, registra la imagen y versión exactas de Home Assistant, la ruta de configuración, las variables de entorno, el modo de red, las asignaciones de dispositivos USB, las rutas montadas y los puertos del host. Después, enumera todo aquello de lo que depende Home Assistant fuera del contenedor: el agente MQTT, la base de datos, Zigbee2MQTT, el proxy inverso, la VPN, el DNS, los certificados, las copias de seguridad y cualquier recurso compartido de red. Esto servirá como mapa de migración.

Clasifica cada dependencia como estado autoritativo, servicio reconstruible o infraestructura externa. La configuración y el estado de la base de datos de Home Assistant son autoritativos. Una imagen de contenedor descargada se puede reconstruir. El DNS y el enrutamiento pueden ser infraestructura externa. Esta clasificación evita un error común: hacer copias de seguridad de la definición del contenedor y olvidar los datos o el servicio que necesita para funcionar.

Separa los datos persistentes de los contenedores sustituibles

Asigna a cada servicio con estado una ruta persistente explícita o un volumen con nombre cuya propiedad y política de copias de seguridad conozcas. La configuración de Home Assistant, el estado de MQTT si se conserva, los archivos de base de datos, los certificados y los secretos relacionados con las automatizaciones no deberían estar únicamente en una capa de escritura del contenedor. Las imágenes y los contenedores deberían poder sustituirse sin perder el estado del hogar.

La recuperación de volúmenes también requiere tener en cuenta la aplicación. Una guía sobre un patrón portátil para hacer copias de seguridad y restaurar volúmenes de Docker explica por qué copiar directorios del entorno de ejecución sin procesar no equivale a hacer una copia de seguridad portátil. En el caso de las bases de datos, coordina el método de copia de seguridad con la base de datos en vez de dar por sentado que una copia de archivos realizada durante escrituras activas será coherente.

Añade de forma deliberada comprobaciones de estado, políticas de reinicio y dependencias de inicio

Una política de reinicio responde a «¿qué debe hacer el entorno de ejecución cuando este proceso se cierra?». Una comprobación de estado responde a «¿está realmente listo el servicio para usarse?». Son preguntas distintas. Un contenedor de base de datos puede estar en ejecución y seguir reproduciendo registros; un agente MQTT puede tener un proceso activo, pero aún no aceptar la conexión que espera Home Assistant.

Usa comprobaciones de estado en servicios que tengan una condición de disponibilidad significativa y añade orden de dependencias solo cuando el servicio dependiente realmente lo necesite. Una guía independiente por qué la política de reinicio y el estado del servicio son señales diferentes explica por qué los reinicios automáticos no demuestran que el servicio esté listo. Otra guía un patrón de disponibilidad en Compose para servicios dependientes resulta útil cuando necesitas supeditar un servicio dependiente a una condición de estado real, en lugar de a un temporizador de espera fijo.

Limita los dominios de fallo con redes, recursos y orden de mantenimiento

No dejes que un análisis de medios, una migración de base de datos o un contenedor experimental consuman todos los ciclos de CPU, toda la RAM disponible o todo el SSD de las aplicaciones mientras se espera que Home Assistant siga respondiendo. Define requisitos de recursos explícitos para los servicios vecinos que exigen mucho, coloca las cachés desechables lejos de los datos críticos cuando sea práctico y mantén la ruta de control de Home Assistant en una red local estable.

Separa también el orden de las actualizaciones. Cambia una capa a la vez: el host, el entorno de ejecución de contenedores, Home Assistant, la base de datos y, por último, los componentes complementarios opcionales. Si todo se actualiza en una sola ventana de mantenimiento y la pila falla, no podrás identificar qué capa causó la regresión. La topología de Home Assistant que separa las funciones de cómputo, almacenamiento y copia de seguridad de ZimaSpace ofrece un mapa más amplio de las funciones de cómputo, almacenamiento, redes y recuperación.

Haz el cambio solo después de superar las pruebas de reinicio y restauración

Pon en marcha la nueva pila con una copia de la configuración o una restauración controlada. Prueba un panel local, una automatización local, una conexión Zigbee o Thread, MQTT si se usa, el acceso al historial y a la base de datos, las notificaciones y el acceso remoto si forma parte del diseño. Después, reinicia todo el host, no solo los contenedores, y comprueba que el orden de inicio y las asignaciones de dispositivos sigan funcionando sin intervención manual.

Por último, demuestra que la recuperación funciona. Restaura en un destino temporal limpio o, como mínimo, restaura los componentes con estado en un espacio de pruebas independiente. Una copia de seguridad del plano de gestión puede resultar engañosa si excluye los volúmenes de las cargas de trabajo; este motivo por el que una copia de seguridad del plano de gestión puede omitir datos de las cargas de trabajo ilustra por qué las definiciones de la pila y los datos de las aplicaciones requieren coberturas de recuperación independientes.

  1. Crea una instantánea o una copia de seguridad del estado funcional del contenedor único.
  2. Asigna las dependencias y clasifica los componentes según conserven estado o se puedan reconstruir.
  3. Crea rutas persistentes y definiciones de servicios explícitas.
  4. Añade políticas de estado, reinicio y recursos solo cuando resuelvan un modo de fallo real.
  5. Prueba el control local, las radios, la base de datos, el acceso remoto, el reinicio completo y la restauración.
  6. Retira el contenedor antiguo solo después de que la nueva pila supere todas las pruebas.

El endpoint resiliente no consiste en «más servicios». Es una pila en la que Home Assistant se puede reconstruir sin perder el estado, las dependencias se recuperan en un orden conocido, los servicios vecinos con gran consumo no pueden acaparar los recursos del plano de control y una actualización fallida se puede aislar en lugar de convertirse en un misterio que afecte a toda la casa.

Configuración de NAS y servidores

Más para leer

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.