Incorporating Nginx. At this point, you’ve swapped out Django’s
runserver command in favor of
gunicorn as the application server. There’s one more player to add to the request chain: a web server such as Nginx.
00:17 Now, you may be thinking you’ve already added Gunicorn! Why do you need to add something new into the picture? The reason for this is that Nginx and Gunicorn are two different things, and they coexist and work as a team.
00:30 Nginx defines itself as a high-performance web server and a reverse proxy server. It’s worth breaking this down because it helps explain Nginx’s relationship to Gunicorn and Django. Firstly, Nginx is a web server in that it can serve files to a web user or client.
00:49 Files are literal documents: HTML, CSS, PNG, PDF—you name it. In the old days, before the advent of frameworks such as Django, it was common for a website to function essentially as a direct view into a file system. In the URL path, slashes represented directories on a limited part of the server’s file system that you could request to view.
01:14 Note the difference in terminology. Django is a web framework. It lets you build the core web application that powers the actual content on the site. It handles HTML rendering, authentication, administration, and back-end logic. Gunicorn is an application server.
01:31 It translates HTTP requests into something that Python can understand. Gunicorn implements the Web Server Gateway Interface (WSGI), which is a standard interface between web server software and web applications.
01:55 Part of Nginx’s role as a web server is that it can more efficiently serve static files. This means that in the case of requests for static content such as images, you can cut out the middleman that is Django and have Nginx render the files directly. You’ll look at this step later on in the course.
02:13 Nginx is also a reverse proxy server in that it stands between the outside world and the Gunicorn/Django application. In the same way that you might use a proxy to make outbound requests, you can use a proxy such as Nginx to receive them. On-screen, you can see how this request chain works in practice.
02:34 To get started using Nginx, first you’ll need to install it, and you can verify its version. Note that the version seen here was the latest one available on the AWS VM at the time of the course being recorded.
04:31 At this point, you have the following setup: Nginx is listening on port 80. Gunicorn is listening separately, on port 8000. But there’s no connection or tie between the two until you specify it.
04:55 You haven’t yet set it up to proxy requests to Gunicorn and Django. You need to give Nginx some bare-bones configuration to tell it to route requests to Gunicorn, which will then feed them to Django.
proxy_set_header field is important. It ensures that Nginx passes through the
Host HTTP request header sent by the end user onto Gunicorn and Django. Nginx would otherwise use
Host: localhost by default, ignoring the
Host header field sent by the end user’s browser.
Now that Nginx is sitting in front of Gunicorn and Django, there’s a couple of points to note here. Firstly, Nginx now returns the
Server header as
Server: nginx, indicating that Nginx is the new front-end web server. Setting
off tells Nginx not to report its exact version. From a security perspective, that would be disclosing unnecessary information. Secondly, Nginx used
chunked for the
Transfer-Encoding header instead of advertising
Become a Member to join the conversation.