Mosquitto: 5. GitLab CI

Diese Dokumentation ist Teil des GitHub Actions & GitLab CI-Leitfadens. Den vollständigen Leitfaden finden Sie hier: Starten Sie einen echten Mosquitto-Service direkt aus Ihrer GitHub Actions- oder GitLab CI-Pipeline, führen Sie Ihre Tests dagegen aus und fahren Sie ihn anschließend automatisch wieder herunter.

👋 Willkommen in der Stackhero-Dokumentation!

Stackhero bietet Ihnen eine vollständig verwaltete Mosquitto MQTT Cloud-Umgebung, die auf Zuverlässigkeit und Flexibilität ausgelegt ist:

• Unbegrenzter Nachrichtendurchsatz und unbegrenzte Datenübertragungen, damit Ihre Workflows niemals auf künstliche Grenzen stoßen.
• Unbegrenzte Geräteauthentifizierung über Ihre eigene externe API, um Onboarding und Zugriffsverwaltung nahtlos zu gestalten.
• Erweiterte ACLs für eine feingranulare Steuerung von Topics, Benutzern und Aktionen.
• Ein individueller Domainname mit integriertem HTTPS für sichere, markenkonforme Endpunkte (zum Beispiel: https://mqtt.your-company.com).
• Updates ohne Aufwand: Verbesserungen oder Sicherheitspatches mit nur einem Klick anwenden.
• Gleichbleibende Performance und hohe Sicherheit, da jede Instanz auf einer privaten, dedizierten Infrastruktur läuft.

Beschleunigen Sie Ihre IoT-Projekte und reduzieren Sie den Betriebsaufwand. Sie können in nur wenigen Minuten eine sichere, produktionsreife Mosquitto MQTT Cloud Hosting-Instanz bereitstellen.

Speichern Sie diese Konfiguration als .gitlab-ci.yml. Mit diesem Setup wird bei jedem Pipeline-Lauf eine frische, echte Mosquitto-Instanz für Ihre Tests bereitgestellt.

test:
  image: ubuntu:24.04
  variables:
    STACK_NAME: "ci-mosquitto-$CI_PIPELINE_ID-$CI_JOB_ID"
    INSTANCE: "200"   # Bei Bedarf anpassen (siehe Schritt 3)
    REGION: "europe"
    SERVICE_STORE: "mosquitto"
  # STACKHERO_TOKEN stammt aus der in Schritt 1 angelegten CI/CD-Variable.
  script:
    - set -euo pipefail
    - curl -fsSL https://www.stackhero.io/install.sh | sh
    - apt-get update && apt-get install -y --no-install-recommends jq curl mosquitto-clients
    - STACK_ID=$(stackhero --format=script stack-create --name="$STACK_NAME")
    - echo "STACK_ID=$STACK_ID" >> deploy.env
    - SERVICE_ID=$(stackhero --format=script service-add --stack="$STACK_ID" --service-store="$SERVICE_STORE" --instance="$INSTANCE" --region="$REGION")
    - echo "SERVICE_ID=$SERVICE_ID" >> deploy.env
    - stackhero service-wait-for --service="$SERVICE_ID"
    - config=$(stackhero service-configuration-get --service="$SERVICE_ID" --format=json)
    - host=$(echo "$config" | jq -r '.configuration.domain')
user=$(echo "$config" | jq -r '.configuration.authenticationUsers[0].login')
password=$(echo "$config" | jq -r '.configuration.authenticationUsers[0].password')
    # Publish a test message to a topic.
    - mosquitto_pub -h "$host" -p 8883 -u "$user" -P "$password" --capath /etc/ssl/certs -t "stackhero/ci" -m "hello"
    - echo "✅ Mosquitto ist aus der CI erreichbar."
    # Sie können hier Ihre eigene Test-Suite mit den oben extrahierten Zugangsdaten ausführen ...
  after_script:
    - test -f deploy.env && . ./deploy.env || true
    - >
      if [ -n "${SERVICE_ID:-}" ]; then
        stackhero service-delete --service="$SERVICE_ID" --confirm
        stackhero service-wait-for --service="$SERVICE_ID"
      fi
    - >
      if [ -n "${STACK_ID:-}" ]; then
        stackhero stack-delete --stack="$STACK_ID" --confirm
      fi

In GitLab erfolgt das Aufräumen im Abschnitt after_script. Dieser wird immer ausgeführt, auch wenn der Job fehlschlägt, sodass Ihre Mosquitto-Ressourcen entfernt werden und keine unnötigen Kosten entstehen.

In GitLab läuft after_script in einer frischen Shell. Um dies zu berücksichtigen, schreibt das Skript die Service- und Stack-IDs während des Jobs in deploy.env und lädt sie vor dem Aufräumen wieder ein. So wird sichergestellt, dass Ihre Ressourcen auch bei einem Fehler im Job entfernt werden.

Damit ist der komplette CI-Lebenszyklus für Mosquitto abgedeckt: Stack erstellen, Service hinzufügen, warten, Zugangsdaten abrufen, Smoke-Test, und immer aufräumen. Jeder Pipeline-Lauf erhält einen echten, isolierten Service – nach Abschluss bleibt nichts zurück. Weitere Informationen zu verfügbaren Befehlen und zur nicht-interaktiven Authentifizierung mit STACKHERO_TOKEN finden Sie in der vollständigen CLI-Dokumentation.