Zum Inhalt springen

Installation & Betrieb

buzzle Commerce Core ist als cloud-natives, containerisiertes System ausgelegt. Alle Komponenten laufen als eigenständige Container und lassen sich vom lokalen Entwicklungsrechner bis zum produktiven Cluster identisch betreiben. Diese Seite gibt den Überblick über die Bausteine des Betriebs; die konkrete Ausbaustufe stimmst du mit deinem Ansprechpartner bei bambit ab.

Eine vollständige Umgebung besteht aus den Diensten der Plattform und ihren Infrastrukturabhängigkeiten:

  • API Gateway – der öffentliche Eingang (ASP.NET Core / YARP).
  • Service Platform – der modulare Backend-Layer mit den Modulen.
  • ZitadelBridge – die Identity-Integration, ideal als Sidecar neben Zitadel.
  • Zitadel – der Identity-Provider.
  • SQL Server – die relationale Datenhaltung der Module.
  • Elasticsearch – der Suchindex für das Search-Modul.
  • RabbitMQ – der Nachrichtenbus.

Alle Eigenkomponenten basieren auf .NET 10 und werden als Docker-Images bereitgestellt.

Die Dienste werden über Konfigurationsdateien (appsettings.json und umgebungsspezifische Varianten) und Umgebungsvariablen konfiguriert; Umgebungsvariablen haben Vorrang. Das erlaubt es, dasselbe Image in unterschiedlichen Umgebungen einzusetzen und nur die Umgebungswerte zu ändern.

Wichtige Konfigurationsbereiche sind unter anderem:

  • Sicherheit / Identity – Adresse des Identity-Servers (Authority) und die Introspection-Zugangsdaten des Gateways.
  • Modul-Discovery – die Adresse(n), unter denen das Gateway die Service Platform nach Modulen abfragt, samt Aktualisierungs- und Wiederholintervallen.
  • Modul-Konfiguration – je Modul ein typisierter Abschnitt unter ServicePlatformModules (etwa Datenbank-Schema und Verbindungsname).
  • Messaging – die Verbindung zum RabbitMQ-Broker und die Eingangs-Queues.
  • ZitadelBridge – die deklarative Beschreibung von Organisation, Projekt, Rollen und OIDC-Anwendungen für den automatischen Abgleich.

Das API Gateway kann sogar seine Management-Oberfläche vollständig aus Umgebungsvariablen konfigurieren, sodass eine komplette Instanz ohne eingehängte Dateien auskommt.

Jeder Dienst überwacht sich selbst. Das Gateway prüft unter /healthcheck unter anderem die Modul-Discovery, die Proxy-Konfiguration und die Erreichbarkeit des Identity-Servers und bietet unter /health eine grafische Übersicht. Jedes Modul stellt einen eigenen Health-Check unter /<modul>/healthcheck bereit, die ZitadelBridge prüft die Erreichbarkeit von Zitadel und des Nachrichtenbus. Ergänzt wird das durch strukturiertes Logging (NLog) und die selbstbeschreibenden Info- und /modules-Seiten der Plattform.

Weil die Dienste entkoppelt und zustandsarm ausgelegt sind, lassen sie sich unabhängig skalieren und aktualisieren. Der Nachrichtenbus puffert Vorgänge und stellt sie bei Bedarf erneut zu, sodass ein vorübergehend nicht erreichbarer Empfänger keine Nachrichten verliert. Die Modul-Discovery des Gateways verkraftet verzögerte Starts und arbeitet notfalls mit dem zuletzt bekannten guten Stand weiter.

Für Entwicklung und Erprobung gibt es einen vollständigen Beispiel-Stack, der die gesamte Plattform samt Infrastruktur (SQL Server, Elasticsearch, RabbitMQ, Zitadel, Maildev für den E-Mail-Test) lokal hochfährt. Damit lässt sich das Zusammenspiel aller Komponenten auf einem Entwicklungsrechner nachvollziehen, bevor es in eine produktive Umgebung geht. Die einzelnen Dienste können auch einzeln lokal gestartet werden, um gezielt an einer Komponente zu arbeiten.

buzzle Commerce Core ist so gebaut, dass Entwicklung und Betrieb nah beieinander liegen: dieselben Container, dieselbe Konfigurationslogik, dieselben Health-Checks – vom Laptop bis in die Produktion. Das senkt die Hürde für einen verlässlichen, nachvollziehbaren Betrieb.