Cómo migrar Mosquitto a un broker MQTT en la nube sin tiempo de inactividad

Cuando migras Mosquitto a MQTT en la nube, la parte arriesgada no es el nuevo broker, sino el momento en que los dispositivos cambian. Este tutorial te ofrece un runbook sin tiempo de inactividad: inventariar lo que se ejecuta hoy en tu Mosquitto, mapear las credenciales al broker en la nube, ejecutar ambos brokers en paralelo con un bridge de Mosquitto, mover los clientes por oleadas y desmantelar con un plan de vuelta atrás preparado. Los ejemplos usan como destino ConnectMQ, un broker MQTT gestionado, pero el método funciona con cualquier broker que cumpla el estándar.

Por qué los equipos migran desde Mosquitto

Mosquitto es un broker excelente y ligero, y sigue siendo la opción adecuada para muchos despliegues en el edge y en laboratorio. Los equipos suelen trasladar el broker central a la nube por motivos operativos más que por carencias técnicas: renovación de certificados, parches del sistema operativo, copias de seguridad, monitorización y guardias recaen sobre alguien que tiene otro trabajo. Los dispositivos remotos también necesitan un endpoint accesible, lo que implica reglas de firewall y exposición pública de un servidor que mantienes tú mismo. Si aún lo estás decidiendo, compara primero los pros y contras en broker MQTT autogestionado frente a gestionado y alternativa a Mosquitto en la nube.

Paso 1: inventariar clientes, topics y funciones

No puedes migrar lo que no has listado. Recoge cuatro cosas del broker actual.

Configuración. Lee mosquitto.conf y los archivos de conf.d. Anota listeners y puertos, allow_anonymous, password_file, acl_file, la configuración de persistencia, max_inflight_messages, los límites de tamaño de mensaje y los bridges existentes.

Clientes. Mosquitto registra cada conexión con su client ID. Extrae del log los IDs únicos y las direcciones de origen:

grep "New client connected" /var/log/mosquitto/mosquitto.log \
  | sed -E 's/.*from ([0-9a-fA-F.:]+):[0-9]+ as ([^ ]+).*/\2 \1/' \
  | sort -u > clients.txt
wc -l clients.txt

Topics. Suscríbete a todo durante un periodo representativo y registra los nombres de topic únicos, incluidos los retenidos:

timeout 600 mosquitto_sub -h localhost -p 1883 -u admin -P 'ADMIN_PASSWORD' \
  -i inventory-$RANDOM -t '#' -F '%t %r' | sort -u > topics.txt

El campo %r imprime 1 para los retained messages, que tendrás que recrear en el nuevo broker.

Uso de funciones. Comprueba si los clientes usan MQTT 5, QoS 2, sesiones persistentes, payloads grandes, suscripciones con comodines o ACLs por topic. Cada una se convierte en un requisito para el destino.

Paso 2: mapear funciones y credenciales

Compara tu inventario con el broker de destino antes de tocar ningún dispositivo:

Dos filas merecen atención. Primero, los client IDs: en Mosquitto cualquier cliente suele poder elegir cualquier ID, mientras que ConnectMQ vincula cada client ID a sus credenciales emitidas. Planifica un juego de credenciales por dispositivo o servicio y actualiza el firmware o la configuración para que cada dispositivo use su client ID emitido. Segundo, las ACLs: si tu configuración de Mosquitto depende de ACLs de topic detalladas para separar a partes que no son de confianza, rediseña esa frontera con brokers separados o con un backend que medie el acceso antes de migrar.

Después, crea el destino: regístrate en app.connectmq.com, elige un plan dimensionado para tu pico de conexiones, crea un broker y emite credenciales para el bridge y para la primera oleada de clientes.

Paso 3: ejecución en paralelo con un bridge de Mosquitto

El bridge es lo que hace posible una migración sin tiempo de inactividad. Mosquitto se conecta al broker en la nube como un cliente MQTT normal y reenvía los topics seleccionados en cada dirección, de modo que los dispositivos de cualquiera de los dos brokers ven los mismos datos durante la transición. Añade un archivo como /etc/mosquitto/conf.d/bridge-connectmq.conf:

connection connectmq
address broker.connectmq.com:8883
bridge_protocol_version mqttv311
remote_clientid YOUR_CLIENT_ID
remote_username YOUR_USERNAME
remote_password YOUR_PASSWORD
bridge_capath /etc/ssl/certs
bridge_insecure false
try_private false
notifications false
cleansession true
restart_timeout 5 60

# La telemetría de los dispositivos locales sube a la nube
topic factory1/+/+/telemetry out 1
topic factory1/+/+/status out 1
# Los comandos de las aplicaciones en la nube bajan a los dispositivos locales
topic factory1/+/+/cmd in 1

Reinicia Mosquitto con sudo systemctl restart mosquitto y comprueba en el log que el bridge se ha conectado correctamente. Algunos parámetros importan:

• try_private false: el flag de bridge privado es una extensión específica de Mosquitto; desactívalo cuando el remoto sea un broker distinto.
• notifications false: impide que Mosquitto publique en el remoto los topics de estado del bridge, que allí no necesitas.
• Topics direccionales: usa out e in en lugar de both siempre que sea posible. Un bridging bidireccional de los mismos topics entre dos brokers puede crear bucles de mensajes.
• restart_timeout: espacia los intentos de reconexión si el lado cloud no está accesible durante un momento.

Verifica el bridge suscribiéndote en el lado cloud con tus propias credenciales, o mirando el explorador de topics en vivo del portal mientras publica un dispositivo local.

mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
  -u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID \
  -t 'factory1/#' -v

Usa aquí un juego de credenciales distinto del del bridge, porque cada client ID solo puede mantener una conexión.

Paso 4: mover los clientes por oleadas

Con el bridge en marcha, cada cliente puede moverse de forma independiente. Mueve primero los consumidores y después los productores:

1. Consumidores backend (bases de datos, Node-RED, dashboards): apúntalos al broker en la nube. Gracias al bridge siguen recibiendo la telemetría local.
2. Un grupo piloto de dispositivos: unos cuantos dispositivos de distintas plantas y versiones de firmware. Cambia el host, el puerto 8883, TLS y las credenciales, y obsérvalos durante unos días.
3. El resto de dispositivos por lotes: por planta o por línea de producto, con un punto de control después de cada lote.
4. Productores de comandos: cuando los dispositivos estén en el broker en la nube, mueve las aplicaciones que envían comandos.

En cada lote, confirma el estado de conexión en $SYS/broker/connection/{clientId}/state, comprueba que los topics esperados aparecen en el explorador y recrea los retained messages que haya marcado tu inventario. Como ConnectMQ no garantiza el estado retenido entre reinicios, haz que los dispositivos republiquen su estado y configuración retenidos cada vez que se conecten, una buena práctica en cualquier broker.

Vigila los límites de tu plan durante las oleadas. Si una oleada supera la cuota de conexiones, los clientes MQTT 5 reciben el reason code 0x97; los clientes 3.1.1 son rechazados. Sube de plan antes de la oleada, no durante.

Paso 5: hacer el cambio y desmantelar

Cuando el broker local ya no tenga clientes directos salvo el bridge, la migración estará funcionalmente completa. Mantén el bridge y el broker antiguo en marcha durante un periodo de observación acordado como vía de vuelta atrás. Revertir un dispositivo es simplemente un cambio de configuración para volver al host antiguo, y mientras tanto el bridge mantiene ambos lados sincronizados.

Después, desmantela en orden: elimina la configuración del bridge, detén Mosquitto, cierra los puertos del firewall, revoca las credenciales antiguas y archiva los archivos de configuración. Si algunas plantas necesitan MQTT local para lógica en el edge que deba funcionar sin conexión, mantén allí una instancia de Mosquitto de forma permanente y conéctala hacia arriba con un bridge; ese diseño híbrido es habitual y perfectamente válido.

Checklist de migración

1. Configuración, lista de clientes y lista de topics exportadas desde Mosquitto.
2. Carencias de funciones (ACLs, QoS 2, tamaño de mensaje, persistencia) resueltas.
3. Broker de destino creado en un plan con suficientes conexiones.
4. Un juego de credenciales emitido por dispositivo o servicio.
5. Bridge en marcha con topics direccionales; datos verificados en ambos lados.
6. Consumidores movidos y verificados.
7. Dispositivos movidos por oleadas con puntos de control.
8. Estado retenido republicado al conectar.
9. Vía de vuelta atrás mantenida durante el periodo de observación.
10. Broker antiguo desmantelado y credenciales revocadas.

La guía MQTT del prototipo a producción cubre pasos de refuerzo que quizá quieras incorporar al mismo proyecto.

Migra a ConnectMQ

Crea un broker gratuito en app.connectmq.com con el plan Serverless, sin tarjeta de crédito, y monta el bridge contra él para probar todo el runbook antes de comprometerte. ConnectMQ te ofrece un broker MQTT gestionado con TLS, WebSockets, credenciales emitidas y un portal con explorador de topics en vivo. Para conocer los modelos de despliegue, lee la guía del broker MQTT en la nube y usa el servidor MQTT público gratuito para experimentos rápidos y sin datos sensibles, nunca para datos de producción.

Preguntas frecuentes

¿Puedo migrar Mosquitto a MQTT en la nube sin cambiar el firmware de los dispositivos?

Solo si el host, el puerto, la configuración TLS, las credenciales y el client ID se pueden configurar sin actualizar el firmware. Los dispositivos con la dirección del broker fijada en el código pueden quedarse en un Mosquitto local conectado a la nube mediante un bridge.

¿Debe el bridge usar QoS 1 o QoS 0?

QoS 1 es la opción habitual para hacer bridging de telemetría y comandos, porque protege los mensajes a través del enlace del bridge. Usa QoS 0 solo para datos de alta frecuencia en los que una pérdida ocasional sea aceptable.

¿Se migran automáticamente los retained messages?

Los retained messages que ya están en Mosquitto no se copian en bloque. El bridge reenvía las nuevas publicaciones; haz que los dispositivos republiquen su estado retenido al conectarse y verifica los topics retenidos en el lado cloud.

¿Cuánto tiempo debo conservar el broker Mosquitto antiguo?

Consérvalo, con el bridge en marcha, hasta que todos los clientes lleven un periodo acordado funcionando de forma estable en el nuevo broker. Así tienes una vía de vuelta atrás inmediata a un coste muy bajo.