I've been using webfaction for all my django needs for the last couple of years but have had a high traffic site fall in my lap that dreamhost are probably better suited to handling.
To set up and experiment with a site with webfaction there are your [user].webfactional.com accounts. Which is sweet.
Equivalently Dreamhost also offers [name].dreamhosters.com
Yet this doesn't seem to work with my database and this doesn't seem to be playing nice with setting up django or passenger_wsgi.
So I'm wondering if I'm interpreting the documentation correctly to suggest that in order to make a site that depends on passenger it needs to be running from an active domain. The documentation is really implicit, I'm baffled.
Has anyone set up a testing/sand box environment for django using dreamhost, or know how to?
I've setup a Django site on Dreamhost on a dreamhosters subdomain before so I can tell you for sure it is possible.
I'm not sure what you mean by active domain but I know that you have to set something to the effect of "Allow Passenger for this domain" under "Manage Domains" > "Web Options". Your passenger_wsgi.py file should be placed in ~/[name].dreamhosters.com/ and needs to include all the necessary project/application paths (including the Django source) as well as set the DJANGO_SETTINGS_MODULE environment variable as described in the Dreamhost wiki. As far as database connections there is nothing special that you have to do in the settings when using Passenger.
On a somewhat related note, I would have to question your statement
...have had a high traffic site fall in
my lap that dreamhost are probably
better suited to handling.
given that Webfaction is by far the top rated host for Django and Dreamhost the absolute worst according to DjangoFriendly. It's possible that many of the reviews were written when Dreamhost was only supporting FastCGI and things might have improved when using Passenger but I still don't think it beats Webfaction's options of FastCGI, mod_python, and mod_wsgi (which is the recommended deployment setup according to the Django docs http://docs.djangoproject.com/en/1.1/howto/deployment/modwsgi/).
Related
I have a Django website as an on-going development which I have running on Ubuntu 16.04.1. It is an intranet and so sits within a corporate network.
It currently works nicely with Nginx, Gunicorn and Supervisor.
However, I would now like to implement single sign on so that users who have already authenticated into their workstations don’t have to sign into the application. As I understand from, the Django documentation, setting the REMOTE_USER environment variable is key and, during my efforts, I have been able to set this variable in my current Nginx config and it authenticates to the Django site.
However, the network environment means that I am looking for a solution that uses with NTLM or Kerberos (rather than Based Auth, which I believe would make this much easier for me although I’m currently unfamiliar with all of them.)
In trying to find internet posts that would help be do this (including on here), I’m not 100% sure that it would actually be possible.
Does anyone know if it is using recent versions of nginx (1.10) ? If not, am I likely to have more success with some sort of Apache set up ( using mod_wsgi instead of Gunicorn as this post this post would insinuate.
I'm new to mezzanine and Django. I have set up a site, everything is working but I can only launch the server on "development". I would like to access de site on the port 80 on the internet instead of internally, as I have no way other than redirecting the port via SSH to access it. I would like to know how to do that.
And another question, is Nginx included with Mezzanine automatically ? Cause I have a tuned up Nginx server there and I'm not sure what I need to do, if run it with my existing Nginx server or with the one included with Django if that is how it works .... thank you for bring some light on this.
NGINX is not included with Mezzanine, it's an entirely separate piece of software, similar to Apache.
Mezzanine includes a fabric script which can automatically set up a production server if you'd like to use it, and will install NGINX on the server for you, among many other things.
Given your question, I can't recommend enough that you read and understand all the related documentation on this topic. Start with the Mezzanine link below, it references many other documentation sites - Django, Fabric, NGINX, plus more.
Enjoy the adventure: http://mezzanine.jupo.org/docs/deployment.html
I'm following through the Django Tutorials by HackedExistence on youtube.
Since the video is about a year old, I assume that the version differences may contribute to this problem. I'm currently on the 2nd video but this issue arose since the first.
On my browser,
http://video1.hackedexistence.com/
This link opens up the Apache 2 Test Page, and the localhost link opens up the Django Administrator page nicely.
But he sets it up so that the hacked existence link loads up the Django Admin page.
How is he able to achieve this? and what steps are needed for setting it up that way with the versions that I'm working with.
Python 2.7.3, Django 1.4.1, Apache 2.2.22 (Unix)
Running on OS X 10.6.8.
video1.hackedexistence.com is (presumably) a domain under the control of HackedExistence, and it's showing an Apache 2 test page because the server it's pointing to is not configured to show anything else. You have no control over this domain or the server it is pointing to, so you can't affect it directly.
It doesn't have anything to do with different versions of python, django, apache, or anything else; it's likely that HackedExistence chose to move on to something else, is no longer maintaining his site (or at least the content on that subdomain of it) and his tutorial now no longer works as a result.
The closest you can come is add an entry to your /private/etc/hosts file (on OSX) so that video1.hackedexistence.com resolves to 127.0.0.1 (i.e. localhost, your own computer), but this is almost certainly not what you're after. For example, if you do this, everybody else will still see the test page you're seeing now, because the /etc/hosts file is just telling your computer to treat the video1.hackedexistence.com domain as if it's pointing to your computer.
For learning web development, you can safely completely disregard this and can continue to test on your local computer.
When it comes to deploying the website for other people to view and use, you will need to buy a domain (e.g. at http://namecheap.com/), get some hosting (for python/django hosting I can recommend WebFaction , or you can use Heroku's free plan), and follow the Django deployment instructions in the official documentation (or the documentation provided by the hosting provider you choose). My advice is to focus on learning web development and get something working before you spend money on any hosting.
I don't know the videos, but I'm assuming that the author of the book owns (or owned at the time) the hackedexistence.com domain name, and had it pointing to his server so that it would be able to interpret the Django App and serve it up to public requests ... and now it looks like that configuration doesn't exist any more.
If you're asking what I think you want to ask, "how can I get a Django app viewable on the public web," well, there are lots of ways to go about doing this. If your server is Apache, https://docs.djangoproject.com/en/dev/howto/deployment/wsgi/modwsgi/ is the way to go. Google could help you find the similar docs for other servers. Lots of answers on stack overflow as well.
If instead you're asking a different question, namely, "how can I get this app on my local machine to be viewable via some method other than localhost" (and you don't have a server), well, the answer is you'd have to get a domain that points to your local machine -- this is a question that has lots of answers elsewhere. One thing to be aware of is that Django through Apache on Mac OS X isn't terribly simple, as it requires manually installing mod_wsgi, but it's not overly difficult either. Here's Google's top link (a bit old but still relevant): http://jessenoller.com/2009/07/24/django-mod_wsgi-apache-and-os-x-do-it/
And finally, if you're asking how you can get your app to show up at hacked existence, well ... buy that domain and see the above paragraph. :)
I'm a complete newbie when it comes to sysadmin/deployment. Here's what I'm hoping to accomplish:
Have domain.com be a normal WordPress site.
Have either domain.com/app or app.domain.com be a Django webapp.
Hosting on Linode.
Quick and easy updates of the Django webapp code.
From what I can tell, gunicorn is an elegant way to serve the Django webapp, while WordPress fits most naturally with Apache. Meanwhile, nginx is recommended as a proxy in front of gunicorn and also seems to be used to improve performance of WordPress sites.
So what I'm thinking is: use nginx as a proxy server that routes all incoming web requests to either gunicorn (for the Django wepapp) or Apache (for the WordPress site). The Linode host would be running nginx, gunicorn, and Apache simultaneously.
Meanwhile, for updates of the Django webapp, I can simply update to the latest version of the code via github.
Does all that make sense? Am I even understanding things conceptually correctly? Or barking up the wrong tree entirely? (For instance can/should I just use a single Apache server to route requests to either WordPress or the Django app based on URL?) What gotchas and issues should I keep in mind as I research how to get this running nice and smoothly?
UPDATE: I've side-stepped all of this by (1) using Heroku to host my Django app, (2) using a CNAME record to map app.domain.com to the Heroku-hosted Django app, and (3) leaving (for now) the WordPress site on its existing host at domain.com. Thankfully, after gaining great new respect for what sysadmins and db admins do as I investigated all this, now I can get back to coding!
#Ghopper21
+1 for your question first.
Now, This is really interesting to know how it's possible in real time execution. I checked with some of my geek friends and I found tremendous response, here are some of suggestion with reference I got after brainstorming with them.
First of all check this link for deploying & running WP altogether with Django on Nginx +uWSGI...
These two threads of support forums from Webfaction.com gives you more idea about how they are recommending it to their client...
Deploying Django and Wordpress in same domain
wordpress + django on same account - advisable or not?
Hey, I got one support ref. of Stack Overflow itself, which is explaining how to achieve it on APACHE server...
How do I run Django and PHP together on one Apache server?
And last but not least, the one where a geek like us integrated WP with Django...
Integrate WordPress and Django
I run a small VPS with 512M memory of memory that currently hosts 3 very low traffic PHP sites and a personal email account.
I have been teaching myself Django over the last few weeks and am starting to think about deploying a project.
There seem to be a very large number of methods for deploying a Django site. Given the limited resources I have available, what would be the most appropriate option?
Will the VPS be suitable to host both python and PHP sites or would it be worth getting a separate server?
Any advice appreciated.
Thanks.
There aren't really a great number of ways to do it. In fact, there's the recommended way - via Apache/mod_wsgi - and all the other ways. The recommended way is fully documented here.
For a low-traffic site, you should have no trouble fitting it in your 512MB VPS along with your PHP sites.
Django has documentation describing possible server arrangements. For light weight, yet very robust set up, I'd recommend Nginx setup. It's much lighter than Apache.
I run several low-traffic Django sites on a 256 VPS without problem. I have Nginx setup as a reverse proxy and to serve static files (javascript, CSS, images) and Apache using mod_wsgi for serving Django as described in the documentation.
Running PHP sites as well may add a little overhead, but, if you're talking about low-traffic "fun" sites then you should be fine.