Docker

Der SQL Server Health Monitor ist eine gewöhnliche ASP.NET-Core-Webanwendung und läuft daher gut in einem Linux-Container. Unter Linux ist der Aufruf UseWindowsService() wirkungslos — die Anwendung ist dort ein normaler Konsolen-Webhost.

Für die Betriebskonfiguration gibt es keine eigene Einstellungsseite: Alles wird über Umgebungsvariablen übergeben (die Standard-Konfigurationsquelle von ASP.NET Core). Die inhaltliche Konfiguration — welche Server überwacht werden, Alarmregeln, Benachrichtigungskanäle — liegt in der Datenbank und wird über die vorhandene Oberfläche gepflegt, nicht über Umgebungsvariablen.

Schnellstart

cp .env.example .env      # SA_PASSWORD + APP_DB_CONNECTION eintragen
docker compose up -d --build

Danach http://localhost:8080 öffnen. Beim ersten Start werden Sie auf /Account/Setup geleitet, um das Administratorkonto anzulegen (sofern Sie nicht ADMIN_EMAIL/ADMIN_PASSWORD vorbelegt haben).

Die Anwendung wendet ihre EF-Core-Migrationen beim Start automatisch an (DatabaseSettings:EnableAutomaticMigrations ist standardmäßig true), das Schema entsteht also beim ersten Hochfahren in einer leeren Datenbank von selbst.

Was die Compose-Datei enthält

  • app — aus dem Dockerfile des Repositorys gebaut, liefert HTTP auf Port 8080 aus.
  • db — ein optionaler Container mssql/server:2022 für die Metadaten des Monitors. Wenn Sie dafür bereits einen SQL Server haben, löschen Sie den Dienst db samt depends_on-Block und richten APP_DB_CONNECTION auf Ihren vorhandenen Server.
  • volumes — dp-keys (DataProtection-Schlüsselbund) und mssql-data (Datenbankdateien).

Konfiguration (Umgebungsvariablen)

Verschachtelte Konfigurationsschlüssel verwenden __ (doppelter Unterstrich) als Trenner.

Variable Zweck
ConnectionStrings__DefaultConnection Die Metadatenbank des Monitors. Erforderlich. (Compose bildet APP_DB_CONNECTION darauf ab)
SecuritySettings__RequireHttps false hinter einem TLS-terminierenden Proxy (siehe unten).
SecuritySettings__BindHttps false in Containern — sonst bindet die Anwendung HTTPS mit einem selbstsignierten Zertifikat.
DataProtection__KeyFolder Pfad für den Schlüsselbund; ein Volume einhängen (Compose nutzt /keys).
Encryption__Key Optionaler 32-Byte-Base64-Schlüssel für die Geheimnisverschlüsselung. Leer = eingebauter Schlüssel.
InitialAdmin__Email / InitialAdmin__Password Optionales nicht-interaktives erstes Administratorkonto.
Authentication__Oidc__* Optionales SSO (siehe docs/sso.md).

Verbindungszeichenfolgen zu überwachten Servern und Benachrichtigungsgeheimnisse werden nicht über Umgebungsvariablen gesetzt — die tragen Sie in der Oberfläche ein, und sie werden verschlüsselt in der Datenbank abgelegt.

HTTPS und Reverse Proxy

appsettings.json wird mit RequireHttps und BindHttps auf true ausgeliefert (sinnvoll für die Windows-/MSI-Installation). In einem Container terminiert man TLS fast immer an einem Reverse Proxy (nginx, Traefik, Caddy, ein Ingress) und betreibt die Anwendung über einfaches HTTP — die Compose-Datei setzt daher beide auf false. Lassen Sie BindHttps=true, erzeugt die Anwendung ein selbstsigniertes Zertifikat im Schlüsselordner und bindet SecuritySettings:HttpsPort (Standard 8443) statt 8080.

Dauerhaftigkeit — was zu sichern ist

  • Die Datenbank — sämtliche Server, Regeln, Verlauf, Benutzer.
  • Das Volume dp-keys — der DataProtection-Schlüsselbund (Anmelde-Cookies; etwaige alte enc:v1-Werte). Geht er verloren, werden lediglich die Benutzer abgemeldet und das Zertifikat neu erzeugt; Verbindungszeichenfolgen gehen nicht verloren, denn die nutzen den festen Encryption:Key (eingebaut oder Ihr ENCRYPTION_KEY). Siehe docs/backup-and-restore.md.

Wenn Sie einen eigenen ENCRYPTION_KEY setzen, behandeln Sie ihn wie ein Kennwort und bewahren ihn bei der Datenbanksicherung auf — ohne ihn sind die verschlüsselten Verbindungszeichenfolgen nicht mehr lesbar.

Das Image direkt bauen (ohne Compose)

docker build -t sqlhealthmonitor .
docker run -d -p 8080:8080 \
  -e ConnectionStrings__DefaultConnection="Server=host.docker.internal,1433;Database=SqlHealthMonitor;User Id=sa;Password=...;TrustServerCertificate=True" \
  -e SecuritySettings__RequireHttps=false \
  -e SecuritySettings__BindHttps=false \
  -e DataProtection__KeyFolder=/keys \
  -v sqlhealth-keys:/keys \
  sqlhealthmonitor

Zustandsprüfungen

Die Anwendung stellt /health und /health/detailed bereit. Richten Sie die Liveness- und Readiness-Prüfungen Ihres Orchestrators auf /health. (Das Basis-Image enthält kein curl, ein container-internes HEALTHCHECK mit curl funktioniert also nicht ohne Weiteres — prüfen Sie vom Orchestrator aus oder ergänzen Sie ein passendes Werkzeug im Image.)

Hinweise

  • appsettings.Development.json wird über .dockerignore aus dem Image ausgeschlossen; Produktivläufe verwenden ASPNETCORE_ENVIRONMENT=Production.
  • Funktionen auf msdb-Basis (SQL-Agent-Aufträge, Sicherungsverlauf) werden bei Azure SQL Database und AWS RDS automatisch übersprungen — unabhängig davon, wie der Monitor selbst betrieben wird.