Custom app container startup arguments

[svallory]

@atrilahiji I could, but I want to create an image anyone can use, so the values cannot be inside the image

[Lonkle]

I ran into a similar issue before (Cloudron not supporting docker run variables). but the best place to put them is in the DOCKERFILE and tell the people you share it with to change it in the DOCKERFILE. I'm pretty sure that's the best you can do rn.

[A Former User]

@svallory Seems like most of those should be set in start.sh (SMTP, domain, DB, etc since those need to be updated on restarts in case someone changes their cloudron app config.

Any options people need to be able to manually change can use something like this to load a .env from start.sh: https://gist.github.com/mihow/9c7f559807069a03e302605691f85572

[svallory]

@atrilahiji

But how do you distribute an App via Cloudron app store (or a similar easy process) using that approach?

won't the user have to get the code, modify start.sh, rebuild, upload, etc...?

[svallory]

@atrilahiji I was planning to submit to the App store, it would be an awesome addition (not my piece of software, btw)

[A Former User]

@svallory no so the start.sh can use environment variables that cloudron gives you for SMTP, domain, and DB settings. So if that info ever changes they should be updated on startup.

Here: https://docs.cloudron.io/custom-apps/addons/

[mehdi]

Taking a quick look at a repo, I am not sure which precise values you expect the user to tweak.

Cloudron's philosophy in these sorts of cases is to automatically configure what can be auto-configured (SMTP, domains, DB ...), chose reasonable defaults for the rest, and possibly allow advanced users to tweak the configuration by editing a file in /app/data manually. The start.sh of your app can check if a custom config file exists in a pre-defined location, merge it with the defaults, write the result in a temp file, and use this temp file for the actual app.

[A Former User]

@mehdi only thing I can see is the S3 stuff I guess.

[A Former User]

@svallory check out the environment vars i am using in start.sh here to automate the setup and config changes: https://git.atridad.dev/alt-ron/cloudron-humhub-app/-/blob/master/start.sh

[svallory]

@atrilahiji and @mehdi thanks for the suggestions. In my custom version there's S3, SITE_NAME and SITE_DESCRIPTION (that I remember) other things can be either generated or got from cloudron I think, but more variables can come along down the road.

I think the combination of a smart start.sh and a file in /app/data may be a solution though. I'll try that.

I would still like to leave the suggestion of either having an input for docker run extra arguments or allowing via the CloudronManifest to set variables that would then be filled in the app settings. The latter would be incredibly awesome and make things a lot easier!

Again: thank you so much for the help!

[girish]

@svallory If I understanding correctly, you want to specify the setting names like S3/SITE_NAME/SITE_DESCRIPTION etc and then these variables can then be configured by UI ? Also, I guess you are expecting these variables to become exposed as environment variables to the app?

[svallory]

@girish exactly! Like the docker UI does for export environment variables

[mehdi]

Honestly, there have been a few times where I could have used something like this too.

[fbartels]

@girish said in Custom app container startup arguments:

these variables can then be configured by UI ? Also, I guess you are expecting these variables to become exposed as environment variables to the app?

I like the way this is implemented in the univention app center. The format of the settings (there they use the ini format) is explained in https://docs.software-univention.de/app-provider-5.0.html#app-settings:reference. It defines different types of settings and allows to template default values (even custom drop downs). The values are then stored in a file in the container and scripts can be triggered inside and outside of the container to react on changes. Outside is probably not necessary here.