We Keep Coding

How does gunicorn deploy django better?

I am using nginx with gunicorn and django. I would like to know
Question: What are the benefits using gunicorn compared to just using django's runserver alone

https://docs.djangoproject.com/en/2.2/ref/django-admin/#runserver
django-admin runserver [addrport]
Starts a lightweight development Web server on the local machine.
...
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.)
Also Gunicorn can create multiple workers listening to the same socket which makes the web-app serve HTTP requests in parallel.

Understanding each component of a web application architecture

Here is a scenario for a system where I am trying to understand what is what:
I'm Joe, a novice programmer and I'm broke. I've got a Flask app and one physical machine. Since I'm broke, I cannot afford another machine for each piece of my system, thus the web server, application and database all live on my one machine.
I've never deployed an app before, but I know that a server can refer to a machine or software. From here on, lets call the physical machine the Rack. I've loaded an instance of MongoDB on my machine and I know that is the Database Server. In order to handle API requests, I need something on the rack that will handle HTTP/S requests, so I install and run an instance of NGINX on it and I know that this is the Web Server. However, my web server doesnt know how to run the app, so I do some research and learn about WSGI and come to find out I need another component. So I install and run an instance of Gunicorn and I know that this is the WSGI Server.
At this point I have a rack that is home to a web server to handle API calls (really just acts as a reverse proxy and pushes requests to the WSGI server), a WSGI server that serves up dynamic content from my app and a database server that stores client information used by the app.
I think I've got my head on straight, then my friend asks "Where is your Application Server?"
Is there an application server is this configuration? Do I need one?

Any basic server architecture has three layers. On one end is the web server, which fulfills requests from clients. The other end is the database server, where the data resides.
In between these two is the application server. It consists of the business logic required to interact with the web server to receive the request, and then with the database server to perform operations.
In your configuration, the WSGI serve/Flask app is the application server.
Most application servers can double up as web servers.

Should you deploy django with wsgi?

Do you need to deploy django with wsgi? I am running Django on a Docker instance and it seems like often the recommended solution is just to use Django's development server, i.e. the command python manage.py runserver. When exactly is a web server such as wsgi needed -- and in this instance, in a containerized application, is the django development server enough for production applications?

You answer your own question:
is the django development server enough for production applications ?
In the django documentation, you can read the following:
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.)
And also this part:
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 no. Don't use the Django development server in production. Security risks, poor performances, etc.

The development server is never recommended as an option for production server. It has a number of security and performance issues.
The solution which is working well for us is Gunicorn behind an Nginx reverse proxy (so that multiple people can connect smoothly.)
The method mentioned in this tutorial is a good beginners guide to a Ubuntu setup with nginx and gunicorn. When bringing docker into the mix use this tutorial.

You can use Django Channels to deploy in production without using WSGI.
You can set things up in one of two ways; either route all traffic through a HTTP/WebSocket interface server, removing the need to run a WSGI server at all; or, just route WebSockets and long-poll HTTP connections to the interface server, and leave other pages served by a standard WSGI server.

What type of server Django runserver uses?

What type of server Django uses when "runserver" command is ran? Documentation says more or less that it's "lightweight development Web server". Is it for example Apache? Thanks in advance.

It's exactly what it says on the tin - a simple, lightweight web server implemented in Python that ships with Django and is intended for development purposes only. It's not a free-standing web server in its own right and is intended purely for developing applications with Django - you should never use it in production because it simply doesn't offer all the functionality you need in a production web server.
A web server can be implemented in virtually any programming language, and so it makes sense to ship one implemented in Python with Django in order that you can get working with it immediately without having to install something like Apache as well. Most web servers that might be used in production, such as Apache and Nginx, are written in C so it wouldn't really be practical to ship them with Django.
Also, shipping your own development server cuts down on complexity. Apache and Nginx are both complex pieces of software that require a fair amount of configuration, and while there are ways to automate that during development, it's not something you really want to have to deal with when you'd rather be writing code. All you need to get you started is something that will serve static and dynamic content - you don't need a lot of the other functionality required. It's notable that even PHP now ships with a development server.
When you go live with a Django project, you should use of course use a proper web server. It's generally recommended that with Django, in production you should use two web servers, one to serve static content, the other to serve dynamic content, because involving Django in serving static content will slow it down. This sounds odd at first, but it actually makes a lot of sense, because what you do is set one web server to serve all the static content, then have it reverse proxy to the other server, which is running on a non-standard port, and serves all the dynamic content. The setup I have for my current project is Nginx for the static content, with Gunicorn for the dynamic content.

What is the correct way to leave a Django server running on an EC2 instance?

I'm currently using screen and doing
sudo python manage.py runserver 0.0.0.0:80
Then closing the terminal. Seems like a bit of a hack. What is the correct way to do it?

runserver is a development server. You shouldn't use it in production, as explained at https://docs.djangoproject.com/en/1.4/ref/django-admin/#runserver-port-or-address-port where it says:
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.)
You should use one of the methods given in https://docs.djangoproject.com/en/1.4/howto/deployment/ for deploying a Django project in production. I have used mod_wsgi with Apache, gunicorn with nginx - the precise solution is up to you and the requirements of your project, but the deployment section of the Django manual goes through various options.

This really isn't a good idea; the built in development server shouldn't be used outside of your local development machine. Look at the 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.)
Instead you should set up nginx+gunicorn/uwsgi or just apache+mod_wsgi.
If you ec2 instance is totally blocked from all possible communication from the outside world (which is unlikely) you can use the screen command