Alternative cloud à Mosquitto : passer de Mosquitto auto-hébergé à un broker MQTT managé

Une alternative cloud à Mosquitto, c'est ce que de nombreuses équipes se mettent à chercher dès que leur premier serveur Mosquitto auto-hébergé devient quelque chose dont les clients dépendent. Cet article explique ce que vous conservez, ce que vous gagnez et ce à quoi vous renoncez en passant de Mosquitto auto-hébergé à un broker MQTT managé compatible MQTT 3.1.1/5.0, et présente une configuration de bridge qui permet de migrer site par site.

Pourquoi Mosquitto est si populaire

Eclipse Mosquitto a mérité sa place. Il est open source, léger, bien documenté et tourne sur presque tout, d'un Raspberry Pi à une grosse VM. Il prend en charge MQTT 3.1.1 et 5.0, TLS, les WebSockets, les fichiers de mots de passe, les fichiers d'ACL et le bridging. Ses outils en ligne de commande, mosquitto_pub et mosquitto_sub, sont l'outil par défaut de nombreux ingénieurs pour tester n'importe quel broker.

Pour un laboratoire, une maison connectée ou un réseau d'usine qui ne touche jamais Internet, Mosquitto suffit souvent. La question d'une alternative ne se pose que lorsque la charge d'exploitation commence à l'emporter sur la commodité. Pour un panorama plus large des solutions open source, consultez le comparatif des brokers MQTT open source.

Là où Mosquitto auto-hébergé devient difficile

Le broker est rarement le problème. C'est le travail autour qui l'est :

• L'exposer à Internet en toute sécurité. Il vous faut une IP publique ou un nom DNS, des règles de pare-feu, des certificats TLS et leur renouvellement, et l'assurance qu'aucun listener anonyme n'a été laissé ouvert.
• Gérer les utilisateurs. mosquitto_passwd et un fichier d'ACL texte fonctionnent pour dix appareils. Avec des centaines, il vous faut des scripts de provisioning et un moyen de révoquer rapidement des identifiants.
• La supervision. Vous devez collecter les statistiques $SYS ou les logs, les stocker et alerter quelqu'un lorsque des connexions tombent.
• Les mises à jour. Les montées de version majeures peuvent modifier les valeurs par défaut. Mosquitto 2.0, par exemple, a changé les réglages par défaut des listeners et de l'accès anonyme, ce qui a surpris de nombreuses installations existantes.
• Une conception mono-nœud. Mosquitto open source fonctionne comme un unique processus de broker. Si cette machine tombe, tous les clients sont déconnectés jusqu'à son retour.

Rien de tout cela n'est une critique de Mosquitto. C'est simplement le coût d'exploitation de n'importe quel broker par vos soins, abordé plus en détail dans broker MQTT auto-hébergé ou managé.

Ce que vous conservez avec un broker MQTT managé

Comme un broker MQTT managé parle le même protocole standard, presque tout ce que vous avez construit est réutilisable :

• Le code client. Paho, MQTT.js, PubSubClient, Node-RED et les outils CLI de Mosquitto fonctionnent tels quels, à l'exception de l'hôte, du port et des identifiants.
• La structure des topics. Votre arborescence de topics migre telle quelle.
• Les fonctionnalités MQTT 5. Sur ConnectMQ, les abonnements partagés (plans payants), les retained messages, l'expiration de session, les alias de topic, l'expiration des messages, les response topics et les reason codes sont disponibles.
• Vos habitudes d'outillage. Vous pouvez continuer à utiliser mosquitto_sub pour déboguer.

Ce que vous gagnez

• Aucun serveur à exploiter. TLS sur le port 8883 et Secure WebSocket sur le port 8084 avec un certificat Let's Encrypt sont prêts dès le premier jour.
• Des identifiants issus d'un portail au lieu de fichiers de mots de passe. Chaque broker reçoit un nom d'utilisateur, un mot de passe et un client ID générés.
• Une visibilité intégrée. Le portail ConnectMQ comprend un client MQTT dans le navigateur, un explorateur de topics en direct, un tableau de bord et des règles d'alerte sur seuil : vous voyez le trafic sans installer d'outils supplémentaires.
• Des protections que vous devriez sinon construire vous-même, comme les quotas par plan, la protection contre l'inondation de messages et le blocage d'IP après des échecs de connexion répétés.
• Des extras industriels le cas échéant : détection des topics ISA-95 / Unified Namespace et décodage des payloads Sparkplug B.

Ce à quoi vous renoncez

Soyez lucide sur les compromis avant de migrer :

Si les ACL par topic ou les plugins personnalisés sont au cœur de votre conception, gardez Mosquitto en edge et utilisez le broker cloud pour les parties qui en tirent profit.

Les questions à poser d'abord à votre équipe

Avant de comparer les fournisseurs, mettez-vous d'accord en interne sur quelques points. Quels appareils doivent continuer à fonctionner quand le lien Internet est coupé ? Qui est aujourd'hui responsable du serveur Mosquitto, et à quoi préférerait-il consacrer son temps ? Quels topics transportent des commandes qui modifient des équipements physiques, et qui doit pouvoir y publier ? Combien de connexions simultanées prévoyez-vous dans un an, et pas seulement aujourd'hui ? Les réponses déterminent s'il vous faut un broker purement cloud, une architecture hybride avec un broker edge local ou un déploiement dédié, et elles gardent l'évaluation centrée sur vos exigences plutôt que sur des listes de fonctionnalités.

Évaluer une alternative cloud à Mosquitto

Quel que soit le fournisseur envisagé, vérifiez les points suivants dans sa documentation à jour :

1. Versions du protocole. Prend-il en charge MQTT 3.1.1 et 5.0, y compris les fonctionnalités MQTT 5 que vous utilisez ?
2. Ports et transports. TLS sur 8883, WebSocket et Secure WebSocket pour les applications web.
3. Niveaux de QoS et limites de taille des messages sur le plan que vous achèteriez réellement.
4. Comportement des retained messages et de l'expiration de session.
5. Modèle d'authentification. Nom d'utilisateur et mot de passe, certificats clients, ou les deux.
6. Offre gratuite. Pouvez-vous tester avec de vrais appareils avant de payer ?
7. Modèles de déploiement. Mutualisé, dédié, dans votre propre cloud ou auto-géré.
8. Porte de sortie. Pouvez-vous partir sans réécrire le firmware des appareils ? L'article sur la dépendance fournisseur MQTT explique à quoi faire attention.

Migrer progressivement avec un bridge Mosquitto

Inutile de tout basculer d'un coup. La fonction de bridge de Mosquitto peut relayer certains topics de votre serveur existant vers un broker MQTT managé. Ajoutez ceci à votre mosquitto.conf (Mosquitto 2.x) :

# Bridge local Mosquitto to a ConnectMQ broker over TLS
connection connectmq-bridge
address broker.connectmq.com:8883
bridge_protocol_version mqttv50
bridge_capath /etc/ssl/certs
remote_clientid YOUR_CLIENT_ID
remote_username YOUR_USERNAME
remote_password YOUR_PASSWORD
cleansession false
restart_timeout 10 60

# Forward plant telemetry to the cloud, receive commands back
topic plant1/+/+/telemetry out 1
topic plant1/+/+/cmd in 1

Redémarrez Mosquitto et vérifiez dans le log que le bridge s'est bien connecté :

sudo systemctl restart mosquitto
sudo journalctl -u mosquitto -n 50 --no-pager

Vérifiez ensuite que les données arrivent dans le cloud en vous abonnant avec les identifiants du broker :

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

Notez que le broker MQTT managé lie les client ID aux identifiants délivrés : pour une seconde connexion simultanée comme cette session de débogage, utilisez un client ID qui vous a été délivré à cet effet, ou utilisez plutôt le client intégré au navigateur dans le portail.

Le schéma du bridge permet aux tableaux de bord et aux utilisateurs distants de passer sur le broker cloud pendant que les appareils locaux continuent de dialoguer avec l'instance Mosquitto qu'ils connaissent déjà. Une fois en confiance, vous pouvez rediriger les appareils directement vers le broker MQTT managé. Le processus complet est décrit dans migrer Mosquitto vers un MQTT cloud.

Dépannage du bridge

• Le bridge se connecte puis décroche en boucle. Un autre client utilise le même client ID. Chaque connexion a besoin de son propre ID.
• Erreurs de handshake TLS. Vérifiez que bridge_capath pointe vers le magasin de CA du système, ou utilisez bridge_cafile avec un bundle incluant la chaîne Let's Encrypt.
• Messages non relayés. Vérifiez le motif de topic et le sens (out envoie du local vers le distant, in reçoit du distant vers le local).
• QoS 2 refusé. Les plans Serverless gratuits prennent en charge QoS jusqu'à 1 : configurez le bridge en QoS 1 ou passez à une offre supérieure.

Essayez un broker MQTT managé en parallèle de Mosquitto

Vous pouvez tester la partie managée sans toucher à la production. Créez un broker Serverless gratuit sur ConnectMQ sans carte bancaire, ajoutez le bloc de bridge ci-dessus à une instance Mosquitto de test et regardez vos topics apparaître dans l'explorateur de topics en direct. Pour approfondir les options, lisez le guide du broker MQTT cloud ou découvrez ce qu'un broker MQTT managé vous enlève comme travail. Pour vérifier vos outils en ligne de commande sans compte, le serveur MQTT public gratuit broker.connectmq.com accepte aussi les connexions anonymes, uniquement pour des tests et des données factices. Plus d'informations sur la plateforme sur connectmq.com.

Questions fréquentes

Existe-t-il une version hébergée de Mosquitto ?

Certains éditeurs proposent Mosquitto en version hébergée ou avec support commercial. À défaut, n'importe quel broker MQTT managé conforme aux standards fonctionne avec les clients et les bridges Mosquitto, puisque le protocole est le même.

Mes clients Mosquitto fonctionneront-ils avec un broker MQTT managé ?

Oui. Les clients qui parlent MQTT 3.1.1 ou 5.0 n'ont besoin que d'un nouvel hôte, d'un nouveau port, d'identifiants et d'un client ID.

Puis-je garder Mosquitto en edge et utiliser aussi le cloud ?

Oui. Un bridge relaie certains topics d'un Mosquitto local vers le broker cloud, un schéma courant pour les usines et les sites à la connectivité peu fiable.

Est-ce que je perds les ACL en quittant Mosquitto ?

Cela dépend du fournisseur. ConnectMQ isole les tenants et lie les client ID aux identifiants, mais ne propose pas d'ACL par topic : gardez Mosquitto en edge si vous en dépendez.