-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issues to consider before releasing as production #3
Comments
|
Unfortunately that doesn't work for environment variables:
|
does as does:
|
Cool, I wasn't aware of that. Do you know an easy way to reference |
I also just realised that the underscore replacement technique wont work because of configs like this: |
With respect to password generation, it would then be necessary to pass in a password if using docker-compose (or some other prescripted docker start commands) I assume? |
Underscores are supported by replacing
For password generation: I guess if you're linking containers then the onus would be on you to define a password for all containers requiring it. |
Ah, I see. I think it would be a mistake to use the periods as then it is harder to customize as you couldn't write a bash script for example. I can imagine that as configs get more complicated, we would probably want to be passing some encoded lock of YML or JSON, so perhaps the underscore technique is ok, if it is not going to be the recommended way down the line. |
One alternative to using env-vars could be to pass them as command line parameters when starting the container, e.g. |
Though, maybe not for passwords because one's command-line parameters are visible to other users on the system. (I may be misunderstanding this discussion though.) |
Now that #1 is merged we're close to production. Once this becomes official it'll be harder to make changes. Some of the issues we should give a final review to are:
CONFIG_omero_web_public_enabled=false
becomesomero.web.public.enabled=false
omero
, should we generate a random password instead? Similarly for the public password when Enable public user #2 is merged?db
under the assumption that a postgres container will be linked with the namedb
, should we remove the default and make it mandatory instead?The text was updated successfully, but these errors were encountered: