Feat: image for usage with orchestrator like swarm/k8s

[rikled]

This PR adds cluster images to the build process to be used by kubernetes or docker swarm. Github workflow is updated to build those as well and push them to the upstream.

For #73

depends on: #92

[chrip]

Summary

Major build infrastructure overhaul adding cluster images for K8s/swarm orchestration, restructuring the Docker build pipeline, and consolidating configs.

What's Good

1. bundle.bake.Dockerfile — nice consolidation of the assembly stage from multiple contexts into a single Alpine-based intermediate image. Clean separation of static vs code content.

2. CI workflow simplification — merging build-develop, manifest-develop, and build-packages into the main build job is a significant reduction. The per-target tag/push logic with set overrides is clean.

3. standalone.bake.Dockerfile — well-structured, mirrors the old docserver.bake.Dockerfile intent but with euro-office paths and proper deb integration.

4. Supervisor configs — adding per-service configs for all components (adminpanel, converter, docservice, example, metrics) is the right move for standalone deployments.

5. Nginx upstream externalization — moving upstream definitions to http-upstream.conf with env var support ($DOCSERVICE_HOST_PORT, etc.) is much cleaner for orchestrated deployments.

Issues

1. Missing trailing newline — bundle.bake.Dockerfile

Last line has \ No newline at end of file. Add one for consistency.

2. develop.bake.Dockerfile removes npm explicitly

-        apt-get install -y nodejs npm openjdk-21-jdk wget zip brotli && \
+        apt-get install -y nodejs openjdk-21-jdk wget zip brotli && \

The nodejs package on Ubuntu 24.04 includes npm as a dependency, so this should still work. But it's worth verifying — on some Ubuntu versions npm is a separate package. Consider keeping it explicit for clarity.

3. build.yml — create_manifest source tag logic for git tags

The refactored create_manifest now takes (repo, target_tag, source_tag). For tag-based releases:

create_manifest "$repo" "${REF}" "latest"

This means the manifest target tag is ${REF} (the sanitized git tag name) while the source images are tagged latest-amd64/latest-arm64. This is correct only if the images_tag output for git tags is latest-${{ matrix.arch }}. Double-check this logic is sound — if the tag is v9.2.1, the manifest will be v9.2.1 pointing to latest-amd64/latest-arm64 images, which is wrong. The source tag should be ${REF} not latest here.

4. Removed build/configs/onlyoffice/ configs — verify migration

All the onlyoffice/ JSON configs (default.json, development-linux.json, local.json, log4js/) are deleted. These need to be accounted for in the standalone.bake.Dockerfile and orchestrated.bake.Dockerfile — are they being copied from somewhere else, or is the configuration now entirely inline/templated in the bake files?

5. Removed build/configs/postgres/createdb.sql

The PostgreSQL schema (doc_changes table, task_result table, merge function) is deleted. Is this schema now handled via migrations in the server code, or does this break database initialization for standalone deployments?

[antichris]

Technically, if the static resource files are only served by Nginx, and the docservice does not directly touch them, they should be distributed in a separate image. It could be based on an official Nginx image and expose the www root as a volume. Then, Nginx can connect to the docserver container(s) over a socket (TCP or unix pipe) to function as a load balancer (a dedicated load balancer, e.g., HAProxy, Envoy, might yield better performance, though).

The docserver container should only run the absolute minimum to support that process, and connect to separate postrgres, rabbit and redis service containers over sockets. Any user-generated resources (e.g., uploads, exports) can be shared with the file server via a dedicated volume.

This modularization would decouple scaling of the docserver from those of the static resources and the persistence/messaging services, and open up more avenues of load balancing/routing customization and infrastructure integration for the deployment administrators, as well as improve deployment security by reducing potential attack surfaces (compromising just one of the multiple service containers would not have the same blast radius as when everything and the kitchen sink runs in the same single container).

[juliusknorr]

Also, I wouldn't touch NodeJS and the dumpster fire that is the npm ecosystem with a thirty-foot pole (just read the news), opting instead for Deno (the compatibility of which has even further improved in the latest release), but that is, probably, a separate issue.

That is for sure a different topic, but feel free to open an issue to further discuss this.