Direkt zum Hauptinhalt

Architektur-Überblick

Diese Übersicht beschreibt den Stand der D-DOK-Komponenten (Release 0.0.7, in Entwicklung 0.0.8). Quelle: git.agrarforschung.at/ddok/ddok.

Architektur-Diagramm

flowchart LR
  subgraph Client["Browser-Client"]
    NG["Angular 21 SPA
(client/)"]
  end

  subgraph Server["D-DOK Server (Node.js)"]
    API["Express + Inversify
(server/)"]
    PDF["PDF-Parse Worker
(modules/pdfparse)"]
  end

  subgraph DBs["Datenbanken (lokal)"]
    MY[("MySQL
Projekte / Publikationen
Metadaten")]
    MO[("MongoDB 7.0
PDF-Dateien + Volltext")]
  end

  subgraph DESS["D-ESS"]
    DESSDB[("MySQL
Kostentraeger / Benutzer:innen")]
  end

  subgraph Auth["Authentifizierung"]
    AD["Active Directory
(LDAPS)"]
    KC["Keycloak OIDC
sso.agrarforschung.at"]
  end

  subgraph Web["BAB Website (0.0.8)"]
    WEBMY[("MySQL
WEB_DATABASE")]
    WEBMO[("MongoDB
WEB_MONGO")]
    SITE["bab.gv.at Public-Frontend"]
  end

  NG -- HTTPS --> API
  API --> MY
  API --> MO
  API -- Lookup --> DESSDB
  API -. optional .-> AD
  API -. optional .-> KC
  API -- "Sync (0.0.8)" --> WEBMY
  API -- "Sync (0.0.8)" --> WEBMO
  WEBMY --> SITE
  WEBMO --> SITE
  PDF --> MO

  classDef new fill:#e8f5e9,stroke:#388e3c
  class WEBMY,WEBMO,SITE,Web new

Komponenten im Überblick

KomponenteStackQuelle
Frontend (SPA)Angular 21 (seit 0.0.8, vorher Angular 17) · Wijmo · Quill-Editorclient/
Backend-APINode.js · Express · Inversify (DI) · TypeScriptserver/
PDF-ParserWorker für Volltext-Extraktion aus PDF-Dateienmodules/pdfparse/
Relationale DBMySQL 3306 — Projekte, Publikationen, StammdatenD-DOK eigene DB
Dokumenten-DBMongoDB 7.0 (Port 27017) — PDF-Binaries + Volltext-IndexD-DOK eigene DB
D-ESS-AnbindungRead-only Zugriff auf D-ESS-Datenbank für Kostentraeger/KS/KT und Benutzer:innen-StammdatenDESS_LINK_ENABLED=true
AuthentifizierungLokal · Active Directory (LDAPS) · Keycloak OIDC (Realm ddok auf sso.agrarforschung.at)Konfiguration in server/config/config.js
Website-Sync (NEU 0.0.8)Zusaetzliche MySQL- und MongoDB-Verbindung zur oeffentlichen BAB-Website — Export ausgewählter PublikationenWEB_DATABASE_* + WEB_MONGO_DATABASE_*

Deployment

D-DOK läuft in Produktion nicht als Container. Das im Repository vorhandene Dockerfile ist ausschließlich eine reproduzierbare Build-Umgebung für die CI – die Laufzeit ist ein klassischer Plesk-/Passenger-Node.js-Prozess.

AspektDetails
Laufzeit-HostPlesk-Server mit Phusion Passenger (LXC-Container). Geteilt mit D-ESS, Datenpool und Adressdatenbank (Co-Tenancy). Node 22 via nodenv.
App-PfadeLive: /var/www/vhosts/agrarforschung.at/ddok.agrarforschung.at
Staging: /var/www/vhosts/agrarforschung.at/staging-ddok.agrarforschung.at
SSOKeycloak-Realm ddok auf sso.agrarforschung.at

Build – npm run build

Führt drei Workspace-Builds nacheinander aus (package.json):

  • build:pdfparse – baut das PDF-Volltext-Modul (modules/pdfparse/).
  • build:client – Angular-Produktions-Build (client/).
  • build:server – bündelt den TypeScript-Server via esbuild (node esbuild.mjs) und erzeugt das Laufzeit-Lockfile (npm --prefix ./dist install --package-lock-only).

Resultat ist der Ordner dist/ – das eigentliche Deployment-Artefakt.

Rolle des Dockerfile

Multi-Stage-Build: Die builder-Stage führt npm ci + npm run build aus und erzeugt dist/; die finale Stage übernimmt nur dist/, exponiert Port 3000 und definiert CMD ["npm","run","start"]. In der CI wird dieses Image jedoch nicht als Runtime ausgerollt, sondern dient als hermetische Build-Box: Nach dem Build wird ein Wegwerf-Container erzeugt und dessen /usr/src/app (= dist/) per docker cp als CI-Artefakt herauskopiert.

CI/CD – .gitlab-ci.yml

Drei Stages, ausschließlich auf Branch master:

  1. build – Docker-Image bauen (Docker-in-Docker, BuildKit-Registry-Cache), nach Harbor pushen und dist/ als Artefakt extrahieren.
  2. deploy:staging (automatisch) – bestehendes Verzeichnis nach backup/ sichern (außer backup/log/config/config.js), dist/* per scp auf den Staging-Host kopieren, .npmrc schreiben, npm ci (nodenv Node 22), touch tmp/restart.txt → Passenger-Reload.
  3. deploy:live (manueller Trigger) – identischer Ablauf auf den Live-Host.

Das Deployment ist somit ein scp-basiertes Datei-Rollout des dist/-Ordners mit anschließendem Passenger-Restart – kein docker run und kein Image-Pull auf dem Zielhost.

Datenfluesse

  1. Projekt-/Publikationsanlage: Benutzer:innen erstellen Projekte und Publikationen im Angular-Frontend; Daten werden in der MySQL-DB persistiert.
  2. PDF-Upload: Hochgeladene Dateien werden in MongoDB gespeichert; ein PDF-Parser-Worker extrahiert den Volltext für die Suche.
  3. D-ESS-Lookup: Kostenstellen, Kostentraeger und Benutzer:innen-Stammdaten werden zur Laufzeit aus der D-ESS-Datenbank gelesen.
  4. Website-Export (0.0.8): Freigegebene Publikationen werden in die separate Website-Datenbank synchronisiert und auf der oeffentlichen BAB-Website angezeigt.

Letzte Aktualisierung: 2026-06-10 · Pflege: Roland Neissl · Quelle: git.agrarforschung.at/ddok/ddok

nach oben