[XorNot]

IMO if you want to drive adoption you need to ship an all-in-one container. Use runit, and stick the DB, redis and your app in the same container with one nice big data directory.

Because for most small teams with the ability to run containers, that's going to be all they ever need - and it means your "let's try it" experience is just `docker run <my container image>`.

[RadiozRadioz]

Doing this as an optional extra alongside the regular app-only container is good, but it definitely shouldn't be the only way this is distributed. It's extremely inflexible.

[grodriguez100]

I know this is not the recommended practice, but I am working on a legacy project where we need to migrate to Docker and the first step (before decomposing in multiple containers) would be to have an all-in-one container running all services. I am looking for hints / recommendations on the best way to do this. Can you provide any pointers ?

[ffsm8]

Not the person you asked, but I've done something like that several years ago, too.

    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 though

I'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

[grodriguez100]

That’s useful, thanks.

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 ?

[nalbyuites]

This has worked pretty well for me both for service control and pre-execution environment setup : https://github.com/just-containers/s6-overlay

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...

[akdev1l]

If you use Ubuntu then just install systemd from the repos and use that imo. Less learning for you to do if you already know how services are configured in Ubuntu.

You’ll need to point the entrypoint to /usr/bin/init.

[freedomben]

You already know this, but I would be remiss if I didn't first point out that this is bad practice for a number of reasons.

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.