I don’t really understand your requirements, or why you write it just now.
I already did the job for nginx+fpm, you can find it here:
I’m waiting this to be answered to PR the official docker library.
IMHO, apache can be added, before or after the PR been accepted (but before will just slow down the process). Anyway, as I don’t use apache in production, I can’t do this work as an open source contribution (I can always freelance of course).
Because I’ve now seen various requests and think we should build something which can fit various needs.
The docker you wrote is just one part, as you mention in the readme, it requires a front-end and a database.
So I think it would be good if we could come up with a list of requirements and a way to compose various setups.
Well, currently, we can use Apache as the frontend. It’s not as efficient as using sockets, but that works.
To meet the mod_php requirement, we would need to build another container and thus would need to look at how we could decouple Nextcloud from that.
And thinking of the base OS switch, it’s not going to work unfortunately because containers rely heavily on the OS , so we need to duplicate the effort to make it that RHEL people can use docker, just like the Ubuntu people can.
There is a misunderstanding, either I don’t understand your issue, or you don’t understand docker.
Docker is a container technology. It is different from virtualization in the sense that it reuse the kernel of the host. Think about it as a super chroot.
In the project you can see the Dockerfile.
Given that, I can clone the project on whatever distribution (debian, ubuntu, rhel, coreos…) and execute a docker build -t nextcloud . and it will work.
Once the image is produced by this step, I can also share the image (though a registry - like https://hub.docker.com) and people can then run docker run nextcloud on whatever distribution (debian, ubuntu, rhel, coreos…).
This is why docker is so amazing! RHEL people will be a bit upset that the base image is not rhel (I am when I use centos image), but still happy that they can just docker run (I also am with the centos images )
Hope it is clarified, and let me know if it is not the answer of the question you had.
But maybe, let’s go back to the problem space I the problem space, when well defined, it really help to solve it well!
Basically yes, but what do you want to achive by doing that?
Docker enables the user of an image to just run it and more or less ignore what happens inside the container. If there are users / customers /… that have specific needs of the structure inside the container they are better off building there own image.
It would be in no way possible to build container images for any possible usecase / need. Takes to much effort.
I still think we could offer a set of scripts for Ubuntu and RHEL and then expand on that. The workflow is always the same since the components are the same. What changes are some OS specific details when loading packages or placing config files.