Birçok ekip, kendi sunucularında barındırdıkları ilk Mosquitto sunucusu müşterilerin bağımlı olduğu bir şeye dönüştüğünde bir Mosquitto bulut alternatifi aramaya başlar. Bu makale, kendi sunucunuzdaki Mosquitto'dan yönetilen bir MQTT 3.1.1/5.0 broker'a geçerken neleri koruduğunuzu, neler kazandığınızı ve nelerden vazgeçtiğinizi açıklıyor ve her seferinde bir sahayı taşımanızı sağlayan bir bridge yapılandırması gösteriyor.
Mosquitto Neden Bu Kadar Popüler
Eclipse Mosquitto bu yeri hak etti. Açık kaynaklıdır, hafiftir, iyi belgelenmiştir ve bir Raspberry Pi'den büyük bir VM'ye kadar hemen her şeyde çalışır. MQTT 3.1.1 ve 5.0, TLS, WebSocket, parola dosyaları, ACL dosyaları ve bridge özelliğini destekler. Komut satırı araçları mosquitto_pub ve mosquitto_sub, birçok mühendisin herhangi bir broker'ı test etmek için varsayılan yoludur.
Bir laboratuvar, tek bir ev ya da internete hiç dokunmayan bir tesis ağı için Mosquitto çoğu zaman ihtiyacınız olan her şeydir. Alternatif sorusu ancak operasyonel taraf kolaylığın önüne geçmeye başladığında gündeme gelir. Açık kaynak alanına daha geniş bir bakış için açık kaynak MQTT broker karşılaştırmasına göz atın.
Kendi Sunucunuzdaki Mosquitto Nerede Zorlaşır
Sorun nadiren broker'ın kendisidir. Asıl iş onun etrafındadır:
- Onu internete güvenli şekilde açmak. Public bir IP ya da DNS adına, güvenlik duvarı kurallarına, TLS sertifikalarına ve bunların yenilenmesine, ayrıca hiçbir anonim listener'ın açık bırakılmadığından emin olmaya ihtiyacınız vardır.
- Kullanıcıları yönetmek.
mosquitto_passwdve metin tabanlı bir ACL dosyası on cihaz için işe yarar. Yüzlerce cihazda provisioning betiklerine ve kimlik bilgilerini hızla iptal etmenin bir yoluna ihtiyaç duyarsınız. - İzleme.
$SYSistatistiklerini ya da logları toplamalı, saklamalı ve bağlantılar düştüğünde birini uyarmalısınız. - Yükseltmeler. Ana sürüm yükseltmeleri varsayılanları değiştirebilir. Örneğin Mosquitto 2.0, listener ve anonim erişim varsayılanlarını değiştirdi ve bu da birçok mevcut kurulumu şaşırttı.
- Tek düğümlü tasarım. Açık kaynak Mosquitto tek bir broker süreci olarak çalışır. O makine arızalanırsa tüm istemciler, makine geri gelene kadar bağlantısız kalır.
Bunların hiçbiri Mosquitto'ya yönelik bir eleştiri değildir. Bu, herhangi bir broker'ı kendiniz işletmenin maliyetidir ve kendi sunucunuzda vs yönetilen MQTT broker yazısında daha kapsamlı ele alınıyor.
Yönetilen Bir Broker ile Neleri Korursunuz
Yönetilen bir broker aynı standart protokolü konuştuğu için oluşturduğunuz hemen her şey aynen taşınır:
- İstemci kodu. Paho, MQTT.js, PubSubClient, Node-RED ve Mosquitto'nun CLI araçları; host, port ve kimlik bilgileri dışında değişmeden çalışır.
- Topic yapısı. Topic ağacınız olduğu gibi taşınır.
- MQTT 5 özellikleri. ConnectMQ'da shared subscription'lar (ücretli planlar), retained message'lar, session expiry, topic alias'ları, message expiry, response topic'leri ve reason code'lar kullanılabilir.
- Araç alışkanlıklarınız. Hata ayıklamak için
mosquitto_subkullanmaya devam edebilirsiniz.
Neler Kazanırsınız
- Çalıştırılacak sunucu yok. Let's Encrypt sertifikalı 8883 portunda TLS ve 8084 portunda Secure WebSocket ilk günden hazırdır.
- Parola dosyaları yerine portaldan kimlik bilgileri. Her broker üretilmiş bir kullanıcı adı, parola ve client ID alır.
- Yerleşik görünürlük. ConnectMQ portalı tarayıcı içi bir MQTT istemcisi, canlı bir topic gezgini, bir dashboard ve eşik alarm kuralları içerir; böylece ek araç kurmadan trafiği görebilirsiniz.
- Aksi halde kendiniz inşa edeceğiniz korumalar; örneğin plan bazlı kotalar, flood koruması ve tekrarlanan başarısız girişlerden sonra IP engelleme.
- İlgiliyse endüstriyel ekstralar: ISA-95 / Unified Namespace topic'lerinin tespiti ve Sparkplug B payload'larının çözümlenmesi.
Nelerden Vazgeçersiniz
Taşımadan önce ödünleşimler konusunda dürüst olun:
| Mosquitto yeteneği | Yönetilen broker açısından dikkat edilecek nokta |
|---|---|
| Özel kimlik doğrulama ya da ACL eklentileri | Bunun yerine sağlayıcının kimlik doğrulama modelini kullanırsınız |
| Topic başına ayrıntılı ACL dosyaları | Hizmetin hangi erişim kontrolünü sunduğunu kontrol edin; ConnectMQ kiracıları izole eder ve client ID'leri kimlik bilgilerine bağlar, ancak topic başına ACL sunmaz |
| Her yapılandırma seçeneği üzerinde tam kontrol | Yalnızca hizmetin sunduğu ayarlar değiştirilebilir |
| Tamamen çevrimdışı çalışma | Bir bulut broker internet erişimi gerektirir; çevrimdışı sahalar için yerel bir broker tutun |
| Seçtiğiniz sınırsız mesaj boyutu | Plan sınırları geçerlidir; örneğin ücretsiz Serverless'ta 256 KB, ücretli Serverless'ta 1 MB |
Topic başına ACL'ler ya da özel eklentiler tasarımınızın merkezindeyse Mosquitto'yu uçta (edge) tutun ve bulut broker'ı ondan fayda sağlayan kısımlar için kullanın.
Önce Ekibinize Sormanız Gereken Sorular
Sağlayıcıları karşılaştırmadan önce birkaç nokta üzerinde kendi içinizde uzlaşın. İnternet bağlantısı kesildiğinde hangi cihazların çalışmaya devam etmesi gerekir? Mosquitto sunucusundan şu anda kim sorumlu ve o kişi bunun yerine ne yapmayı tercih ederdi? Hangi topic'ler fiziksel ekipmanı değiştiren komutlar taşıyor ve bunlara kimler yayın yapabilmeli? Yalnızca bugün değil, bir yıl içinde kaç eşzamanlı bağlantı bekliyorsunuz? Yanıtlar; saf bir bulut broker'a mı, yerel bir edge broker'lı hibrit bir yapıya mı yoksa dedicated bir dağıtıma mı ihtiyacınız olduğuna karar verir ve değerlendirmeyi özellik listeleri yerine gereksinimlerinize odaklı tutar.
Bir Mosquitto Bulut Alternatifini Değerlendirmek
Hangi sağlayıcıyı düşünürseniz düşünün, aşağıdakileri onun güncel dokümantasyonuyla karşılaştırın:
- Protokol sürümleri. Kullandığınız MQTT 5 özellikleri dahil hem MQTT 3.1.1'i hem 5.0'ı destekliyor mu?
- Portlar ve taşıma katmanları. 8883 portunda TLS, tarayıcı uygulamaları için WebSocket ve Secure WebSocket.
- Gerçekte satın alacağınız plandaki QoS seviyeleri ve mesaj boyutu sınırları.
- Retained message ve session expiry davranışı.
- Kimlik doğrulama modeli. Kullanıcı adı ve parola, istemci sertifikaları ya da her ikisi.
- Ücretsiz katman. Ödeme yapmadan önce gerçek cihazlarla test edebiliyor musunuz?
- Dağıtım modelleri. Paylaşımlı, dedicated, kendi bulutunuzda ya da kendi yönetiminizde.
- Çıkış yolu. Cihaz firmware'ini yeniden yazmadan ayrılabilir misiniz? MQTT tedarikçi bağımlılığı makalesi nelere dikkat etmeniz gerektiğini açıklıyor.
Bir Mosquitto Bridge ile Kademeli Taşıma
Her şeyi aynı anda geçirmek zorunda değilsiniz. Mosquitto'nun bridge özelliği, mevcut sunucunuzdan seçilen topic'leri yönetilen bir broker'a iletebilir. Bunu mosquitto.conf dosyanıza ekleyin (Mosquitto 2.x):
# Yerel Mosquitto'yu TLS üzerinden bir ConnectMQ broker'a bridge ile bağla
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
# Tesis telemetrisini buluta ilet, komutları geri al
topic plant1/+/+/telemetry out 1
topic plant1/+/+/cmd in 1
Mosquitto'yu yeniden başlatın ve başarılı bir bridge bağlantısı için logu kontrol edin:
sudo systemctl restart mosquitto
sudo journalctl -u mosquitto -n 50 --no-pager
Ardından broker kimlik bilgileriyle abone olarak verinin buluta ulaştığını doğrulayın:
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
Yönetilen broker'ın client ID'leri verilen kimlik bilgilerine bağladığını unutmayın; bu nedenle bu hata ayıklama oturumu gibi ikinci bir eşzamanlı bağlantı için size bu amaçla verilmiş bir client ID kullanın ya da bunun yerine portaldaki tarayıcı içi istemciyi kullanın.
Bridge modeli, yerel cihazlar zaten tanıdıkları Mosquitto örneğiyle konuşmaya devam ederken dashboard'ların ve uzak kullanıcıların bulut broker'a geçmesini sağlar. Emin olduğunuzda cihazları doğrudan yönetilen broker'a yönlendirebilirsiniz. Sürecin tamamı Mosquitto'yu bulut MQTT'ye taşıma yazısında anlatılıyor.
Bridge Sorunlarını Giderme
- Bridge bağlanıyor, sonra sürekli düşüyor. Başka bir istemci aynı client ID'yi kullanıyor. Her bağlantının kendi kimliği olmalıdır.
- TLS el sıkışma hataları.
bridge_capathdeğerinin sistem CA deposunu gösterdiğini doğrulayın ya da Let's Encrypt zincirini içeren bir paketlebridge_cafilekullanın. - Mesajlar iletilmiyor. Topic desenini ve yönü kontrol edin (
outyerelden uzağa gönderir,inuzaktan yerele alır). - QoS 2 reddediliyor. Ücretsiz Serverless planları QoS 1'e kadar destekler; bu yüzden bridge'i QoS 1 ile kurun ya da planınızı yükseltin.
Mosquitto'nun Yanında Yönetilen Bir Broker Deneyin
Üretime dokunmadan yönetilen tarafı test edebilirsiniz. Kredi kartı gerektirmeden ConnectMQ'da ücretsiz bir Serverless broker oluşturun, yukarıdaki bridge bloğunu test amaçlı bir Mosquitto örneğine ekleyin ve topic'lerinizin canlı topic gezgininde belirmesini izleyin. Seçenekleri daha derinlemesine anlamak için bulut MQTT broker rehberini okuyun ya da yönetilen bir MQTT broker'ın üzerinizden neleri aldığını öğrenin. Platform hakkında daha fazlası connectmq.com adresinde.
Sık Sorulan Sorular
Mosquitto'nun barındırılan bir sürümü var mı?
Bazı tedarikçiler barındırılan ya da ticari destekli Mosquitto sunar. Alternatif olarak, protokol aynı olduğundan standartlara uygun herhangi bir yönetilen MQTT broker Mosquitto istemcileri ve bridge'leriyle çalışır.
Mosquitto istemcilerim yönetilen bir broker ile çalışır mı?
Evet. MQTT 3.1.1 veya 5.0 konuşan istemciler yalnızca yeni bir host, port, kimlik bilgileri ve client ID'ye ihtiyaç duyar.
Mosquitto'yu uçta tutup bulutu da kullanabilir miyim?
Evet. Bir bridge, seçilen topic'leri yerel bir Mosquitto'dan bulut broker'a iletir; bu, bağlantısı güvenilir olmayan tesisler ve sahalar için yaygın bir modeldir.
Mosquitto'dan ayrılırken ACL'leri kaybeder miyim?
Sağlayıcıya bağlıdır. ConnectMQ kiracıları izole eder ve client ID'leri kimlik bilgilerine bağlar, ancak topic başına ACL sunmaz; bu yüzden onlara güveniyorsanız Mosquitto'yu uçta tutun.
