Over the weekend, some students in a technical group asked about Django development and deployment, so today I would like to share with you the Python Django framework deployment based on Docker.

First of all, there are two common ways to deploy Django:

  1. Django + Nginx + uWSGI

  2. Django+ Nginx + Gunicorn

Due to space constraints, today we will focus on the first deployment method of uWSGI with Nginx.

First of all, we need to know the steps of our release online. Here we use Docker container as an example:

1. Use automated scripts to synchronize code to online servers (via Fabric or Ansible, etc.) 2. It is a process management tool that handles Django server launches via uWSGI. Docker-compose update docker image for docker-compose update docker image for docker-compose update docker image for docker-compose update docker image for docker-compose update Table Migrate if the table has changed (if it is a relational database). Restart the Docker container with docker-compose

As long as the corresponding configuration files (nginx, uWSGI, Supervisor, etc.) are configured for the above 5 steps, we can publish code with one click through a release script.

Nginx, Supervisor, uWSGI, Docker-compose and other configuration files and their usage are briefly described below.

Nginx

Nginx is a high-performance HTTP and reverse proxy server.

To deploy the service, we need to configure the corresponding configuration file first.

Place the configuration file under /etc/nginx/sites-enabled/, where you can also place it in the project and link it to ln.

/etc/nginx/nginx.conf is the include /etc/nginx/sites-enabled/ directory.

Here we name the configuration file api.yourdomain.com.conf as follows

# api.yourdomain.com.conf

server {

    listen 80;

    charset utf-8;

    server_name api.yourdomain.com;  DNS resolves to the current Nginx serverLocation / {proxy_pass http://127.0.0.1:9527;The port of the proxy
        proxy_pass_header Server;
        proxy_set_header  Host $host;
        proxy_set_header  X-Real-IP $remote_addr;
        proxy_set_header  X-Scheme $scheme;

    }

    access_log /test/log/nginx.access.log;

    error_log /test/log/nginx.error.log;

}
Copy the code

uWSGI

With nginx configured, it’s time to configure uWSGI. UWSGI is a Web server that implements WSGI, uWSGI, HTTP, and other protocols.

UWSGI and Gunicorn are both servers that implement the WSGI Server protocol.

With uWSGI we can get better service performance, detailed logging, multiple application management and many more customization features. Let’s take a quick look at the configuration file.

# /yourdir/uwsgi.ini 

[uwsgi]

chdir     = /yourdir/  # execute directory
module    = yourproject.wsgi # wsgi file
master    = true
processes = 1  In general, the more processes, the more processing power, since here is set to 1 test
vacuum    = trueHTTP = 0.0.0.0:9527# virtualenv = /home/test/project/python/yourproject/venvEnv = DJANGO_SETTINGS_MODULE= YourProject. Settings harakiri = 30Destroy a process when it is stuck for more than a certain number of seconds

no-orphans  # Automatically terminate a worker process without the main process.
Copy the code

In order to facilitate the display and interpretation, I have deleted and simplified some configurations. The specific online configuration is more complicated. Please configure the specific situation.

UWSGI is a language-independent server. You can deploy Django, Flask, Web2py, etc. You can equate this with the Python manage.py runserver command, distinguishing it in a test environment from an online one.

Supervisor

Our supervisor is a configuration file for Linux. It is a configuration file for Linux. Our supervisor is a configuration file for Linux.

[supervisord]

nodaemon=true

logfile=/data/log/supervisord.log
pidfile=/var/run/supervisord.pid

[program:your_app_name]

process_name=app%(process_num)s

command=uwsgi -i /yourdir/uwsgi.ini --touch-reload=/yourdir/uwsgi.ini directory=/yourdir ; Change the working directory user=sitin; Use sitin tostart the process stopSignal =HUP autostart =true
autorestart=true   ; Automatic restart redirect_stderr =true   ; Redirection log stdout_logfile = /data/log/stdout-%(program_name)s.log logfile_maxbytes=300MB logfile_backups=5 numprocs=3  ; 9527, 9528, 9529 numprocs_start=9527; Since 9527Copy the code

The Supervisor controls the uWSGI service to start the service. We can perform operations such as start, restart, and stop.

Docker-compose

Docker-compose is composed for container orchestration, which is convenient for container management. We configure the above documents, and then look at docker – compose a configuration file, here I am docker articles to share before the same, reference docker container deployment practices docker compose

version: "3"  Note the version number

services:  An application container can contain multiple instances of the same mirror container

  dev:
    image: hub.yourdomain.com/test: 1.0# mirror address
    command: supervisord -c /yourdir/supervisord.conf #  Container execution command
    container_name: test   # container name
    restart: always  
    volumes:
      - ./docker:/data  #  Mount the address

    ports:
      - "9527:9527"  # port environment: - PYTHONPATH=/data - XXX_API_SETTINGS=XXX.config.dev - DJANGO_SETTINGS_MODULE=yourproject.settings network_mode: bridge extra_hosts:Configure an additional host name

      - "Test.yourdomain.com: 127.0.0.1"
    external_links: # link to external containers
      - redis:redis 
      - mysql:mysql
Copy the code

There must be some students here have been a little dizzy, let’s try to rationalize the logic here.

  1. We control supervisor startup through the Docker-compose configuration file

  2. The Supervisor controls the startup of uWSGI port services

  3. UWSGI pulls the entire Django application together (similar here to Python manage.py runserver)

  4. Our browser requests arrive at Nginx and are reverse-proxy to the uWSGI port service to access our Django application.

  5. This is the deployment configuration of the entire application (except that there are no automated release scripts)

The last

With the above configuration file, we’ve covered the main steps involved in the whole Django application publishing process, but it’s a little more complicated. More detailed optimization parameters we can go to understand. That’s all for today’s uWSGI deployment, and next time we’ll share the Gunicorn deployment.

Today is the fourth installment of Docker Deploying Django applications. Later, I will continue to share more related content, from the introduction of container deployment to deployment practice layout technology. Welcome to continue to pay attention to.

Scan code to join for free

Related articles:

Docker container Deployment Practices — Getting started

Docker Docker swarm Docker Docker swarm

Docker container deployment practice Dockerfile

Linux series pit remember (1)- common 3 commands