Why is the main folder required to be on a volume, for updates?

[flixman]

I have an existing nextcloud installation, that I want to migrate to nextcloud:fpm docker container. To this end, I am considering the following docker run command, that allows me to reuse my existing mysql db and data folders:

docker run -d \
-v /nextcloud:/var/www/html \
-v /nextcloud/apps:/var/www/html/custom_apps \
-v /nextcloud/config:/var/www/html/config \
-v /nextcloud/data:/var/www/html/data \
--net="host" \
-e MYSQL_DATABASE=<mysql_db> \
-e MYSQL_USER=<mysql_user> \
-e MYSQL_PASSWORD=<mysql_pass> \
-e MYSQL_HOST=127.0.0.1 \
nextcloud:fpm

My question is: in the image readme is stated that mapping /var/www/html is required for updating, but I do not understand why: If the container will be thrown away when there is an update, and a new one will be pulled, I think I do not need that mapped volume... right?

Thank you!

[SnowMB]

The way the updating process works is not as simple as switching out the php files to newer ones. There have a few additional steps to be done (like database migration and app updates).

In the container the nextcloud files are stored in /usr/src/nextcloud. The entrypoint.sh checks if the version of nextcloud in this folder is newer than your installation in /var/www/html and if so triggers the full updating process.

[anagno]

Hello Everyone,

I also had the same question. Would it make more sense to mount only the config/config.php (and in general the config folder)?
The version of our instance is also stored in the config.php, so we can retrieve it from there. If we detect that the version between our source code and the config.php does not match, then we can trigger the migration of the database (and all other necessary files) and in the end update also the version in the config.php. That way we can always use the source code from the container and not store it as a volume.
Is there a specific reason that we are retrieving this information from the version.php ?

Kind regards,

Vasileios

[HassoSigbjoernson]

The way the updating process works is not as simple as switching out the php files to newer ones. There have a few additional steps to be done (like database migration and app updates).

In the container the nextcloud files are stored in /usr/src/nextcloud. The entrypoint.sh checks if the version of nextcloud in this folder is newer than your installation in /var/www/html and if so triggers the full updating process.

Wouldn't it be possible to solve this by hard coding the version in entrypoint.sh and running the occ upgrade stuff if this version differs from the version in the (mounted) config.php?

[danieljkemp]

Before the upgrade step is run, a list of active plugins is obtained. Then the upgrade step runs, and the list of active plugins is compared and the diff printed in the log.

That is it, that is the only thing that is done before the upgrade command runs.

IMO, it isn't worth copying source files to a volume just for that functionality.

[chrisamti]

Before the upgrade step is run, a list of active plugins is obtained. Then the upgrade step runs, and the list of active plugins is compared and the diff printed in the log.

That is it, that is the only thing that is done before the upgrade command runs.

IMO, it isn't worth copying source files to a volume just for that functionality.

Well, if you check out how owncloud docker image (https://github.com/owncloud-docker/base/blob/a74c82926b8a3829f348e37d292bd9049e7d17e8/latest/overlay/etc/owncloud.d/20-config.sh#L8) ist done, you will see, that it's possible to upgrade without copying owncloud php code into a persistent volume. They use symbolic links to a single persistent volume into /var/www/owncloud (config, apps).

IMO owncloud docker image implementation follows more the docker principles, than the current nextcloud implementation it does.

[danieljkemp]

Since I am running in k8s, I did the following:

1. Moved the upgrade logic into a shell script stored in a configmap
2. Made my own docker image that copies the source into /var/www/html
3. Set the deployment entrypoint/command to apache
4. Created a k8s job that runs the upgrade shell script as a argocd/helm hook

kinda ugly since the /usr/src/nextcloud folder being defined as a volume within the dockerfile means hardlinks won't work so moving/copying the source adds a large (500M) amount to the image size. I might end up trying to change the webroot in the apache config if the container size ends up being an issue.

Doesn't seem worth it just for a list of plugins changed that many admins won't even see. Better off leaving a note/reminder to doublecheck enabled plugins with the version update.

[chrisamti]

We also are running on k8s and we also did some modification by creating own docker image based on the official one. Thinking in the same direction as you like changing webroot or like creating a complete rewrite of how the docker image is done in a more k8s way.

We are currently using cephfs to have multiple pods and created 2 pvcs for mounting /var/www/html and one for /var/www/data.

Initial setup or upgrades of nextcloud are done by a init container and using NEXTCLOUD_DATA_DIR to let nextcloud use the intended data pvc volume.

Because cephfs is having a journal about every open file on a client, the current implementation how nextcloud docker image is done, setup creates very high load on the journal by only having php/apc checking if anything has changed on the php code. We see a steady write stream into the cephfs metadata pool around 500 MB/s having around 1000 client sessions.

We also use owncloud on k8s and because of the smarter way how owncloud docker image is done, we see a way lower impact coming from owncloud on cephfs than coming from the nextcloud docker images.

[HassoSigbjoernson]

Upgrading the Apache image without copying the files at startup shouldn't be too much of a problem, after all a manual upgrade, as described in the documentation, means replacing the old files with new ones and running occ upgrade. Doing the upgrade for the fpm-image is more difficult though, unless you want to ship the Nextcloud files in both the php- and the webserver-container and make sure that both stay in sync.

[danieljkemp]

Upgrading the Apache image without copying the files at startup shouldn't be too much of a problem, after all a manual upgrade, as described in the documentation, means replacing the old files with new ones and running occ upgrade. Doing the upgrade for the fpm-image is more difficult though, unless you want to ship the Nextcloud files in both the php- and the webserver-container and make sure that both stay in sync.

Mounting the plugins in a volume is fine since they need to persist anyway. Creating a nginix image with the core NC files feels like the right way to do it. It'll be faster to start and update, no issues with multiple replicas and no reading the static files over a network share for no reason.

Keep the old behavior behind a flag maybe