Requirements for our docker containers

Topic to try and come up with a list of containers which could be used to build various appliances


  • Every component in a container
  • Container scripts for various OS (RHEL, CentOS, Ubuntu, SLES, arch, etc.)
  • A compose script to build various set-ups using the containers

List of containers

  • Apache + mod_PHP
  • Apache
  • MariaDB
  • Redis
  • LDAP

Would be good to have one script which installs Nextcloud on top of mod_php or PHP-FPM container


Officially supported platform is Apache + mod_php (, working setups with nginx+fastcgi are used, tested, and documented as well. We have seen some issues with apache+php-fpm in the past. Possible that you can figure out these problems.

I’ve seen some issues being reported, but used to run that in production without any issues, so that’s probably fixable.
Let’s start with mod_php then.


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

Let me know where I can help?

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 :frowning: , so we need to duplicate the effort to make it that RHEL people can use docker, just like the Ubuntu people can.

Well, this is the magic of docker :slight_smile: This image can be used by any distribution, this is a new software package if you want :slight_smile:

AFAIK, it can’t because this will fail on RHEL.

RUN apt-get update && apt-get install -y \
  bzip2 \
  libcurl4-openssl-dev \
  libfreetype6-dev \
  libicu-dev \
  libjpeg-dev \
  libmcrypt-dev \
  libmemcached-dev \
  libpng12-dev \
  libpq-dev \
  libxml2-dev \
  && rm -rf /var/lib/apt/lists/*

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 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 :slight_smile: )

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 :slight_smile: I :heart: the problem space, when well defined, it really help to solve it well!

That’s the problem I’m having. The example I gave above will only work if Docker loads a base image on top of my OS and I don’t want that. I want to use Docker compose as an orchestration tool.

I thought the same when I was learning docker, but actually there is no way around that.
You have to give a FROM, you can’t tell docker to use your base OS.

Thanks for the pointer :slight_smile:
Here is the link for people reading this:

I thought I would be able to omit that statement…

That means that each container needs to be duplicated for each base OS in order to avoid running a mix of OS.

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.

Here is an example of what I mean: