search

chirpstack / chirpstack-docker

Setup ChirpStack using Docker Compose
https://www.chirpstack.io/
MIT License
283 stars 318 forks source link

use env variables instead of using plain passwords #21

Closed krasi-georgiev closed 5 years ago

krasi-georgiev commented 5 years ago

Signed-off-by: Krasi Georgiev 8903888+krasi-georgiev@users.noreply.github.com

bconway commented 5 years ago

I don't think this is a good idea, as it requires more environment boilerplate for a user to get a working setup. The intent of this repository is to be used as building blocks, not a production deployment.

krasi-georgiev commented 5 years ago

That is only a single env variable $JWT_SECRET. The $POSTGRES_PASSWORD one will be set to a default "postgres" when not set.

Apart from this change I don't see anything else that needs changing to use it production. If that is not the case can you give some more details on what else would be needed to make it production ready?

krasi-georgiev commented 5 years ago

the reason for this change is so that I can just copy and paste the compose file and init scripts without going through each line and removing/changing passwords. This in my opinion is more work than just exporting these env variables with

export .....

brocaar commented 5 years ago

Thanks @krasi-georgiev but I agree with @blocknonip. These files are intended to make it really easy (and predictable) for people to get started as one can simply run docker-compose up to spin up an environment. The created databases, users and passwords also matches with the loraserver.toml and lora-app-server.toml file configuration, so the whole setup is self-contained.

For some users using env. variables is not an issue, but for many it is.

krasi-georgiev commented 5 years ago

Thanks for the review I have few more comments to try and convince you :smiley_cat:

using $POSTGRES_PASSWORD doesn't enforce the user to set this variable as it is set to the default of postgres when not set.

This change allows me to just copy and past the skeleton without going through each line every time there is an update to see what changes are required to make it production ready.

For some users using env. variables is not an issue, but for many it is.

I am curious what kind of issues are you referring to?

I just remembered that I can also update the compose files to add these variables so that this is not imposed on the user meaning no change in the workflow would be required still making it more explicit what passwords are used when bootstraping the database.

To be honest I didn't even realize about this hard coded password until recently and was intending to use this in production.