Why is it mounting the docker socket / spawning auxiliary containers?

[ForestJohnson]

Why was the decision made to mount the docker socket and spawn additional docker containers via the docker API? Wouldn't docker-compose be a much better option when multiple containers are desired?

It its called "all-in-one" why is it even using multiple docker containers anyways?

Yes, I understand that cramming multiple processes inside one docker container violates docker norms

Let me explain, if you are unfamiliar (click to expand)

Docker is supposed to be the system that keeps your processes running -- restarts them if they crap out, and lets you know if they can't be started successfully. If you embed a secondary process manager inside your docker container, now you have two process managers one inside the other, with the possibility for confusing results from the user's perspective in the event that something goes wrong. For example, nextcloud-all-in-one could appear to be "running" just fine from docker's perspective, but internally inside its own process manager, it could be in a "degraded" state or even a hard failure.

Ok. So that's a justification for designing it like how it was designed. But I really don't think it holds up... outside of use-cases like continuous integration where we often have no other choice, mounting the docker socket into a container and having it create / manage other containers is ALSO considered a big no-no. We can see a user's nervousnous about this bubbling up here: #150

Personally I would not recommend this project to anyone at this point because of this design decision. Its really not "all in one" at all, and it makes all kinds of assumptions about where/how it is being run, while requiring its users to introduce the worst docker security vulnerability known to humankind in the process.

Yes, doing nextcloud with a process manager inside a single docker container would certainly be more work to get "right", but in the end I think it would truly be worthy of the name "all-in-one".

If you really want to keep this design for the long term, I think that this project should be called "nextcloud docker-deployment-manager" not "nextcloud all-in-one"

The deployment manager container which mounts the docker socket should not be exposed to the internet. It should be separate from the containers which have web servers and app code running in them, i.e., all I should have to run is

sudo docker run -it 
 --name nextcloud-deployment-manager \
 --restart always \
 --volume /var/run/docker.sock:/var/run/docker.sock:ro \
 nextcloud/deployment-manager:latest

[szaimen]

Hi,

I'll try to answer your questions below:

Why not docker-compose?

Because it was not flexible enough and would not have made it possible to spawn this project with simply one command and providing the ease of use that was required for this project.

It its called "all-in-one" why is it even using multiple docker containers anyways?

Because it complies to docker norms and we are able to add additional containers without having to re-implement everything which would also make everything much more complicated to maintain.

mounting the docker socket into a container and having it create / manage other containers is ALSO considered a big no-no.

I don't see why we should not be allowed to do this when other projects do it, too. See e.g. https://docs.portainer.io/v/ce-2.11/start/install/server/docker/linux#deployment and https://yacht.sh/docs/Installation/Install/

Personally I would not recommend this project to anyone at this point because of this design decision.

That is fine. There are enough solutions out there for deploying Nextcloud. Simply pick the one that fits you best!

If you really want to keep this design for the long term, I think that this project should be called "nextcloud docker-deployment-manager" not "nextcloud all-in-one"

I fear it is unfortunately already too late for renaming this project. The name was used during the initial development and was kept after the release. Now we have to deal with it.

The deployment manager container which mounts the docker socket should not be exposed to the internet. It should be separate from the containers which have web servers and app code running in them, i.e., all I should have to run is

If you didn't follow the docs: we don't require to publish the AIO interface to the public internet (see https://github.com/nextcloud/all-in-one#which-ports-are-mandatory-to-be-open-in-your-firewallrouter). You can simply access it locally or put it behind a VPN if you want to increase the security.

[szaimen]

For anyone interested, it might be possible to auto-convert our containers definition into a docker-compose file using yq and some bash magic but I am not really interested in digging into this.

Here a simple example:

1. install yq
2. run wget https://raw.githubusercontent.com/nextcloud/all-in-one/main/php/containers.json
3. run yq -P containers.json
4. see the result which already looks kind of like a docker-compose file.
5. Now this would need to be auto adjusted to generate a working docker-compose file. PRs for this convert logic are welcome!

[szaimen]

I opened #557 for this

[szaimen]

This is now implemented. See https://github.com/nextcloud/all-in-one/tree/main/manual-install

[szaimen]

Another possibility is to run it with docker-rootless:
https://github.com/nextcloud/all-in-one/blob/main/docker-rootless.md

[crowjdh]

Props to both of you guys for bringing up valid concern and following up with solutions to deal with it.