feat: adds ability to specify container options in process-compose.yml

[brandonbiggs]

I have been utilizing process compose for a few weeks now. I think it's a great tool, but there are a couple of challenges where I'm trying to utilize it in places it may not have been meant to be used in. In an attempt to fix this and improve this tool, I'd like to propose adding some additional process configuration options.

Background

There is a containerization tool in high performance computing that functions similarly to docker but can function without root permissions. This tool is called Apptainer. It can do many of the same tasks as docker without needing the docker permissions. However the tooling around apptainer is not as mature as docker as it is not used by nearly as many people.

Here is an example of running a command with apptainer:

apptainer exec --bind /data:/mnt my_container.sif python3 api.py

my_container.sif is a single executable file. Not the definition file, but the built container that can be transported. I can create it from scratch or by pulling existing apptainer or docker containers.

I can do this with process-compose as it currently exists, but I think it makes more sense to have some additional functionality for clarity and config cleanliness.

Here's an example of running a python API.

processes:
  API:
    command: "apptainer run --nv python.sif python3 /path/to/api.py"
    description: "Python API"
    log_location: "python.log"
    working_dir: "/path/to/python"
    availability:
      restart: "always"
    environment:
      - "APPTAINER_BINDPATH=\
         data/:/data,\
         settings.toml:/etc/python/settings.toml,\
         authentication.ini:/etc/python/authentication.ini"
      - "PATHS_CONFIG=/etc/python/authentication.ini"

This PR would allow it to be defined as:

 processes:
  API:
    command: "python3 /path/to/api.py"
    description: "Python API"
    log_location: "python.log"
    working_dir: "/path/to/python"
    availability:
      restart: "always"
    is_container: true
    container_runtime: "apptainer"
    container_execution: "exec"
    container_volumes:
      - "data:/data"
      - "settings.toml:/etc/python/settings.toml"
      - "authentication.ini:/etc/python/authentication.ini"
    container_image: "python.sif"
    container_args:
      - "--nv"
    environment:
      - "PATHS_CONFIG=/etc/python/authentication.ini"

I think this makes it more clear, and more similar to docker compose (without the need for docker and other strengths provided by process-compose :) )

Contributions

This PR adds the following options:

is_container            bool
container_runtime       string      (docker, apptainer, singularity, podman, etc)
container_execution     string      (exec, run, etc)
container_volumes       []string    (Each container runtime has a different way to define volumes, right now I'm only considering apptainer volumes which are defined with a -B/--bind
container_image         string      (full path to .sif or OCI path)
container_args          []string    (additional arguments to pass to the container runtime)

These options are ignored if is_container is not set to true or if container_runtime is not set to apptainer. This could be expanded to allow for other container tools like podman, singularity, docker, etc, but for right now it is just configured with apptainer in mind as that's the only app I have to test at the moment.

If there are any questions or feedback on this, please let me know. Thanks!

[sonarcloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud