diff --git a/Architecture.de.md b/Architecture.de.md index 2a6a9b0..dc1679d 100644 --- a/Architecture.de.md +++ b/Architecture.de.md @@ -83,20 +83,35 @@ Der mRomexis-Proxy schreibt Backend-Proxy-Anfragen auf den internen Dienst `rome romexis-payload: | +--> romexis-server: - | +--> romexis-admin: - | +--> romexis-mromexis-app: +romexis-client-payload: + | + +--> romexis-client: + romexis-base-jre:11- | +--> romexis-server:- +romexis-gui-runtime:1- + | + +--> romexis-admin:- + +--> romexis-client:- + romexis-firebird-payload:latest | +--> romexis-server:- + +Independent service images: + romexis-migration-service:latest + romexis-control-agent:latest ``` +Payload-Images enthalten versionsabhängige Inhalte aus dem Installer. Runtime-Images enthalten aufwendige architekturspezifische Abhängigkeiten, die über mehrere Romexis-Versionen hinweg wiederverwendet werden. Die finalen Server-, Admin- und Client-Images setzen daher im Wesentlichen ein Payload mit der passenden Runtime-Schicht und komponentenspezifischen Startdateien zusammen. + +`romexis-client` erbt nicht mehr von `romexis-admin`; beide verwenden unabhängig voneinander die gemeinsame `romexis-gui-runtime`. Payload- und Runtime-Images sind Build-Abhängigkeiten und keine zusätzlichen Dienste im Runtime-Compose-Stack. + --- ## Compose-Architektur diff --git a/Architecture.md b/Architecture.md index 1a53f67..db9f215 100644 --- a/Architecture.md +++ b/Architecture.md @@ -83,20 +83,35 @@ The mRomexis proxy rewrites backend proxy requests to the internal `romexis` ser romexis-payload: | +--> romexis-server: - | +--> romexis-admin: - | +--> romexis-mromexis-app: +romexis-client-payload: + | + +--> romexis-client: + romexis-base-jre:11- | +--> romexis-server:- +romexis-gui-runtime:1- + | + +--> romexis-admin:- + +--> romexis-client:- + romexis-firebird-payload:latest | +--> romexis-server:- + +Independent service images: + romexis-migration-service:latest + romexis-control-agent:latest ``` +Payload images contain version-specific installer content. Runtime images contain expensive architecture-specific dependencies that are shared across Romexis versions. The final Server, Admin and Client images therefore mainly assemble a payload with the appropriate runtime layer and component-specific startup files. + +`romexis-client` no longer inherits from `romexis-admin`; both use the shared `romexis-gui-runtime` independently. Payload and runtime images are build-time dependencies and are not additional services in the runtime Compose stack. + --- ## Compose Architecture diff --git a/Base-Image.de.md b/Base-Image.de.md index df2d670..740e2de 100644 --- a/Base-Image.de.md +++ b/Base-Image.de.md @@ -1,28 +1,49 @@ -**Deutsch** | [English](Base-Image) +[**Deutsch**](Base-Image.de) | [English](Base-Image) -# Base-Image +# Runtime-Basis-Images -Das Base-Image stellt wiederverwendbare Laufzeitabhängigkeiten für das Romexis-Server-Image bereit. +Die Build-Architektur verwendet getrennte wiederverwendbare Runtime-Images für Server sowie grafische Admin-/Client-Workloads. Dadurch bleiben aufwendige architekturspezifische Abhängigkeiten aus den versionsspezifischen finalen Images heraus. -Verzeichnis: +Verzeichnisse: ```text romexis-base/ +romexis-gui-runtime/ +romexis-common/ ``` --- -## Verantwortlichkeiten +## Verantwortlichkeiten der Server-Runtime -Das Base-Image stellt Folgendes bereit: +`romexis-base-jre` stellt Folgendes bereit: - Java-11-Laufzeit - JavaFX-/OpenJFX-Unterstützung - Microsoft-SQL-Server-Kommandozeilenwerkzeuge - Firebird-Clientbibliotheken und -Werkzeuge - gemeinsame Betriebssystempakete +- native Chilkat-Bibliothek und JAR +- `RomexisPropertyAgent.jar` - Sicherheitsaktualisierungen +Die aufwendigen Native-/Java-Artefakte werden dadurch einmal pro Architektur statt einmal pro Romexis-Version gebaut. + +--- + +## Verantwortlichkeiten der GUI-Runtime + +`romexis-gui-runtime` wird gemeinsam von `romexis-admin` und `romexis-client` verwendet. Sie stellt bereit: + +- Java 17 und OpenJFX +- Xvfb, Openbox und xcompmgr +- x11vnc und noVNC/websockify +- GTK-/Mesa-/OpenGL-Abhängigkeiten +- Chilkat und `RomexisPropertyAgent.jar` +- die aus `romexis-common/dxservice_dummy.c` gebaute DxService-Kompatibilitätsbibliothek + +Admin und Client installieren bzw. kompilieren diese Abhängigkeiten daher nicht erneut für jede Romexis-Version. + --- ## Architekturspezifische Tags @@ -30,9 +51,14 @@ Das Base-Image stellt Folgendes bereit: ```text romexis-base-jre:11-amd64 romexis-base-jre:11-arm64 +romexis-base-jre:11 + +romexis-gui-runtime:1-amd64 +romexis-gui-runtime:1-arm64 +romexis-gui-runtime:1 ``` -Das Base-Image ist architekturspezifisch, weil es native Laufzeitpakete enthält. +Die Runtime-Images sind architekturspezifisch, weil sie native Laufzeitpakete enthalten. Die Tags ohne Architektur-Suffix sind Multi-Architektur-Manifeste, die erst nach erfolgreichen Builds beider Architekturen veröffentlicht werden. --- diff --git a/Base-Image.md b/Base-Image.md index cbb6e9c..de2a6fa 100644 --- a/Base-Image.md +++ b/Base-Image.md @@ -1,28 +1,49 @@ [Deutsch](Base-Image.de) | **English** -# Base Image +# Runtime Base Images -The base image provides reusable runtime dependencies for the Romexis Server image. +The build architecture uses separate reusable runtime images for the server and graphical Admin/Client workloads. This keeps expensive architecture-specific dependencies out of the version-specific final images. -Directory: +Directories: ```text romexis-base/ +romexis-gui-runtime/ +romexis-common/ ``` --- -## Responsibilities +## Server Runtime Responsibilities -The base image provides: +`romexis-base-jre` provides: - Java 11 runtime - JavaFX/OpenJFX support - Microsoft SQL Server command-line tools - Firebird client libraries and tools - common OS packages +- Chilkat native library and JAR +- `RomexisPropertyAgent.jar` - security updates +The expensive native/Java artifacts are therefore built once per architecture instead of once per Romexis version. + +--- + +## GUI Runtime Responsibilities + +`romexis-gui-runtime` is shared by `romexis-admin` and `romexis-client`. It provides: + +- Java 17 and OpenJFX +- Xvfb, Openbox and xcompmgr +- x11vnc and noVNC/websockify +- GTK/Mesa/OpenGL dependencies +- Chilkat and `RomexisPropertyAgent.jar` +- the DxService compatibility library built from `romexis-common/dxservice_dummy.c` + +Admin and Client therefore do not repeatedly install or compile these dependencies for every Romexis version. + --- ## Architecture-Specific Tags @@ -30,9 +51,14 @@ The base image provides: ```text romexis-base-jre:11-amd64 romexis-base-jre:11-arm64 +romexis-base-jre:11 + +romexis-gui-runtime:1-amd64 +romexis-gui-runtime:1-arm64 +romexis-gui-runtime:1 ``` -The base image is architecture-specific because it contains native runtime packages. +The runtime images are architecture-specific because they contain native runtime packages. The unsuffixed tags are multi-architecture manifests published only after both architecture builds succeed. --- diff --git a/Build-System.de.md b/Build-System.de.md index 1908985..fa6a2c8 100644 --- a/Build-System.de.md +++ b/Build-System.de.md @@ -5,19 +5,20 @@ Das Build-System ist in unabhängige Schichten und Service-Images aufgeteilt. ```text -romexis-payload - | - +--> romexis-server - +--> romexis-admin - +--> romexis-mromexis-app - ^ - | -romexis-base-jre +romexis-payload ----------------+--> romexis-server + +--> romexis-admin + +--> romexis-mromexis-app -romexis-firebird-payload - | - v -romexis-server +romexis-client-payload ------------> romexis-client + +romexis-base-jre ------------------> romexis-server + +romexis-gui-runtime -----------+--> romexis-admin + +--> romexis-client + +romexis-firebird-payload ----------> romexis-server + +romexis-common -> server/gui runtime build sources ``` --- @@ -38,6 +39,10 @@ Er erzeugt: Er stellt außerdem Dateien bereit, die von anderen Service-Images verwendet werden, einschließlich Admin-Dateien und, sofern verfügbar, der WAR-Datei der mRomexis Web App. +### Client-Payload-Build + +Das Client-Payload wird aus demselben Windows-Installer mit einer separaten Copy-Map extrahiert. Es erzeugt die für das eigenständige Image `romexis-client` benötigten Dateien und wird als `romexis-client-payload:` versioniert. + ### Firebird-Payload-Build Der Firebird-Payload-Build extrahiert das Datenbankpaket des macOS-Installers. @@ -51,15 +56,25 @@ Er erzeugt: /opt/romexis-firebird-db/templates ``` -### Base-Image-Build +### Server-Runtime-Build -Das Base-Image stellt wiederverwendbare Runtime-Abhängigkeiten bereit: +`romexis-base-jre` stellt wiederverwendbare Server-Runtime-Abhängigkeiten bereit: - Java 11 - JavaFX/OpenJFX - SQL-Server-Werkzeuge - Firebird-Clientbibliotheken und -Werkzeuge - Betriebssystemabhängigkeiten +- Chilkat +- Java Property Agent + +### GUI-Runtime-Build + +`romexis-gui-runtime` enthält den von Admin und Client gemeinsam verwendeten architekturspezifischen Grafik-Stack: Java 17/OpenJFX, X11/noVNC, Mesa/GTK, Chilkat, PropertyAgent und die DxService-Kompatibilitätsbibliothek. + +### Gemeinsame Runtime-Quellen + +`romexis-common/` ist der zentrale Quellort für `RomexisPropertyAgent.java`, die Chilkat-Patch-Quelle und `dxservice_dummy.c`. Diese Quellen werden in die passenden Runtime-Images kompiliert, statt in Verzeichnissen finaler Images dupliziert zu werden. ### Server-Image-Build @@ -68,14 +83,12 @@ Das finale Server-Image importiert: - `/opt/romexis` aus `romexis-payload` - `/opt/romexis-mssql-db` aus `romexis-payload` - `/opt/romexis-firebird-db` aus `romexis-firebird-payload` -- die Basis-Runtime aus `romexis-base-jre` -- die native Chilkat-Bibliothek -- den Java Property Agent +- die Server-Runtime aus `romexis-base-jre` - Runtime-Hilfsskripte ### Admin-Image-Build -Das Admin-Image importiert die Romexis-Admin-Dateien aus der Payload und ergänzt eine browserzugängliche X11-/noVNC-Runtime. +Das Admin-Image importiert die Romexis-Admin-Dateien aus der Payload und kombiniert sie mit der gemeinsamen browserzugänglichen `romexis-gui-runtime`. Wichtige Runtime-Komponenten: @@ -88,6 +101,10 @@ noVNC/websockify JavaFX ``` +### Client-Image-Build + +Das finale Client-Image kombiniert `romexis-client-payload` mit `romexis-gui-runtime` und Client-spezifischen Start-/Testskripten. Es erbt nicht mehr vom Admin-Image. + ### Build der mRomexis Web App Das Image der mRomexis Web App kopiert: @@ -131,37 +148,39 @@ Windows PowerShell: Einzelne Image-Gruppen bauen: ```bash -./scripts/build-local.sh base server -./scripts/build-local.sh admin mromexis -./scripts/build-local.sh migration +./scripts/build-local.sh server-runtime server +./scripts/build-local.sh gui-runtime admin client +./scripts/build-local.sh migration control ``` --- -## Beispiele für manuelle Docker-Builds +## Beispiele für manuelle Builds -Payload bauen: +Die Hilfsskripte sind der unterstützte manuelle Einstiegspunkt, weil sie die benötigten Runtime-/Payload-Abhängigkeitskontexte konsistent erzeugen. + +Wiederverwendbare Runtimes bauen: ```bash -docker buildx build --platform linux/amd64 --provenance=false --sbom=false --build-arg ROMEXIS_VERSION=6.5.3.444.203 -t gitea.buchhorster.de/planmeca/romexis-payload:6.5.3.444.203 --load ./romexis-payload +./scripts/build-local.sh server-runtime gui-runtime ``` -Server-Image bauen: +Payloads explizit bauen: ```bash -docker buildx build --platform linux/amd64 --provenance=false --sbom=false --build-arg TARGETARCH=amd64 --build-arg ROMEXIS_VERSION=6.5.3.444.203 -t gitea.buchhorster.de/planmeca/romexis-server:6.5.3.444.203-amd64 --load ./romexis +./scripts/build-local.sh payload client-payload firebird-payload ``` -Admin-Image bauen: +Finale Anwendungs-Images bauen: ```bash -docker buildx build --platform linux/amd64 --provenance=false --sbom=false --build-arg TARGETARCH=amd64 --build-arg ROMEXIS_VERSION=6.5.3.444.203 -t gitea.buchhorster.de/planmeca/romexis-admin:6.5.3.444.203-amd64 --load ./romexis-admin +./scripts/build-local.sh server admin client mromexis ``` -mRomexis Web App bauen: +Für Windows PowerShell stehen dieselben Targets bereit: -```bash -docker buildx build --platform linux/amd64 --provenance=false --sbom=false --build-arg TARGETARCH=amd64 --build-arg ROMEXIS_VERSION=6.5.3.444.203 -t gitea.buchhorster.de/planmeca/romexis-mromexis-app:6.5.3.444.203-amd64 --load ./romexis-mromexis-app +```powershell +.\scripts\build-local.ps1 -Targets server-runtime,gui-runtime,server,admin,client ``` --- diff --git a/Build-System.md b/Build-System.md index e25e0fb..9e2c642 100644 --- a/Build-System.md +++ b/Build-System.md @@ -5,19 +5,20 @@ The build system is split into independent layers and service images. ```text -romexis-payload - | - +--> romexis-server - +--> romexis-admin - +--> romexis-mromexis-app - ^ - | -romexis-base-jre +romexis-payload ----------------+--> romexis-server + +--> romexis-admin + +--> romexis-mromexis-app -romexis-firebird-payload - | - v -romexis-server +romexis-client-payload ------------> romexis-client + +romexis-base-jre ------------------> romexis-server + +romexis-gui-runtime -----------+--> romexis-admin + +--> romexis-client + +romexis-firebird-payload ----------> romexis-server + +romexis-common -> server/gui runtime build sources ``` --- @@ -38,6 +39,10 @@ It produces: It also provides files consumed by other service images, including Admin files and the mRomexis Web App WAR when available. +### Client payload build + +The Client payload is extracted from the same Windows installer with a separate copy map. It produces the files required by the standalone `romexis-client` image and is versioned as `romexis-client-payload:`. + ### Firebird payload build The Firebird payload build extracts the macOS installer database package. @@ -51,15 +56,25 @@ It produces: /opt/romexis-firebird-db/templates ``` -### Base image build +### Server runtime build -The base image provides reusable runtime dependencies: +`romexis-base-jre` provides reusable server runtime dependencies: - Java 11 - JavaFX/OpenJFX - SQL Server tools - Firebird client libraries and tools - OS dependencies +- Chilkat +- Java property agent + +### GUI runtime build + +`romexis-gui-runtime` contains the architecture-specific graphical stack shared by Admin and Client: Java 17/OpenJFX, X11/noVNC, Mesa/GTK, Chilkat, PropertyAgent and the DxService compatibility library. + +### Shared runtime sources + +`romexis-common/` is the single source location for `RomexisPropertyAgent.java`, the Chilkat patch source and `dxservice_dummy.c`. These sources are compiled into the appropriate runtime images instead of being duplicated in final image directories. ### Server image build @@ -68,14 +83,12 @@ The final server image imports: - `/opt/romexis` from `romexis-payload` - `/opt/romexis-mssql-db` from `romexis-payload` - `/opt/romexis-firebird-db` from `romexis-firebird-payload` -- base runtime from `romexis-base-jre` -- Chilkat native library -- Java property agent +- server runtime from `romexis-base-jre` - runtime helper scripts ### Admin image build -The Admin image imports Romexis Admin files from the payload and adds a browser-accessible X11/noVNC runtime. +The Admin image imports Romexis Admin files from the payload and combines them with the shared browser-accessible `romexis-gui-runtime`. Important runtime components: @@ -88,6 +101,10 @@ noVNC/websockify JavaFX ``` +### Client image build + +The final Client image combines `romexis-client-payload` with `romexis-gui-runtime` and Client-specific startup/test scripts. It no longer inherits from the Admin image. + ### mRomexis Web App build The mRomexis Web App image copies: @@ -131,37 +148,39 @@ Windows PowerShell: Build individual image groups: ```bash -./scripts/build-local.sh base server -./scripts/build-local.sh admin mromexis -./scripts/build-local.sh migration +./scripts/build-local.sh server-runtime server +./scripts/build-local.sh gui-runtime admin client +./scripts/build-local.sh migration control ``` --- -## Manual Docker Build Examples +## Manual Build Examples -Build payload: +The helper scripts are the supported manual entry point because they create the required runtime/payload dependency contexts consistently. + +Build reusable runtimes: ```bash -docker buildx build --platform linux/amd64 --provenance=false --sbom=false --build-arg ROMEXIS_VERSION=6.5.3.444.203 -t gitea.buchhorster.de/planmeca/romexis-payload:6.5.3.444.203 --load ./romexis-payload +./scripts/build-local.sh server-runtime gui-runtime ``` -Build server image: +Build payloads explicitly: ```bash -docker buildx build --platform linux/amd64 --provenance=false --sbom=false --build-arg TARGETARCH=amd64 --build-arg ROMEXIS_VERSION=6.5.3.444.203 -t gitea.buchhorster.de/planmeca/romexis-server:6.5.3.444.203-amd64 --load ./romexis +./scripts/build-local.sh payload client-payload firebird-payload ``` -Build Admin image: +Build final application images: ```bash -docker buildx build --platform linux/amd64 --provenance=false --sbom=false --build-arg TARGETARCH=amd64 --build-arg ROMEXIS_VERSION=6.5.3.444.203 -t gitea.buchhorster.de/planmeca/romexis-admin:6.5.3.444.203-amd64 --load ./romexis-admin +./scripts/build-local.sh server admin client mromexis ``` -Build mRomexis Web App: +For Windows PowerShell the same targets are available: -```bash -docker buildx build --platform linux/amd64 --provenance=false --sbom=false --build-arg TARGETARCH=amd64 --build-arg ROMEXIS_VERSION=6.5.3.444.203 -t gitea.buchhorster.de/planmeca/romexis-mromexis-app:6.5.3.444.203-amd64 --load ./romexis-mromexis-app +```powershell +.\scripts\build-local.ps1 -Targets server-runtime,gui-runtime,server,admin,client ``` --- diff --git a/CI-CD-Pipeline.de.md b/CI-CD-Pipeline.de.md index c94e2bd..fe4329a 100644 --- a/CI-CD-Pipeline.de.md +++ b/CI-CD-Pipeline.de.md @@ -11,21 +11,43 @@ Das Projekt verwendet Drone CI, um Images zu bauen und in der Gitea-Container-Re Die Pipeline baut: ```text -romexis-payload -romexis-firebird-payload -romexis-base-jre:11-amd64 -romexis-base-jre:11-arm64 -romexis-server:-amd64 -romexis-server:-arm64 -romexis-admin:-amd64 -romexis-admin:-arm64 -romexis-mromexis-app:-amd64 -romexis-mromexis-app:-arm64 -romexis-migration-service:amd64 -romexis-migration-service:arm64 -multiarch manifests +romexis-payload: +romexis-client-payload: +romexis-firebird-payload:latest +romexis-base-jre:11-amd64 / 11-arm64 +romexis-gui-runtime:1-amd64 / 1-arm64 +romexis-server:-amd64 / -arm64 +romexis-admin:-amd64 / -arm64 +romexis-client:-amd64 / -arm64 +romexis-mromexis-app:-amd64 / -arm64 +romexis-migration-service:amd64 / arm64 +romexis-control-agent:amd64 / arm64 +public multiarch manifests ``` +## Pipeline-Graph und Parallelität + +Der Build ist in fünf voneinander abhängige Drone-Pipelines aufgeteilt: + +```text +quality-gate + | + v +build-romexis-payload + | + +-------------------+ + v v +build-romexis-amd64 build-romexis-arm64 + | | + +---------+---------+ + v +create-romexis-manifests +``` + +Innerhalb jeder Architektur-Pipeline können unabhängige Komponenten entsprechend ihrem Abhängigkeitsgraphen parallel laufen. Runtime-abhängige Server-/Admin-/Client-Builds warten nur auf die Runtime, die sie tatsächlich verwenden. + +--- + --- ## Behandlung von Branch-Suffixen @@ -40,11 +62,32 @@ Bei Feature-Branches wird der Branchname normalisiert und als Image-Suffix angeh Dadurch können Feature-Branch-Images und -Manifeste getestet werden, ohne `main`-Images zu überschreiben. +## Änderungserkennung und Versionsmatrix + +Drone bestimmt betroffene Komponenten aus dem Branch-Diff, statt für jeden Commit die vollständige Image-Matrix neu zu bauen. Feature-Branches werden gegen die Merge-Base des Ziel-/Default-Branches verglichen, damit eine frühere Änderung desselben Feature-Branches auch in späteren CI-Läufen sichtbar bleibt. + +Typische Abhängigkeitsbereiche: + +| Geänderter Bereich | Neu gebaute Komponenten | +|---|---| +| `romexis-base/**` oder Server-Runtime-Quellen | Server-Runtime, Server | +| `romexis-gui-runtime/**` oder GUI-Runtime-Quellen | GUI-Runtime, Admin, Client | +| `romexis/**` | Server | +| `romexis-admin/**` | Admin | +| `romexis-client/**` | Client | +| `migration-service/**` | Migration Service | +| `romexis-control-agent/**` | Control Agent | +| nur Dokumentation | keine Produktions-Images | + +Normale Feature-Branches bauen nur die Standard-Romexis-Version, sofern nicht ausdrücklich ein vollständiger Matrix-Build angefordert wird. + +--- + --- ## Payload-Buildlogik -Der Windows-Payload-Build prüft Versionsdefinitionen und Änderungen an der Kopierzuordnung. +Der Windows-Payload-Build prüft Versionsdefinitionen sowie Änderungen an den Server-/Admin- und Client-Copy-Maps. Stabile Payload-Tags werden über normale Feature-Branches hinweg wiederverwendet; geänderte Payload-Erzeugung verwendet isolierte commit-spezifische CI-Tags. Gewünschtes Verhalten: @@ -75,25 +118,33 @@ romexis-firebird-payload:latest Das Server-Image verwendet das gemeinsame Firebird-Payload-Image. +## Gemeinsame Runtime-Builds und Registry-Cache + +`romexis-base-jre` und `romexis-gui-runtime` werden pro Architektur einmal gebaut, wenn sich ihre Quellen ändern. BuildKit-Cache-Daten werden in getrennten Registry-Cache-Scopes gespeichert und über `--cache-from` / `--cache-to` wiederverwendet. + +Dadurch werden aufwendige Paketinstallationen, Chilkat-Extraktion sowie Java-/Native-Kompilierung nicht für jede Romexis-Version wiederholt. + +--- + --- ## Server-Build -Der Server-Build lädt: +Der Server-Build kombiniert die ausgewählte Server-Runtime, das Romexis-Payload und das Firebird-Payload über explizite BuildKit-Image-Contexts: ```text -ROMEXIS_PAYLOAD_IMAGE -ROMEXIS_FIREBIRD_PAYLOAD_IMAGE -ROMEXIS_BASE_IMAGE +romexis-server-runtime +romexis-payload +romexis-firebird-payload ``` -Anschließend wird das endgültige Laufzeitimage für jede Architektur gebaut. +Wurde eine Runtime im selben CI-Lauf neu gebaut, wird direkt ihr commit-spezifischer Staging-Tag verwendet. Andernfalls wird der stabile öffentliche Runtime-Tag genutzt. Das finale Server-Image wird getrennt für jede Architektur gebaut. --- ## Admin-Build -Der Admin-Build verwendet das Romexis-Payload und baut: +Der Admin-Build verwendet die gemeinsame GUI-Runtime zusammen mit dem Romexis-Server-/Admin-Payload und baut: ```text romexis-admin:-amd64 @@ -104,6 +155,14 @@ romexis-admin:latest Das endgültige Image enthält die grafische noVNC-Laufzeit sowie die Dateien von Romexis Admin / RomexisConfig. +## Client-Build + +Der Client-Build verwendet `romexis-gui-runtime` zusammen mit `romexis-client-payload` und veröffentlicht versionierte amd64-/arm64-Images. Er ist vom Admin-Build unabhängig; eine reine Admin-Quelländerung erfordert keinen Client-Rebuild. + +Zu den veröffentlichten öffentlichen Tags gehören das Versionsmanifest und `latest` für die konfigurierte Standardversion. + +--- + --- ## mRomexis-Web-App-Build @@ -133,9 +192,9 @@ romexis-mromexis-app:latest ## Push gegenüber Load -In CI sollte `--push` für die buildx-Ausgabe verwendet werden, wenn Images veröffentlicht werden. +In CI verwenden Architektur-Builds `--push` und schreiben ausschließlich unveränderliche `ci--...`-Staging-Tags. Öffentliche Versions-, `latest`- und Runtime-Manifest-Tags werden während des Builds nicht verändert. -Dies vermeidet unnötiges lokales Laden von Images und kann die Worker-Zeit reduzieren. +Nach erfolgreichen amd64- und arm64-Builds erstellt bzw. ersetzt die finale Pipeline die öffentlichen Manifeste atomar mit `docker buildx imagetools create`. Ein Branch-Head-Guard verhindert, dass ein älterer langsamer Build über einen neueren Commit veröffentlicht. Dadurch bleiben bestehende öffentliche Manifeste auch während eines laufenden neuen Builds pullbar. --- @@ -143,17 +202,7 @@ Dies vermeidet unnötiges lokales Laden von Images und kann die Worker-Zeit redu ### Build ist nach dem Leeren des Caches zu schnell -Dies kann bedeuten, dass die Pipeline den Build übersprungen hat, weil das Registry-Image bereits existiert. - -Nach Protokollzeilen wie diesen suchen: - -```text -already exists -Skipping rebuild -docker manifest inspect -``` - -Einen Neubau erzwingen, indem die Pipeline-Bedingung geändert oder die Variable für den erzwungenen Neubau gesetzt wird. +Dies bedeutet üblicherweise, dass die Änderungserkennung die Komponente als nicht betroffen eingestuft hat oder BuildKit den Großteil der Layer aus dem Registry-Cache wiederhergestellt hat. Prüfe die Prepare-/Change-Detection-Ausgabe und die Komponenten-Build-Logs, bevor du einen Rebuild erzwingst. ### `latest`-Tag nicht gefunden diff --git a/CI-CD-Pipeline.md b/CI-CD-Pipeline.md index 390dafb..48111cc 100644 --- a/CI-CD-Pipeline.md +++ b/CI-CD-Pipeline.md @@ -11,21 +11,43 @@ The project uses Drone CI to build and publish images to the Gitea container reg The pipeline builds: ```text -romexis-payload -romexis-firebird-payload -romexis-base-jre:11-amd64 -romexis-base-jre:11-arm64 -romexis-server:-amd64 -romexis-server:-arm64 -romexis-admin:-amd64 -romexis-admin:-arm64 -romexis-mromexis-app:-amd64 -romexis-mromexis-app:-arm64 -romexis-migration-service:amd64 -romexis-migration-service:arm64 -multiarch manifests +romexis-payload: +romexis-client-payload: +romexis-firebird-payload:latest +romexis-base-jre:11-amd64 / 11-arm64 +romexis-gui-runtime:1-amd64 / 1-arm64 +romexis-server:-amd64 / -arm64 +romexis-admin:-amd64 / -arm64 +romexis-client:-amd64 / -arm64 +romexis-mromexis-app:-amd64 / -arm64 +romexis-migration-service:amd64 / arm64 +romexis-control-agent:amd64 / arm64 +public multiarch manifests ``` +## Pipeline Graph and Parallelism + +The build is split into five dependent Drone pipelines: + +```text +quality-gate + | + v +build-romexis-payload + | + +-------------------+ + v v +build-romexis-amd64 build-romexis-arm64 + | | + +---------+---------+ + v +create-romexis-manifests +``` + +Within each architecture pipeline, independent components can run in parallel according to their dependency graph. Runtime-dependent Server/Admin/Client builds wait only for the runtime they actually consume. + +--- + --- ## Branch Suffix Handling @@ -40,11 +62,32 @@ For feature branches, the branch name is normalized and appended as an image suf This allows feature branch images and manifests to be tested without overwriting `main` images. +## Change Detection and Version Matrix + +Drone determines affected components from the branch diff instead of rebuilding the complete image matrix for every commit. Feature branches compare against the merge base of the target/default branch so an earlier change on the same feature branch remains visible to later CI runs. + +Typical dependency scopes: + +| Changed area | Rebuilt components | +|---|---| +| `romexis-base/**` or server runtime sources | Server runtime, Server | +| `romexis-gui-runtime/**` or GUI runtime sources | GUI runtime, Admin, Client | +| `romexis/**` | Server | +| `romexis-admin/**` | Admin | +| `romexis-client/**` | Client | +| `migration-service/**` | Migration Service | +| `romexis-control-agent/**` | Control Agent | +| documentation only | no production images | + +Normal feature branches build only the default Romexis version unless a full matrix build is explicitly requested. + +--- + --- ## Payload Build Logic -The Windows payload build checks version definitions and copy-map changes. +The Windows payload build checks version definitions and both server/admin and Client copy-map changes. Stable payload tags are reused across ordinary feature branches; changed payload generation uses isolated commit-specific CI tags. Desired behavior: @@ -75,25 +118,33 @@ romexis-firebird-payload:latest The server image consumes the shared Firebird payload image. +## Shared Runtime Builds and Registry Cache + +`romexis-base-jre` and `romexis-gui-runtime` are built once per architecture when their sources change. BuildKit cache data is stored in separate registry cache scopes and reused through `--cache-from` / `--cache-to`. + +This prevents expensive package installation, Chilkat extraction and Java/native compilation from being repeated for every Romexis version. + +--- + --- ## Server Build -The server build pulls: +The server build combines the selected server runtime, Romexis payload and Firebird payload through explicit BuildKit image contexts: ```text -ROMEXIS_PAYLOAD_IMAGE -ROMEXIS_FIREBIRD_PAYLOAD_IMAGE -ROMEXIS_BASE_IMAGE +romexis-server-runtime +romexis-payload +romexis-firebird-payload ``` -Then builds the final runtime image for each architecture. +When a runtime was rebuilt in the same CI run, its commit-specific staging tag is consumed directly. Otherwise the stable public runtime tag is used. The final Server image is built separately for each architecture. --- ## Admin Build -The Admin build consumes the Romexis payload and builds: +The Admin build consumes the shared GUI runtime plus the Romexis server/admin payload and builds: ```text romexis-admin:-amd64 @@ -104,6 +155,14 @@ romexis-admin:latest The final image contains the graphical noVNC runtime and Romexis Admin / RomexisConfig files. +## Client Build + +The Client build consumes `romexis-gui-runtime` plus `romexis-client-payload` and publishes versioned amd64/arm64 images. It is independent from the Admin build; an Admin-only source change does not require a Client rebuild. + +Published public tags include the version manifest and `latest` for the configured default version. + +--- + --- ## mRomexis Web App Build @@ -133,9 +192,9 @@ romexis-mromexis-app:latest ## Push vs Load -In CI, use `--push` for buildx output when publishing images. +In CI, architecture builds use `--push` and write only immutable `ci--...` staging tags. Public version, `latest` and runtime manifest tags are not modified during the build. -This avoids unnecessary local image loading and can reduce worker time. +After amd64 and arm64 succeed, the final pipeline creates or replaces public manifests atomically with `docker buildx imagetools create`. A branch-head guard prevents an older, slower build from publishing over a newer commit. This also keeps existing public manifests pullable while a new build is running. --- @@ -143,17 +202,7 @@ This avoids unnecessary local image loading and can reduce worker time. ### Build is too fast after cache cleanup -This may mean the pipeline skipped the build because the registry image already exists. - -Look for log lines like: - -```text -already exists -Skipping rebuild -docker manifest inspect -``` - -Force rebuild by changing the pipeline condition or setting the force rebuild variable. +This usually means change detection decided that the component is unaffected, or BuildKit restored most layers from the registry cache. Check the prepare/change-detection output and the component build logs before forcing a rebuild. ### latest tag not found diff --git a/Container-Images.de.md b/Container-Images.de.md index 6505791..85ad397 100644 --- a/Container-Images.de.md +++ b/Container-Images.de.md @@ -10,12 +10,17 @@ Images werden in dem vom Projekt verwendeten Namespace der Gitea-Paket-Registry ```text gitea.buchhorster.de/planmeca/romexis-payload: +gitea.buchhorster.de/planmeca/romexis-client-payload: gitea.buchhorster.de/planmeca/romexis-firebird-payload:latest gitea.buchhorster.de/planmeca/romexis-base-jre:11-amd64 gitea.buchhorster.de/planmeca/romexis-base-jre:11-arm64 gitea.buchhorster.de/planmeca/romexis-base-jre:11 +gitea.buchhorster.de/planmeca/romexis-gui-runtime:1-amd64 +gitea.buchhorster.de/planmeca/romexis-gui-runtime:1-arm64 +gitea.buchhorster.de/planmeca/romexis-gui-runtime:1 + gitea.buchhorster.de/planmeca/romexis-server:-amd64 gitea.buchhorster.de/planmeca/romexis-server:-arm64 gitea.buchhorster.de/planmeca/romexis-server: @@ -25,6 +30,11 @@ gitea.buchhorster.de/planmeca/romexis-admin:-arm64 gitea.buchhorster.de/planmeca/romexis-admin: gitea.buchhorster.de/planmeca/romexis-admin:latest +gitea.buchhorster.de/planmeca/romexis-client:-amd64 +gitea.buchhorster.de/planmeca/romexis-client:-arm64 +gitea.buchhorster.de/planmeca/romexis-client: +gitea.buchhorster.de/planmeca/romexis-client:latest + gitea.buchhorster.de/planmeca/romexis-mromexis-app:-amd64 gitea.buchhorster.de/planmeca/romexis-mromexis-app:-arm64 gitea.buchhorster.de/planmeca/romexis-mromexis-app: @@ -33,6 +43,10 @@ gitea.buchhorster.de/planmeca/romexis-mromexis-app:latest gitea.buchhorster.de/planmeca/romexis-migration-service:amd64 gitea.buchhorster.de/planmeca/romexis-migration-service:arm64 gitea.buchhorster.de/planmeca/romexis-migration-service:latest + +gitea.buchhorster.de/planmeca/romexis-control-agent:amd64 +gitea.buchhorster.de/planmeca/romexis-control-agent:arm64 +gitea.buchhorster.de/planmeca/romexis-control-agent:latest ``` --- @@ -47,6 +61,14 @@ Das Windows-Payload-Image wird mit der Romexis-Version versioniert und ist archi romexis-payload:6.5.3.444.203 ``` +### Client-Payload-Image + +Das Client-Payload wird unabhängig vom finalen Client-Image versioniert, verwendet aber dieselbe Romexis-Version: + +```text +romexis-client-payload:6.5.3.444.203 +``` + ### Base-Image Base-Images sind architekturspezifisch und werden zusätzlich als Manifest veröffentlicht: @@ -57,6 +79,16 @@ romexis-base-jre:11-arm64 romexis-base-jre:11 ``` +### GUI-Runtime-Image + +Admin und Client verwenden eine gemeinsame architekturspezifische GUI-Runtime, die ebenfalls als Multi-Architektur-Manifest veröffentlicht wird: + +```text +romexis-gui-runtime:1-amd64 +romexis-gui-runtime:1-arm64 +romexis-gui-runtime:1 +``` + ### Server-Image Server-Images sind architekturspezifisch und werden als Multi-Architektur-Manifest veröffentlicht: @@ -78,6 +110,17 @@ romexis-admin: romexis-admin:latest ``` +### Client-Image + +Der Client ist ein eigenständiges finales Image und erbt nicht vom Admin: + +```text +romexis-client:-amd64 +romexis-client:-arm64 +romexis-client: +romexis-client:latest +``` + ### mRomexis-Web-App-Image Das mRomexis-Web-App-Image wird mit der Romexis-Version versioniert: @@ -97,6 +140,22 @@ Es kann nur für Romexis-Versionen gebaut werden, die Folgendes enthalten: Dies wird für Romexis 6.5.3 und neuer erwartet. +### Migration- und Control-Agent-Images + +Diese Dienste sind von der Romexis-Installer-Versionsmatrix unabhängig und veröffentlichen Architektur-Aliase sowie ein `latest`-Multi-Architektur-Manifest: + +```text +romexis-migration-service:amd64 +romexis-migration-service:arm64 +romexis-migration-service:latest + +romexis-control-agent:amd64 +romexis-control-agent:arm64 +romexis-control-agent:latest +``` + +--- + --- ## Branch-Image-Suffixe @@ -119,7 +178,23 @@ Beispiel für ein aufgelöstes Image: gitea.buchhorster.de/planmeca/romexis-server:6.5.3.444.203-feature-romexis-admin ``` -Dies verhindert, dass Feature-Branch-Builds Laufzeitimages von `main` überschreiben oder mit ihnen verwechselt werden. +Dies verhindert, dass Feature-Branch-Builds Laufzeitimages von `main` überschreiben oder mit ihnen verwechselt werden. Stabile versionierte Payloads werden normalerweise ohne Branch-Suffix wiederverwendet; nur Branches mit Änderungen an der Payload-Erzeugung erstellen isolierte commit-spezifische CI-Payload-Tags. + +## CI-Staging-Tags und Build-Cache + +Drone baut nicht direkt in öffentliche Runtime-Tags. Architektur-Builds verwenden zunächst unveränderliche commit-spezifische Staging-Tags, zum Beispiel: + +```text +romexis-base-jre:ci--amd64 +romexis-gui-runtime:ci--arm64 +romexis-server:ci---amd64 +romexis-admin:ci---arm64 +romexis-client:ci---amd64 +``` + +Erst nachdem beide Architekturen erfolgreich sind, werden öffentliche Manifeste mit `docker buildx imagetools create` aktualisiert. Separate Registry-Einträge `romexis-buildcache:*` sind BuildKit-Caches und keine Runtime-Images. + +--- --- @@ -137,6 +212,12 @@ Admin-Image: docker pull gitea.buchhorster.de/planmeca/romexis-admin:latest ``` +Client-Image: + +```bash +docker pull gitea.buchhorster.de/planmeca/romexis-client:latest +``` + mRomexis-Web-App-Image: ```bash diff --git a/Container-Images.md b/Container-Images.md index bfea663..214454b 100644 --- a/Container-Images.md +++ b/Container-Images.md @@ -10,12 +10,17 @@ Images are published to the Gitea package registry namespace used by the project ```text gitea.buchhorster.de/planmeca/romexis-payload: +gitea.buchhorster.de/planmeca/romexis-client-payload: gitea.buchhorster.de/planmeca/romexis-firebird-payload:latest gitea.buchhorster.de/planmeca/romexis-base-jre:11-amd64 gitea.buchhorster.de/planmeca/romexis-base-jre:11-arm64 gitea.buchhorster.de/planmeca/romexis-base-jre:11 +gitea.buchhorster.de/planmeca/romexis-gui-runtime:1-amd64 +gitea.buchhorster.de/planmeca/romexis-gui-runtime:1-arm64 +gitea.buchhorster.de/planmeca/romexis-gui-runtime:1 + gitea.buchhorster.de/planmeca/romexis-server:-amd64 gitea.buchhorster.de/planmeca/romexis-server:-arm64 gitea.buchhorster.de/planmeca/romexis-server: @@ -25,6 +30,11 @@ gitea.buchhorster.de/planmeca/romexis-admin:-arm64 gitea.buchhorster.de/planmeca/romexis-admin: gitea.buchhorster.de/planmeca/romexis-admin:latest +gitea.buchhorster.de/planmeca/romexis-client:-amd64 +gitea.buchhorster.de/planmeca/romexis-client:-arm64 +gitea.buchhorster.de/planmeca/romexis-client: +gitea.buchhorster.de/planmeca/romexis-client:latest + gitea.buchhorster.de/planmeca/romexis-mromexis-app:-amd64 gitea.buchhorster.de/planmeca/romexis-mromexis-app:-arm64 gitea.buchhorster.de/planmeca/romexis-mromexis-app: @@ -33,6 +43,10 @@ gitea.buchhorster.de/planmeca/romexis-mromexis-app:latest gitea.buchhorster.de/planmeca/romexis-migration-service:amd64 gitea.buchhorster.de/planmeca/romexis-migration-service:arm64 gitea.buchhorster.de/planmeca/romexis-migration-service:latest + +gitea.buchhorster.de/planmeca/romexis-control-agent:amd64 +gitea.buchhorster.de/planmeca/romexis-control-agent:arm64 +gitea.buchhorster.de/planmeca/romexis-control-agent:latest ``` --- @@ -47,6 +61,14 @@ The Windows payload image is versioned by Romexis version and is architecture-in romexis-payload:6.5.3.444.203 ``` +### Client payload image + +The Client payload is versioned independently from the final Client image but uses the same Romexis version: + +```text +romexis-client-payload:6.5.3.444.203 +``` + ### Base image Base images are architecture-specific and also published as a manifest: @@ -57,6 +79,16 @@ romexis-base-jre:11-arm64 romexis-base-jre:11 ``` +### GUI runtime image + +Admin and Client share an architecture-specific GUI runtime that is also published as a multi-architecture manifest: + +```text +romexis-gui-runtime:1-amd64 +romexis-gui-runtime:1-arm64 +romexis-gui-runtime:1 +``` + ### Server image Server images are architecture-specific and published as a multi-architecture manifest: @@ -78,6 +110,17 @@ romexis-admin: romexis-admin:latest ``` +### Client image + +The Client is a standalone final image and does not inherit from Admin: + +```text +romexis-client:-amd64 +romexis-client:-arm64 +romexis-client: +romexis-client:latest +``` + ### mRomexis Web App image The mRomexis Web App image is versioned by Romexis version: @@ -97,6 +140,22 @@ It can only be built for Romexis versions that contain: This is expected for Romexis 6.5.3 and newer. +### Migration and Control Agent images + +These services are independent from the Romexis installer version matrix and publish architecture aliases plus a `latest` multi-architecture manifest: + +```text +romexis-migration-service:amd64 +romexis-migration-service:arm64 +romexis-migration-service:latest + +romexis-control-agent:amd64 +romexis-control-agent:arm64 +romexis-control-agent:latest +``` + +--- + --- ## Branch Image Suffixes @@ -119,7 +178,23 @@ Example resolved image: gitea.buchhorster.de/planmeca/romexis-server:6.5.3.444.203-feature-romexis-admin ``` -This prevents feature branch builds from overwriting or being confused with `main` runtime images. +This prevents feature branch builds from overwriting or being confused with `main` runtime images. Stable versioned payloads are normally reused without a branch suffix; only branches that change payload generation create isolated commit-specific CI payload tags. + +## CI Staging Tags and Build Cache + +Drone does not build directly into public runtime tags. Architecture builds first use immutable commit-specific staging tags, for example: + +```text +romexis-base-jre:ci--amd64 +romexis-gui-runtime:ci--arm64 +romexis-server:ci---amd64 +romexis-admin:ci---arm64 +romexis-client:ci---amd64 +``` + +Only after both architectures succeed are public manifests updated with `docker buildx imagetools create`. Separate `romexis-buildcache:*` registry entries are BuildKit caches and are not runtime images. + +--- --- @@ -137,6 +212,12 @@ Admin image: docker pull gitea.buchhorster.de/planmeca/romexis-admin:latest ``` +Client image: + +```bash +docker pull gitea.buchhorster.de/planmeca/romexis-client:latest +``` + mRomexis Web App image: ```bash diff --git a/Developer-Guide.de.md b/Developer-Guide.de.md index 36e1c2c..2a31442 100644 --- a/Developer-Guide.de.md +++ b/Developer-Guide.de.md @@ -9,11 +9,20 @@ Diese Seite beschreibt die interne Projektstruktur und den Entwicklungsworkflow. ## Hauptverzeichnisse des Projekts ```text +romexis-common/ + Shared Java agent, patches and native helper sources. + romexis-base/ - Runtime base image. + Shared Romexis Server runtime image. + +romexis-gui-runtime/ + Shared GUI runtime for Romexis Admin and Client. romexis-payload/ - Windows installer payload extraction. + Windows installer payload extraction for Server/Admin/mRomexis. + +romexis-client-payload/ + Version-specific Romexis Client payload image. romexis-firebird-payload/ macOS Firebird SQL payload extraction. @@ -21,12 +30,27 @@ romexis-firebird-payload/ romexis/ Final Romexis Server image. +romexis-admin/ + Final Romexis Admin image. + +romexis-client/ + Final standalone Romexis Client image. + +romexis-mromexis-app/ + Final mRomexis Web App image. + +romexis-control-agent/ + Restricted container control API. + migration-service/ Migration Web UI, REST API, SFTP and restore orchestration. migration-client/ Source-side migration helper client. +scripts/ + Local and CI build helpers. + docs/ Extended markdown documentation. ``` @@ -36,15 +60,31 @@ docs/ ## Entwicklungsgrundsätze - Proprietäre Binärdateien aus Git fernhalten. -- Installerextraktion in Payload-Images belassen. -- Laufzeitabhängigkeiten im Base-Image belassen. -- Das endgültige Server-Image auf Zusammenbau und Laufzeitlogik konzentrieren. +- Versionsabhängige Installerextraktion in Payload-Images belassen. +- Aufwendige architekturabhängige Abhängigkeiten in gemeinsamen Runtime-Images belassen. +- Gemeinsame Agent-, Patch- und native Hilfsquellen in `romexis-common/` pflegen. +- Die finalen Server-, Admin- und Client-Images auf Zusammenbau und Laufzeitlogik konzentrieren. +- Romexis Admin und Romexis Client als unabhängige finale Images auf Basis derselben GUI-Runtime halten. - MSSQL- und Firebird-Initialisierung getrennt halten. - Das Wrapper-Skript ausschließlich für das Backend-Routing verwenden. - Explizite Validierung gegenüber still erzeugten, unvollständigen Images bevorzugen. --- +## Build-Abhängigkeitsmodell + +Der Build ist bewusst in drei Ebenen aufgeteilt: + +1. **Payload-Images** enthalten versionsabhängige Inhalte aus dem Romexis-Installer. +2. **Runtime-Images** enthalten wiederverwendbare architekturabhängige Betriebssystem- und Bibliotheksabhängigkeiten. +3. **Finale Images** kombinieren Payload und Runtime mit den komponentenspezifischen Skripten. + +Dadurch bleiben sowohl die umfangreiche Installerextraktion als auch die aufwendige Runtime-Vorbereitung über Server-, Admin- und Client-Builds hinweg wiederverwendbar. Reine Payload- und Runtime-Build-Images sind keine zusätzlichen Laufzeitdienste in Docker Compose. + +Für lokale Entwicklung werden `scripts/build-local.sh` oder `scripts/build-local.ps1` verwendet. Drone nutzt dasselbe Abhängigkeitsmodell mit unveränderlichen commitbezogenen Staging-Tags und Registry-basierten BuildKit-Caches. + +--- + ## Datenbankinitialisierungsskripte ```text diff --git a/Developer-Guide.md b/Developer-Guide.md index 14e3187..f7c3e9f 100644 --- a/Developer-Guide.md +++ b/Developer-Guide.md @@ -9,11 +9,20 @@ This page describes the internal project structure and development workflow. ## Main Project Directories ```text +romexis-common/ + Shared Java agent, patches and native helper sources. + romexis-base/ - Runtime base image. + Shared Romexis Server runtime image. + +romexis-gui-runtime/ + Shared GUI runtime for Romexis Admin and Client. romexis-payload/ - Windows installer payload extraction. + Windows installer payload extraction for Server/Admin/mRomexis. + +romexis-client-payload/ + Version-specific Romexis Client payload image. romexis-firebird-payload/ macOS Firebird SQL payload extraction. @@ -21,12 +30,27 @@ romexis-firebird-payload/ romexis/ Final Romexis Server image. +romexis-admin/ + Final Romexis Admin image. + +romexis-client/ + Final standalone Romexis Client image. + +romexis-mromexis-app/ + Final mRomexis Web App image. + +romexis-control-agent/ + Restricted container control API. + migration-service/ Migration Web UI, REST API, SFTP and restore orchestration. migration-client/ Source-side migration helper client. +scripts/ + Local and CI build helpers. + docs/ Extended markdown documentation. ``` @@ -36,15 +60,31 @@ docs/ ## Development Principles - Keep proprietary binaries out of Git. -- Keep installer extraction in payload images. -- Keep runtime dependencies in the base image. -- Keep final server image focused on assembly and runtime logic. +- Keep version-specific installer extraction in payload images. +- Keep expensive architecture-specific dependencies in shared runtime images. +- Keep common agent, patch and native helper sources in `romexis-common/`. +- Keep final Server, Admin and Client images focused on assembly and runtime logic. +- Keep Romexis Admin and Romexis Client as independent final images based on the same GUI runtime. - Keep MSSQL and Firebird initialization separated. - Use the wrapper script only for backend routing. - Prefer explicit validation over silent incomplete images. --- +## Build Dependency Model + +The build is intentionally split into three layers: + +1. **Payload images** contain version-specific Romexis installer content. +2. **Runtime images** contain reusable architecture-specific operating-system and library dependencies. +3. **Final images** assemble payload and runtime content together with the component-specific scripts. + +This keeps large installer extraction and expensive runtime preparation reusable across Server, Admin and Client builds. Build-only payload and runtime images are not additional runtime services in Docker Compose. + +For local development use `scripts/build-local.sh` or `scripts/build-local.ps1`. Drone uses the same dependency model with immutable commit-specific staging tags and registry-backed BuildKit caches. + +--- + ## Database Init Scripts ```text diff --git a/Home.de.md b/Home.de.md index 2857455..a3f72f5 100644 --- a/Home.de.md +++ b/Home.de.md @@ -4,7 +4,7 @@ Willkommen im Wiki des Romexis-Docker-Projekts. -Dieses Wiki dokumentiert den Docker-basierten Romexis-Runtime-Stack, das Backend-spezifische Compose-Layout, die lokalen Build-Skripte, die Payload-Image-Architektur, den Romexis-Admin-Container, den mRomexis-Web-App-Container, die Datenbank-Backends, die Migrationswerkzeuge und den CI/CD-Workflow. +Dieses Wiki dokumentiert den Docker-basierten Romexis-Runtime-Stack, das Backend-spezifische Compose-Layout, die lokalen und Drone-Build-Workflows, die Payload-/Runtime-Image-Architektur, die Romexis-Server-, Admin- und Client-Container, den mRomexis-Web-App-Container, die Datenbank-Backends, die Migrationswerkzeuge und den CI/CD-Workflow. > Dieses Projekt stellt eine reproduzierbare Docker-Umgebung für den Betrieb von Planmeca Romexis Server unter Linux, macOS oder WSL mit Windows bereit und hält den Build-Prozess dabei nahe am Layout des ursprünglichen Installers. Romexis-Anwendungsbinärdateien werden nicht im Repository gespeichert. Sie werden während des Build-Prozesses aus offiziellen Installer-Paketen extrahiert. @@ -21,6 +21,7 @@ Dieses Wiki dokumentiert den Docker-basierten Romexis-Runtime-Stack, das Backend | [Konfiguration](Configuration.de) | Umgebungsvariablen und Runtime-Konfiguration | | [Container-Images](Container-Images.de) | Registry-Images, Tags, Manifeste und Branch-Suffixe | | [Romexis Admin](Romexis-Admin.de) | Browserbasierter RomexisConfig-/Admin-Container über noVNC | +| [Romexis Client](Romexis-Client.de) | Browserbasierter Romexis-Client-Container über noVNC | | [mRomexis Web App](mRomexis-WebApp.de) | Separater Tomcat-basierter mRomexis-Web-Frontend-Container | | [Build-System](Build-System.de) | Payload-, Base-, Server-, Admin- und Web-App-Build-Workflow | | [Lokale Build-Skripte](Local-Build-Scripts.de) | Lokale Build-Hilfsskripte für Linux/macOS und Windows | @@ -37,13 +38,19 @@ Dieses Wiki dokumentiert den Docker-basierten Romexis-Runtime-Stack, das Backend ```text romexis-payload/ - Builds architecture-independent payload images from the official Windows installer. + Builds architecture-independent server/admin and client payload images from the official Windows installer. romexis-firebird-payload/ Builds a Firebird SQL payload from the official macOS installer. +romexis-common/ + Contains shared PropertyAgent, Chilkat patch and DxService compatibility sources. + romexis-base/ - Builds the reusable Java 11 runtime base image. + Builds the reusable Java 11 server runtime image. + +romexis-gui-runtime/ + Builds the reusable Java 17/X11/noVNC GUI runtime for Admin and Client. romexis/ Builds the final Romexis Server image. @@ -51,17 +58,23 @@ romexis/ romexis-admin/ Builds the browser-accessible Romexis Admin / RomexisConfig container. +romexis-client/ + Builds the browser-accessible Romexis Client container. + romexis-mromexis-app/ Builds the standalone mRomexis Web App container from the Romexis payload WAR. migration-service/ Provides browser-based and API-driven migration orchestration. +romexis-control-agent/ + Provides restricted container-control operations for migration and service coordination. + migration-client/ Provides the Windows migration helper client. scripts/ - Contains local build helpers such as build-local.sh and build-local.ps1. + Contains local and CI build helpers. ``` --- @@ -93,10 +106,11 @@ Das aktive Backend wird in `.env` über `DATABASE_BACKEND` und `COMPOSE_FILE` au 4. [Schnellstart](Quick-Start.de) 5. [Konfiguration](Configuration.de) 6. [Romexis Admin](Romexis-Admin.de) -7. [mRomexis Web App](mRomexis-WebApp.de) -8. [Datenbank-Backends](Database-Backends.de) -9. [Build-System](Build-System.de) -10. [Entwicklerhandbuch](Developer-Guide.de) +7. [Romexis Client](Romexis-Client.de) +8. [mRomexis Web App](mRomexis-WebApp.de) +9. [Datenbank-Backends](Database-Backends.de) +10. [Build-System](Build-System.de) +11. [Entwicklerhandbuch](Developer-Guide.de) --- diff --git a/Home.md b/Home.md index 35187f5..016767f 100644 --- a/Home.md +++ b/Home.md @@ -4,7 +4,7 @@ Welcome to the Romexis Docker project wiki. -This wiki documents the Docker-based Romexis runtime stack, the backend-specific Compose layout, the local build scripts, the payload image architecture, the Romexis Admin container, the mRomexis Web App container, database backends, migration tooling and CI/CD workflow. +This wiki documents the Docker-based Romexis runtime stack, the backend-specific Compose layout, the local and Drone build workflows, the payload/runtime image architecture, the Romexis Server, Admin and Client containers, the mRomexis Web App container, database backends, migration tooling and CI/CD workflow. > This project provides a reproducible Docker environment for running Planmeca Romexis Server on Linux, macOS or WSL with Windows while keeping the build process close to the original installer layout. Romexis application binaries are not stored in the repository. They are extracted from official installer packages during the build process. @@ -21,6 +21,7 @@ This wiki documents the Docker-based Romexis runtime stack, the backend-specific | [Configuration](Configuration) | Environment variables and runtime configuration | | [Container Images](Container-Images) | Registry images, tags, manifests and branch suffixes | | [Romexis Admin](Romexis-Admin) | Browser-based RomexisConfig/Admin container via noVNC | +| [Romexis Client](Romexis-Client) | Browser-based Romexis Client container via noVNC | | [mRomexis Web App](mRomexis-WebApp) | Separate Tomcat-based mRomexis Web frontend container | | [Build System](Build-System) | Payload, base, server, admin and web app build workflow | | [Local Build Scripts](Local-Build-Scripts) | Local build helper scripts for Linux/macOS and Windows | @@ -37,13 +38,19 @@ This wiki documents the Docker-based Romexis runtime stack, the backend-specific ```text romexis-payload/ - Builds architecture-independent payload images from the official Windows installer. + Builds architecture-independent server/admin and client payload images from the official Windows installer. romexis-firebird-payload/ Builds a Firebird SQL payload from the official macOS installer. +romexis-common/ + Contains shared PropertyAgent, Chilkat patch and DxService compatibility sources. + romexis-base/ - Builds the reusable Java 11 runtime base image. + Builds the reusable Java 11 server runtime image. + +romexis-gui-runtime/ + Builds the reusable Java 17/X11/noVNC GUI runtime for Admin and Client. romexis/ Builds the final Romexis Server image. @@ -51,17 +58,23 @@ romexis/ romexis-admin/ Builds the browser-accessible Romexis Admin / RomexisConfig container. +romexis-client/ + Builds the browser-accessible Romexis Client container. + romexis-mromexis-app/ Builds the standalone mRomexis Web App container from the Romexis payload WAR. migration-service/ Provides browser-based and API-driven migration orchestration. +romexis-control-agent/ + Provides restricted container-control operations for migration and service coordination. + migration-client/ Provides the Windows migration helper client. scripts/ - Contains local build helpers such as build-local.sh and build-local.ps1. + Contains local and CI build helpers. ``` --- @@ -93,10 +106,11 @@ The active backend is selected in `.env` through `DATABASE_BACKEND` and `COMPOSE 4. [Quick Start](Quick-Start) 5. [Configuration](Configuration) 6. [Romexis Admin](Romexis-Admin) -7. [mRomexis Web App](mRomexis-WebApp) -8. [Database Backends](Database-Backends) -9. [Build System](Build-System) -10. [Developer Guide](Developer-Guide) +7. [Romexis Client](Romexis-Client) +8. [mRomexis Web App](mRomexis-WebApp) +9. [Database Backends](Database-Backends) +10. [Build System](Build-System) +11. [Developer Guide](Developer-Guide) --- diff --git a/Local-Build-Scripts.de.md b/Local-Build-Scripts.de.md index 6b6447f..241e34f 100644 --- a/Local-Build-Scripts.de.md +++ b/Local-Build-Scripts.de.md @@ -40,26 +40,34 @@ Verfügbare Zielgruppen: ```text all -base +runtimes +server-runtime +gui-runtime +payload +client-payload +firebird-payload server admin +client mromexis migration +control +manifests ``` Beispiele: ```bash -./scripts/build-local.sh base server -./scripts/build-local.sh admin mromexis -./scripts/build-local.sh migration +./scripts/build-local.sh server-runtime server +./scripts/build-local.sh gui-runtime admin client +./scripts/build-local.sh migration control ``` PowerShell-Beispiele: ```powershell -.\scripts\build-local.ps1 -Targets base,server -.\scripts\build-local.ps1 -Targets admin,mromexis +.\scripts\build-local.ps1 -Targets server-runtime,server +.\scripts\build-local.ps1 -Targets gui-runtime,admin,client ``` --- @@ -80,6 +88,11 @@ ROMEXIS_IMAGE=romexis-server MIGRATION_IMAGE=romexis-migration-service ADMINISTRATION_IMAGE=romexis-admin MROMEXIS_WEBAPP_IMAGE=romexis-mromexis-app +CLIENT_IMAGE=romexis-client +CONTROL_AGENT_IMAGE=romexis-control-agent +SERVER_RUNTIME_VERSION=11 +GUI_RUNTIME_VERSION=1 +REGISTRY_CACHE=0 ``` Für Feature-Branches: @@ -88,6 +101,14 @@ Für Feature-Branches: IMAGE_SUFFIX=-feature-romexis-admin ``` +## Abhängigkeitsauflösung und lokale Aliase + +Vor dem Build eines finalen Images stellen die Skripte sicher, dass die benötigten Payload-Images verfügbar sind: Ein vorhandenes lokales Image wird wiederverwendet, andernfalls wird die Registry versucht und wenn das Image weiterhin fehlt, wird es aus den lokalen Projektquellen gebaut. + +Bei `PUSH=0` erhalten lokal gebaute Runtime-/Payload-Abhängigkeiten zusätzlich isolierte `romexis-local/...`-Aliase. Diese Aliase verhindern, dass BuildKit ein älteres Registry-Image mit demselben öffentlichen Tag auflöst. Die Aliase sind reine Build-Implementierungsdetails und werden nicht veröffentlicht. + +--- + --- ## Beziehung zu Runtime Compose @@ -104,6 +125,24 @@ ${REGISTRY}/${MROMEXIS_WEBAPP_IMAGE}:${ROMEXIS_VERSION}${IMAGE_SUFFIX} Dadurch kann dieselbe `.env` für lokale Builds und den Start der Laufzeit verwendet werden. +## Sicherer Push und Manifest-Veröffentlichung + +Ein lokaler Single-Architecture-Build mit `PUSH=1` veröffentlicht nur den Architektur-Tag, zum Beispiel `romexis-server:-amd64`. Der öffentliche Multi-Architektur-Tag wird dadurch nicht ersetzt. + +Nachdem beide Architekturen gepusht wurden, werden die Manifeste explizit veröffentlicht: + +```bash +PUSH=1 ./scripts/build-local.sh manifests +``` + +PowerShell: + +```powershell +.\scripts\build-local.ps1 -Targets manifests -Push 1 +``` + +--- + --- ## Typischer Workflow diff --git a/Local-Build-Scripts.md b/Local-Build-Scripts.md index 2425600..eb083c9 100644 --- a/Local-Build-Scripts.md +++ b/Local-Build-Scripts.md @@ -40,26 +40,34 @@ Available target groups: ```text all -base +runtimes +server-runtime +gui-runtime +payload +client-payload +firebird-payload server admin +client mromexis migration +control +manifests ``` Examples: ```bash -./scripts/build-local.sh base server -./scripts/build-local.sh admin mromexis -./scripts/build-local.sh migration +./scripts/build-local.sh server-runtime server +./scripts/build-local.sh gui-runtime admin client +./scripts/build-local.sh migration control ``` PowerShell examples: ```powershell -.\scripts\build-local.ps1 -Targets base,server -.\scripts\build-local.ps1 -Targets admin,mromexis +.\scripts\build-local.ps1 -Targets server-runtime,server +.\scripts\build-local.ps1 -Targets gui-runtime,admin,client ``` --- @@ -80,6 +88,11 @@ ROMEXIS_IMAGE=romexis-server MIGRATION_IMAGE=romexis-migration-service ADMINISTRATION_IMAGE=romexis-admin MROMEXIS_WEBAPP_IMAGE=romexis-mromexis-app +CLIENT_IMAGE=romexis-client +CONTROL_AGENT_IMAGE=romexis-control-agent +SERVER_RUNTIME_VERSION=11 +GUI_RUNTIME_VERSION=1 +REGISTRY_CACHE=0 ``` For feature branches: @@ -88,6 +101,14 @@ For feature branches: IMAGE_SUFFIX=-feature-romexis-admin ``` +## Dependency Resolution and Local Aliases + +Before building a final image, the scripts ensure that required payload images are available: an existing local image is reused, otherwise the registry is tried, and if the image is still unavailable it is built from the local project sources. + +For `PUSH=0`, locally built runtime/payload dependencies are additionally tagged with isolated `romexis-local/...` aliases. These aliases prevent BuildKit from resolving an older registry image that happens to have the same public tag. The aliases are build-only implementation details and are not published. + +--- + --- ## Relationship to Runtime Compose @@ -104,6 +125,24 @@ ${REGISTRY}/${MROMEXIS_WEBAPP_IMAGE}:${ROMEXIS_VERSION}${IMAGE_SUFFIX} This allows the same `.env` to be used for local builds and runtime startup. +## Safe Push and Manifest Publication + +A local single-architecture build with `PUSH=1` publishes only the architecture tag, for example `romexis-server:-amd64`. It does not replace the public multi-architecture tag. + +After both architectures have been pushed, publish manifests explicitly: + +```bash +PUSH=1 ./scripts/build-local.sh manifests +``` + +PowerShell: + +```powershell +.\scripts\build-local.ps1 -Targets manifests -Push 1 +``` + +--- + --- ## Typical Workflow diff --git a/Payload-Images.de.md b/Payload-Images.de.md index 29e9434..f01b91a 100644 --- a/Payload-Images.de.md +++ b/Payload-Images.de.md @@ -33,6 +33,20 @@ Ausgabevertrag: Das Payload darf keine architekturspezifischen Laufzeitbibliotheken wie Chilkat enthalten. +## Client-Payload + +Derselbe Windows-Installer wird zusätzlich verwendet, um ein separates architekturunabhängiges Client-Payload zu bauen: + +```text +romexis-client-payload: +``` + +Die Extraktion wird über `romexis-payload/romexis-client-copy-map.tsv` gesteuert. Durch das separate Client-Payload kann das finale Image `romexis-client` unabhängig vom Admin-Image gebaut werden. + +Server-/Admin-Payload und Client-Payload sind normalerweise stabile, versionierte Eingaben und werden über Feature-Branches hinweg wiederverwendet, statt bei jedem Commit erneut extrahiert zu werden. + +--- + --- ## Versionsdatei @@ -114,6 +128,19 @@ Wichtige Dateien: /opt/romexis-firebird-db/templates/romexis_new.fdb ``` +## CI-Rebuild- und Staging-Verhalten + +Drone baut Payloads nur neu, wenn eine neue Romexis-Version oder eine Änderung an Extraktion/Copy-Maps dies erfordert. Ändert ein Feature-Branch die Payload-Erzeugung, werden isolierte commit-spezifische Tags verwendet, zum Beispiel: + +```text +romexis-payload:ci-- +romexis-client-payload:ci-- +``` + +Dadurch ersetzen experimentelle Extraktionsänderungen keine stabilen versionierten Payloads. + +--- + --- ## Ein Payload-Image untersuchen diff --git a/Payload-Images.md b/Payload-Images.md index da84876..ae87a7f 100644 --- a/Payload-Images.md +++ b/Payload-Images.md @@ -33,6 +33,20 @@ Output contract: The payload must not contain architecture-specific runtime libraries like Chilkat. +## Client Payload + +The same Windows installer is also used to build a separate architecture-independent Client payload: + +```text +romexis-client-payload: +``` + +Its extraction is controlled by `romexis-payload/romexis-client-copy-map.tsv`. Keeping Client files in a separate payload allows the final `romexis-client` image to be built independently from the Admin image. + +The server/admin payload and Client payload are normally stable, versioned inputs and are reused across feature branches instead of being re-extracted for every commit. + +--- + --- ## Version File @@ -114,6 +128,19 @@ Important files: /opt/romexis-firebird-db/templates/romexis_new.fdb ``` +## CI Rebuild and Staging Behavior + +Drone rebuilds payloads only when a new Romexis version or payload extraction/copy-map change requires it. A feature branch that changes payload generation uses isolated commit-specific tags such as: + +```text +romexis-payload:ci-- +romexis-client-payload:ci-- +``` + +This prevents experimental extraction changes from replacing stable versioned payloads. + +--- + --- ## Inspecting a Payload Image diff --git a/Project-Structure.de.md b/Project-Structure.de.md index 4e05497..3a25f16 100644 --- a/Project-Structure.de.md +++ b/Project-Structure.de.md @@ -5,6 +5,7 @@ ```text . ├── .drone.yml +├── .dockerignore ├── .env.sample ├── docker-compose.yml ├── docker-compose.mssql.yml @@ -16,13 +17,26 @@ ├── DEVELOPERS.md ├── scripts/ │ ├── build-local.sh -│ └── build-local.ps1 +│ ├── build-local.ps1 +│ ├── ci-lib.sh +│ ├── ci-prepare.sh +│ ├── ci-prepare-buildx.sh +│ ├── ci-payload.sh +│ ├── ci-build-component.sh +│ └── ci-publish-manifests.sh +├── romexis-common/ +│ ├── RomexisPropertyAgent.java +│ ├── dxservice_dummy.c +│ └── patches-src/ ├── romexis-base/ │ └── Dockerfile +├── romexis-gui-runtime/ +│ └── Dockerfile ├── romexis-payload/ │ ├── Dockerfile │ ├── romexis-versions.env │ ├── romexis-copy-map.tsv +│ ├── romexis-client-copy-map.tsv │ ├── download-romexis-installer-parts.py │ └── extract-and-copy-romexis-parts.sh ├── romexis-firebird-payload/ @@ -32,18 +46,20 @@ ├── romexis/ │ ├── Dockerfile │ ├── entrypoint.sh -│ ├── init-romexis-db.sh -│ ├── init-romexis-mssql-db.sh -│ ├── init-romexis-firebird-db.sh -│ ├── fix-keystore-alias.sh -│ └── RomexisPropertyAgent.java +│ └── database/runtime helper scripts ├── romexis-admin/ │ ├── Dockerfile │ ├── start.sh -│ └── native helper sources -├── romexis-mromexis-app/ +│ └── test.sh +├── romexis-client/ │ ├── Dockerfile -│ └── nginx.conf +│ ├── start.sh +│ └── test.sh +├── romexis-mromexis-app/ +│ └── Dockerfile +├── romexis-control-agent/ +│ ├── Dockerfile +│ └── app.py ├── migration-service/ │ ├── Dockerfile │ ├── entrypoint.sh diff --git a/Project-Structure.md b/Project-Structure.md index 5b391b4..656c98e 100644 --- a/Project-Structure.md +++ b/Project-Structure.md @@ -5,6 +5,7 @@ ```text . ├── .drone.yml +├── .dockerignore ├── .env.sample ├── docker-compose.yml ├── docker-compose.mssql.yml @@ -16,13 +17,26 @@ ├── DEVELOPERS.md ├── scripts/ │ ├── build-local.sh -│ └── build-local.ps1 +│ ├── build-local.ps1 +│ ├── ci-lib.sh +│ ├── ci-prepare.sh +│ ├── ci-prepare-buildx.sh +│ ├── ci-payload.sh +│ ├── ci-build-component.sh +│ └── ci-publish-manifests.sh +├── romexis-common/ +│ ├── RomexisPropertyAgent.java +│ ├── dxservice_dummy.c +│ └── patches-src/ ├── romexis-base/ │ └── Dockerfile +├── romexis-gui-runtime/ +│ └── Dockerfile ├── romexis-payload/ │ ├── Dockerfile │ ├── romexis-versions.env │ ├── romexis-copy-map.tsv +│ ├── romexis-client-copy-map.tsv │ ├── download-romexis-installer-parts.py │ └── extract-and-copy-romexis-parts.sh ├── romexis-firebird-payload/ @@ -32,18 +46,20 @@ ├── romexis/ │ ├── Dockerfile │ ├── entrypoint.sh -│ ├── init-romexis-db.sh -│ ├── init-romexis-mssql-db.sh -│ ├── init-romexis-firebird-db.sh -│ ├── fix-keystore-alias.sh -│ └── RomexisPropertyAgent.java +│ └── database/runtime helper scripts ├── romexis-admin/ │ ├── Dockerfile │ ├── start.sh -│ └── native helper sources -├── romexis-mromexis-app/ +│ └── test.sh +├── romexis-client/ │ ├── Dockerfile -│ └── nginx.conf +│ ├── start.sh +│ └── test.sh +├── romexis-mromexis-app/ +│ └── Dockerfile +├── romexis-control-agent/ +│ ├── Dockerfile +│ └── app.py ├── migration-service/ │ ├── Dockerfile │ ├── entrypoint.sh diff --git a/Release-Process.de.md b/Release-Process.de.md index 79b84c3..470d4bf 100644 --- a/Release-Process.de.md +++ b/Release-Process.de.md @@ -12,21 +12,35 @@ Ein Release umfasst üblicherweise: - optionale Änderungen am Migrationsdienst - optionale Änderungen am Client +Die optimierte Build-Architektur unterscheidet zwischen versionsabhängigen Payload-Images, gemeinsamen architekturabhängigen Runtime-Images und finalen, für Anwender bestimmten Komponenten-Images. Payload- und Runtime-Images sind Build-Abhängigkeiten; reguläre Installationen verwenden weiterhin die finalen Images. + --- ## Empfohlene Release-Schritte -1. Sicherstellen, dass das Repository fehlerfrei gebaut wird. -2. Verfügbarkeit der Payload-Images prüfen. -3. Base-Images für die Zielarchitekturen prüfen. -4. Server-Images für die Zielarchitekturen prüfen. -5. Multiarch-Manifeste prüfen. -6. Docker-Compose-Start testen. -7. Datenbankinitialisierung testen. -8. Start des Migrationsdienstes testen. -9. Release Notes erstellen. -10. Gitea-Release veröffentlichen. -11. Gitea-Pakete prüfen. +1. Sicherstellen, dass das Repository fehlerfrei gebaut wird und die Wiki-Tests bestehen. +2. Verfügbarkeit der Server-, Client- und Firebird-Payload-Images prüfen. +3. Server- und GUI-Runtime-Images für die Zielarchitekturen prüfen. +4. Server-, Admin-, Client- und mRomexis-Images für die Zielarchitekturen prüfen. +5. Images für Migrationsdienst und Control Agent prüfen, sofern diese betroffen sind. +6. Multiarch-Manifeste prüfen. +7. Docker-Compose-Start testen. +8. Datenbankinitialisierung testen. +9. Start des Migrationsdienstes testen. +10. Release Notes erstellen. +11. Gitea-Release veröffentlichen. +12. Gitea-Pakete prüfen. + +--- + +## Zu prüfende Image-Ebenen + +| Ebene | Images | Zweck | +|---|---|---| +| Payload | `romexis-payload`, `romexis-client-payload`, `romexis-firebird-payload` | Versionsabhängige Installer-/Datenbankinhalte | +| Runtime | `romexis-base-jre`, `romexis-gui-runtime` | Wiederverwendbare architekturabhängige Abhängigkeiten | +| Final | `romexis-server`, `romexis-admin`, `romexis-client`, `romexis-mromexis-app` | Bereitstellbare Romexis-Komponenten | +| Dienste | `romexis-migration-service`, `romexis-control-agent` | Unabhängige unterstützende Dienste | --- @@ -43,6 +57,8 @@ Untersuchen: docker manifest inspect gitea.buchhorster.de/planmeca/romexis-server: ``` +Der öffentliche Multiarch-Tag wird erst veröffentlicht, nachdem die erforderlichen architekturspezifischen Staging-Images erfolgreich fertiggestellt wurden. Drone verwendet commitbezogene `ci--...`-Staging-Tags und erstellt das öffentliche Manifest am Ende der Pipeline. Dadurch bleibt das vorherige öffentliche Manifest während eines laufenden Builds weiterhin pullbar. + --- ## Release Notes sollten Folgendes erwähnen @@ -54,6 +70,8 @@ docker manifest inspect gitea.buchhorster.de/planmeca/romexis-server: - erforderliche Änderungen an Umgebungsvariablen - bekannte Einschränkungen +Änderungen, die nur die internen Payload-/Runtime-Buildebenen betreffen, erfordern normalerweise keine Anpassung der Bereitstellung, solange die öffentlichen finalen Image-Namen, Tags und Laufzeitschnittstellen kompatibel bleiben. + --- ## Gitea-Bereiche @@ -64,6 +82,6 @@ Gitea wird wie folgt verwendet: |---|---| | Code | Quellcode und Dockerfiles | | Releases | Menschenlesbare, versionierte Release Notes | -| Packages | Veröffentlichte Container-Images | +| Packages | Veröffentlichte Payload-, Runtime- und finale Container-Images | | Wiki | Betriebs- und Entwicklerdokumentation | | Issues | Fehler, Funktionswünsche und Planung | diff --git a/Release-Process.md b/Release-Process.md index 8ebc659..ab4db3f 100644 --- a/Release-Process.md +++ b/Release-Process.md @@ -12,21 +12,35 @@ A release usually includes: - optional migration service changes - optional client changes +The optimized build architecture distinguishes between version-specific payload images, shared architecture-specific runtime images and final user-facing component images. Payload and runtime images are build dependencies; final images remain the images consumed by normal deployments. + --- ## Suggested Release Steps -1. Ensure the repository builds cleanly. -2. Verify payload image availability. -3. Verify base images for target architectures. -4. Verify server images for target architectures. -5. Verify multiarch manifests. -6. Test Docker Compose startup. -7. Test database initialization. -8. Test migration service startup. -9. Create release notes. -10. Publish Gitea release. -11. Verify Gitea packages. +1. Ensure the repository builds cleanly and the wiki tests pass. +2. Verify Server, Client and Firebird payload image availability. +3. Verify Server and GUI runtime images for the target architectures. +4. Verify Server, Admin, Client and mRomexis images for the target architectures. +5. Verify Migration Service and Control Agent images when affected. +6. Verify multiarch manifests. +7. Test Docker Compose startup. +8. Test database initialization. +9. Test migration service startup. +10. Create release notes. +11. Publish Gitea release. +12. Verify Gitea packages. + +--- + +## Image Layers to Verify + +| Layer | Images | Purpose | +|---|---|---| +| Payload | `romexis-payload`, `romexis-client-payload`, `romexis-firebird-payload` | Version-specific installer/database content | +| Runtime | `romexis-base-jre`, `romexis-gui-runtime` | Reusable architecture-specific dependencies | +| Final | `romexis-server`, `romexis-admin`, `romexis-client`, `romexis-mromexis-app` | Deployable Romexis components | +| Services | `romexis-migration-service`, `romexis-control-agent` | Independent supporting services | --- @@ -43,6 +57,8 @@ Inspect: docker manifest inspect gitea.buchhorster.de/planmeca/romexis-server: ``` +The public multiarch tag is published only after the required architecture-specific staging images have completed successfully. Drone uses commit-specific `ci--...` staging tags and creates the public manifest at the end of the pipeline, so the previous public manifest remains pullable during a running build. + --- ## Release Notes Should Mention @@ -54,6 +70,8 @@ docker manifest inspect gitea.buchhorster.de/planmeca/romexis-server: - required environment variable changes - known limitations +Changes that only affect internal payload/runtime build layers normally do not require deployment changes as long as the public final image names, tags and runtime interfaces remain compatible. + --- ## Gitea Areas @@ -64,6 +82,6 @@ Use Gitea as follows: |---|---| | Code | Source code and Dockerfiles | | Releases | Human-readable versioned release notes | -| Packages | Published container images | +| Packages | Published payload, runtime and final container images | | Wiki | Operational and developer documentation | | Issues | Bugs, feature requests and planning | diff --git a/Romexis-Admin.de.md b/Romexis-Admin.de.md index 2476a7e..befd2b6 100644 --- a/Romexis-Admin.de.md +++ b/Romexis-Admin.de.md @@ -24,6 +24,14 @@ Openbox und xcompmgr sind erforderlich, weil Romexis Admin Swing-/AWT-Dialoge mi Das Openbox-Kontextmenü des Root-Desktops ist im Startskript deaktiviert, weil es in der noVNC-Laufzeit nicht nützlich ist. +## Gemeinsame GUI-Runtime + +`romexis-admin` installiert den vollständigen Java-/X11-/noVNC-/Native-Stack nicht mehr selbst. Diese architekturspezifischen Abhängigkeiten werden durch `romexis-gui-runtime:1-` bereitgestellt, die ebenfalls von `romexis-client` verwendet wird. + +Das finale Admin-Image ergänzt nur noch das versionsspezifische Admin-Payload, materialisiert die gemeinsamen Runtime-Artefakte im Admin-Verzeichnis und fügt die Admin-Start-/Testskripte hinzu. Admin und Client sind unabhängige finale Images; keines erbt vom jeweils anderen. + +--- + --- ## Zugriff diff --git a/Romexis-Admin.md b/Romexis-Admin.md index 6c3a793..0862265 100644 --- a/Romexis-Admin.md +++ b/Romexis-Admin.md @@ -24,6 +24,14 @@ Openbox and xcompmgr are required because Romexis Admin uses Swing/AWT dialogs w The Openbox root desktop context menu is disabled in the startup script, because it is not useful in the noVNC runtime. +## Shared GUI Runtime + +`romexis-admin` no longer installs the complete Java/X11/noVNC/native stack itself. These architecture-specific dependencies are provided by `romexis-gui-runtime:1-`, which is also used by `romexis-client`. + +The final Admin image only adds the version-specific Admin payload, materializes the shared runtime artifacts in the Admin directory and adds the Admin startup/test scripts. Admin and Client are independent final images and neither inherits from the other. + +--- + --- ## Access diff --git a/Romexis-Client.de.md b/Romexis-Client.de.md new file mode 100644 index 0000000..9db1e3f --- /dev/null +++ b/Romexis-Client.de.md @@ -0,0 +1,76 @@ +[**Deutsch**](Romexis-Client.de) | [English](Romexis-Client) + +# Romexis Client + +Der Dienst `romexis-client` stellt den Linux-Romexis-Client browserbasiert über dasselbe X11-/noVNC-Runtime-Konzept bereit, das auch der Admin-Container verwendet. + +Er wird unabhängig von `romexis-admin` gebaut: Beide Images verwenden die gemeinsame `romexis-gui-runtime`, während die Client-Anwendungsdateien aus dem dedizierten Image `romexis-client-payload` stammen. + +--- + +## Image-Abhängigkeiten + +```text +romexis-client-payload: + | + v +romexis-gui-runtime:1- + | + v +romexis-client:- +``` + +Die Trennung verhindert, dass reine Admin-Änderungen einen Client-Rebuild erzwingen, und hält die große Installer-Extraktion von den architekturspezifischen GUI-Abhängigkeiten getrennt. + +--- + +## Runtime-Komponenten + +Die gemeinsame GUI-Runtime stellt bereit: + +```text +Java 17 +OpenJFX +Xvfb +Openbox +x11vnc +noVNC / websockify +GTK / Mesa / OpenGL dependencies +Chilkat +DxService compatibility library +``` + +Das finale Client-Image ergänzt das versionsspezifische Romexis-Client-Payload sowie die Client-Start- und Testskripte. + +--- + +## Zugriff + +Der Client wird über noVNC bereitgestellt. Der konkrete Host-Port wird über die Compose-Konfiguration gesteuert. + +Für Logs: + +```bash +docker compose logs -f romexis-client +``` + +Shell zur Fehleranalyse öffnen: + +```bash +docker compose run --rm --entrypoint /bin/bash romexis-client +``` + +--- + +## Build und Tags + +Veröffentlichte Versions-Tags folgen demselben Schema wie Server und Admin: + +```text +romexis-client:-amd64 +romexis-client:-arm64 +romexis-client: +romexis-client:latest +``` + +Zuerst werden die Architektur-Tags erstellt. Die öffentlichen Multi-Architektur-Tags werden erst veröffentlicht, wenn beide Architekturen erfolgreich abgeschlossen wurden. diff --git a/Romexis-Client.md b/Romexis-Client.md new file mode 100644 index 0000000..89d2fec --- /dev/null +++ b/Romexis-Client.md @@ -0,0 +1,76 @@ +[Deutsch](Romexis-Client.de) | **English** + +# Romexis Client + +The `romexis-client` service provides browser-based access to the Linux Romexis Client through the same X11/noVNC runtime concept used by the Admin container. + +It is built independently from `romexis-admin`: both images share `romexis-gui-runtime`, while the Client application files come from the dedicated `romexis-client-payload` image. + +--- + +## Image Dependencies + +```text +romexis-client-payload: + | + v +romexis-gui-runtime:1- + | + v +romexis-client:- +``` + +The separation prevents Admin-only changes from forcing a Client rebuild and keeps the large installer extraction independent from architecture-specific GUI dependencies. + +--- + +## Runtime Components + +The shared GUI runtime provides: + +```text +Java 17 +OpenJFX +Xvfb +Openbox +x11vnc +noVNC / websockify +GTK / Mesa / OpenGL dependencies +Chilkat +DxService compatibility library +``` + +The final Client image adds the version-specific Romexis Client payload and the Client startup/test scripts. + +--- + +## Access + +The Client is exposed through noVNC. The concrete host port is controlled by the Compose configuration. + +For logs: + +```bash +docker compose logs -f romexis-client +``` + +Open a shell for troubleshooting: + +```bash +docker compose run --rm --entrypoint /bin/bash romexis-client +``` + +--- + +## Build and Tags + +Published version tags follow the same pattern as Server and Admin: + +```text +romexis-client:-amd64 +romexis-client:-arm64 +romexis-client: +romexis-client:latest +``` + +The architecture tags are created first. The public multi-architecture tags are published only after both architectures completed successfully. diff --git a/Runtime-Layout.de.md b/Runtime-Layout.de.md index 8a4a042..9197bd6 100644 --- a/Runtime-Layout.de.md +++ b/Runtime-Layout.de.md @@ -39,6 +39,9 @@ firebird romexis-admin Browser-accessible Romexis Admin / RomexisConfig runtime. +romexis-client + Browser-accessible Romexis Client runtime. + romexis-app Tomcat-based mRomexis Web App. @@ -46,7 +49,10 @@ proxy OpenResty/Nginx proxy for mRomexis Web App. romexis-migration - Optional migration service for MSSQL workflows. + Migration service for upload, validation and restore workflows. + +romexis-control-agent + Restricted container-control service used for coordinated runtime operations. ``` --- @@ -78,6 +84,19 @@ romexis-migration Der Admin-Container bietet Browserzugriff über noVNC und verwendet VNC-Statusdateien, um RomexisConfig abhängig von aktiven Sitzungen zu starten oder zu stoppen. +## Client-Container-Pfade + +```text +/opt/romexis/client +/opt/romexis/sconfig +/programdata/Planmeca/Romexis +/tmp/romexis-client-vnc-state +``` + +Der Client-Container verwendet dieselbe gemeinsame GUI-Runtime wie Admin, erhält seine Anwendungsdateien jedoch aus dem separaten Image `romexis-client-payload`. + +--- + --- ## Pfade der mRomexis Web App diff --git a/Runtime-Layout.md b/Runtime-Layout.md index 7e2a4cc..dc9962b 100644 --- a/Runtime-Layout.md +++ b/Runtime-Layout.md @@ -39,6 +39,9 @@ firebird romexis-admin Browser-accessible Romexis Admin / RomexisConfig runtime. +romexis-client + Browser-accessible Romexis Client runtime. + romexis-app Tomcat-based mRomexis Web App. @@ -46,7 +49,10 @@ proxy OpenResty/Nginx proxy for mRomexis Web App. romexis-migration - Optional migration service for MSSQL workflows. + Migration service for upload, validation and restore workflows. + +romexis-control-agent + Restricted container-control service used for coordinated runtime operations. ``` --- @@ -78,6 +84,19 @@ romexis-migration The Admin container provides browser access through noVNC and uses VNC state files to start or stop RomexisConfig based on active sessions. +## Client Container Paths + +```text +/opt/romexis/client +/opt/romexis/sconfig +/programdata/Planmeca/Romexis +/tmp/romexis-client-vnc-state +``` + +The Client container uses the same shared GUI runtime as Admin, but receives its application files from the separate `romexis-client-payload` image. + +--- + --- ## mRomexis Web App Paths diff --git a/Server-Image.de.md b/Server-Image.de.md index 3323a60..dfc3285 100644 --- a/Server-Image.de.md +++ b/Server-Image.de.md @@ -21,7 +21,6 @@ ROMEXIS_FIREBIRD_PAYLOAD_IMAGE ROMEXIS_VERSION TARGETARCH IMAGE_SUFFIX -CHILKAT_VERSION ``` Beispielvorgaben: @@ -31,9 +30,9 @@ ARG TARGETARCH=amd64 ARG ROMEXIS_VERSION=6.5.3.444.203 ARG IMAGE_SUFFIX= -ARG ROMEXIS_BASE_IMAGE=gitea.buchhorster.de/planmeca/romexis-base-jre:11-${TARGETARCH}${IMAGE_SUFFIX} -ARG ROMEXIS_PAYLOAD_IMAGE=gitea.buchhorster.de/planmeca/romexis-payload:${ROMEXIS_VERSION}${IMAGE_SUFFIX} -ARG ROMEXIS_FIREBIRD_PAYLOAD_IMAGE=gitea.buchhorster.de/planmeca/romexis-firebird-payload:latest${IMAGE_SUFFIX} +ARG ROMEXIS_BASE_IMAGE=gitea.buchhorster.de/planmeca/romexis-base-jre:11 +ARG ROMEXIS_PAYLOAD_IMAGE=gitea.buchhorster.de/planmeca/romexis-payload:${ROMEXIS_VERSION} +ARG ROMEXIS_FIREBIRD_PAYLOAD_IMAGE=gitea.buchhorster.de/planmeca/romexis-firebird-payload:latest ``` --- @@ -41,19 +40,27 @@ ARG ROMEXIS_FIREBIRD_PAYLOAD_IMAGE=gitea.buchhorster.de/planmeca/romexis-firebir ## Build-Stufen ```text -Stage 1: romexis-payload - Imports /opt/romexis and /opt/romexis-mssql-db. +Build context: romexis-server-runtime + Provides Java 11, Chilkat and RomexisPropertyAgent.jar. -Stage 2: romexis-firebird-payload - Imports /opt/romexis-firebird-db. +Build context: romexis-payload + Provides /opt/romexis and /opt/romexis-mssql-db. -Stage 3: agent-build - Compiles RomexisPropertyAgent.java. +Build context: romexis-firebird-payload + Provides /opt/romexis-firebird-db. -Stage 4: final image - Assembles runtime image. +Final stage + Uses romexis-server-runtime as its filesystem base and assembles payloads plus runtime scripts. ``` +## BuildKit-Abhängigkeitskontexte + +Die lokalen und CI-Build-Skripte übergeben Runtime- und Payload-Images als explizite BuildKit-Named-Image-Contexts. Dadurch ist die Abhängigkeitskette eindeutig; CI kann commit-spezifische Staging-Images verwenden, während lokale Builds isolierte lokale Aliase nutzen können. + +Das finale Server-Dockerfile kompiliert Chilkat oder den PropertyAgent nicht mehr selbst; diese Artefakte werden aus der gemeinsamen Server-Runtime materialisiert. + +--- + --- ## Laufzeitskripte diff --git a/Server-Image.md b/Server-Image.md index 42a2f1f..af6c964 100644 --- a/Server-Image.md +++ b/Server-Image.md @@ -21,7 +21,6 @@ ROMEXIS_FIREBIRD_PAYLOAD_IMAGE ROMEXIS_VERSION TARGETARCH IMAGE_SUFFIX -CHILKAT_VERSION ``` Example defaults: @@ -31,9 +30,9 @@ ARG TARGETARCH=amd64 ARG ROMEXIS_VERSION=6.5.3.444.203 ARG IMAGE_SUFFIX= -ARG ROMEXIS_BASE_IMAGE=gitea.buchhorster.de/planmeca/romexis-base-jre:11-${TARGETARCH}${IMAGE_SUFFIX} -ARG ROMEXIS_PAYLOAD_IMAGE=gitea.buchhorster.de/planmeca/romexis-payload:${ROMEXIS_VERSION}${IMAGE_SUFFIX} -ARG ROMEXIS_FIREBIRD_PAYLOAD_IMAGE=gitea.buchhorster.de/planmeca/romexis-firebird-payload:latest${IMAGE_SUFFIX} +ARG ROMEXIS_BASE_IMAGE=gitea.buchhorster.de/planmeca/romexis-base-jre:11 +ARG ROMEXIS_PAYLOAD_IMAGE=gitea.buchhorster.de/planmeca/romexis-payload:${ROMEXIS_VERSION} +ARG ROMEXIS_FIREBIRD_PAYLOAD_IMAGE=gitea.buchhorster.de/planmeca/romexis-firebird-payload:latest ``` --- @@ -41,19 +40,27 @@ ARG ROMEXIS_FIREBIRD_PAYLOAD_IMAGE=gitea.buchhorster.de/planmeca/romexis-firebir ## Build Stages ```text -Stage 1: romexis-payload - Imports /opt/romexis and /opt/romexis-mssql-db. +Build context: romexis-server-runtime + Provides Java 11, Chilkat and RomexisPropertyAgent.jar. -Stage 2: romexis-firebird-payload - Imports /opt/romexis-firebird-db. +Build context: romexis-payload + Provides /opt/romexis and /opt/romexis-mssql-db. -Stage 3: agent-build - Compiles RomexisPropertyAgent.java. +Build context: romexis-firebird-payload + Provides /opt/romexis-firebird-db. -Stage 4: final image - Assembles runtime image. +Final stage + Uses romexis-server-runtime as its filesystem base and assembles payloads plus runtime scripts. ``` +## BuildKit Dependency Contexts + +The local and CI build scripts pass runtime and payload images as explicit BuildKit named image contexts. This makes the dependency chain unambiguous and allows CI to use commit-specific staging images while local builds can use isolated local aliases. + +The final Server Dockerfile no longer compiles Chilkat or the PropertyAgent itself; those artifacts are materialized from the shared server runtime. + +--- + --- ## Runtime Scripts diff --git a/_Sidebar.md b/_Sidebar.md index 9ad9def..1486cc1 100644 --- a/_Sidebar.md +++ b/_Sidebar.md @@ -20,6 +20,7 @@ ### Runtime Services - [Romexis Admin](Romexis-Admin) +- [Romexis Client](Romexis-Client) - [mRomexis Web App](mRomexis-WebApp) - [Runtime Layout](Runtime-Layout) - [Backup and Restore](Backup-and-Restore) @@ -77,6 +78,7 @@ ### Runtime-Dienste - [Romexis Admin](Romexis-Admin.de) +- [Romexis Client](Romexis-Client.de) - [mRomexis Web App](mRomexis-WebApp.de) - [Runtime-Layout](Runtime-Layout.de) - [Sicherung und Wiederherstellung](Backup-and-Restore.de)