I have a django application that uses a postgres DB.
I have a chef recipe that sets up the postgres DB, including setting up a postgres username/password for the django app to use.
This username/password is then used by the DATABASES settings.py value.
At the moment I have to have the postgres details in both attributes.rb and in settings.py.
How can I have them in just one place?
Options I have currently considered:
Having settings.py (or part of it) generated by a chef template. That way the details only need to be in the chef recipe.
The downside of this is that the django app is incomplete unless it is deployed via chef. (This might not be that much of an issue, as even local dev is done with vagrant+chef).
Having a known file on the filesystem that settings.py checks and loads some values from. This file is generated by chef.
This is only a little bit better than the first solution. Also it requires some boilerplate code in settings.py to load and parse the file.
Have the details in settings.py and let chef extract them (somehow).
This approach is problematic because it muddles with the ordering in the chef recipe (I have to check out my django app, extract the value, use the values to set up postgres, and then start django).
That itself might not be too bad, but the real issue comes when/if I want to move to a system where passwords aren't in source-controlled files but in something like chef's data-bags.
I've googled quite a bit, but other than various discussions on the layout of settings.py and general talk about how to use django and chef, I can't find a nice solution.
Surely someone else has deployed a django app with postgres using chef and come across this before?
You should use a data bag. And as you store a password there, it should be encrypted data bag. Then you can read data from it in both recipes (postgres and python).
And storing your passwords in attributes also is not a good idea - because they are too exposed.
Related
I'm new to Django just started learning it today, since I am quite proficient in express/nodejs and mongodb, I know there are some variables that one should not push to github as they can contain passwords and other identifying information. On express/node I create a .env file and add it to my .gitignore, typically containing the password to my mongodb connection.
I am about to push my first Django api project to github and want to know if there are any other information besides the "SECRET_KEY" that I should protect. Also is .env file still the best way to protect it in Django. Furthermore I have my Django project within a ll_env-virtual environment should it make a difference.
Besides SECRET_KEY there are some other variables like:
Database credentials (PASSWORD, etc)
If hosted on any cloud providers, their secret keys (AWS_SECRET_KEY)
If using Email service, there will be your mail specific password and etc.
In short every variables that you think are to be secured should be stored in a .env file.
Also for the ease of development and production you can store Debug variable.
Basically .env file contains the individual user environment variables when collaborative working. This article by djangocentral may help you know more.
I built a Django project with a few models. Now I created a second server with the same setup. This one is meant to be the deployment server. Databases are separate from the dev-server.
However can you tell me if I can simply copy the databases from the dev server to the deploy or will the Django logic, since I also mean the user models and permissions etc.
The tables which I created myself are no problem to transfer to the new server. However I am wondering If Django gets confused when I also transfer something like the auth_user Model.
Should this work since I also just copied the backend logic as well?
I am new to Django 2.2 and I found that SQLite is default database engine here. But I want to use the PostgreSQL instead of SQLite.
I have created a new project and migrate the (ex: Post) model after creating and adding the app to the settings.py and admin.py file. And after that, I decided to use the postgreSQL, and I did it too by migrating to postgreSQL. Before migrating I created a postgres database and add all the necessary details to the settings.py file's DATABASE settings according to instruction of Django. It's working fine. I haven't got any problem yet. Though I see still the sqlite database file still in the project directory. It looks bit odd though. I'm new to Django. Can you please tell me should I keep that file there or delete sqlitedb file? And is there any security issue with sqlitedb file if I keep there? I love to want a neat and clean project settings. Thanks in advance my dear friends!
It's totally up to you. If you want to keep then keep it. And if you want to delete that file delete it. There is no security reason or any problem will occur. Just delete it if you don't need it.
When to Use SQLite?
All applications that require portability and don’t require expansion.
In cases where applications need to read or write files to disk directly.
When to Use MySQL?
Where high-security features are required for data access.
For websites that work on MySQL despite some constraints.It's a
scalable tool that is easy to manage.
Basically, I have two django servers (django v 1.2):
Server 1 has a bunch of models, local database, and remote database access to ModelA in Server 2.
Server 2 has ModelA
I want to use ModelA.objects.get() and django ORM API in Server 1 for ModelA. Am I supposed to just duplicate models.py from Server 2 to Server 1? By just copying models.py over, I can use the ORM methods and trust the database routers that I set up to not do weird stuff when they syncdb.
This seems to be good enough right? I don't see any reason to use django-piston or those other restful API packages because in those cases, I have to still add all the extra code to recognize the model. Main reason I even dove into looking at the API packages is because I was wondering if there was a clean way of giving ORM access without duplicating the code.
Copying the code is pretty common. You can configure your settings to point to whatever database server you want.
As an app grows it is common to have to add webservers. One way this can be done is to copy your code base to another machine and run it behind a reverse proxy.
This means the exact same code is running on more than one machine, sharing a database backend.
Django provides an 'app' structure which you might want to look at. You can package an app and distribute it to another projecct.
I created a database for a site i'm doing using Django as the admin backend. However because the server where the site is hosted on, won't be able to support Python, I find myself needing to do the front end in PHP and as such i've decided to use CodeIgniter along with Datamapper to map the models/relationship.
However DataMapper requires the tables to be in a specific format for it to work, and Django maps its tables differently, using the App name as the prefix in the table. I've tried using the prefix & join_prefix vars in datamapper but still doesn't map them correctly.
Has anyone used a combination of this? and if so how have the fixed the issue of db table names being inconsistent? Is there anything out there that i can use to make them work together?
----edit: clarification on backend---
Let me clarify: i'm going to be running the admin from a subdomain pointing to a python ready server. However i can't move the main domain name from the php only webserver because of certain constraints/binding contracts the company got itself in. and don't want to use cloaking/masking because of seo purposes.
i'm using the django admin because i'm using some packages to make a pretty/functional admin, such as grappelli for the admin template, along with its editor for editing news stories, etc. also using photologue to manage photos/galleries. etc.
If your problem is simply making Django use the same tables as your other software, use the db_column and db_table parameters in the models.
http://www.djangoproject.com/documentation/models/custom_columns/
Two apparent solutions:
Instead of hacking one or both to work well with each other, emulate the Django admin in PHP/CodeIgniter code. **
Get a server that supports Django. Make the frontend in Django.
Time-wise, either one of those solutions will be less involving than trying to make two different frameworks using different programming languages mesh well together. I can't imagine the future maintenance required to ensure everlasting compatibility and interoperability.
Also, I assume by saying:
I created a database for a site i'm doing using Django as the admin backend
You really mean that you modeled your apps using Django, and that you also intend on administrating the database that has resulted from this modeling in the Django admin. (In which case you already have your Models layer complete and should just try building the rest of the site in Django)
If that's the case then in your models you are going to need to define the exact column names (db_column) that DataMapper will expect, as well as manually define the table names (db_table), including M2M tables.
You may also have to define all of your primary keys manually, if DM expects something named differently.
Also:
If the server can't support Python, where are you going to be running your backend? Different server? Locally? This plan just isn't making a lot of sense.
** I would not suggest trying this. I had been attempting to make a CI backend that actually shared much of the same ideas as Django's admin, before I knew about Django's admin. And of course once discovering Django, I dropped the CI work immediately and continued on with what I have found to be a much more amazing framework that is much faster to develop on.
So as I understand you plan on using Django just because of django-admin, and you are trying to use CI for the actual site because the server runs PHP, right?
So why don't you use framework that generates something like Django's admin but that you can run on your server?
The Symfony Framework has a really nice admin generator, in the spirit of Django's and you might be able to run it on your server. This would save you from the maintainance nightmare that might come later as #jonwd7 answered