Alternativa ao Mosquitto na Nuvem: do Mosquitto Auto-hospedado ao Broker MQTT Gerenciado

Uma alternativa ao Mosquitto na nuvem é o que muitas equipes começam a procurar quando o seu primeiro servidor Mosquitto auto-hospedado vira algo de que os clientes dependem. Este artigo explica o que você mantém, o que ganha e do que abre mão ao migrar do Mosquitto auto-hospedado para um broker MQTT gerenciado 3.1.1/5.0, e mostra uma configuração de bridge que permite migrar um site de cada vez.

Por que o Mosquitto é tão popular

O Eclipse Mosquitto conquistou o seu lugar. Ele é open source, leve, bem documentado e roda em quase tudo, de um Raspberry Pi a uma VM grande. Suporta MQTT 3.1.1 e 5.0, TLS, WebSockets, arquivos de senha, arquivos de ACL e bridging. Suas ferramentas de linha de comando, mosquitto_pub e mosquitto_sub, são a forma padrão de muitos engenheiros testarem qualquer broker.

Para um laboratório, uma única casa ou uma rede de fábrica que nunca toca a internet, o Mosquitto muitas vezes é tudo de que você precisa. A questão de uma alternativa só surge quando o lado operacional começa a pesar mais do que a conveniência. Para uma visão mais ampla do cenário open source, veja a comparação de brokers MQTT open source.

Onde o Mosquitto auto-hospedado fica difícil

O broker raramente é o problema. O trabalho em volta dele é:

• Expô-lo à internet com segurança. Você precisa de um IP público ou nome DNS, regras de firewall, certificados TLS e sua renovação, e da certeza de que nenhum listener anônimo ficou aberto.
• Gerenciar usuários. O mosquitto_passwd e um arquivo de ACL em texto funcionam para dez dispositivos. Com centenas, você precisa de scripts de provisionamento e de uma forma de revogar credenciais rapidamente.
• Monitoramento. Você precisa coletar as estatísticas $SYS ou os logs, armazená-los e alertar alguém quando as conexões caírem.
• Atualizações. Atualizações de versão principal podem mudar padrões. O Mosquitto 2.0, por exemplo, mudou os padrões de listeners e de acesso anônimo, o que surpreendeu muitas instalações existentes.
• Projeto de nó único. O Mosquitto open source roda como um único processo de broker. Se essa máquina falhar, todos os clientes se desconectam até ela voltar.

Nada disso é uma crítica ao Mosquitto. É simplesmente o custo de operar qualquer broker por conta própria, tema abordado em mais detalhes em broker MQTT auto-hospedado vs. gerenciado.

O que você mantém com um broker MQTT gerenciado

Como um broker MQTT gerenciado fala o mesmo protocolo padrão, quase tudo o que você construiu é aproveitado:

• Código dos clientes. Paho, MQTT.js, PubSubClient, Node-RED e as ferramentas de CLI do Mosquitto funcionam sem alterações, exceto host, porta e credenciais.
• Estrutura de topics. A sua árvore de topics migra como está.
• Recursos do MQTT 5. Na ConnectMQ, estão disponíveis shared subscriptions (planos pagos), retained messages, session expiry, topic aliases, message expiry, response topics e reason codes.
• Seus hábitos de ferramentas. Você pode continuar usando o mosquitto_sub para depurar, inclusive contra o servidor MQTT público (gratuito) em broker.connectmq.com, que serve para testes e protótipos, não para dados de produção.

O que você ganha

• Nenhum servidor para operar. TLS na 8883 e Secure WebSocket na 8084 com certificado Let's Encrypt prontos desde o primeiro dia.
• Credenciais a partir de um portal em vez de arquivos de senha. Cada broker recebe usuário, senha e client ID gerados.
• Visibilidade integrada. O portal da ConnectMQ inclui um cliente MQTT no navegador, um explorador de topics ao vivo, um dashboard e regras de alerta por limite, para que você veja o tráfego sem instalar ferramentas extras.
• Proteções que, de outra forma, você teria que construir, como cotas por plano, proteção contra flood e bloqueio de IP após tentativas de login malsucedidas repetidas.
• Extras industriais, se forem relevantes: detecção de topics ISA-95 / Unified Namespace e decodificação de payloads Sparkplug B.

Do que você abre mão

Seja honesto sobre as contrapartidas antes de migrar:

Se ACLs por topic ou plugins personalizados forem centrais no seu projeto, mantenha o Mosquitto na borda e use o broker na nuvem para as partes que se beneficiam dele.

Perguntas para fazer à sua equipe primeiro

Antes de comparar provedores, alinhe internamente alguns pontos. Quais dispositivos precisam continuar funcionando quando o link de internet cair? Quem é hoje o responsável pelo servidor Mosquitto, e o que essa pessoa preferiria estar fazendo? Quais topics carregam comandos que alteram equipamentos físicos, e quem deveria poder publicar neles? Quantas conexões simultâneas você espera daqui a um ano, e não apenas hoje? As respostas definem se você precisa de um broker puramente na nuvem, de um modelo híbrido com um broker de borda local ou de uma implantação dedicada, e mantêm a avaliação focada nos seus requisitos em vez de em listas de recursos.

Avaliando uma alternativa ao Mosquitto na nuvem

Seja qual for o provedor considerado, verifique os pontos a seguir na documentação atual dele:

1. Versões do protocolo. Ele suporta MQTT 3.1.1 e 5.0, incluindo os recursos do MQTT 5 que você usa?
2. Portas e transportes. TLS na 8883, WebSocket e Secure WebSocket para aplicações no navegador.
3. Níveis de QoS e limites de tamanho de mensagem no plano que você realmente compraria.
4. Comportamento de retained messages e session expiry.
5. Modelo de autenticação. Usuário e senha, certificados de cliente ou ambos.
6. Camada gratuita. Dá para testar com dispositivos reais antes de pagar?
7. Modelos de implantação. Compartilhado, dedicado, na sua própria nuvem ou autogerenciado.
8. Caminho de saída. Dá para sair sem reescrever o firmware dos dispositivos? O artigo sobre vendor lock-in em MQTT explica o que observar.

Migrando aos poucos com uma bridge do Mosquitto

Você não precisa migrar tudo de uma vez. O recurso de bridge do Mosquitto pode encaminhar topics selecionados do seu servidor atual para um broker MQTT gerenciado. Adicione isto ao seu 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

Reinicie o Mosquitto e confira no log se a bridge se conectou com sucesso:

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

Depois verifique se os dados chegam à nuvem assinando com as credenciais do 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

Observe que o broker MQTT gerenciado vincula os client IDs às credenciais emitidas, então, para uma segunda conexão simultânea como esta sessão de depuração, use um client ID que tenha sido emitido para ela ou use o cliente no navegador do portal.

O padrão de bridge permite que dashboards e usuários remotos passem para o broker na nuvem enquanto os dispositivos locais continuam falando com a instância Mosquitto que já conhecem. Quando estiver confiante, você pode apontar os dispositivos diretamente para o broker MQTT gerenciado. O processo completo está descrito em migrar o Mosquitto para MQTT na nuvem.

Solução de problemas da bridge

• A bridge conecta e cai repetidamente. Outro cliente está usando o mesmo client ID. Cada conexão precisa do seu próprio ID.
• Erros de handshake TLS. Confirme se bridge_capath aponta para o repositório de CAs do sistema, ou use bridge_cafile com um bundle que inclua a cadeia da Let's Encrypt.
• Mensagens não encaminhadas. Verifique o padrão do topic e a direção (out envia do local para o remoto, in recebe do remoto para o local).
• QoS 2 rejeitado. Os planos Serverless gratuitos suportam QoS até 1, então faça a bridge com QoS 1 ou faça upgrade.

Experimente um broker MQTT gerenciado ao lado do Mosquitto

Você pode testar o lado gerenciado sem tocar na produção. Crie um broker Serverless gratuito na ConnectMQ, sem cartão de crédito, adicione o bloco de bridge acima a uma instância Mosquitto de teste e veja os seus topics aparecerem no explorador de topics ao vivo. Para entender as opções com mais profundidade, leia o guia de broker MQTT na nuvem ou descubra o que um broker MQTT gerenciado tira das suas costas. Mais sobre a plataforma em connectmq.com.

Perguntas frequentes

Existe uma versão hospedada do Mosquitto?

Alguns fornecedores oferecem o Mosquitto hospedado ou com suporte comercial. Como alternativa, qualquer broker MQTT gerenciado compatível com o padrão funciona com clientes e bridges do Mosquitto, já que o protocolo é o mesmo.

Meus clientes Mosquitto vão funcionar com um broker MQTT gerenciado?

Sim. Clientes que falam MQTT 3.1.1 ou 5.0 só precisam de novos host, porta, credenciais e client ID.

Posso manter o Mosquitto na borda e usar a nuvem também?

Sim. Uma bridge encaminha topics selecionados de um Mosquitto local para o broker na nuvem, um padrão comum em fábricas, fazendas, mineradoras e outros sites com conectividade instável.

Perco as ACLs ao deixar o Mosquitto?

Depende do provedor. A ConnectMQ isola os tenants e vincula client IDs às credenciais, mas não oferece ACLs por topic; portanto, mantenha o Mosquitto na borda se você depender delas.