To this point, I just created and played my Django server in my localhost, like setting up a basic server Linux distro on my another device and testing etc.
However, I also heard of server applications like apache2 or nginx. The thing I wonder about is: Do I really need to use one of them in production? I want to buy (or rent?) a VPS service, then deploy (or publish?) my project on that server. The questions on my head are:
Running server with manage.py runserver 0.0.0.0:80 means it does not make my application worldwide? An server application (or whatever it is) makes it accessible outside?
Or a server application is simply needed for better performance, optimization etc. ?
Simply, why do I need to use apache2 or nginx to deploy my project?
It's a long story. In few words:
Running your project on localhost surely wont make it worldwide accessible, since at least you need a public address for your server, but not a local one.
Speaking honestly it is not a problem to run a site in pro using django built-in server. But, as you can read in docs, it is strongly NOT recommended. Why? Because it was developed specially for testing. It is written in python (slow enough for web server) and not suitable for handling multiple queries to the server and it is only a matter of time when it will crash. Of course, there are plenty of other reasons like cache and access settings, redirects and others.
Related
I have a site that I want to expose to a bunch of colleagues that serves as an interface for some Machine learning tools.
I’ve made the site in Django 2.0 and would like to serve it from a small windows PC under my desk, and then from a more dedicated server once it’s operational.
I’ve had a look around and it looks like my options are using uWSGI or Django it self to serve the site. Obviously Django is mich slower, but on a PC with an i5 i recon it should be able to handle a couple of requests a minute, which is the peak traffic I’m expecting.
FastCGI appears to be depreciated, so what other options, prioritizing ease of confit on my part are there?
So anyone in a similar situation:
I ended up using waitress as the server and whitenoise to serve the static files.
This appears to work sufficiently fast and requires little configuration, once you have have worked out how to get the static files going with whitenoise.
Django itself can serve pages to other machines on your network. SImply start the local server with this command
python manage.py runserver 0.0.0.0:8000
Then, you can access the local website by requesting http://<dev_machine_ip>:8000. Obviously, this is a very simple and inefficient solution if you want to provide this website to many users connected all at the same time. But for tests/demo purpose, it is very handy
In debugging mode, I can run django web that can be accessed by public (inside LAN) with:
python manage.py runserver 0.0.0.0:8000
So, is it possible to run it directly on port 80 (maybe with a domain) like normally webserver does? If yes, is it a bad idea? I mean, is it better to use apache with mod_wsgi?
Its possible, but its a really bad idea because the default server that django ships with does not support multiproccessing etc, and is meant solely for development.
As the documentation notes:
Now’s a good time to note: DON’T use this server in anything resembling a production environment. It’s intended only for use while developing. (We’re in the business of making Web frameworks, not Web servers.)
As for the choice of web server, do have a look at the django book to get more ideas around how to go ahead with it.
It is possible. You can do it like this:
python manage.py runserver yourdomain.com:80
Whether it is a bad idea, it may depend on your use case. Generally I would recommend using e.g. apache or nginx for long-term running production environment though. It will surely perform better.
If you are needing to more easily debug an issue specifically when using similar environment to deployment, but still have it run on port 80, then presuming the system Apache is shut down and so not using port 80 at the time, then have a look at mod_wsgi-express.
https://pypi.python.org/pypi/mod_wsgi
For information on better integrating mod_wsgi-express with Django and using it for debugging see:
http://blog.dscpl.com.au/2015/04/introducing-modwsgi-express.html
http://blog.dscpl.com.au/2015/04/using-modwsgi-express-with-django.html
http://blog.dscpl.com.au/2015/04/integrating-modwsgi-express-as-django.html
http://blog.dscpl.com.au/2015/05/using-modwsgi-express-as-development.html
Sound like two questions there.
Is it possible? Yes (see #geckon's answer).
Is it wise to run a debug-friendly lightweight development server in production? : No
But luckily there's plenty of official documentation on running Apache with mod_wsgi, so that shouldn't be too hard.
I am writing a backend web api for a mobile app. It should support HTTPS. Most of my experience in .NET, but for this one I want to use Go/Golang. I have a sample service ready, now I need to make sure that it is production ready.
In .NET I will just use IIS, but I have no clue what would be a good approach for Go.
Should I have nginx as reverse proxy, or I better use FastCGI ? And how to make sure that my go app is up and will run on system reboot ? should I use upstart or something similar ?
I've been using Nginx FastCGI with a Go webservice - they work well together. It's no harder to set up than HTTP reverse proxying - except for having to learn how to do it. The performance ought in principle to be a lot better, but I have no measurements to justify that hunch. My web service can work in both HTTP mode and FastCGI mode (one or other at a time), so I suppose I ought to do some benchmarking (note to self!).
If you want proper system startup (and you should), you need to learn how init scripts work. I sometimes cheat and start with an existing working script someone else wrote for a similar application and customise it to work with mine.
I've used nginx as a reverse proxy for my Go projects. I've found that it's a lot easier to set up useful server settings such as TLS, compression, etc., in nginx rather than as a pure Go server.
Keeping it alive on server reboot is a more complicated question. I would suggest learning how to write a script/whatever for your server's init daemon and just doing it that way.
I've put together a Django app that was intended to run on Pythonanywhere. However, I soon found out that Pythonanywhere's free plan blocks the remote sites which I intend to interact with, so I decided running the app on a local machine would be good enough for my purposes.
Now, I know that Django's development server isn't meant to be run in a production setting. So, what server daemon do I run on the aging Windows workstation the app's probably gonna be deployed to? Apache, lighttpd, Cherokee? Something else?
My first priority here is conserving system resources as much as I can; I'm probably also going to use Python's built-in sqlite3 instead of MySQL.
Personally I deploy Django with fcgi and Nginx. Nginx offers various strategies to conserve system resources; its use as reverse proxy is well documented and widely used.
The question/answer pair here might help you clear some initial questions about the various components when deploying Django.
Sorry to hear you can't use PythonAnywhere's free version :-(
I'll second the usage of nginx; it's what we use as the front-end for PA. However, we use uwsgi for the backend. It works really well for us and is very easy to configure.
Concerning the built in debugging server started with the manage.py runserver command, the Django docs state, "DON’T use this server in anything resembling a production environment."
If I wanted to develop a Django application over ssh on a remote machine, would using Nginx as a proxy to a running Django debug server be a reasonable thing to do? Is the Django debug server insecure, or just not built to handle large amounts of traffic?
From the Django docs:
DO NOT USE THIS SERVER IN A PRODUCTION SETTING. It has not gone through security audits or performance tests. (And that's how it's gonna stay. We're in the business of making Web frameworks, not Web servers, so improving this server to be able to handle a production environment is outside the scope of Django.)
So, that answers the latter two questions. As for the former, it depends on how your debug server is set up. If your server is exposed to the public Internet, doesn't have a firewall blocking port 8000, and you intend to use runserver with something other than the default 127.0.0.1 address, set up a more 'proper' application stack.
If you're going to use nginx, why not just use the suggested FastCGI configuration so that your debug environment will be more similar to the future production environment?
Modern web servers have all sorts of features, related to both security and performance, that the Django development server does not. It is a stripped-down, very basic, single-threaded server for the purposes of development. Hence why the docs say to not use it in a production setting.
However, people get way to afraid of this statement. The key defining point is that it's for development. Whether that development takes place on your local machine or a remote VPS or an entire cluster is besides the point.
If the server is publicly available, it will be open to hacking, breaches, DoS attacks, etc. But, if what's there isn't of any importance, just a development site running on dummy data, it doesn't matter. So, yes, you can use the development server on your remote server for development purposes. There's nothing at all wrong with that. My only caution would be to avoid using production data (such as using a dump from your production database to develop against) because that data could be compromised. Otherwise, it's no big deal.
Is the Django debug server insecure, or just not built to handle large amounts of traffic?
IT IS BOTH INSECURE AND NOT INTENDED FOR HEAVY TRAFFIC!
It might take care of a few of the issues by hiding the testing server behind a proxy, but if you're going to that much trouble you've done about the same amount of work as you need to do it right... right being WSGI. Use mod_wsgi, gunicorn, or check this out for more bleeding-edge solution: http://bartek.im/blog/2012/07/08/simplicity-nginx-uwsgi-deployment.html. Whatever you do.... DON'T USE THE DJANGO TEST SERVER FOR PRODUCTION ENVIRONMENTS!