Environment Variables for settings.py about container-healthchecks HOT 27 CLOSED

@Braintelligence ping

from container-healthchecks.

@Braintelligence You just the variable name and add HC_ before and add it to the environment variables.
Example:

• TELEGRAM_BOT_NAME -> env var HC_TELEGRAM_BOT_NAME

from container-healthchecks.

Oh sorry, I thought only stuff worked, that was explicitly mentioned in the entrypoint.sh

from container-healthchecks.

I may need to add the variables that are "special" cases (integer, arrays) but overall that should work for most config options.

from container-healthchecks.

Do I need to use string brackets for those variables on the right side?

from container-healthchecks.

For string values not, quotes are added around your variable, see https://github.com/galexrt/docker-healthchecks/blob/master/entrypoint.sh#L75

from container-healthchecks.

What would be the easiest way to check the contents of the settings.py currently? There's no nano or vim available in the container T_T

from container-healthchecks.

Use cat PATH_TO_SETTINGS_PY, less or more (depending on which is installed, cat should be installed).

from container-healthchecks.

Hm, the settings.py seems to be correct but the Telegram Bot doesn't react =/... I can't seem to find any debugging info.

from container-healthchecks.

Same for mail, actually. I can't see any errors in the container logs but mails aren't being sent.

from container-healthchecks.

@galexrt I want to set DEBUG = False in the settings.py but you already have DEBUG in there resulting in a server error if I do this by HC_DEBUG = False

from container-healthchecks.

Also it seems that the settings are just copied at the end of the settings.py ... does this work that way? Theoretically you can overwrite variables by just setting it anew, but this creates a lot of spam in the settings.py

from container-healthchecks.

Oooooh, wait a second. I think those come from upgrading the container with new environment variables.

from container-healthchecks.

Did you create the container in such a way, that if it is restarted with new environment variables, it would just put them under the settings.py without checking if they were already set?

from container-healthchecks.

Yeah, overwriting of the variables works, but it seems you can't do:
DEBUG = True
then
DEBUG = False
you get HTTP 500 then.

from container-healthchecks.

Actually you get HTTP 500 if setting DEBUG = False in every case... I need to find out if you can even do runserver without it.

from container-healthchecks.

More info here:
healthchecks/healthchecks#115 (comment)

Maybe we should have this command be invokable by docker, without going into the container.

from container-healthchecks.

There is a way to invoke manage.py commands through the entrypoint.sh, but it isn't documented, could you create a separate issue to document that?

from container-healthchecks.

Done

from container-healthchecks.

This is something I might work on in a later PR, if it's ok with you we can keep this open until then.

from container-healthchecks.

@Braintelligence Yes, is it okay if I assign this issue to you then?

from container-healthchecks.

Sure

from container-healthchecks.

@Braintelligence Any news on this?

from container-healthchecks.

Oh wow, I'm sorry for not reacting to your comments O_O.

I get flooded with GitHub mails so much due to Mailcow, that I missed this entirely.

I just stumbled on this because I moved my healthcheck stack from one server to another. Is this here still a thing?

from container-healthchecks.

@Braintelligence Yes, this project is still a thing. I had hoped you work on the PR for this feature as you commented earlier.

What is the status on your side?

from container-healthchecks.

@galexrt Hey, currently I'm super busy. No free time I'm afraid :(. By "here" I meant the this ticket btw.

from container-healthchecks.

Closing as the healthchecks project uses env vars to read its config from.

from container-healthchecks.