[Feature Request] All-in-one docker

[rursache]

Any chance of creating an all-in-one docker container for this for ease of Self-Hosted deployment?

[kenellorando]

Hi and welcome!

Cadence provides "all-in-one" through Docker Compose. Simply running docker compose up (if you have the Docker Compose plugin) or docker-compose up (on older Docker versions) will launch all Cadence service containers configured to work with each other. See https://github.com/kenellorando/cadence#start-here for more details. Thanks.

[rursache]

@kenellorando that's not "all-in-one", its a stack of multiple containers. I'm interested in running Cadence with docker run not compose, similar on how I do with all linuxserver containers.

[kenellorando]

@rursache This gets into the philosophy of how technology should be used. Combining them all into one is an improper usage of containerization. Containers run one process at PID 1 because each container is in principal equivalent to one process. A sample I took of the containers on that list all run one process only, right?

By combining all services into one container, we lose:

• Minimized upgrade and build time. Atomic containers allow one service to be independently updated from another. If one service is failing, we can replace one service. Combining containers, if we updated one service, we have to rebuild all three services. If one service fails, the whole radio stack is dead.
• Isolated logging. One service to one container makes for ease of troubleshooting. We can easily observe which processes are freaking out, burning memory or compute, if they all remain on separate containers.
• The possibility of scaling. If I'm running Cadence in a Kubernetes cluster (I am) or any orchestration system that can scale, I can't roll out multiple replica API servers if it were combined into one container.
• Compose itself is a Docker standard. Moving otherwise would be using Docker in a substandard way. If it's "ease of use" we're talking about, I don't see an effective difference between running docker run and docker compose up. Compose was designed by Docker for this exact use case so developers could properly use containers as they were supposed to without resorting to combining services together like on virtual machines. Hosts are meant to run multiple containers.

For these reasons, my thinking is one component should live per container, and the official "all-in-one" solution is Docker Compose.

---

• https://runnable.com/docker/rails/run-multiple-processes-in-a-container
• https://devops.stackexchange.com/questions/447/why-it-is-recommended-to-run-only-one-process-in-a-container
• https://docs.docker.com/config/containers/multi-service_container/
• https://www.tutorialworks.com/containers-single-or-multiple-processes/
• https://www.marcelbelmont.com/docker-workshop/docs/containers/
• https://developers.redhat.com/blog/2016/02/24/10-things-to-avoid-in-docker-containers
• https://cloud.google.com/architecture/best-practices-for-building-containers

[rursache]

@kenellorando thanks for the time and effort you put in your explanation and reasoning.

I don't fully disagree with it however looking at the mastodon-server, nextcloud, plex (+ other) images, you can see that those containers spawn multiple processes.

• Upgrade/build time shouldn't matter much, github actions will take care of the build and the upgrade will mostly depend on the users' internet speed more than anything.
• I'm interested in running Cadence on my homelab/server, there is no reason to go the Kubernetes/k8s route for me and probably most other self-hosters.
• Compose itself is a Docker standard indeed however Docker run is not going away or being deprecated. I think there is a reason that compose is still considered a plugin and must be installed separately. I prefer using CLI and scripts instead of yaml, that's why my 50+ containers all run on docker run, not compose.

I hope you consider this a friendly discussion, not a confrontation. Hopefully you'll reconsider creating a single container as well, there is no need to drop the current segmentation!

[kenellorando]

@rursache First, let me say I don't wish to have any antagonism, so I hope I haven't come off that way. Any thoughts I hold about this topic are in no way a reflection of you as a person who I respect for being interested in Cadence! Just want to have a discussion in good faith with you about containers. 😃

I slept on the idea, and while I still strongly think the idea of multi-process containers is improper, I won't ultimately deny it if people find value in it over Docker Compose. The change would not be trivial, and it would necessitate additional ongoing maintenance of an additional piece to Cadence's containerization stack, so that's something I have to keep in mind. Though I can't say yes to this right now, would you feel it fair enough if we keep this issue open for others to chime in if they think also believed they would derive value from a singleton Docker image?

[rursache]

@kenellorando would you feel it fair enough if we keep this issue open for others to chime in if they think also believed they would derive value from a singleton Docker image?

of course!

[rursache]

Another similar discussion: schlagmichdoch/PairDrop#22 (comment)