Any thoughts to remove the `/var/www/html` volume?

[vfreex]

Currently, in the image the Nextcloud files are stored in /usr/src/nextcloud. Everytime a Nextcloud container is created, entrypoint.sh syncs those files to /var/www/html when the version in /usr/src/nextcloud is newer than /var/www/html, then runs php /var/www/html/occ upgrade --no-app-disable to upgrade the database structure and so on.

This works well for a small group of users. Everything works fine without too much human attention.
But if you are running Nextcloud in production, things will be different:

1. You may not want the DB upgrade to be run automatically, especially when running multiple Nextcloud services behind a loadbalancer.
2. Nextcloud files should be immutable once the image is built, for security, stability, and testing reasons.
3. Mouting /var/www/html as a volume makes it unfriendly to rollback to a earlier version when you are running on Kubernetes or OpenShift.

Is it possible to remove the /var/www/html volume? Mounting subdirectories like custom_apps, config, themes, and data should be adequate AFAIK (correct me if I am wrong).
After disabling the auto-upgrade, users can still upgrade through the Web UI or occ.

[vfreex]

See #382

[pierreozoux]

The reason for that is some people do mount /var/www/htmlto the host system.

I think the target for this image are small setup.

For bigger setup, I just recommend using this as a base, and then modify the entrypoint to your liking.

[vfreex]

@pierreozoux Thanks for the explanation. Currently I am doing this way.
But it would be nice if images for bigger setup can also be maintained by the Nextcloud community.

[SnowMB]

For the most part this docker image is an example and aimed at new / unexperienced user that want to get started fast. It also is quite usable at small scale.

If you have improvements for larger setups, it would be nice to share them here, but please don't break existing functionalities.

I think with scaling up the requirements vary so much, that it is better to customize the underlying dockerfile accordingly or even start from scratch.

[vfreex]

@SnowMB Is it possible to maintain such images for larger setups (as variants, for example) alongside with existing images? So that they can be upgraded automatically and potential issues can be found easily as more and more people are using them.

[SnowMB]

I'm not exactly sure if this is feasible, but what might be possible is extracting a base image from the existing one. So it is easier to skip certain "convenience" parts that are not needed for larger installs (like automatic update). But I have no idea if this is possible and what that would look like.

One problem we should keep in mind is that each variation multiplies with the existing ones. Let's say we have fpm and apache. We have some work for alpine images. Ideally that would give us fpm-alpine and apache-alpine. With extracting base images, we are at six, that have to maintained and documented in a way that is not confusing to the users.

There are so many possible solutions, that we tried to focus on giving examples on how to modify the image for ones own needs. Hence the section in the readme about building derived images. (For some context look at the early issues / prs and my comment in #37)

[snalhattali]

can you help me? what is the root password though the terminal I need to delete some files?