You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
i like to add a easy mechanis to setup and configure appplication.
so i see the following new options in values.yaml:
nextcloud:
appManagement:
# -- if app not listed under apps it will be disabledautoDisable: true# -- if app not listed under apps it will be uninstalledautoRemove: trueapps:
deck:
enabled: truedrawio:
enabled: trueconfig:
DrawioUrl: "https://embed.diagrams.net"DrawioOffline: "yes"
Therefore
i will use the occ command with an initContainer for enable and check there installation
nextcloud.appManagement.apps is an dict for easy use multiple value.yaml files and merge them
config of applications are stored in an kubernetes-secret because they could containe sensitiv informations
Does you like to merge such code? Do you like to change something in the outside behaviour ?
I like the idea as well, I wonder how much work it is to concert the yaml into the php array syntax with nesting etc. (and how easy it could break).
yeah, that makes sense. I think my main concern is the config section with each app. It may make more sense to start with support for just installing, enabling, and disabling, as config can get hairy, as you mentioned with regards to how nested a config for a given app might be, especially considering some apps will have different methods for config than others 🤔
That is an implementation detail, that i like to discuss in my PR later.
but if you like to know - i wanted to write shell script and with using occ config:set (or config:import) without writing any php code ( and handling arrays in php).
When this PR, nextcloud/docker#2115, get merged, we could use the docker level hooks by mounting configMaps into the post-installation or before-starting folders as per the docs. It was discussed a bit in nextcloud/docker#763 (comment) as to why we can't do that for now, but knowing these folders exist, reduces the need for more init containers or external post install jobs, not just for managing apps, for running other occ commands as well.
the rest is logic to put that app-management.sh into a secret and mount it in the deployment under /docker-entrypoint-hooks.d/before-starting/app-management.sh
(that is high in development, so some command could change any time like an switch to occ config:import).
PS: thanks for the hint of the hooks @jessebot. i believe that is my code is just an helm-values to shell mapping, to put that into the image is to trivial, maybe it should be part of the nextcloud-server or just keep it here.
If you are not willing to merge such code, please say it now.
So i could switch for my setup to the values of extraVolumenMount and so on.
Activity
jessebot commentedon Nov 11, 2023
This does sound pretty neat and streamlined 👀 I think it's a good idea. How about you friends, @provokateurin @tvories ? :)
provokateurin commentedon Nov 11, 2023
I like the idea as well, I wonder how much work it is to concert the yaml into the php array syntax with nesting etc. (and how easy it could break).
jessebot commentedon Nov 11, 2023
yeah, that makes sense. I think my main concern is the config section with each app. It may make more sense to start with support for just installing, enabling, and disabling, as config can get hairy, as you mentioned with regards to how nested a config for a given app might be, especially considering some apps will have different methods for config than others 🤔
wrenix commentedon Nov 11, 2023
That is an implementation detail, that i like to discuss in my PR later.
but if you like to know - i wanted to write shell script and with using occ config:set (or config:import) without writing any php code ( and handling arrays in php).
provokateurin commentedon Nov 12, 2023
Sounds good, but how would you delete keys that got removed from the config?
jessebot commentedon Dec 15, 2023
When this PR, nextcloud/docker#2115, get merged, we could use the docker level hooks by mounting configMaps into the
post-installationorbefore-startingfolders as per the docs. It was discussed a bit in nextcloud/docker#763 (comment) as to why we can't do that for now, but knowing these folders exist, reduces the need for more init containers or external post install jobs, not just for managing apps, for running otherocccommands as well.provokateurin commentedon Dec 15, 2023
Agreed, I feel like this is not the job of the chart. If there is a way to do this with the docker image we can and should support that.
[-]Manage apps with initContainer[/-][+]Manage apps with hooks[/+]wrenix commentedon Dec 25, 2023
A Preview of my draft:
here i start to develop it: https://github.com/wrenix/nextcloud-helm
(current commit: wrenix@efddf1f <- maybe i amend it later)
just the logic of the
app-management.shis over to develop it here:https://github.com/wrenix/nextcloud-helm/blob/main/charts/nextcloud/files/app-management.sh.gotmpl
the rest is logic to put that
app-management.shinto a secret and mount it in the deployment under/docker-entrypoint-hooks.d/before-starting/app-management.sh(that is high in development, so some command could change any time like an switch to
occ config:import).PS: thanks for the hint of the hooks @jessebot. i believe that is my code is just an helm-values to shell mapping, to put that into the image is to trivial, maybe it should be part of the nextcloud-server or just keep it here.
If you are not willing to merge such code, please say it now.
So i could switch for my setup to the values of
extraVolumenMountand so on.wrenix commentedon Feb 8, 2024
openDesk has created a other solution: For security they build a image with this apps inside:
https://gitlab.opencode.de/bmi/opendesk/components/platform-development/images/opendesk-nextcloud-base-layer/-/tree/main?ref_type=heads
yaml for configuration:
https://gitlab.opencode.de/bmi/opendesk/components/platform-development/images/opendesk-nextcloud-base-layer/-/blob/main/src/files/apps.yaml?ref_type=heads
provokateurin commentedon Feb 8, 2024
I think that approach is better, as it is more secure and less likely to fail, especially with upgrades.