Replacing WSGIServer With Gunicorn

00:00 Replacing WSGIServer With Gunicorn. Do you want to start moving your app towards a state where it’s ready for the outside world? If so, then you should replace Django’s built-in WSGIServer, the application server used by manage.py, with a separate dedicated application server. But wait a minute: WSGIServer seem to be working just fine. Why replace it?

00:22 To answer this question, have a look at the Django documentation, which is seen on-screen. Django is a web framework and not a web server, and its maintainers want to make that distinction clear.

00:37 In this section, you’ll replace Django’s runserver command with Gunicorn. It’s first and foremost a Python WSGI app server, and a battle-tested one of that. It’s fast, optimized, and designed for production.

00:51 It gives you more fine-grained control over the application server itself. It has more complete and configurable logging. And it’s well-tested, specifically for its functionality as an application server.

01:05 You can install Gunicorn through pip into the virtual environment, as seen on-screen. First, cd returns back to the user’s home directory, and a check that the correct virtual environment is still active is made. If it isn’t, used deactivate and then the appropriate command to reactivate the correct virtual environment.

01:25 Finally, pip is used to install Gunicorn.

01:36 Next, you’ll need to do some configuration. The great thing about a Gunicorn config file is that it just needs to be valid Python code, with variable names corresponding to arguments.

01:47 You can store multiple Gunicorn configuration files within a project subdirectory. Having created the appropriate directories, open the configuration file

02:04 and add the following. The comments included in this file should explain what each of the options are doing. This is a development-suitable configuration, particularly as it will automatically restart the workers when files are changed, allowing updates to the site to be made quickly. Then,

03:40 before starting Gunicorn, you should halt the runserver process. Use jobs to find it and kill to stop it. Next, make sure that log and PID directories exist for the values set in the Gunicorn configuration file previously seen.

04:05 With these commands, you’ve ensured that the necessary PID and log directories exist for Gunicorn and they are writeable by the ubuntu user.

04:17 With all of that out of the way, you can finally start Gunicorn using the -c flag to point to a configuration file from the project root.

04:37 This runs Gunicorn in the background with the development configuration file dev.py that you specified previously. Just as before, you can now monitor the output file to see the output logged by Gunicorn.

04:55 Now visit the site’s URL again in the browser. You’ll still need the 8000 port, as seen on-screen.

05:09 Check the VM terminal again, and you should see one or more lines from Gunicorn’s log file. These are access logs that tell you about incoming requests, and their meaning is shown on-screen. Excluded for brevity, the last entry on each line is typically the user agent, which may be lengthy.

05:30 Here’s an example from Firefox on macOS. With Gunicorn up and listening, the next piece of the puzzle is to introduce a web server into the equation, and that’s what you’ll be doing in the next part of the course.