Install Nextcloud AIO with Docker

SYSTEM INFORMATION
OS type and version Debian 11
Virtualmin version 7.5

Hi guys,

first of all, thanks a lot to the community for providing very good help and support.
I have a question, I want to install the Nextcloud AIO Docker to my Virtualmin system.
I have everything already running with the LAMP stack.
From what I know at the moment, I need to install Docker first. After this, I’m actually lost a bit.

I think to continue, I need to create a new subdomain for it, let’s say something like: nc.domain.com
Here I create a new folder, let’s say “docker” and put the .yml file inside and start it with the docker-up command to get all the files and configs.

After this, I need to somehow make a proxy to the Nextcloud AIO running in docker. I don’t actually know how to do it. Does anyone here have experience with it?

Thanks a lot guys

1 Like

Search the forums, there plenty talk about it. I’m not sure you can run docker inside a vm, I might be wrong.

Hi Stefan,

Yes, I have searched the Forum, but I haven’t found any good instructions actually.
Docker should be able to run I think, I don’t think it affect the Virtualmin installation…

Same here, brother.

I installed docker, but the nextcloud AIO install guide found here does not work.

Problems with ports, and problems with SSL authentication… You end up trying to figure out how to install a reverse proxy on apache, and I am sure that’s not where you should be.

What makes you think that? That’s exactly where you should be, if you’re running things in containers. There’s no other way to get there! Proxying is just how this is done.

Well, let me put it this way: installing Nextcloud the old fashioned way takes two command lines and is a fool-proof 5-minutes long process with no hitches whatsoever.
How in the world they promote this docker thing as being the easiest and more convenient way to get Nextcloud is beyond me. Sure it may be better at managing it once you have it, but they sure made the road to get there as elitist as they could.

I suspect that a container deploy would seem easier for someone who doesn’t already have a working database, PHP-FPM, Apache VirtualHost, etc. as provided by Virtualmin or other automated tool for setting all that up. The container can…contain everything needed for the application.

I am much less enthusiastic about Docker for distributing applications than much of the rest of the industry, but I understand where they’re coming from. Telling someone how to setup a database/web server/etc. on any of the popular distributions is a lot of writing. Putting it all in a container is a mostly one-time cost for them, whereas dealing with every new version of every supported OS (and all the crazy ways people find to do things wrong) is ongoing and very time-consuming. Once everybody is comfortable with containers, deploying every application begins to look like the same problem.

It pushes a lot of complexity out of sight of the end user. It introduces some complexity of its own, but it will be uniform complexity when everything is deployed via containers. I don’t love the thought process that got us here, but here we are and we all have to learn to love it.

1 Like

I can see this but…

The part that should really be made easier (and where a hypothetical Virtualmin module, sort of like, from what I hear, CyberPanel has, could really help) is the integration of that container with the preexisting “outside world” and, in particular:
1st) associating it with a server or sub-server and
2nd) make it work with the ssl certificate installed on that server.

If these kinds of problems were worked out for the user, the user would certainly be motivated to learn more about the convenience of containers.

As I said, Virtualmin 8 will have support for container-based app deployment. Current Virtualmin has GUI for setting up proxy rules, though that may only be in Pro.

I’m not sure what else you need, though; I think you’re making this more complicated than it actually is. Associating with a server or sub-server is just running it as the user and putting the proxy rules in the right VirtualHost. The SSL cert has nothing to do with it. The endpoint is the VirtualHost, which would already be managed by Virtualmin and can already get LE certs automatically. You just need to make sure you exclude .well-known path from the proxy rules, to allow it to be served from the filesystem, which is required for LE validation, but that’s true for any redirects, proxy rules, etc. regardless of the involvement of a container.

I am sure everything is easy once you know how to do it.

That’s however the kind of thinking that brings developers to write guides and howtos meant for the wrong audience.

There is no such thing as “following instructions”, here. One has to take bits and pieces from different sources, but they don’t always integrate each other very well.

Sure I did install docker, I did create a sub-server, with his LE certificate…

It should be noted however that the official guide for Nextcloud AIO makes no mention whatsoever of associating to a domain or the other.
This is how the Nextcloud AIO guide says the container should be installed:

# For x64 CPUs and without reverse proxy already in place:
sudo docker run \
--sig-proxy=false \
--name nextcloud-aio-mastercontainer \
--restart always \
--publish 80:80 \
--publish 8080:8080 \
--publish 8443:8443 \
--volume nextcloud_aio_mastercontainer:/mnt/docker-aio-config \
--volume /var/run/docker.sock:/var/run/docker.sock:ro \
nextcloud/all-in-one:latest
  1. No mention whatsoever of domain or subdomain
  2. choice of ports that will immediately break either apache or the setup of the very container
  3. even overcoming points 1) and 2), which I eventually did, none of this would work with an ssl certificate simply associated to that domain.

The guide for the reverse proxy, whatever that is, is even more convoluted and lacking. The fact that they don’t even bother explaining what a reverse proxy is or why it should be used in this case says it all.

I don’t mean to sound bitter, I am sure docker is a great piece of technology. This just annoys me because I simply don’t have the time to study this and/or I am not sure it’s worth it.

I would not use --publish 80:80. Give it its own ports, or better yet use a UNIX file socket.

Then add something like this to the VirtualHost where you want it to run:

  ProxyPass /.well-known !
  ProxyPass / http://127.0.0.1:8080/
  ProxyPassReverse / http://127.0.0.1:8080/

Adjust accordingly if you use file sockets instead of ports, of course. Ports are less secure in a shared hosting environment, but if you don’t have anybody else on the system, it’s fine.

Restart Apache. You’re done. Proxying is not complicated!

I would assume 8443 is for SSL within the container itself, which is probably not necessary or useful, that’s going to add complexity, though I guess if it has handling for getting LE certificates, you could skip the .well-known rule and also proxy port 443 over to 8443 in the container. That feels overly complicated, though.

Thanks for the brief instructions. Not sure what a UNIX file socket is , but i did give it its own ports. Following many more errors I realized I probably needed the reverse proxy thing, and I tried to include the proper lines in the virtualhost file (according to their reverse proxy instructions, which suggest much more lines than the three you suggest) but, anyway, it didn’t work (“slim application error”)… that’s when I started pining for a virtualmin module.

Will try again if I find the time (but, is it really worth it?). Thanks, though. Perhaps one of you guys should write a real, proper, understandable guide. There isn’t one out there.

I’ve been playing with containers only because that is the only way Discourse is available. Then I find out they want one container per instance? That starts to add up resource wise. But, same as who cares to write clean code when you can just throw more resources at it?

@nonhocapito it is really easy to deploy docker containers and link them with virtualmin, I’ve been using containers for a lot of apps from 4-5 years now.

Generally the first thing you should do for deploying any container app is look for a docker-compose.yaml file (so it’ll be easier to upgrade and maintain), expose port 80 inside container to a custom port on host like 8080 (or any available port on that system), and finally link the exposed port to apache reverse proxy.

since you needed a guide for nextcloud here it is:

mkdir -p ~/docker/nc && cd ~/docker/nc
nano docker-compose.yaml

Paste the following content taken from official docker container page (Docker)

make sure to update MYSQL_PASSWORD var throughout the file and the port on left side i.e. port 8080 under app service.

version: '2'

volumes:
  nextcloud:
  db:

services:
  db:
    image: mariadb:10.5
    restart: always
    command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW
    volumes:
      - db:/var/lib/mysql
    environment:
      - MYSQL_ROOT_PASSWORD=
      - MYSQL_PASSWORD=
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud

  app:
    image: nextcloud
    restart: always
    ports:
      - 8080:80
    links:
      - db
    volumes:
      - nextcloud:/var/www/html
    environment:
      - MYSQL_PASSWORD=
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
      - MYSQL_HOST=db

Next install docker-compose if not already installed (Install the Compose standalone | Docker Documentation)

curl -SL https://github.com/docker/compose/releases/download/v2.15.1/docker-compose-linux-x86_64 -o /usr/local/bin/docker-compose
chmod +x /usr/local/bin/docker-compose
ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose

Once installed run docker-compose up to start the nextcloud container services

cd ~/docker/nc && docker-compose up -d

Next create new virtualhost in virtualmin
e.g nc.example.com

After creating virtual host go to it’s Server Configuration > Website Options > and select yes on Redirect all requests to SSL site?

Next go to it’s Service > Configure SSL Website > Edit Directives and paste the below config

ProxyPass / http://127.0.0.1:8080/ nocanon
ProxyPassReverse / http://127.0.0.1:8080/
RequestHeader set X-Forwarded-Proto "https"
RequestHeader set X-Forwarded-Port "443"
RewriteEngine on
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteCond %{HTTP:Connection} upgrade [NC]
RewriteRule ^/?(.*) "ws://127.0.0.1:8080/$1" [P,L]

In above config first part is for proxying http requests and second part of config is for proxying websocket connections.

I usually paste this just one line above the SSLEngine on but you can paste at the end of file also and click “Save and Close”.

Next open terminal for side bar or ssh session

and run these commands to reflect proxypass changes done in virtualhost

apachectl -t

if above command returns OK then only reload the apache although apache will not reload in case there are issues in your config but still.

apachectl graceful

image

Next you can visit your newly created nextcloud instance on https://nc.example.com

5 Likes

Apologies the docker compose file shared above is for nextcloud and not for nextcloud AIO,

for nextcloud AIO though the process seems bit more involved as docker AIO expects 2 urls one for managing the docker containers and other for actual nextcloud instance

mkdir -p ~/docker/nc && cd ~/docker/nc
nano docker-compose.yaml

Paste the following content taken from official github repo (all-in-one/docker-compose.yml at main · nextcloud/all-in-one · GitHub)

make sure to update port 8080 under app service (if port is not locally available on the server).

version: "3.8"

volumes:
  nextcloud_aio_mastercontainer:
    name: nextcloud_aio_mastercontainer # This line is not allowed to be changed

services:
  nextcloud:
    image: nextcloud/all-in-one:latest # Must be changed to 'nextcloud/all-in-one:latest-arm64' when used with an arm64 CPU
    restart: always
    container_name: nextcloud-aio-mastercontainer # This line is not allowed to be changed
    volumes:
      - nextcloud_aio_mastercontainer:/mnt/docker-aio-config # This line is not allowed to be changed
      - /var/run/docker.sock:/var/run/docker.sock:ro # May be changed on macOS, Windows or docker rootless. See the applicable documentation. If adjusting, don't forget to also set 'DOCKER_SOCKET_PATH'!
    ports:
      - 8080:8000
    environment: # Is needed when using any of the options below
      - APACHE_PORT=11000 # Is needed when running behind a reverse proxy. See https://github.com/nextcloud/all-in-one/blob/main/reverse-proxy.md
      # - APACHE_IP_BINDING=127.0.0.1 # Should be set when running behind a reverse proxy that is running on the same host. See https://github.com/nextcloud/all-in-one/blob/main/reverse-proxy.md
      - COLLABORA_SECCOMP_DISABLED=false # Setting this to true allows to disable Collabora's Seccomp feature. See https://github.com/nextcloud/all-in-one#how-to-disable-collaboras-seccomp-feature
      # - DOCKER_SOCKET_PATH=/var/run/docker.sock # Needs to be specified if the docker socket on the host is not located in the default '/var/run/docker.sock'. Otherwise mastercontainer updates will fail. For macos it needs to be '/var/run/docker.sock'
      # - DISABLE_BACKUP_SECTION=false # Setting this to true allows to hide the backup section in the AIO interface.
      - NEXTCLOUD_DATADIR=/root/docker/nc/ncdata # Allows to set the host directory for Nextcloud's datadir. See https://github.com/nextcloud/all-in-one#how-to-change-the-default-location-of-nextclouds-datadir
      # - NEXTCLOUD_MOUNT=/mnt/ # Allows the Nextcloud container to access the chosen directory on the host. See https://github.com/nextcloud/all-in-one#how-to-allow-the-nextcloud-container-to-access-directories-on-the-host
      # - NEXTCLOUD_UPLOAD_LIMIT=10G # Can be adjusted if you need more. See https://github.com/nextcloud/all-in-one#how-to-adjust-the-upload-limit-for-nextcloud
      # - NEXTCLOUD_MAX_TIME=3600 # Can be adjusted if you need more. See https://github.com/nextcloud/all-in-one#how-to-adjust-the-max-execution-time-for-nextcloud
      # - NEXTCLOUD_MEMORY_LIMIT=512M # Can be adjusted if you need more. See https://github.com/nextcloud/all-in-one#how-to-adjust-the-php-memory-limit-for-nextcloud
      # - NEXTCLOUD_TRUSTED_CACERTS_DIR=/path/to/my/cacerts # CA certificates in this directory will be trusted by the OS of the nexcloud container (Useful e.g. for LDAPS) See See https://github.com/nextcloud/all-in-one#how-to-trust-user-defiend-certification-authorities-ca
      # - NEXTCLOUD_STARTUP_APPS=deck twofactor_totp tasks calendar contacts # Allows to modify the Nextcloud apps that are installed on starting AIO the first time. See https://github.com/nextcloud/all-in-one#how-to-change-the-nextcloud-apps-that-are-installed-on-the-first-startup
      # - NEXTCLOUD_ADDITIONAL_APKS=imagemagick # This allows to add additional packages to the Nextcloud container permanently. Default is imagemagick but can be overwritten by modifying this value. See https://github.com/nextcloud/all-in-one#how-to-add-os-packages-permanently-to-the-nextcloud-container
      # - NEXTCLOUD_ADDITIONAL_PHP_EXTENSIONS=imagick # This allows to add additional php extensions to the Nextcloud container permanently. Default is imagick but can be overwritten by modifying this value. See https://github.com/nextcloud/all-in-one#how-to-add-php-extensions-permanently-to-the-nextcloud-container
      # - NEXTCLOUD_ENABLE_DRI_DEVICE=true # This allows to enable the /dev/dri device in the Nextcloud container which is needed for hardware-transcoding. See https://github.com/nextcloud/all-in-one#how-to-enable-hardware-transcoding-for-nextcloud
      # - TALK_PORT=3478 # This allows to adjust the port that the talk container is using.

Run docker-compose up to start the nextcloud container services

cd ~/docker/nc && docker-compose up -d

Next create new virtualhost in virtualmin
e.g nc-admin.example.com

After creating virtual host go to it’s Server Configuration > Website Options > and select yes on Redirect all requests to SSL site?

Next go to it’s Service > Configure SSL Website > Edit Directives and paste the below config

ProxyPass / http://127.0.0.1:8080/ nocanon
ProxyPassReverse / http://127.0.0.1:8080/
RequestHeader set X-Forwarded-Proto "https"
RequestHeader set X-Forwarded-Port "443"
RewriteEngine on
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteCond %{HTTP:Connection} upgrade [NC]
RewriteRule ^/?(.*) "ws://127.0.0.1:8080/$1" [P,L]

and click “Save and Close”.

Next create another virtualhost in virtualmin
e.g nc.example.com

After creating virtual host go to it’s Server Configuration > Website Options > and select yes on Redirect all requests to SSL site?

Next go to it’s Service > Configure SSL Website > Edit Directives and paste the below config

ProxyPass / http://127.0.0.1:11000/ nocanon
ProxyPassReverse / http://127.0.0.1:11000/
RequestHeader set X-Forwarded-Proto "https"
RequestHeader set X-Forwarded-Port "443"
RewriteEngine on
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteCond %{HTTP:Connection} upgrade [NC]
RewriteRule ^/?(.*) "ws://127.0.0.1:11000/$1" [P,L]

and click “Save and Close”.

Next open terminal for side bar or ssh session

and run these commands to reflect proxypass changes done in virtualhost

apachectl -t

if above command returns OK then only reload the apache although apache will not reload in case there are issues in your config but still.

apachectl graceful

image

Next you have to visit your nexcloud aio management panel for deploying actual nextcloud services (you might need to open ports for nextcloud talk as well) at https://nc-admin.example.com

It’ll ask for nextcloud url provide, nc.example.com here (don’t forget to replace example.com to your actual domain) and select required containers on next page

Wait for them to install for me took around 10 minutes.

Once their status goes to running you can visit your newly created nextcloud instance on https://nc.example.com or via clicking “Open your Nextcloud” button.

3 Likes

Awesome @naresh335 ,

thanks a lot for the instructions. I’ll give it a try and see if I can get it work .

Thanks a lot :grinning:

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.