Closed sunjam closed 6 years ago
Thanks @sunjam for your kind words :)
This project aims at only one thing, be a really nice base image for other projects.
The only way I see collaboration happening would be to add arm support to this project, and that, hopefully, NextcloudPI can base there work on top of our.
To be honest, I'll not be the one to be able to do that. But if you are interested, please head to https://github.com/docker-library/official-images#architectures-other-than-amd64 to get basic instructions on how to add arm support to an official docker image.
We'd be happy to review and accept PR for that feature.
Hi, what about x86 support? NextcloudPi supports that architecture as well and the ncp-config + ncp-web utilities I linked above would benefit your images!
What is ncp-config and ncp-web? I I need the links but didn't manage to find it quickly.
Hi,
@sunjam thanks for the suggestion.
Well it would be nice to join forces for sure. NCP is available as x86 and armhf docker containers, but it can be conceived as an extra utility layer on top of a LAMP stack and as such it could be built on top of this docker container. In this sense, we are duplicating efforts.
NCP is a LAMP stack + Nextcloud + a set of utilities, or ncp-apps. The real added value is those ncp-apps and the fact that it is preconfigured and packaged ready to use in the form of docker containers, SD cards for several boards and so on. There is also a first run wizard to help automatically set up external storage, Letsencrypt, port forwarding and so on. The goal is to make it easy for non technical users to have a Nextcloud instance at home.
You can see screenshots and a list of features here, and you can just run the docker version locally to try it out and see what you think.
In any case, the docker version was built reusing code from the SD card version and it's architecture is quite non-conventional, as all the services run in a single container. It is more similar to a traditional VM than to the current docker convention, but there is no reason why this could not be adapted. The code is neatly separated already and you can mostly just build the NCP layer on top of any LAMP stack.
It is what I thought too, there is a docker way of doing things.
For instance, web and TLS is usually handled by https://github.com/jwilder/nginx-proxy and https://github.com/JrCs/docker-letsencrypt-nginx-proxy-companion.
So I think the best to share effort, is to base the NextcloudPi on this official image. This is the only collaboration I can see happening for now.
Yes, I agree. Exactly what I was trying to say.
Forgot to add the instructions to try it.
git clone https://github.com/nextcloud/nextcloudpi.git
cd nextcloudpi
docker-compose up
, or just
docker run -d -p 4443:4443 -p 443:443 -p 80:80 -v ncdata:/data --name nextcloudpi ownyourbits/nextcloudpi-x86
By the way, adding arm support looks stright forward, check this PR :) https://github.com/docker-library/official-images/pull/4670
We already have arm support. See: https://github.com/docker-library/official-images/blob/master/library/nextcloud#L7
Hello,
You have ARM support for Nextcloud, but NCP is not only a NC instance. We are talking about adding the NCP tools on top of your existing image.
I suggest you try the above container in order to check it out for yourselves and understand better what NCP adds to NC.
Cheers!
@nachoparker the scope of this project is to provide the best and minimal Nextcloud docker image. The scope of NCP is to make a tool that does handle everything around Nextcloud administration.
I'm a personal fan of the unix philosophie. And this project (as all other docker official images) are built with this philosophie in mind. The official docker images are nice building blocks that people can reuse.
I'm not saying that this project is more valuable than the other one, just saying we have different goals helping different people. And both are needed :)
To give an example - Let's encrypt.
Nextcloud will never add support for let's encrypt, and this docker image will also never do it. This is the responsability of somebody else.
(the .examples
folder helps docker-compose people on that topic, although, I'd be advocating to have this piece of information and support for that in a different project ;) )
I'm now using kubernetes, and there is a nice software that does it beautifully, cert-manager and I find it beautiful that it works with this docker image without any changes.
But I do understand that for some people it is complicated, and it is our duty to help them. And to be honest, I think your approach is nice for people. You have a nice integration that help people admin there Nc. I think your approach requires a lot of effort, and I think on the long run it is better to have reusable building blocks, but this, it is just my personal opinion.
To sum it up, this project will never have NCP installed. I recommend you to use our docker image as a building block. I recommend to not put different processes in the same container. I recommend you to look at https://github.com/JrCs/docker-letsencrypt-nginx-proxy-companion for let's encrypt in docker world. But maybe don't listen to me, and keep up with building a nice monolith that has perfect integration. I don't know what is the best solution :)
(I'll close, but feel free to continue the discussion, I'm interested in the topic)
Actually this is the same question as how do we solve web needs for the people:
Thanks for this conversation @pierreozoux
@sunjam suggested we joined forces and it is true that we are both dealing with the LAMP + NC part, so we are duplicating efforts. Under that point of view I was suggesting that we could rebuild NCP on top of your container. Note that I am not suggesting at any point that you add NCP to your container, but that we build NCP on top of your container with the benefit that the NCP community would help test / maintain it.
I also personally like small building blocks, but as you say the goal of this particular NCP project is to provide a complete prepackaged solution that my grandma could use, so probably we could not reconcile our different design goals.
I know the benefits of one service per container, but in our use case it made sense because it reuses existing NCP code and we are able to provide a web UI to control all different parts of the system in a single place.
Think Letsencrypt. If we implemented it in a different container then we would not be able to manage it from the main NCP container, leaving aside the fact that you need an extra service running in your low power raspberry pi. I know it is against docker purism, but there are also benefits in the traditional virtual machine use case. We would need to rewrite something similar to ncp-web but that manages and coordinates containers instead of systemd services, so we'd better reuse our code ;)
Anyhow, when I read @sunjam suggestion, I was happy to offer my availability to help but at the same time I knew that our architectures are completely different so there is little room for cooperation.
Cheers, and keep up the good work
Also, for us is not a lot of extra effort to keep maintaining the LAMP+NC stack because we have to do it anyway for Debian / Raspbian / Armbian. One good thing of our approach is that code is quite reusable and for that reason we support many different boards and architectures.
Yeah at the end, it depends if you want to manage systemd files or docker api :) And I totally understand that you don't want to rewrite it all, I also see little value doing so! It was nice meeting you! This year I'll mnot make it for the Nc conference, it clashes with another important event, but hopefully next year!
Same! Nice meeting you. I also won't be able to go to the NC conf this year, hopefully next year I can be there.
Hello!
I can't help, but wish the Nextcloud Docker team and NextcloudPi Docker team would combine forces, similar to the Avengers before they save the world.
It could prove useful to both of your projects to combine forces and development! Thanks for reading, and thank you for your excellent docker images.