Towards declarative deployment

[Deaddy]

Describe your Issue

The current setup effectively requires several writable and persistent directories, both for writing configs via entrypoints as well as for managing nextcloud itself. Furthermore, by using the entrypoint dockerism, secret values are unnecessarily exposed to env (apps exposing env via debug endpoints is a favorite ;D ). Furthermore, apps can be installed from within the application.

This makes deployment at scale a game of luck.

Limitations

• unless we add another persistent, writable mount to the app directory, adding new apps requires new images (which is kinda the point of this exercise, but there is a need for clear communication to the user)
• upgrades possibly require some manual management of the config, but at least we have some support for readonly configs in https://docs.nextcloud.com/server/25/admin_manual/configuration_server/config_sample_php_parameters.html#config-is-read-only

Approach

I expect this to play out roughly like this and would try to keep it roughly updated to reflect reality as good as it is possible:

First iteration(s)

1. mount emptyDir to initContainer using same image as deployment at config path
2. let entrypoint do its magic
3. start main container with readOnlyRootFilesystem SecurityContext and command/arg skipping entrypoint and without persistence
4. see what breaks [^1]
5. fix it and try again :-)

Next step (possibly trivial)

1. remove secrets from env
2. see what breaks
3. fix it and try again :-)

Further things

• [ ] notes.txt mentioning limitations when readOnlyRootFilesystem and no persistence is set
• [ ] see if it is necessary to gate initContainer for this scenario or if it actually also improves non-readonly-scenarios by removing secrets form env
• [ ] if applicable make consistency check of used config parameters

Related issues

• https://github.com/nextcloud/helm/issues/531

[hansbogert]

let entrypoint do its magic

The problem starts here. I just spend a day dissecting the logic of the docker image, sorry for being harsh, but it's ridiculous. Why does it copy over perfectly fine source code at /usr/src/nextcloud ?

My scenario was trying to get OVERWRITEPROTOCOL to work which eventually I found was in /usr/src/nextcloud/config/... however, that directory is only rsynced at first boot. So changes made to that directory are never migrated to the /var/www/html directory during upgrades. My installation being somewhat older never got reverse-proxy.config.php and all other fancy stuff.

Would the above issue of not being up-to-date with (at least) /usr/src/nextcloud/config be solved with your proposal?

[jessebot]

The current setup effectively requires several writable and persistent directories, both for writing configs via entrypoints as well as for managing nextcloud itself.

Yeah, that's currently just how nextcloud works.

Furthermore, by using the entrypoint dockerism, secret values are unnecessarily exposed to env (apps exposing env via debug endpoints is a favorite ;D ).

You'd need to take this up with the nextcloud/docker repo, and possibly nextcloud/server if it's an issue of env vars being exposed via debug endpoints. When you open that issue, please include steps to reproduce, including the debug endpoints you saw the security issue for.

Furthermore, apps can be installed from within the application.

That's probably not going to change, as that's just a feature of nextcloud.

unless we add another persistent, writable mount to the app directory, adding new apps requires new images (which is kinda the point of this exercise, but there is a need for clear communication to the user)

Adding a new app does not currently require a new image. I currently backup all of my nextcloud-files PVC and it backs up all the apps. You're still free to build an image with the apps you want, but then you'd have to rebuild the image everytime one of the apps upgrades, and that seems a bit unnecessary, but technically doable.

This issue is a bit all over the place. Is there something specific you'd like to see done? If so, please create an issue for the specific thing you'd like to do. For instance, if you would like to update "notes.txt mentioning limitations when readOnlyRootFilesystem and no persistence is set", it would be better to create an issue for just that. This chart is community maintained, and large issues mentioning multiple specific requests are a bit harder for maintainers to follow up on. You can also submit PRs directly to this repo for work you'd like to see done.