Issue/500 support for other engines

[Leaced]

See: #500

Closes #500.

Changes

This creates a new dev-setup based on podman quadlet and podman-kube. Further discussion is needed.
Maybe we should use quadlet only in production and a single yaml with kube-play for dev-setups?

How Was This Patch Tested?

It is used in a test-instance of the Universitätsmedizin der Johannes Gutenberg-Universität Mainz.
Because it is only a deployment, there are no unit tests.

[Leaced]

Status

I created a single instance setup with rootles podman quadlet that could already be used in production with more documentation. This needs to be adjusted for a 3dic-ttp dev-setup. For this quadlet is maybe not the best choice. A pure kubernetes yaml setup with podman kube-play is considered.

The single instance setup is further documented under dsf-dev-setups/dsf-podman-dev-setup

Planned improvements on single instance

1. Multiline config as mounted YAML — Load Spring Boot configuration as a mounted config.yaml instead of environment variables for better readability of multiline values such as role configurations:

   - name: spring-application-config
     mountPath: /config

2. Unified naming — Avoid duplicate names between BPE and FHIR to support single-instance dev setups.

3. Migrate to Deployments — Replace kind: Pod with kind: Deployment (replicas: 1) for a smoother migration path to Kubernetes.

4. One secret per password — Currently all DB passwords are bundled in a single Kubernetes Secret. Splitting them improves least-privilege access.

5. Unprivileged proxy port — Find a solution that avoids the net.ipv4.ip_unprivileged_port_start=80 sysctl requirement, e.g. by using a higher container port with host port mapping or a setcap-based approach.

3dic-ttp Setup Tasks (based on the single instance setup)

• The setup has less bind-mounts and needs a new ways of secret and cert creation
• quadlet is not ideal for dev-setups. So a single kubernetes file for podman kube play needs to be created

[hhund]

Thank you for the PR, @Leaced!
After reading your changes and some of the Kubernetes YAML documentation, I think I have a better understanding of the challenges in using Kubernetes YAML for our dev-setups.

Maybe we should use quadlet only in production and a single yaml with kube-play for dev-setups?

I agree, Quadlet / systemd seams too heavyweight for dev-setups. For the install guide we currently generate tar.gz archives with docker-compose.yml files and other defaults from a private repository. But we were thinking about creating a new public dsf-config repo that could be a good place to house example production files for docker-compose, Quadlet / systemd and Kubernetes (including Helm?). If you want to contribute, will we get back to you for this.

In general I think that Kubernetes YAML based deployments are too static for the use in dev-setups. When using the dsf-docker-dev-setup-3dic-ttp for example, we often only startup some of the services or stop one of them to see how a process-plugin behaves if some parts are not reachable. Deploying process-plugins via the local file system and having access to the debug-level log files while getting an overview via the info-level system-out log is another argument for using docker-compose during development.

If you are up for it, I still would like you to add a Kubernetes YAML equivalent for the dsf-docker-dev-setup to this repository.

Please consider the following changes:

• Keep the old dsf-docker-dev-setup and dsf-docker-dev-setup-3dic-ttp folders untouched.
• Add a new dsf-podman-dev-setup folder (at root level).
• From a usability perspective I would like a solution that needs me to:
  1. Run mvn package to build the DSF.
  2. Run mvn dsf:generate-dev-setup-cert-files to generate all needed certificates, keys and secrets.
  3. Run podman-build.sh / podman-build.bat to build the images.
  4. Run podman kube play fhir.yml to start the FHIR server.
  5. Run podman kube play bpe.yml to start the BPE server.
• While a bad idea in production, may be use hostPath to simulate bind-mount behavior for the conf, process and log folders.

For step 1 we could modify the templating function of our dsf-maven-plugin to fill-in Secret and ConfigMap values, as well as absolute paths. In case you don't want to take this on yourself, I'm happy to contribute the needed additions to the dsf-maven-plugin. Placeholders like ${something} in the YAML files should work. The YAML file templates would live in src/main/resources/templates and a dsf-maven-plugin config similar to the existing ones would then copy the finished files to the dsf-podman-dev-setup folder. Make sure the dsf-docker-dev-setup folder includes a README.md file, so that the folder always exists. As the dsf-podman-dev-setup/fhir.yml and dsf-podman-dev-setup/bpe.yml files would be "generated" they will need to be added to .gitignore.

For the privileged port problem: As mentioned in #500 I think we should consider adding "minimal" variants of our images. These would not include curl, would only use unprivileged ports and maybe have configurable uids/gids. We would need four more Dockerfiles (Dockerfile.minimal?) and some modifications to the build scripts. But maybe we want to tackle this in a separate PR.

[Leaced]

But we were thinking about creating a new public dsf-config repo that could be a good place to house example production files for docker-compose, Quadlet / systemd and Kubernetes (including Helm?). If you want to contribute, will we get back to you for this.

This sounds like an ideal place for the setup I already have.

If you are up

for it, I still would like you to add a Kubernetes YAML equivalent for the dsf-docker-dev-setup to this repository.

This is something I can do. In a dev-setup I would use hostpath and then I can keep this close to the existing dev-setups. What about the rootless? It would be good to test this, if we want it in the dsf-config, but this would need a few changes for namespacing. Should the dev-setup include them?

So I would split this in 2 completely different projects. A dev-setup and an prod-setup. I will continue with my work in the next week.