MQTT Geliştirme, Staging ve Üretim Ortamlarını Kurmak

MQTT'yi geliştirme, staging ve üretim ortamlarında çalıştırmanın en temiz yolu kısaca şöyledir: her ortama kendi broker'ını (ya da izole bir broker instance'ını) ve kendi kimlik bilgilerini verin, topic adlarını ortamlar arasında aynı tutun ve kod bir ortamdan diğerine geçerken yalnızca yapılandırmayı (URL, kullanıcı adı, parola) değiştirin. Bu rehberin geri kalanı, bu süreci sıkıcı ve güvenli hale getirmekle ilgili.

Her ortam ne işe yarar

Staging ancak üretim gibi davranıyorsa işe yarar. TLS'i, kimlik doğrulaması olmayan ya da ACL'leri sonuna kadar açık bir staging broker'ı, üretimde ilk gün patlayacak release'leri gönül rahatlığıyla geçirir.

Ortamları ayırmanın üç yolu

Hangisini seçerseniz seçin, üretim asla testlerle aynı broker'ı paylaşmaz. Bir yük testi, kontrolden çıkmış bir simülatör ya da yanlışlıkla publish edilmiş bir retained mesaj gerçek cihazlara ulaşamamalıdır.

Topic öneklerini doğru kullanmak

Ortam başına bir broker varsa ortam adını topic'e hiç koymayın. factory/line1/temp staging'de ve üretimde aynı topic'tir; böylece subscription'lar, dashboard'lar, kurallar ve ACL dosyaları hiç düzenlenmeden taşınabilir.

Ortamlar bir broker'ı paylaşıyorsa önek zorunludur ve tek bir yerde eklenmelidir. En kötü desen, koda dağılmış ortam kontrolleridir (if env == "prod": topic = ...). Her topic'i yapılandırılmış öneki başa ekleyen bir yardımcı fonksiyonla oluşturun ve ortamın kendi broker'ı varsa öneki boş bırakın:

import mqtt from "mqtt";

export const ENV = process.env.APP_ENV ?? "dev";
const url = process.env.MQTT_URL;
const prefix = process.env.MQTT_TOPIC_PREFIX ?? "";   // ortamın kendi broker'ı varsa ""

if (!url) throw new Error("MQTT_URL is not set");

export const topic = (t) => (prefix ? `${prefix}/${t}` : t);

export function connect(name) {
  return mqtt.connect(url, {
    clientId: `${name}-${ENV}-${Math.random().toString(16).slice(2, 8)}`,
    username: process.env.MQTT_USER,
    password: process.env.MQTT_PASS,
    protocolVersion: 5,
    reconnectPeriod: 2000,
  });
}

import { connect, topic } from "./mqtt-config.mjs";

const client = connect("ingest");
client.on("connect", () => client.subscribe(topic("factory/+/temp"), { qos: 1 }));

Ortam adını client ID'ye eklemek broker loglarını da okunur kılar: ingest-stg-3fa9c1'in bir staging servisi olduğunu hemen görürsünüz. Paylaşılan bir geliştirme broker'ında her geliştiriciye testmqtt/dev-alice gibi kişisel bir önek verin ki denemeler asla çakışmasın; ayrıntılar testlerin asla çakışmaması için test topic'lerini adlandırma yazısında.

Ortam başına kimlik bilgileri ve ACL'ler

Her ortamın kendi kullanıcıları olur ve bir ortamın kimlik bilgisi diğerinde işe yaramamalıdır. Kullanıcıları servis ve ortama göre adlandırın (ingest-stg, ingest-prod); böylece sızdırılmış veya yanlış kullanılan bir kimlik bilgisi loglarda hemen göze çarpar.

Paylaşılan bir geliştirme/staging broker'ında ortamları gerçekten ayıran şey ACL'lerdir. Bu durum için bir Mosquitto ACL dosyası:

user ingest-dev
topic read dev/telemetry/#
topic write dev/cmd/#

user ingest-stg
topic read stg/telemetry/#
topic write stg/cmd/#

Ayrıma güvenmek yerine onu doğrulayın: dev kullanıcısıyla bağlanın ve stg/# topic'ine subscribe olmayı deneyin. MQTT 5'te broker SUBACK içinde bir hata kodu (0x87 Not authorized) döndürür; MQTT 3.1.1'de 0x80 alırsınız ya da hiç mesaj gelmez. MQTT ACL izinlerini test etme yazısı bu negatif testleri nasıl otomatikleştireceğinizi gösteriyor.

Ortam başına yapılandırma

Her ortam için bir yapılandırma dosyası tutun ve uygulama açılırken yükleyin; kod aynı kalır.

APP_ENV=dev
MQTT_URL=mqtt://broker.connectmq.com:1883
MQTT_USER=username
MQTT_PASS=password
MQTT_TOPIC_PREFIX=testmqtt/dev-alice

APP_ENV=staging
MQTT_URL=mqtts://<your-staging-host>:8883
MQTT_USER=ingest-stg
MQTT_PASS=<secret store'unuzdan>
MQTT_TOPIC_PREFIX=

Üretim değerleri yalnızca üretim deployment'ının secret store'unda bulunur; asla repoda ve asla CI test job'larında değil. Bir hatanın test paketini üretime yönlendirememesi için test kurulumuna bir koruma ekleyin:

import { ENV } from "../mqtt-config.mjs";

if (ENV === "prod" || ENV === "production") {
  throw new Error("Refusing to run tests against production");
}

Cihazlar da aynı disiplini gerektirir. Firmware broker'ı koda gömmemelidir; ortam, cihazın kimlik bilgileriyle birlikte provisioning sırasında atanır, böylece bir staging cihazı üretim filosuna karışamaz. Bkz. MQTT cihaz provisioning.

Broker yapılandırmasını ortamlar arasında taşımak

Broker yapılandırması (listener'lar, TLS ayarları, limitler, ACL dosyaları) ortamlar arasında tıpkı kod gibi ilerlemelidir:

1. Broker yapılandırmasını git'te tek bir şablon ve ortam başına değerler (host adları, sertifika yolları, limitler) olarak tutun. Mosquitto yapılandırma üreteci, doğru bir başlangıç dosyası oluşturmanın hızlı bir yoludur.
2. ACL değişikliklerini kod gibi gözden geçirin; yanlış satırdaki tek bir # her şeyi açar.
3. Değişikliği önce geliştirmeye, sonra staging'e uygulayın, testleri çalıştırın ve ancak bundan sonra aynı commit'i üretime taşıyın.
4. Her release'den önce staging ile üretimi karşılaştırın. Host adı, secret veya kapasite limiti dışındaki her fark, ortaya çıkmayı bekleyen bir bug'dır.

Her ortamda smoke test

Her deployment'tan sonra o ortamın kendi kimlik bilgileriyle uçtan uca bir gidiş-dönüş testi çalıştırın. Aynı script her yerde çalışır:

#!/usr/bin/env bash
set -euo pipefail
: "${MQTT_HOST:?}" "${MQTT_USER:?}" "${MQTT_PASS:?}"
T="${MQTT_TOPIC_PREFIX:-testmqtt}/smoke/$(date +%s)"
OUT=$(mktemp)
mosquitto_sub -h "$MQTT_HOST" -p 8883 --capath /etc/ssl/certs \
  -u "$MQTT_USER" -P "$MQTT_PASS" -t "$T" -C 1 -W 10 > "$OUT" &
sleep 1
mosquitto_pub -h "$MQTT_HOST" -p 8883 --capath /etc/ssl/certs \
  -u "$MQTT_USER" -P "$MQTT_PASS" -t "$T" -m ok -q 1
wait
grep -qx ok "$OUT" && echo "smoke test passed on $MQTT_HOST"

-W 10, on saniye içinde hiçbir şey gelmezse subscriber'ın hatayla çıkmasını sağlar; böylece bozuk bir ortam pipeline'ı askıda bırakmak yerine başarısız kılar. Daha kapsamlı bir sürüm için MQTT smoke test scripti yazısına bakın; elle kontrol için ortamın kimlik bilgileriyle online MQTT client üzerinden bağlanın.

Sık yapılan hatalar

• Her yerde aynı kimlik bilgileri. Sızan bir geliştirme parolası üretim olayına dönüşür.
• TLS'siz veya kimlik doğrulamasız staging. Sertifika ve izin hataları ilk kez üretimde ortaya çıkar.
• İş mantığında ortam kontrolleri. Kod dallarını değil, yapılandırmayı taşıyın.
• Paylaşılan broker'da kalan retained test verileri. Test çalıştırmalarından sonra temizleyin, yoksa sonraki çalıştırmalar eskimiş durumu okur.
• Unutulmuş staging cihazları. Eski bir yapılandırma yüzünden üretime bağlanan test donanımı gerçek verileri kirletir.

Canlıya çıkmadan önce MQTT üretim kontrol listesini staging'e değil, doğrudan üretim ortamına karşı uygulayın.

Ayrı broker'lar, ayrı kimlik bilgileri, aynı topic'ler ve yapılandırmanın değiştiği tek bir yer: bu dört kuralla bir release'i geliştirmeden staging'e ve üretime taşımak bir göç değil, bir yapılandırma değişikliği ve bir smoke testten ibarettir.

Sıkça sorulan sorular