Deploying Django Web Applications In Docker Containers

This talk will describe how to package a Django web application as a Docker container image for use on a container orchestration platform. Starting with a common Django setup involving Nginx, Gunicorn, and Celery, we will show how to adapt the application to run inside containers.

Container orchestration platforms such as Kubernetes and DC/OS are growing increasingly popular. These systems provide many advantages, but require significant changes to how applications are packaged and deployed. Instead of running on staticly-configured webservers, applications must run in containers that are dynamically deployed to a pool of hosts.

There are further benefits to packaging applications as containers. By providing an easy-to-use and tested base image for Django applications, deployment best-practices are easily and consistently replicated. Integration testing becomes more practical, as containers can be run similarly between development and production environments.

This talk expects some familiarity with Django, as well as the basics of Docker and HTTP. There should be lessons relevant to anybody interested in using Docker for Python-based web applications.

Transcript

1. Deploying Django web applications in Docker containers Jamie Hewland PyConZA 2017
2. SRE at Praekelt.org Hi , I’m Jamie 00 @JayH5 @jayhewland /jhewland
3. We moved to containers because we needed to deploy a lot of sites quickly ...and manually managing Python processes across many servers wasn’t scaling.
5. Specifically, Docker containers to run under a container orchestration system. • What are Docker containers?* • What is container orchestration?* • How is Django typically deployed? • How do I deploy Django in a Docker container? Deploying Django web applications in Docker containers *Very roughly speaking
6. It’s Containers & container orchestration 01
7. Isolation of a process’ view of its operating environment (via namespaces) ⚬ Process trees ⚬ Networking ⚬ User IDs ⚬ Mounted file systems... Limitation/prioritization of resources (via cgroups) ⚬ CPU ⚬ Block I/O ⚬ Memory ⚬ Networking... What’s a (Linux) container?
8. Docker is the most popular container technology. • Batteries included • Easy-to-use, lots of sensible defaults • “Copy-on-write union filesystem”: containers can start up very quickly and share a lot of image data • Images available for all the software you know & love Docker containers
9. > $ docker run python rabbitmq postgres sentry redis debian nginx nodejs ubuntu
10. Docker terminology Docker- file Docker image Docker container docker build docker run ls Dockerfile ls *.dockerfile docker images docker ps file layers on disk running process Terms “image” and “container” often conflated
11. Why containers? Consistent portability • A clean way to package software • With (almost) everything it needs to run • With a single, simple entry-point • Limit access to resources • Eliminates “but it works on my machine”
12. Container orchestration “Container Orchestration refers to the automated arrangement, coordination, and management of software containers.” Container Orchestration with Kubernetes: An Overview - Adrian Chifor http://bit.ly/2takgmd
13. Container orchestration Achieved through a variety of services: • Service discovery • Load balancing • Health checks • Resource management • More...
14. Container orchestration is
15. controller01 controller02 controller03 worker01 worker02 worker03 worker{n} follower follower postgresql01 replica primary rabbitmq01 mirror mirror leader
16. controller01 controller02 controller03 worker01 worker02 worker03 worker{n} follower follower postgresql01 replica primary rabbitmq01 mirror mirror leader Control- plane Pool of workers Stateful services
17. Advantage 1: Deployments Don’t need to choose how/where to run apps worker03 controller03 leader I want to run my container. (P.S. I don’t care how.) Can do! I have the perfect worker in mind! Run this container controller03 leader Working on it! worker03
18. Advantage 2: Failover worker01 worker03 worker02 worker04 worker01 worker03 worker02 worker04 1. worker01 is unhealthy 2. Containers migrated off worker01 Containers get moved off unhealthy worker hosts
19. Advantage 3: Scaling Can scale the number of running containers controller03 leader I thought I wanted 2, but now I want 3 instances! Can do! worker03 Run this container controller03 leader New container started! lb01 I’ll route some requests to that
20. Advantage 4: Resource utilisation Orchestration systems can pack containers efficiently worker03 CPU: 0.5 RAM: 128MB CPU: 0.4 RAM: 512MB CPU: 1.0 RAM: 768MB CPU: 1.9/3.0 RAM: 1.375/2.0GB worker05 CPU: 0.5 RAM: 256MB CPU: 1.0 RAM: 512MB CPU: 1.0 RAM: 768MB CPU: 2.5/3.0 RAM: 1.5/2.0GB CPU: 1.0 RAM: 512MB
21. “Webservers” Deploying Django web applications 02
22. • Open source web framework • Very popular • Roughly model-view-controller (MVC) • Featureful: Caching, i18n, middleware… • Lots of 3rd party extensions
23. Running Django • Django applications typically served using a WSGI server • Web Server Gateway Interface (WSGI): PEP 3333 • Two sides: “server”/“gateway” and “application”/“framework” • Server calls application once per request with data from request
24. • Gunicorn is a WSGI server • Based on Unicorn (Ruby software) • Pre-fork worker model: ◦ One master process spawns one or more worker processes ◦ Master terminates workers if they take too long ◦ Workers = 2-4 x number of cores • Designed to only serve fast clients* *With its default worker implementation
25. How it fits together
26. • Reverse proxy most often used with Gunicorn is Nginx • Very fast and battle-tested: “shields” our Python code from the outside • Can use it to do other useful stuff: ◦ Serve static files (CSS, JS, fonts...) ◦ Caching ◦ Compression, SSL, more...
27. • Django under Gunicorn runs only in response to requests • What about long-running and/or periodic tasks? • Celery: Distributed Task Queue • Integrates with Django • But now we need a message broker
28. Other things needed for Django A database: probably PostgreSQL (Optional) caching: Redis or Memcached
30. ...just chuck it on a server Take all of that and...
31. webserver01 All the things...
32. webserver01 Most of the things... db01 Primary db02 Replica
33. db02 Replica webserver01 Some of the things... db01 Primary amqp01 Primary celery01 Mirror
34. db02 Replica django01 db01 Primary amqp01 Primary celery01 Mirror lb01 From 1 server to 10+ Scaling
35. Containerizing Django 03 Making it fit
36. You’ll never guess what we tried first...
37. ...just chucked it in a container Took most of that and...
38. Do not do this • Docker containers are not mini-VMs • Isolate processes, not services • Good health checks very difficult • No programs to manage multiple processes (no init system) • Container orchestration systems expect containers to be ephemeral
39. What we’ve settled on
40. Configuration • Don’t want to build a Docker image with all the config files inside it ◦ Not flexible, slow reconfiguration ◦ Secrets in Docker image • Difficult to move configuration files around with containers • Solution: Django settings module reads config from environment variables
41. django-environ DATABASE_URL=postgres://user:pass@db01/dbname CACHE_URL=memcache://mem01:11211,mem02:11211 EMAIL_URL=smtp+tls://user:pass@smtp01:465
42. Startup (entrypoint) scripts When the container starts we need to do some things... • Run database migrations • Create a superuser account on first run • Set some default Gunicorn arguments • Switch to a non-root user • More… (but hopefully not)
43. Logging Since containers are ephemeral, so are their log files • Log everything to stdout/stderr • Container orchestrators will collect this • Even more important that only one thing runs in a container • Bonus points: make your logs machine-readable
44. User-uploaded files User-uploaded files in Django can be stored in a “media” directory • Don’t do this (containers or not) • Extra hard if you have to manage networked storage • Use django-storages, store in S3
45. django-bootstrap image (Not to be confused with CSS Bootstrap) • Standardized base image for all our Django deployments • Nginx configuration optimised for Django in a container • Startup scripts for Django & Celery • Thoroughly tested with example app praekeltfoundation/docker-django-bootstrap
46. django-bootstrap Dockerfile
47. Where to from here? 04 Further improvements
48. But you’re still running more than one thing in a container? Django container Nginx Gunicorn
49. Deploying as a pod
50. Configuration secrets • We’re now putting passwords in environment variables • But env vars are quite easy to leak • Container orchestration platforms have tools for storing secret data securely • Dynamic credential management (Hashicorp Vault): credentials only valid as long as the container exists
51. Metrics via nginx-lua-prometheus
52. Metrics via nginx-lua-prometheus • Prometheus can poll container orchestrator to know where to scrape • Get Django-specific metrics from Nginx (e.g. all requests not to /static/) • “Free” metrics for all apps with same base image • But you should properly instrument your Django application...
53. In conclusion 05 Containers are cool, but...
54. Containers/container orchestration can seem complicated... • Persistent storage difficult* • No config files* • No log files* • Can only run one thing per container* • Can’t SSH in* • Distributed system *Roughly speaking
55. ...but they have some big advantages • Easy deployments • Easy scaling • Efficient resource usage • Generally increased automation • Consistently packaged apps
56. Containers for Django A common base image can provide... • Tested and optimised server (Nginx) config • Encapsulate best practices for containers & container orchestration platform • Consistent platform for deploying apps • Potential for adding new features
57. Questions? praekeltfoundation/docker-django-bootstrap
58. Thank you. Special thanks to Jeremy Thurgood (@jerith) for reviewing my code. Go see his talk later!
59. Complication 1: Persistent storage Moving data is harder than moving a container 1. The container needs to be moved 2. But its data needs to move with it worker01 Container Data volume worker02 Container ??? worker01 Container Data volume
60. Complication 2: Networking Things move around and thus have weird addresses worker03 10.25.0.3:10237 cake-service container I need to speak to soda-service Use soda-service .marathon.l4lb .thisdcos .directory worker03 10.25.0.3:10237 cake-service container worker13 10.25.0.13:11487 soda-service container iptables (or something)
61. Complication 3: Debugging It’s hard to just “SSH into” a container ssh -t public01 ssh worker42 worker42 docker ps | grep cake-service 1. Find which worker the container is on 2. SSH into the worker 3. Find the container ID 4. Run Bash in the container docker exec -it 981681d291ab bash root@981681d291ab:~# curl controller01:8080/v2/apps ...