Lorsque vous migrez Mosquitto vers MQTT cloud, le risque ne vient pas du nouveau broker mais du moment où les appareils basculent. Ce tutoriel vous donne un runbook sans interruption de service : inventorier ce qui tourne aujourd'hui sur votre Mosquitto, faire correspondre les identifiants avec le broker cloud, faire fonctionner les deux brokers côte à côte grâce à un bridge Mosquitto, déplacer les clients par vagues et décommissionner avec un plan de retour arrière prêt. Les exemples utilisent ConnectMQ, un broker MQTT managé, comme destination, mais la méthode fonctionne avec n'importe quel broker conforme aux standards.
Pourquoi les équipes quittent Mosquitto
Mosquitto est un excellent broker léger, et il reste le bon choix pour de nombreux déploiements en périphérie et en laboratoire. Les équipes migrent généralement leur broker central vers le cloud pour des raisons opérationnelles plutôt que pour des lacunes techniques : renouvellement des certificats, correctifs du système d'exploitation, sauvegardes, supervision et astreintes retombent sur quelqu'un qui a d'autres tâches. Les appareils distants ont aussi besoin d'un endpoint joignable, ce qui implique des règles de pare-feu et l'exposition publique d'un serveur que vous maintenez vous-même. Si vous hésitez encore, comparez d'abord les compromis dans broker MQTT auto-hébergé ou managé et alternative cloud à Mosquitto.
Étape 1 : inventorier clients, topics et fonctionnalités
On ne peut pas migrer ce qu'on n'a pas recensé. Collectez quatre éléments sur le broker actuel.
Configuration. Lisez mosquitto.conf et les fichiers de conf.d. Notez les listeners et les ports, allow_anonymous, password_file, acl_file, les paramètres de persistance, max_inflight_messages, les limites de taille de message et les bridges existants.
Clients. Mosquitto journalise chaque connexion avec son client ID. Extrayez les ID uniques et les adresses sources du journal :
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. Abonnez-vous à tout pendant une période représentative et enregistrez les noms de topic uniques, y compris les topics retenus :
timeout 600 mosquitto_sub -h localhost -p 1883 -u admin -P 'ADMIN_PASSWORD' \
-i inventory-$RANDOM -t '#' -F '%t %r' | sort -u > topics.txt
Le champ %r affiche 1 pour les retained messages, que vous devrez recréer sur le nouveau broker.
Fonctionnalités utilisées. Vérifiez si les clients utilisent MQTT 5, la QoS 2, des sessions persistantes, des payloads volumineux, des abonnements avec jokers ou des ACL par topic. Chacun de ces points devient une exigence pour la destination.
Étape 2 : faire correspondre fonctionnalités et identifiants
Comparez votre inventaire avec le broker de destination avant de toucher au moindre appareil :
| Fonctionnalité Mosquitto | À vérifier sur la destination | ConnectMQ |
|---|---|---|
| MQTT 3.1.1 / 5.0 | Mêmes versions prises en charge | Les deux pris en charge |
| Listeners 1883 / 8883 / WebSockets | Ports et chemins | 1883, 8883, 8083, 8084 avec /mqtt |
Utilisateurs password_file |
Mode d'émission des identifiants | Nom d'utilisateur, mot de passe et client ID générés dans le portail |
| Tout client ID accepté | Règles de client ID | Client ID liés aux identifiants émis |
Règles par topic acl_file |
Prise en charge des ACL | ACL par topic non proposées ; brokers ou identifiants distincts par périmètre de confiance |
| QoS 2 | Prise en charge selon l'offre | Serverless Paid et au-delà |
message_size_limit |
Payload maximal | 256 Ko en Free, 1 Mo en Serverless Paid |
| Persistance après redémarrage | Durabilité des sessions et des messages retenus | Non garantie ; les clients doivent se réabonner et republier leur état |
| Bridges vers d'autres brokers | Bridging natif | Non proposé côté cloud ; conservez le bridging sur Mosquitto si nécessaire |
Deux lignes méritent une attention particulière. D'abord, les client ID : sur Mosquitto, n'importe quel client peut généralement choisir n'importe quel ID, alors que ConnectMQ lie chaque client ID à ses identifiants émis. Prévoyez un jeu d'identifiants par appareil ou service, et mettez à jour le firmware ou la configuration pour que chaque appareil utilise le client ID qui lui a été attribué. Ensuite, les ACL : si votre configuration Mosquitto s'appuie sur des ACL de topic fines pour séparer des parties non fiables, repensez cette frontière avec des brokers distincts ou un backend qui arbitre les accès, avant de migrer.
Créez ensuite la destination : inscrivez-vous sur app.connectmq.com, choisissez une offre dimensionnée pour votre pic de connexions, créez un broker et émettez des identifiants pour le bridge et pour la première vague de clients.
Étape 3 : double fonctionnement avec un bridge Mosquitto
C'est le bridge qui rend possible une migration sans interruption. Mosquitto se connecte au broker cloud comme un client MQTT ordinaire et relaie les topics sélectionnés dans chaque sens, de sorte que les appareils de l'un ou l'autre broker voient les mêmes données pendant la transition. Ajoutez un fichier tel que /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 télémétrie produite par les appareils locaux remonte vers le cloud
topic factory1/+/+/telemetry out 1
topic factory1/+/+/status out 1
# Les commandes émises par les applications cloud descendent vers les appareils locaux
topic factory1/+/+/cmd in 1
Redémarrez Mosquitto avec sudo systemctl restart mosquitto et vérifiez dans le journal que le bridge s'est bien connecté. Quelques paramètres comptent :
try_private false: le drapeau de bridge privé est une extension propre à Mosquitto ; désactivez-le lorsque le broker distant est d'un autre type.notifications false: empêche Mosquitto de publier des topics d'état du bridge sur le broker distant, où vous n'en avez pas besoin.- Topics directionnels : utilisez
outetinplutôt quebothchaque fois que possible. Un bridge bidirectionnel sur les mêmes topics entre deux brokers peut créer des boucles de messages. restart_timeout: espace les tentatives de reconnexion si le côté cloud est brièvement injoignable.
Vérifiez le bridge en vous abonnant côté cloud avec vos propres identifiants, ou en observant l'explorateur de topics en direct du portail pendant qu'un appareil local publie.
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
Utilisez ici un autre jeu d'identifiants que celui du bridge, car chaque client ID ne peut maintenir qu'une seule connexion.
Étape 4 : déplacer les clients par vagues
Une fois le bridge en place, chaque client peut migrer indépendamment. Déplacez d'abord les consommateurs, puis les producteurs :
- Consommateurs backend (bases de données, Node-RED, tableaux de bord) : pointez-les vers le broker cloud. Grâce au bridge, ils continuent de recevoir la télémétrie locale.
- Un groupe pilote d'appareils : quelques appareils issus de sites et de versions de firmware différents. Changez l'hôte, le port 8883, le TLS et les identifiants, et surveillez-les pendant quelques jours.
- Les appareils restants par lots : par site ou par gamme de produits, avec un point de contrôle après chaque lot.
- Producteurs de commandes : une fois les appareils sur le broker cloud, déplacez les applications qui envoient les commandes.
Pour chaque lot, confirmez l'état de connexion sur $SYS/broker/connection/{clientId}/state, vérifiez que les topics attendus apparaissent dans l'explorateur et recréez les retained messages signalés par votre inventaire. Comme ConnectMQ ne garantit pas la conservation de l'état retenu après un redémarrage, faites republier par les appareils leur statut et leur configuration retenus à chaque connexion, ce qui est une bonne pratique sur n'importe quel broker.
Surveillez les limites de votre offre pendant les vagues. Si une vague fait dépasser le quota de connexions, les clients MQTT 5 reçoivent le code de raison 0x97 ; les clients 3.1.1 sont refusés. Passez à l'offre supérieure avant la vague plutôt que pendant.
Étape 5 : basculer, puis décommissionner
Lorsque le broker local ne porte plus aucun client direct à part le bridge, la migration est fonctionnellement terminée. Laissez tourner le bridge et l'ancien broker pendant une période d'observation convenue, comme solution de retour arrière. Revenir en arrière pour un appareil se résume à remettre l'ancien hôte dans sa configuration, et le bridge maintient pendant ce temps les deux côtés synchronisés.
Décommissionnez ensuite dans l'ordre : supprimez la configuration du bridge, arrêtez Mosquitto, fermez les ports du pare-feu, révoquez les anciens identifiants et archivez les fichiers de configuration. Si certains sites ont besoin d'un MQTT local pour une logique en périphérie qui doit fonctionner hors ligne, conservez-y une instance Mosquitto de façon permanente et reliez-la au cloud par un bridge ; cette architecture hybride est courante et parfaitement valable.
Checklist de migration
- Configuration, liste des clients et liste des topics exportées depuis Mosquitto.
- Écarts fonctionnels (ACL, QoS 2, taille de message, persistance) résolus.
- Broker de destination créé sur une offre avec suffisamment de connexions.
- Un jeu d'identifiants émis par appareil ou service.
- Bridge en fonctionnement avec des topics directionnels ; données vérifiées des deux côtés.
- Consommateurs déplacés et vérifiés.
- Appareils déplacés par vagues avec points de contrôle.
- État retenu republié à la connexion.
- Solution de retour arrière conservée pendant la période d'observation.
- Ancien broker décommissionné et identifiants révoqués.
Le guide MQTT, du prototype à la production couvre des étapes de durcissement que vous voudrez peut-être intégrer au même projet.
Migrer vers ConnectMQ
Créez un broker gratuit sur app.connectmq.com avec l'offre Serverless, sans carte bancaire, et montez le bridge vers ce broker pour tester l'ensemble du runbook avant de vous engager. ConnectMQ vous offre un broker MQTT managé avec TLS, WebSockets, identifiants émis et un portail doté d'un explorateur de topics en direct. Pour comprendre les modèles de déploiement, lisez le guide sur le broker MQTT cloud, et utilisez le serveur MQTT public gratuit pour des essais rapides et non sensibles, jamais pour des données de production.
Questions fréquentes
Puis-je migrer Mosquitto vers MQTT cloud sans modifier le firmware des appareils ?
Uniquement si l'hôte, le port, les paramètres TLS, les identifiants et le client ID sont configurables sans mise à jour du firmware. Les appareils dont l'adresse du broker est codée en dur peuvent rester sur un Mosquitto local relié au cloud par un bridge.
Le bridge doit-il utiliser la QoS 1 ou la QoS 0 ?
La QoS 1 est le choix habituel pour relayer télémétrie et commandes, car elle protège les messages sur le lien du bridge. N'utilisez la QoS 0 que pour des données à haut débit où une perte occasionnelle est acceptable.
Les retained messages migrent-ils automatiquement ?
Les retained messages déjà présents sur Mosquitto ne sont pas copiés en bloc. Le bridge relaie les nouvelles publications ; faites republier par les appareils leur statut retenu à la connexion et vérifiez les topics retenus côté cloud.
Combien de temps conserver l'ancien broker Mosquitto ?
Conservez-le, avec le bridge actif, jusqu'à ce que chaque client soit stable sur le nouveau broker pendant une période convenue. Vous disposez ainsi d'une solution de retour arrière instantanée pour un coût très faible.
