Env vars are considered bad in contexts where everything runs in the same... environment. And I too have considered them as hacks or as options to avoid by all means.
But times are changing, and nowadays there is a move towards containerized apps, even outside the cloud context. And we are no more now in the traditional initial hype phase, which means that the approach has proven its benefits (and also its constraints and maybe weaknesses). As an example of a real life work project, I've deployed a docker compose stack on RaspberryPi's for running an instrumentation system, to avoid having to install each and every component and manage the possible conflicts or interferences between them. It works 24/7 for months now without any hiccup. Containers really shine for relieving you from DLLs/shared libs/packages/... hell.
That being said, in such an architecture, each container is an isolated environment, and thus you can use env vars without fearing that someone else could tampered with them.
So perhaps the time is coming for considering env vars are no more the evil :) It depends on when and how you use them.
Best
Eric
Sent: Friday, March 30, 2018 2:11:02 PM
To: django-users@googlegroups.com
Subject: Re: Decoupling Postgres database credentials in django for deployment.
Environment variables are the best option for not embedding sensitive information in filesHowever some people (me that is :-) think that environment variables, though widely used, are an ugly hack for this problem.
I explain the way I do it (TLDR; production settings must be stored in a different "deployment" repository, preferably with any secrets encrypted) in https://www.crowdcast.io/e/deploying-django, from 38m10s to 46m30s.
Regards,
Antonis
Antonis Christofides http://djangodeployment.com
On 2018-03-30 13:06, PASCUAL Eric wrote:
Hi,
Environment variables are the best option for not embedding sensitive information in files which have chances to be stored in places such as external source repositories (GitHub et al.).
If you are working with orchestrators such as Kubernetes, you can use the "secrets", which are specialized shared configuration data, stored in encrypted form. As shared configuration data, they bring the extra benefit over env vars of being manageable from a single central place, and then distributed to all the replicas and services which need them.
Best regards
Eric
From: django-users@googlegroups.com <django-users@googlegroups.com> on behalf of Andréas Kühne <andreas.kuhne@hypercode.se>
Sent: Friday, March 30, 2018 11:08:52 AM
To: django-users@googlegroups.com
Subject: Re: Decoupling Postgres database credentials in django for deployment.--Hi,--
I am sorry, but this doesn't really make sense. What do you mean by decoupling the data?
Deploying to the cloud, will mean that you will need to setup a new database for your project - there you will get a completly new database, that won't be connected to your development data in any way.
You can then add system variables for the username and password for the database - and thats about all you need?
Regards,
Andréas
2018-03-29 22:24 GMT+02:00 prince gosavi <princegosavi12@gmail.com>:
Hi,--
I have made a django project and want to deploy it on cloud.
Before that i want to decouple all the private information.
I want to decouple the database info too, like the username password etc.
Any help is appreciated.
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com .
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users .
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/4b09223d- .d58f-4fda-b3f7-64b230960d94% 40googlegroups.com
For more options, visit https://groups.google.com/d/optout .
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAK4qSCeZFiw9D7Sa213H_MkPgcH-aTQ3fk-j5HLjZdHK%2B5ps%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/DB7P193MB0331039E86ABAEFF1B794D898CA10%40DB7P193MB0331.EURP193.PROD.OUTLOOK.COM.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/39b874a1-dbaf-75e2-3151-747bd95045dc%40djangodeployment.com.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment