From alpine
RUN apk add --no-cache $yourDependencies
Add theSoftware /bin/theSoftware
CMD rc-service yourDependency start && /bin/theSoftware
You probably want to make that CMD into a bash script, produce theSoftware in another "from $yourRuntime as builderImage" and COPY from=builderImage thoughI'd strongly encourage you to explore the image with dive after to visualize whats been added on which command while you're changing the dockerfile
https://github.com/wagoodman/dive
I'd push back on that being a good idea though. It's okayish, but it'd be better if the software had no dependencies, falling back to file storage/embedded DB. But that's obviously scope screep, so probably not worth the effort if your chosen framework doesn't give you a drop in option for that. Basically ymmv, I wouldn't touch a software that nests multiple daemons into the same image. It's a hack for easier demos or transient starts on dev machines, but that's it.
Your orm does support sqlite though, that'd probably be better then nesting a database daemon
Will probably need to start with an Ubuntu image instead of Alpine to keep changes to a minimum.
Recommendations for an “rc-service” to use in this context ?
There is also good old supervisord, but I haven't personally used it in containers yet. https://docs.docker.com/config/containers/multi-service_cont...
You’ll need to point the entrypoint to /usr/bin/init.
That said, I have had to do this before and if I ever have to do it again, I will be going right for a base image that has systemd. Red Hat provides UBI images that have systemd in it for reasons similar to this. Assuming that a pod or deployment using something like podman is not an option, This what I would use personally.