1. Deployment Architecture

The program processing flow when a browser visits a page:

(1) The browser sends a request to Nginx. If it matches a static URL on the Nginx side, for example files such as js, css, or 404.html under the /static directory, Nginx returns the file directly. Other request URLs are forwarded to uWSGI for processing via the uwsgi_pass configuration.

(2) uWSGI parses the request headers and request body, converts the http protocol into wsgi protocol content, and finally forwards the request to Django.

(3) Through URL matching, Django finds the specified View function, accesses services such as MySQL and Redis, and assembles a Response to return to uWSGI.

(4) uWSGI generates the response headers and response body from the returned Response, converts the uWSGI protocol into http protocol content, and finally forwards the request to Nginx.

(5) The browser renders the content returned by Nginx on the page and presents it to the user.

It should be noted that Nginx, as a reverse proxy, provides load balancing capability, and at the same time, thanks to Nginx’s excellent static file serving capability, it improves the concurrency of the system. uWSGI improves Django’s concurrency through multiple workers, fully leveraging the advantages of multiple cores.

The system deployment structure diagram is as follows:

Docker Compose provides the ability to assemble multi-container applications, and can assemble multiple individual containers into a single whole. The containers needed here are:

• One Nginx container
• One uWSGI + Django container
• One MySQL container
• One Redis container
• One RabbitMQ container

2. The File Organization Structure

The entire project is divided into six parts

• django-devops-mysql builds the MySQL image
• django-devops-nginx builds the Nginx image
• django-devops-rabbitmq builds the RabbitMQ image
• django-devops-redis builds the Redis image
• django-devops-uwsgi builds the uWSGI and Django image
• django-devops-compose orchestrates the five images above, mounts directories, and provides configuration files, logs, code management, the runtime environment, and so on.

The image-building directories mainly need a Dockerfile. In the django-devops-compose directory

• The www/app directory holds the Django code
• The www/conf directory holds configuration information for containers such as MySQL and uWSGI
• The www/env directory holds the Python virtual runtime environment created by virtualenv
• The www/log directory holds the various logs
• docker-compose.yml holds the container orchestration information

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

├── django-devops-compose
│   ├── docker-compose.yml
│   ├── README.md
│   ├── reset_data.sh
│   ├── reset_docker.sh
│   └── www
│       ├── app
│       │   ├── books_cbv
│       │   ├── books_fbv
│       │   ├── books_fbv_user
│       │   ├── __init__.py
│       │   ├── manage.py
│       │   ├── README.md
│       │   ├── requirements.txt
│       │   ├── settings.py
│       │   ├── static
│       │   ├── urls.py
│       │   ├── views.py
│       │   ├── wsgi.py
│       ├── conf
│       │   ├── env
│       │   ├── my.cnf
│       │   ├── nginx.conf
│       │   ├── uwsgi.ini
│       │   ├── uwsgi.params
│       │   └── uwsgi.sock
│       ├── env
│       │   ├── bin
│       │   ├── include
│       │   ├── lib
│       │   ├── lib64 -> lib
│       │   └── pip-selfcheck.json
│       ├── log
│       │   ├── mysql
│       │   ├── nginx
│       │   └── uwsgi
│       └── mysql
├── django-devops-mysql
│   ├── Dockerfile
│   ├── mysql.repo
│   └── start.sh
├── django-devops-nginx
│   ├── Dockerfile
│   └── nginx.repo
├── django-devops-rabbitmq
│   └── Dockerfile
├── django-devops-redis
│   └── Dockerfile
└── django-devops-uwsgi
    ├── Dockerfile
    └── start.sh