Skip to content

Docker-Container

Der SVWS-Server kann als Container betrieben werden. Dies eignet sich insbesondere für die folgenden beiden Szenarien:

Die SVWS-Container-Images sind unter Docker (docker engine, docker desktop) lauffähig. Ein Betrieb unter anderen Container-Umgebungen wie z.B. Podman, Kubernetes, OpenShift ist grundsätzlich möglich, jedoch noch nicht getestet (Stand 27.09.2024).

Im Git-Repository von SVWS befinden sich Beispiele, Skripte und Image-Definitionen zum Aufbau von Docker-basierten SVWS-Umgebungen.

Systemvoraussetzungen Installation Docker-Umgebung

Für die lokale Inbetriebnahme ist eine Installation von Docker auf dem Entwickler-PC notwendig. Bitte die Nutzungsbedingungen der Fa. Docker Inc. für Docker beachten!

Bitte informieren Sie sich auf der Dokumentationsseite von Docker über die notwendigen Schritte in Ihrer Umgebung.

SVWS-Umgebung mit docker-compose starten

Die SVWS-Umgebung kann über die Konsole des verwendeten Betriebssystems mittels docker-compose gestartet werden. Beispiele zur dazu obligatorischen docker-compose.yml und Dateien befinden sich im Github-Repository .

Beispiel: aktuellen Testserver im Docker Container

Beispiel einer vorbereiteten Docker-Compose

Diese Datei muss in einem Ordner entpackt werden und legt damit die geforderte Ordnerumgebung an, so dass der Keystore beim ersten Start des SVWS-Servers erzeugt wird und danach erhalten bleibt.

Außerdem werden Volumes für die Daten der MariaDB angelegt, die später ja auch erhalten bleiben müssen.

Im Ordner liegen dann eine docker-compose.yml und eine .env Datei, die angepasst werden muss. Im Ordner Volume werden dann für svws und mariadb entsprechende Ordner angelegt.

Im Ordner svws werden beim ersten hochfahren des Containers die svwsconfig.json und der Keystore angelegt. Diese können dort auch mit einer eigenen Konfiguration bzw. eigenen Zertifikatseinstellungen abgelegt werden. Im Ordner svws/logs werden später die LOG-Dateien erscheinen, wenn der logging-Pfad auf Defaulteinstellung bleibt.

Es werden nun Services für eine komplette SVWS-Umgebung gestartet: Datenbank, SVWS-Anwendung (Backend, Frontend). Ebenso sind die Volumes für den Keystore gemountet.

Nach dem Start kann der SVWS-Server über den Port 8443 erreicht werden. Auf die Datenbank kann standardmäßig nicht außerhalb der Docker-Umgebung zugegriffen werden ("not bound"). Intern nutzt die Datenbank den Port 3306. Für den Zugriff von SchILD 3 ist ein Port-Binding auch außerhalb von Docker nötig, dies wird über die Angabe eines Port-Mappings (ports) Eintrag in der Datei erreicht. In diesem Beispiel wird der Port 3306 im Container auf den Port 3306 auf dem Host abgebildet.:

Beispiel:

yaml
...
services:
  mariadb:
    ...
    ports:
        - "3306:3306"
    ...

Diese Ports müssen auf Ihre Umgebung angepasst werden, je nach Anforderung.

Konfiguration der SVWS-Umgebung

Die Konfiguration der Docker-basierten SVWS-Umgebung erfolgt über Umgebungsvariablen. Die Werte dieser Variablen werden in der Datei .env definiert.

Hier ein Beispiel:

bash
IMPORT_TEST_DATA=true
MARIADB_ROOT_PASSWORD=your-mariadb-root-pw
MARIADB_DATABASE=your-svws-db-schema-name
MARIADB_HOST=mariadb
MARIADB_USER=your-mariadb-user
MARIADB_PASSWORD=your-mariadb-pw
SVWS_TLS_KEYSTORE_PATH=/etc/app/svws/conf/keystore
SVWS_TLS_KEYSTORE_PASSWORD=your-keystore-pw
SVWS_TLS_KEY_ALIAS=your-keystore-key-alias
SVWS_TLS_CERT_CN=YOURCERTNAME
SVWS_TLS_CERT_OU=SVWSOU
SVWS_TLS_CERT_O=SVWSO
SVWS_TLS_CERT_L=CITY
SVWS_TLS_CERT_S=STATE
SVWS_TLS_CERT_C=COUNTRY
VariableBeschreibung
IMPORT_TEST_DATAtrue Startet den automatischen Import, Default = false
MARIADB_ROOT_PASSWORDPasswort, das für den Root-User der MariaDB-Instanz verwendet werden soll
MARIADB_DATABASEName des Datenbankschemas, mit dem sich der SVWS-Server verbindet (z.B. "gymabi")
MARIADB_HOSTName des Hosts, auf dem die SVWS-Datenbank läuft. Im Falle der Docker-Umgebung entspricht dieser Wert dem Service-Namen von docker-compose (also "mariadb").
MARIADB_USERDatenbank-Benutzer, unter dem sich der SVWS-Server mit der Datenbank verbindet.
MARIADB_PASSWORDPasswort des Datenbank-Benutzers, unter dem sich der SVWS-Server mit der Datenbank verbindet.
SVWS_TLS_KEYSTORE_PATHUnter diesem Pfad erwartet der SVWS den Java-Keystore für die Terminierung von SSL am Server
SVWS_TLS_KEYSTORE_PASSWORDPasswort des Keystores
SVWS_TLS_KEY_ALIASAlias des zu verwendenden Keys im Keystore
SVWS_TLS_CERT_CNName des selbstsignierten Zertifikats Default:SVWSCERT
SVWS_TLS_CERT_OUName der Organistationseinheit Default: SVWSOU
SVWS_TLS_CERT_OName der Organisation Default:SVWSO
SVWS_TLS_CERT_L=CITYName des Ortes Default: Duesseldorf
SVWS_TLS_CERT_S=STATEName des Bundeslands Name Default: NRW
SVWS_TLS_CERT_C=COUNTRYName des Staates Default: Germany

Automatische Initialisierung beim Start, Testdatenimporte

Es besteht die Möglichkeit, beim Start der SVWS-Container die Datenbank mit Testdaten zu initialisieren. Ansonsten kann anch dem Start des Containers der dmin-Client aufgerufen werden und weitere Daten können importiert werden.

Funktionsweise: Beim Start der SVWS-Container wird die Variable IMPORT_TEST_DATA ausgewertet. Wenn diese auf "true" steht, dann wird aus dem Repository von SVWS-NRW eine Testdatenbank heruntergeladen und importiert.

Achtung! Wenn die Variable auf "true" stehen bleibt geschieht dies bei jedem Start. Dies ist nur für Entwickler erforderlich, die immer eine frische Testdatenbank benötigen.

bash
IMPORT_TEST_DATA=true
#...

Deaktivierung der automatischen Initialisierung

Umgebungsvariable INIT_SCRIPTS_DIR muss auskommentiert sein (vgl. Konfiguration der SVWS-Umgebung).

bash
IMPORT_TEST_DATA=false
#...

Diese Zeile sollte nach dem ersten Start immer auskommentiert oder auf "false" gesetzt werden, es sei denn man möchte einen Container erstellen, der nach dem Start immer "frische" Testdaten haben soll.

Sie können in der .env Datei auch ein Schema ohne Migration angeben, dann wird dies beim ersten Start ohne Daten angelegt. Dies kann dann im Admin-Client befüllt werden.

bash
MARIADB_DATABASE=your-svws-db-schema-name
MARIADB_HOST=mariadb
MARIADB_USER=your-mariadb-user
MARIADB_PASSWORD=your-mariadb-pw