Skip to content

Docker

Jump to bottom
coolstartnow edited this page Aug 30, 2026 · 1 revision

Docker: Image nutzen & Umgebungsvariablen

🇬🇧 English version

Das fertige Image

Jedes Release wird als GitHub Package in der GitHub Container Registry veröffentlicht, für linux/amd64 und linux/arm64 — getaggt als :latest und :<version> (z. B. :1.40.0):

docker compose up -d
# App läuft unter http://localhost:3000

Oder ohne Compose (data/ muss ein Bind-Mount sein — Daten werden nie ins Image gebacken):

docker run -d --name isms-builder -p 3000:3000 \
  -e JWT_SECRET="$(openssl rand -hex 32)" \
  -v "$PWD/data:/app/data" \
  ghcr.io/coolstartnow/isms-builder:latest

Das ist die Standard-Variante: Daten werden als reine JSON-Dateien in ./data gespeichert — kein Datenbank-Container nötig. Empfohlener Einstieg für kleine Teams.

Signierte Herkunftsprüfung: Jedes Image trägt eine signierte Build-Provenance-Attestierung, die belegt, dass es tatsächlich aus diesem Repository per GitHub Actions gebaut wurde:

gh attestation verify oci://ghcr.io/coolstartnow/isms-builder:latest --owner coolstartnow

PostgreSQL oder MariaDB statt JSON

Das Image unterstützt das ohne Weiteres — braucht dafür aber einen zweiten Container (die Datenbank selbst) plus ein paar Umgebungsvariablen, die der App sagen, wo sie diese findet. Wichtig, falls du nur das Image gezogen hast (docker pull ghcr.io/coolstartnow/isms-builder), ohne dieses Repository zu klonen: docker-compose.yml und .env.example, wo diese Variablen sonst dokumentiert sind, liegen im Git-Repo, nicht im Image selbst. Diese Seite existiert genau deshalb.

Das isms-builder-Image bündelt selbst niemals einen Datenbankserver — postgres:17 (oder mariadb:11) ist ein völlig generischer, leerer Datenbank-Engine von Docker Hub, ohne jede Kenntnis der Tabellen dieses Projekts. Diese Tabellen (Risiken, Assets, SoA-Controls usw.) werden automatisch von der Anwendung selbst erzeugt, sobald sie startet und eine leere Datenbank vorfindet — kein manueller SQL-Import, kein separater Migrationsschritt.

Zwei Container, ein gemeinsames Docker-Netzwerk, dann wird der App gesagt, wo die Datenbank liegt:

# 1) Ein isoliertes Netzwerk, damit sich die Container per Name erreichen
docker network create isms-net

# 2) Die Datenbank — leer, bis die App sich zum ersten Mal verbindet und die Tabellen anlegt
docker run -d --name isms-postgres --network isms-net \
  -e POSTGRES_DB=isms_builder \
  -e POSTGRES_USER=isms \
  -e POSTGRES_PASSWORD="$(openssl rand -hex 16)" \
  -v isms-postgres-data:/var/lib/postgresql/data \
  postgres:17-alpine

# 3) Die App, per Docker-DNS auf den Datenbank-Container verwiesen — kein manuelles
#    Host/Port-Jonglieren nötig
docker run -d --name isms-builder --network isms-net -p 3000:3000 \
  -e JWT_SECRET="$(openssl rand -hex 32)" \
  -e STORAGE_BACKEND=postgres \
  -e DB_HOST=isms-postgres \
  -e DB_PORT=5432 \
  -e DB_USER=isms \
  -e DB_PASS="<gleiches Passwort wie POSTGRES_PASSWORD oben>" \
  -e DB_NAME=isms_builder \
  ghcr.io/coolstartnow/isms-builder:latest

Für MariaDB: postgres:17-alpine durch mariadb:11 ersetzen, in Schritt 2 dessen MARIADB_DATABASE/MARIADB_USER/MARIADB_PASSWORD verwenden, und in Schritt 3 STORAGE_BACKEND=mariadb sowie DB_PORT=3306 setzen.

Compose-Nutzer bekommen das geschenkt: docker-compose.yml bringt bereits mariadb- und postgres-Service-Profile mit (standardmäßig auskommentiert, samt Erklärung der jeweiligen Variablen) — docker compose --profile postgres up -d startet beide Container automatisch verkabelt, ohne manuelles Netzwerken oder Passwort-Copy-Paste.

Umgebungsvariablen-Übersicht

Variable Zweck
JWT_SECRET (erforderlich) Secret für JWT-Signierung — 32+ Zufallszeichen verwenden
PORT HTTP/HTTPS-Port, Standard 3000
STORAGE_BACKEND json (Standard), sqlite, postgres/pg, oder mariadb
DB_HOST Hostname des Datenbank-Containers — bei gemeinsamem Docker-Netzwerk einfach der --name
DB_PORT 5432 für PostgreSQL, 3306 für MariaDB
DB_USER / DB_PASS / DB_NAME Müssen zu den Werten auf dem Datenbank-Container passen
SSL_CERT_FILE / SSL_KEY_FILE Pfade zu TLS-Zertifikat/-Key → aktiviert HTTPS
DATA_DIR Datenverzeichnis überschreiben (für Docker-Volumes), Standard ./data
SMTP_HOST / SMTP_PORT / SMTP_USER / SMTP_PASS / SMTP_FROM SMTP für E-Mail-Benachrichtigungen

Die vollständige, referenzierte Liste jeder vom Projekt verstandenen Variable (einschließlich SSL, Reverse-Proxy-Trust, SMTP, 2FA u. a.) steht in .env.example im Repository.

Wie entsteht das Datenbankschema?

Weder postgres:17 noch mariadb:11 wissen irgendetwas über dieses Projekt — es sind generische, leere Datenbank-Engines. Es gibt keinen SQL-Dump zum Importieren und keinen separaten Migrationsbefehl. Stattdessen legt der Anwendungscode selbst (server/db/knexDatabase.js) jede benötigte Tabelle an, sobald der Container startet und eine leere Datenbank vorfindet — per hasTable()/createTable(), noch bevor die App HTTP-Anfragen annimmt. Das ist idempotent: der erste Start baut das komplette Schema, jeder spätere Neustart gegen dieselbe Datenbank ist ein stiller No-Op. Live-verifiziert gegen SQLite, MariaDB 11 und PostgreSQL 17 (siehe #70).

Aus Quellcode bauen (optional)

Den build:-Block in docker-compose.yml einkommentieren und docker compose up -d --build ausführen.

Warum eigentlich nicht selbst bauen?

Kurz gefragt: Wenn das eigene Bauen des Images nur ~2 Minuten dauert — warum dann überhaupt ein fertiges GHCR-Image anbieten? Die Antwort: Die Bauzeit ist selten der eigentliche Hinderungsgrund, aus mehreren Gründen — und einige davon wiegen bei einem ISMS-/Compliance-Tool besonders schwer:

  1. Rüstzeit vor dem Bauen. Wer nur schnell evaluieren will, hat oft noch keine funktionierende Docker-Build-Umgebung startklar — das kostet mehr Zeit als der Build selbst.
  2. Vertrauen in den Build-Prozess. Ein Dockerfile zieht Base-Images und Pakete aus dem Netz nach. Selbst zu bauen bedeutet, jeder dieser Upstream-Quellen zu vertrauen — statt nur dem einen, kuratierten, signierten Image (siehe Provenance-Verifikation oben).
  3. Reproduzierbarkeit. Ein selbst gebautes Image kann durch Netzwerk-Timeouts, abweichende latest-Tags oder Firmen-Proxys unvorhersehbar vom offiziellen Image abweichen. Ein GHCR-Image ist ein bekannter, fixer Zustand.
  4. Docker-Standarderwartung. "Pull and run" ist bei Docker der Normalfall, nicht "clone and build".
  5. Compliance/Audit-Kontext (besonders relevant hier): In vielen Unternehmen dürfen Entwickler nicht einfach beliebige Dockerfiles bauen und Base-Images aus dem Netz ziehen — freigegebene, signierte Images aus einer Registry sind oft der einzige praktikable und auditierbare Weg. Für ein ISMS-Tool, das genau in solchen Umgebungen läuft, ist das signierte GHCR-Image also nicht nur bequemer, sondern passt zum eigenen Anspruch an nachvollziehbare Herkunft.

Clone this wiki locally