Custom app container startup arguments
I created a custom app for Outline (https://github.com/tokilabs/outline) and had some issues getting it to run.
The app uses an environment variables config file
.envthat should live outside the image and be passed to the container at start via
--env-fileargument like this:
docker run --env-file=.env outlinewiki/outline
I found no way of configuring Cloudron to do that. Is it possible or should I open a feature request?
I found another way to make it work by manually setting each variable using the cloudron cli and automated the process via an
shscript. But it was a big hassle and duplicated variable management
timconsidine last edited by
@svallory It looks very interesting so wish you well to solve the problem, although sorry i don't know the anser.
@atrilahiji I could, but I want to create an image anyone can use, so the values cannot be inside the image
Lonkle last edited by
I ran into a similar issue before (Cloudron not supporting
docker runvariables). 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.
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 last edited by svallory
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...?
@atrilahiji I was planning to submit to the App store, it would be an awesome addition (not my piece of software, btw)
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
start.shof 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.
@mehdi only thing I can see is the S3 stuff I guess.
@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
@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.shand a file in
/app/datamay be a solution though. I'll try that.
I would still like to leave the suggestion of either having an input for
docker runextra 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!
@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?
@girish exactly! Like the docker UI does for export environment variables
Honestly, there have been a few times where I could have used something like this too.
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.