Docker questions

Hi there,

I am planning to set up a Nextcloud instance on a proper dedicated server after having used it only on a raspberry pi before. Because I just followed a lenghty guide on how to deploy Nextcloud (an older version of this one) I knew I never wanted to do that again. I am just not familiar with php enough and I have no idea what I am doing when I do this.
So I knew the next time I would use Docker together with [Podman](https://podman.io/).

However, I have some questions about this. Sorry if they sound naive, I tried looking but did not find close enough and up-to-date answers.

  1. Seeing that the docker image is not one of the main ways of installing but devaluated on the website as “by the community”: Is it stable & smooth? Is there any downside to using the Docker image? esp. security but also performance, delayed (security) releases, etc.?
  2. How much maintainance of the Docker image do I have to do? I guess this is always my biggest question: I install someone else’s setup but how do I maintain it? More specifically:
    2a. How do I maintain the nextcloud install after I installed it over time? Can I just keep doing the updates from the web interface?
    2b. What about the necessary packages like php-related, would I need to update them manually or just pull the image? If there is a security issue, do I need to wait until someone pushed them to the docker image?
  3. I guess this is the whole point of Docker, but just to be sure: Is there any way system updates of my distro (likely OpenSUSE leap) can mess up my install?
  4. Again Safety: When I set up my instance by hand, I had to set up database users, passwords, etc. Where is all this info or setup in the docker? Where would I get these credentials if I have to fix something?
  5. The guide says that for the apache version, everything will be auto-configured, at least for the first setup and an SQLite db will be used. Then in the docker-compose part it only lists a mariadb script which also does not use ssl and needs to be behind a proxy. Is there a guide on one easy way to set everything up with sensible defaults like the guide I used last time listed above?

Again, apologies for dumb questions, but I am a bit nervous about this.

there is official docker image. it has little lag compared to official schedule but in real life a delay of 1-2-3 days doesn’t really matter. Please read and understand the guide - it is more basic then some community solutions but it gives you a good insight how to setup and maintain your Nextcloud as docker. For serious installation I would always user docker-compose as I find it easier to understand, control and maintain. Docker-compose gives you better control of e.g. version (always pin the exact version you use - this saves a lot headache)

Unfortunately the official guide doesn’t cover reverse proxy and SSL setup (I guess for sake of simplicity) - I’m running my docker setup since a year with traefik. it works, provides SSL with letsencrypt “out-of-the-box” and it’s easy to have multiple instances of Nextcloud in parallel - latest one, previous one, testing, production.

The general docker philosophy is that you don’t care about the images - this is done by the maintainer (especially don’t do something like an upgrade via web-updater). You must periodically pull new image to perform an update. As a drawback you have to wait until the maintainer of the package provides security updates for the application and related packages like PHP (but you can built you own image based on the official one if you want).

Thank you, I have since sucessfully installed nextcloud and everything (nginx+lets encrypt) following this guide: https://linuxhandbook.com/install-nextcloud-docker/

I read the provided link but now I ask myself: I have everything deployed with docker compose, great. But when I look at my overview, I am currently on 21.0.0 but there is already a newer version (21.0.4).
Now with this docker setup, what is the update procedure?

Okay so here is what I did to update:

In my docker-compose.yaml I changed the tag from nextcloud:21.0.0 to nextcloud:21.0.4.
Then I pulled the image: docker-compose pull, then restarted everything forcing the new image to be used with docker-compose up --force-recreate -d and then removed the old image with docker rmi <image-id>.

Is this a viable path? I pulled half of this out of my ass after reading a lot of forum entries lol.

I wondered if it is better to keep chaning the docker-compose.yaml or if I should just pull explicitly, e.g. docker pull nextcloud:21.0.4. I figured it is better to use the yaml since it is kept updated and can be used if I ever need to redeploy or whatever.
Next up I will attempt to update mariadb lol.

(Edit: Updating MariaDB in the same way worked flawlessly. It all seems a little bit too easy, cannot believe it really).

yes it’s a good way to go… after you adopt the compose file you can go with

docker-compose will detect the configuration change, download new versions and start. This is really very easy in my eyes as well.

I feel it’s easier to get rid of old images by running docker image prune from time to time…

1 Like

How? Podman is a Docker replacement. You can’t use it together.
Probably you meant to use container images with Podman. Personally I wouldn’t advice you to do so. For newbies Docker is the better choice. You’ll find a lot more howtos on the internet.

zero. the image is provided by nextcloud gmbh on docker hub. you just have to pull the newest image from time to time an dreplace your container.

don’t work. don’use this method. never.

they are updated by the image maintainer. an image contains of several layers. e.g. nextcloud is based on an offical php image.

https://github.com/nextcloud/docker/blob/master/22/apache/Dockerfile#L2

the php teams cares about the php updates and docker hub builds a new image whenever a newer version of php:7.4-apache-bullseye is released.

the nextcloud version is updated if nextcloud decide to change the following line:

https://github.com/nextcloud/docker/blob/master/22/apache/Dockerfile#L124

in your docker compose file you can choice nextcloud version 22.1.1 and stay with this version forever but you will always get the newest php 7.4 releases because nextcloud decided to use FROM php:7.4-apache-bullseye

best advice is to choose an image tag like 22-apache or 22-fpm to stay on that version but get all updates. if you choose latest or production you get also the updates to the next major version. choosing 22-xxx you would have to update to 23-xxx manually by editing your docker compose file.

OK?

yes. it is.

if you screw up things you have to make sure that have a backup of your persistence data.

use docker-compose instead of plain docker.

and

https://github.com/nextcloud/docker#docker-secrets

https://www.google.com/search?client=firefox-b-d&q=nextcloud+docker+how+to

p.s.: you may want to have a look at watch tower. it will keep all container up2date automatically.

you may also want to have a look at portainer. a kind of docker gui.

1 Like

Thank you for that comprehensive answer. I have since sucessfully installed everything following this guide: https://linuxhandbook.com/install-nextcloud-docker/

But I am thus far specifying the docker image as nextcloud:21.0.4. In the official docker guide (which was not as comprehensive as the one I followed), this would correspond to the fpm I suppose? Could I just change my nextcloud image from the nextcloud:21.0.4 to nextcloud:fpm?

Also one more question. I wanted to secure logins with fail2ban and followed the official guide on the nextcloud website here.
I set up everything exactly the same, just with the log file at /var/lib/docker/volumes/nextcloud_NCData/_data/data/nextcloud.log, which is the only nextcloud.log I could find when searching as root.
Is that correct?

Edit: Also I ended up not using Podman, it was still llimited and openSUSE Leap does not yet offer version 3 which brings a lot of nice features.

1 Like

yes and no. the fpm image always needs an additional nginx as web server.

but if you get this right you just have to use the same volumes (persistent data).

you may look at the example docker compose files how to do this.

note that the link shows an older version. the newer versions alos include things like redis and cron.

nevertheless you might get the idea what is the difference between the apache and the fpm image.

1 Like

Okay so the nextcloud:21.0.4 is the 21.0.4 version of the nextcloud:apache version?
If that is so, would I be able to upgrade to nextcloud:apache easily?

What I want is: Going away from specifying the versions myself like that and let that be handled by the upstream image. I just don’t know what my image corresponds to. To me this is all somewhat opaque.

Thank you for taking time to help out a newby with dumb questions, btw!

no.

apache == 22.1.0

stable-apache == 21.0.4

just look at the tags and hashes on hub.docker.com

e.g.

nextcloud:apache

https://hub.docker.com/layers/nextcloud/library/nextcloud/apache/images/sha256-12a7a5ab4ccaa02a6cd8dcd0c50df36c97e746907c572ac71a4a9409fc253d67?context=explore

and

nextcloud:21.0.4

https://hub.docker.com/layers/nextcloud/library/nextcloud/stable-apache/images/sha256-77940816ab31150343d100663020afe04129c34b7559ff2f2bb5e8f4b827d1fb?context=explore

you can run docker images and docker inspect <nextcloud image id> and you’ll get all the image details. including the variable "NEXTCLOUD_VERSION=22.1.0"

1 Like

Sorry what I was asking was: the version is have (which specifies neither apache or fpm explicltly) is not the fpm branch but the apache correct? So it corresponds to a nextcloud-apache image from the past (or the current apache-stable as it seems)?

(The tags are a bit confusing, and I don’t see how my tag is a former nextcloud-apache image)

So if want to switch to a version where I don’t need to keep track of the current (stable) nextcloud version, I could switch from my nextcloud:21.0.4 to nextcloud:apache-stable which right now corresponds to my current image, and over time, I will be upgrade to 22.x if I pull at a later point automatically. Correct?

yes. that’s the way it works.

Late to the party, good that you got it going. For the next ones reading this, podman has one additional nice feature, it can auto update containers. So one less thing to worry, it would notice there is new version of nextcloud container image at dockerhub, and would do pull and restart automatically. Depending on your processes, it might be handy.

I shy away from auto-update in general, been burnt by breaking changes too many times.
That said, I’m happily running the official Nextcloud image as a rootless podman pod (on Fedora Server 34).
The only thing that would make it better is a simple way to tell Nextcloud (and Mariad, and Redis) that it should run as root. Rootless podman takes care of mapping the container’s root the user’s UID on the host.

Hmmm… I wouldn’t want to run them as root. That’s still too much power to whoever manages to get into pod. Layers of security is nice.

You can repeatedly get the same uid for the mappped user, so you can chown the volume mounts on host anyhow.

Would be nice if in the future someone could write a little guide on how to use a Nextcloud docker-setup with podman (2.x) and podman-compose instead.
I understand that it should be a drop-in replacement but it just does not work in some cases in the same way and I am not as advanced with docker to understand what is going on.
Rootless deployment is so nice though.

Here’s my two cents. Not really the same way, but perhaps it gives you ideas. GitHub - ikke-t/ansible-podman-examples: This is to share some of ansible examples for running stu

I use ansible to set it all up. There are some old blogs also for it:

All things are a bit updated since I wrote the piece, but it is 95% the same setup still. I run the pods on fedora-iot nowadays.

I suppose that’s a reasonable view, but then anyone who gets www-data user access in the pod has as much power as they need.
Even if they get root in the container, they still only have at most the host user’s access on the host. I run my rootless pods as an unprivileged user. I’m working on SELinux policies for the containers, to restrict them further.