Incorporating Nginx

00:00 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:44 Nginx is a web server. It’s the public handler, more formally called the reverse proxy, for incoming requests and scales to thousands of simultaneous connections.

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.

03:05 Next, you should change the inbound-allow rules that you set for port 8000 to port 80. Replace the inbound rule for TCP:8000 with the one seen on-screen.

03:16 Other rules, such as that for SSH access, should remain unchanged. Next, start the nginx service and confirm that it’s running.

03:37 Hitting Q will take you back to the terminal prompt. Now you can make a request of a familiar-looking URL.

03:51 That’s a big difference compared to what you had previously. You no longer need to add port 8000 in the URL, because the default of port 80 will be used instead.

04:00 You should see the Nginx welcome page, as seen on-screen. If you start Nginx with no configuration, it shows you this page to show that it’s successfully installed and running.

04:12 Now add /myapp to the end of the URL.

04:19 You should see a 404 response, and that’s okay. This is because you’re requesting the /myapp path over port 80, which is where Nginx, rather than Gunicorn, is listening.

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:46 Nginx doesn’t know that Gunicorn and Django have some HTML that they want the world to see. That’s why it returns a 404 Not Found response.

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.

05:09 Edit the file in the path seen on-screen, but remembering to add your own domain name instead of the one seen.

05:26 As you’re entering the contents of this file, make sure to replace deploydjango with your own domain name. This file is the Hello, World of Nginx reverse proxy configuration.

05:37 It tells Nginx how to behave: Listen on port 80 for requests to deploydjango.site and its subdomains and pass those requests on to http://localhost:8000, which is where Gunicorn is listening.

05:54 The 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.

06:17 You can validate your configuration file using nginx configtest.

06:30 This output indicates the configuration file is valid and can be pared. Now, restart Nginx to begin using the new configuration.

06:45 And now that Nginx is being used as a web server front end, you can resend a request to the site.

06:57 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 server_tokens to 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 Content-Length.

07:32 Now that you have Nginx up and running, in the next section of the course, you’ll leverage another one of its core features: the ability to serve static files quickly and efficiently.