Docker: config file is not created automatically when missing

[Heartnett]

trafficstars

My motivation behind this issue is that I could not get the container work out of the box, without the config.json. One would expect that there would be checks and default settings in place if the config file is not present.

Here are some potential improvements for the project:

:fire: 1. Default configuration file(s) :fire: Writing in the readme something to the effect of "these settings go into the 'xyz' array", while informative, just does not quite cut it. Adding default settings, generating example config(s), and/or supplying a default version of the required config file(s) in the event that the config file(s) are not present/omitted should provide the following benefits (in this scenario):

• Prevent the container from crashing without configuration. Especially good when users just want to test your project. (First impressions are important!). You don't want to try-out an app, the app then breaks/dies/freezes/loops, then you go wondering "WTF just happend!?" Only to find that the app requires more config up-front.
• Save users time from unnecessarily guessing, troubleshooting, debugging, digging through the source code, reaching for the README, posting issues, and/or giving-up and moving-on from your project all together.

*Also consider using environment variables?

2. De-bloat the container image - consider a multi-stage Dockerfile This should reduce the size of the resulting container image, even if its by a couple of megabytes. Ideally, the "final product" (compiled code) should be shipped. It also has to do with separation of concern (in my mind at least): keep the source code in the repo and ship the compiled code in the container image. You could also argue that the code should be shipped with the compiled code (for the sake of FOSS/open source).

3. Add Docker Compose config Nowadays lots of users are opting for the ease of use that docker compose files offer. Consider adding a docker-compose.yaml file and/or embed it in the readme. That way you provide users with the option to incorporate your container config into their container stack(s) as opposed to either running the lengthy docker run command or transforming the docker run command into a docker compose file.

[dani3l0]

Adding default settings, generating example config(s), and/or supplying a default version of the required config file(s) in the event that the config file(s) are not present/omitted should provide the following benefits (in this scenario)

I agree, this is kinda annoying. Although config is already inside docker image, -v overrides it with empty directory. This is to be fixed.

Prevent the container from crashing without configuration.

Container is not crashing. The website does, due to missing configuration file as it's taken directly by frontend.

Especially good when users just want to test your project. (First impressions are important!).

That's why public demo exists.

Also consider using environment variables?

There is no dynamic backend to handle them?

De-bloat the container image - consider a multi-stage Dockerfile

I don't think our current Dockerfile is 'bloated'. Just small Nodejs image based on Alpine, project itself and its dependencies: where's the bloat? That's how all npm projects are handled. If you want to save extra space, put prebuilt zip files from releases in your bare-metal webserver.

running the lengthy docker run command

Lengthy by providing just one port mapping and one volume mount? docker compose makes sense with bigger, more complicated projects. People who organize their homeservers with docker-compose.yml files already know how to configure their own way.

While I see the problem of default config file not being created, I don't understand describing deployment process as a terryfying nightmare. If somebody doesn't know how to run a simple docker container, maybe one should learn the basics first or just give up self-hosting?