Inbetriebnahme

Tipp

Fuer einen einzelnen Knoten ist Installation als Paket der kuerzeste Weg: .deb/.rpm legen Dienstkonto, systemd-Unit und Konfiguration inklusive Operator-Passwort an.

Start

DNSE_ENCRYPTION_KEY=<hex-key> \
DNSE_ADMIN_PASSWORD=<bootstrap> \
DNSE_OPERATOR_PASSWORD=<operator-passwort> \
./dnseditor-cloud

Erreichbar sind dann zwei getrennte Welten:

• Anwendung — http://127.0.0.1:8422, Anmeldung per E-Mail
• Operator-Panel — http://127.0.0.1:8422/operator, eigenes Konto, eigener Token

Konfiguration

Es gelten alle Variablen aus CE und EE. Dazu kommen:

Variable	Vorgabe	Bedeutung
DNSE_OPERATOR_USER	operator	Benutzername des Bootstrap-Operators
DNSE_OPERATOR_PASSWORD	—	Passwort beim allerersten Start
DNSE_OPERATOR_TOKEN	—	Statisches Token für Maschinenzugriff (X-Operator-Token)
DNSE_REGIONS	eingebauter Katalog	Regionen als code:Label,code:Label,…
DNSE_REGION	erste Region	Heimat-Region dieser Instanz
DNSE_BACKUP_DIR	—	Verzeichnis für nächtliche Mandanten-Exporte
DNSE_DEMO	off	on legt den großen Demo-Datensatz an

DNSE_OPERATOR_PASSWORD wirkt wie das Admin-Passwort in CE nur beim ersten Start; ein später geändertes Passwort bleibt bestehen.

Das Operator-Token ist für Maschinen gedacht (Checkout-Frontend, CI). Es umgeht die Anmeldung und gilt als Administrator — entsprechend behandeln oder weglassen, wenn nur Menschen ans Panel sollen.

Regionen

Der Regionenkatalog steuert, welche Heimat-Regionen für Organisationen wählbar sind und was die System-Seite im Operator-Panel auswertet.

DNSE_REGIONS="eu-central:Mitteleuropa,eu-southwest:Südwesteuropa,na:Amerika"
DNSE_REGION=eu-central

Ohne DNSE_REGIONS gilt der eingebaute Katalog: Mitteleuropa, Südwesteuropa, Amerika, Südamerika, Asien.

Hinweis

Regionen sind derzeit eine fachliche Zuordnung: Jede Organisation hat eine Heimat-Region, und das Panel wertet die Verteilung aus. Die physische Geo-Partitionierung der Daten ist eine spätere Stufe — aktuell liegen alle Daten im selben Cluster.

Plattform-Einstellungen

Kern-Einstellungen (SMTP — global oder je Region) und Portalnachrichten liegen in der Cloud auf Plattform-Ebene: Der Betreiber pflegt sie einmal im Operator-Panel, alle Mandanten lesen sie. In den Admin-Panels der Mandanten sind diese Seiten deshalb ausgeblendet.

Entwicklung

make help              # Übersicht aller Ziele
make run               # Port 8422
make demo              # Port 8479, zehn Demo-Organisationen
make test              # Go-Tests (race) + gofmt + vet
make test-cluster-up   # Vier-Knoten-Testcluster, siehe Clusterbetrieb

Selbstheilung im Dauerbetrieb

Jeder Cloud-Knoten bringt die Absturzsicherung des Kerns mit: Panics in Handlern und Jobs bleiben lokal, GET /healthz (Liveness) und GET /readyz (Readiness, echter DB-Ping) stehen für Load Balancer und Orchestrierung bereit, und der Watchdog beendet einen anhaltend ungesunden Knoten kontrolliert (Exit-Code 2) — der Supervisor startet ihn neu, die übrigen Knoten übernehmen währenddessen. Der Vier-Knoten-Testcluster nutzt genau das: restart: unless-stopped je Knoten und /readyz als Healthcheck. Konfiguration (DNSE_WATCHDOG*) in der CE-Doku unter Einstieg → Betrieb & Selbstheilung.