Test-Driven Development with Python, 3rd Edition

Chapter 10. Making Our App Production-Ready

Our container is working fine but it’s not production-ready. Let’s try to get it there, using the tests to keep us safe.

In a way we’re applying the red/green/refactor cycle to our productionisation process. Our hacky container config got us to green, and now we’re going to refactor, working incrementally (just as we would while coding), trying to move from working state to working state, and using the FTs to detect any regressions.

What We Need to Do

What’s wrong with our hacky container image? A few things: first, we need to host our app on the “normal” port 80 so that people can access it using a regular URL.

Perhaps more importantly, we shouldn’t use the Django dev server for production; it’s not designed for real-life workloads. Instead, we’ll use the popular Gunicorn Python WSGI HTTP server.

Note

Django’s runserver is built and optimised for local development and debugging. It’s designed to handle one user at a time; it handles automatic reloading upon saving of the source code, but it isn’t optimised for performance, nor has it been hardened against security vulnerabilities.

In addition, several options in settings.py are currently unacceptable. DEBUG=True is strongly discouraged for production, we’ll want to set a unique SECRET_KEY and, as we’ll see, other things will come up.

Warning

DEBUG=True is considered a security risk, because the Django debug page will display sensitive information like the values of variables, and ...