Environment and name cleanup

[isodude]

• First change: from netbox to app on the container, since db is not named postgres :)
• Second change: use .env-files instead of environments inside docker-compose.yml
• Third change: use docker-compose.prod.yml instead of docker-compose.yml, changable through .env.

[isodude]

16eb64f is a fix for #2

[pitkley]

• Why docker-compose.prod-yml? Where does the prod come to play?
• I'm all for using env-files, but:
  1. I'd rather have them named e.g. netbox.env and postgres.env
  2. Create both files with default data so the user doesn't have to create them.
• I'm not entirely sure how I feel about renaming the service netbox to app, although your argument makes perfect sense. I will get back to you on that point.
• If you don't mind, squash your changes to a single commit. It's not a must though, I can also squash them while merging alternatively.

[isodude]

• It's a common way of handling the stage/production environments here at least, I see that https://github.com/getcarina/examples/tree/master/python-web-app does it as well and https://docs.docker.com/compose/production/ recommends it. I don't personally like the docker-compose-prod.yml, but rather docker-compose.prod.yml, but the one with hyphens may work better in a windows environment. So maybe switch to that instead.
• That's fine as well, the postgres.env contains all the database stuff and netbox has them configured auto in the compose file. netbox.env should just contain allowed hosts and secret in that case.
• Maybe naming them netbox.example.env ? I think it's a good routine to have .env-files in .gitignore.
• I can squash the changes to a single commit no worries. I'm not that used to do pull requests on github so you've to excuse me :)

[pitkley]

It's a common way of handling the stage/production environments here at least

While that may be true, I don't think we should tell the user what to do. But that is not a critical point overall.

Maybe naming them netbox.example.env ?

Yes, good idea!

I'm not that used to do pull requests on github so you've to excuse me :)

No worries. It generally depends on the repo-owner if they want you to squash your commits. I personally just like a clean git history with every commit being dedicated to a logical change! :grinning: