Docker Image Available

xataz · July 11, 2016, 2:10pm

With alpine, no with official repos. But we can compile us own php7.

oparoz · July 11, 2016, 2:20pm

Thanks. From my pov, it would be worth compiling it yourself.

pierreozoux · July 12, 2016, 2:25pm

Hello everybody, and sorry to come after war, but I’m glad to see this thread!

I’m the one who PRed the official docker ownCloud image to add fpm support and I am also the maintainer of piwik and Rocket.Chat official images. I also maintain a bunch of compose/docker files.

I think we should make it an official image and the easiest would be to reuse the ownCloud one, @otbe already did the job here.

To get this going, we need:

a repo github.com/nextcloud/docker-nextcloud
2 subfolders:
alpine with @Wonderfall and @xataz work
fpm with @otbe’ work
an email address for the maintainer(s)

I’m a strong advocate of one process per container, and docker also, so it would be nice to make the alpine image without cron/nginx and so on, just fpm.
To make it faster, we can start just with the fpm image, and then add the alpine one later.
We can create an other repo with a compose file, something like compose-nextcloud would make sense.

Once the repo is done, we can PR the official repo.

I can help on all the process, let me know!

@stp yes looks cool Will you use ceph for a distributed filesystem? This is actually a setup I plan to work on, but I think I’ll s/kubernetes/docker swarm/ with ceph as the data backend! If you have questions on docker, I might have some answers! Do not hesitate!

jospoortvliet · July 12, 2016, 3:15pm

gimme github user names and I’ll add you to our organization, @blizzz is creating the repo

blizzz · July 12, 2016, 3:17pm

If these are more than one docker images/dockerfiles does not it make sense to create a repo for each of it?

jospoortvliet · July 12, 2016, 3:21pm

I think I’ve invited all of you to join our project, welcome!

Docker repo’s created, too. Have fun and - once you do a ‘official’ release, let me know and I’ll add them to nextcloud.com/install

blizzz · July 12, 2016, 3:22pm

I created now docker-alpine and docker-rpm repos, @jospoortvliet added you there.

pierreozoux · July 12, 2016, 3:54pm

Actually not.

Look at: https://github.com/docker-library/owncloud

Then, there is a script that is tagging things into docker hub.

Could you make just one repo? Maybe docker would be fine

xataz · July 12, 2016, 4:20pm

Finally, We create AiO docker image, or create one image for nginx (+nextcloud?) and one image for php-fpm ?

I understand @pierreozoux advice for docker philosophy (one process by container), but a AiO image is easier to use.

I don’t think we create one image for nginx and one image for php-fpm, because create a docker-compose with official nginx and php-fpm (and mariadb or postgre) with nextcloud in external volume is same.

PS : Sorry for my bad english ^^

Wonderfall · July 12, 2016, 4:49pm

Okay, nice to see something is finally happening.
If I understood you well, we’re going to split up into two projects : docker-alpine and docker-fpm. Perhaps one repo could be enough since we can tag thinks like @pierreozoux said. It’s up to you.

Concerning docker-alpine, I agree with @xataz. Although this is contrary to docker philosophy, we’d like to keep an AIO image as it makes things much easier for installation. We can eventually debate about this (if you don’t mind), so you can make our goal clear.

And what about a Docker Hub organisation? Could be interesting too.

otbe · July 12, 2016, 5:57pm

Aggree with @pierreozoux to keep clean and one-process-per-container images. From my experience AiO images are the wrong way to let users start, especially if they want to use it in production after some time. A good compose file with some basic configs should be enough to getting started and it is as simple as docker-compose up

@Wonderfall +1 for docker hub organization and automated builds

rootlogin · July 13, 2016, 8:47am

For me it’s also okay to have an additional AIO image for nextcloud. In fact it’s not really AIO, because it doesn’t have a database. For the DB you still need to link another container.

But to say that too, for me it’s not wrong to use AIO containers, if you do it right. It always depends why you do it or why you don’t do it. And if you have things like cron, which are a dependency of the application it makes sense to not put them in a separate container. Also NGinx needs access to static files too. Yes you could do that in a separate container, but it makes the setup more harder, because you shouldn’t deliver static files through FPM and linking everything increases the chance of an error. So for me that setup is valid, but it wouldn’t if you would bundle MariaDB or something like that.

So for a small setup it makes sense to me, but if you want to deploy a big cluster, then you should have everything separate anyway. But then I would have an application only container, without FPM, which is then accessed/linked through a separate FPM container. Otherwise every worker has his own copy of Nextcloud.

For me there is no real wrong or right… It depends on what you want/need.

pierreozoux · July 13, 2016, 8:57am

you can do it with volume_from.

pierreozoux · July 13, 2016, 9:05am

Actually, docker-fpm and docker-alpine are not good names as docker-alpine will have fpm inside.

I offer to rename docker-fpm to docker. put the fpm code there and PR the official image. This will be fast, and they’ll accept it quickly.

About the discussion of alpine, we can open an issue there, and see what Official image think about it.
In the mean time, we can keep it under docker-alpine, and distribute it though the docker hub Nextcloud community account.

Let’s move this forward

rootlogin · July 13, 2016, 9:08am

I know that, I wanted to show both ways, how you could get the static files. It goes more about that we also should have the FPM separately, if we want to do it this way.

Here is some thread at the docker forum about bundling/not bundling stuff: Why nobody does not make it in the docker? (All-in-one container/“black box”) - #2 by programmerq - General - Docker Community Forums

pierreozoux · July 13, 2016, 12:23pm

I have little time for philosophy discussion

I agree that both camps have solid arguments.
My argument is that officail images have their own rules. So if the goal is to make it official, then we should stick to the rules. If the objective is something else, then, we can do whatever we want

blizzz · July 13, 2016, 2:30pm

Ok I renamed one to docker and deleted the other. The repo goes here: https://github.com/nextcloud/docker

All good?

rootlogin · July 13, 2016, 8:32pm

Would everyone agree if we start from the official owncloud image: https://hub.docker.com/_/owncloud/

I would like to fork that one and improve then.

What do you think?

jospoortvliet · July 21, 2016, 2:37pm

I say that that makes total sense. Get it in there and then - see where to go from there, I bet there’ll be issues filed soon enough.

In general, a suggestion: don’t wait for permission, do until you get pushback

Wonderfall · July 27, 2016, 7:14am

Now we should do something.
I agree we should provide an image similar to the one actually provided by ownCloud, and I think @otbe did a great job about that. As discussed before we can also provide Alpine based images, most of the work is already done too… But @pierreozoux is right about official rules, and AIO may not be the right choice when scalability becomes a concern. To be honest I don’t really know about larger setups. Yet I’m still convinced we should provide an AIO image for those who want something simple to install/to try Nextcloud, without the need to bother with compose and multiple images, etc. (just pull and run).

I don’t want to do something wrong so I’m waiting for a common agreement about this. More and more people are using my image (30+ stars and almost 4k pulls on Docker Hub, the first suggestion you can get when searching “nextcloud” is mine… ), now at this stage I’d like them to use something safer, and I don’t feel I can maintain it alone for too much people…