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.

[Leaced]

This is an initial draft establishing a local development setup similar to dsf-docker-dev-setup, prior to implementing the 3dic-ttp configuration.

Key differences from a production-ready environment:

• Orchestration: Uses podman kube play instead of a full kubernetes cluster or Quadlets
• Storage & Config: Relies heavily on bind-mounts rather then dedicated persistent volumes and ConfigMaps
• Image Building: Utilizes standard podman build instead of Buildah.

The goal is to provide an environment that closely mirrors the production setup for quadlet while remaining lightweight and simple for local testing. Please note that this setup is still experimental and requires thorough testing. I am seeking feedback on the general structure before proceeding.

To-Do List

• Implement the 3dicttp configuration
• Conduct comprehensive testing and write documentation.
• Determine a permanent location/repository for the production setup.

Known Limitations

• Configuration Conflict: The property dev.dsf.bpe.fhir.client.certificate.private is treated as a key with a string value in some contexts, but as an object in others. This structural inconsistency makes it difficult to manage natively within a YAML-based Kubernetes ConfigMap as source for an Externalized Configuration in Spring Boot.

Alternatives to consider:

I initially explored using Quadlets as an intermediate stepping stone toward Kubernetes. However, transitioning to Kubernetes will require additional architectural changes. Continuing down this path risks leaving us with three separate environments to maintain (Kubernetes, Compose, and Quadlets).

Alternatively, Podman has its own Compose Provider. We could simply provide a deployment guide on how to run our existing Compose files using rootless Podman, which would require minimal modifications. From there, the YAML configurations generated during this spike could be used to build a standardized Helm chart.

Under this approach, we would only need to support two setups:

• A Podman/Docker Compose setup (for local development and lightweight deployments).
• A Helm chart (for Kubernetes enterprise deployments).

To validate the production-ready path, we could test the Helm chart locally during development using a tool like KinD (Kubernetes in Docker).