Publish an image that is ready for scalable cloud deployments

Hi Folks,

thank you for providing a next cloud container image!

Unfortunately I spent a lot of time to get nextcloud running in my Kubernetes cluster. Unfortunately it's still not running and I would like to consider/discuss the following aspects.

rsync on startup?

As far as I can see, the entrypoint script rsyncs files from the container image to a different location:
https://github.com/nextcloud/docker/blob/7bd3b7b6dbd694bab3612a28b17a9767f2339c9e/docker-entrypoint.sh#L177

In my eyes, a containerized application should be self-containing and source code should be ran from the image (ideally stored there in read-only mode, immutable for security reasons).

Can someone explain to me, why this image copies source files (even third party code, like the aws library) to another location before starting? For me, this seems to be an anti-pattern in the world of container images.
I read something about upgrading, but I think upgrading in the container world means - not to compare any version.php files residing in a persistent file system - but to change the tag of the image. The application itself (again running from a readonly part of the filesystem) should detect its current version and compare this to the database. Then it has to handle the upgrade process (if required) with lockfiles, leases, migrations, etc. Also from a performance perspective I disagree with the approach to rsync application files before application startup. There could be slower persistent media like NFS and startup takes a long time, then you get into trouble with the readinessProbe (i know, I can set a startupProbe - but it feels dirty)...

instanceid?

The running application writes an instanceid to the configuration which has to be persisted, otherwise the application will try to re-install after pod restarts.

Can someone explain to me, why this instanceid is needed and why it has to be written into the configuration? I would expect it in the database, but not in the file system. The containerized application should not get any state (we have a database for that) and if it has to, it should be stored in the data directory. Otherwise scaling the application is a pain as well.

I would be really happy if someone could shed some light at this rsync idea. Until then, I'll have to build my own image.

Thank you very much :)

BR Matthias

Related issues:
https://github.com/nextcloud/docker/issues/1006
https://github.com/nextcloud/docker/issues/1582
https://github.com/nextcloud/docker/issues/1050
https://github.com/nextcloud/helm/issues/590

Start with docker-entrypoint.sh at the linked rsync section and read related issues #1006, #1582, #1050, plus nextcloud/helm#590. Establish the desired immutable-image and instanceid behavior, then document an agreed deployment design and validation criteria for scalable Kubernetes use.