On Mon, Sep 24, 2018 at 03:18:46PM -0700, jim_rain wrote:
> Hi,
>
> I'm developing a Django app, it's hosted on an EC2 instance so I'm using
> wsgi, even in development. I would like to create a production and a
> development version where really the only things that are different are the
> two databases. I want the code to be the same on both. I figured I could
> just have two settings files and two wsgi.py files so it's set up like this:
>
> wsgi_prod.py:
>
> *import os*
>
> *from django.core.wsgi import get_wsgi_application*
>
> *os.environ.setdefault("DJANGO_SETTINGS_MODULE",
> "canzare.settings.production")*
>
> *application = get_wsgi_application()*
>
>
> wsgi_dev.py:
>
>
> *import os*
>
> *from django.core.wsgi import get_wsgi_application*
>
> *os.environ.setdefault("DJANGO_SETTINGS_MODULE",
> "canzare.settings.development")*
>
> *application = get_wsgi_application()*
>
>
> Then in my httpd.conf I have these lines:
>
>
> *WSGIScriptAlias /dev /home/canzare/work_area/canzare/canzare/wsgi_dev.py*
>
> *WSGIScriptAlias / /home/canzare/work_area/canzare/canzare/wsgi_prod.py*
>
>
> The only real difference in the settings.py files is that they point to two
> different databases in mysql.
>
>
> This sort of works, I can access the production site with <mysite>/ and I
> can access the development site with <mysite>/dev/
>
>
> But then everything falls apart. The admin site on both seems to be broken.
> It looks ok but if I try to perform any actions it tries to make me
> re-login.
>
>
> Also (and this may be the root of the other problem) I don't think
> migration works correctly. I can migrate to one instance but not the other.
>
>
> Has anybody come across something like this before and/or and I'm going
> about this completely wrong and is there a better way?First, regarding management commands, of course, if you have different WSGI applications using different settings, you need to match your management commands to those as well. So if you want to migrate the production database, you need to run the migrate management command with DJANGO_SETTINGS_MODULE pointing to the production settings, and likewise for the development environment. Second, just using different databases might not be enough, at the very least, another obvious thing you'd probably want to isolate is media storage, not to mention caches, and what have you. Third, the issue with cookies is because you presumably use the same cookie name for the session cookie for both deployments, so they overwrite each others' session IDs. While you can fix this by setting a custom name for the session cookie in one of the settings modules, you're likely to encounter such conflicts for any other cookies that you might use, too. Oh, and it's likely that a lot of links from your deployment sitting at the /dev/ prefix will point to URLs sitting in the production deployment, unless you're extra careful with making sure that all links include the script prefix. All in all, your approach seems like it's more trouble than it's worth, and you'll make your life a lot easier if you just make two separate deployments sitting on separate domains. (A relatively common approach is to use a “dev.” or “staging.” or “beta.” subdomain of your main domain for the dev/testing/staging environment.) Good luck, Michal -- 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+unsubscr...@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/20181003080839.GA1181%40koniiiik.org. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Digital signature
