Shulou(Shulou.com)06/02 Report--

With the popularity and maturity of Docker, it has gradually become the first choice for deployment projects. Today, let's share with you how to use docker to deploy django technology stack projects.

The Django technology stacks we are talking about here are: python3.6, Django2.2, redis, mysql, celery, gunicorn and nginx. In an actual production project, these components are distributed among different machines in the cluster, such as Nginx, redis, and Mysql, which may be responsible for by separate teams or departments. The deployment architecture and container choreography involved will be more complex, which will not be delved into in this article. This article focuses on how to orchestrate these components using docker-compose, which is suitable for the deployment of a test environment or your personal sideproject deployment.

By default in this article, you already know some basic knowledge of docker and docker-compose. If you don't, you can read the following materials:

Docker knowledge Daquan Docker official document Docker Compose document

Let's talk about how to deploy.

Project organization structure

First of all, take a look at our project organization structure, which is as follows:

├── LICENSE ├── README.md ├── compose │ ├── celery │ │ ├── Dockerfile │ │ ├── celery-beat.sh │ │ └── celery.sh │ ├── mysql │ │ └── my.cnf nginx nginx.conf web Dockerfile entrypoint.sh gunicorn.conf gunicorn .sh ├── docker-compose.yml ├── docker_django_demo │ ├── _ _ init__.py │ ├── celery.py │ ├── settings.py │ ├── urls.py │ └── wsgi.py ├── env.tpl ├── manage.py ├── requirements.txt

In addition to the project files of Django, the directory of compose configuration files and docker-compose.yml configuration files are mainly added.

The compose directory mainly stores the dockerfile files and startup scripts of each component. Docker-compose.yml is the orchestration configuration file for docker-compose.

Write Dockerfile and start initialization script

In docker-compose, there are two ways to start a container, one is to start the container directly using a public image, and the other is through our own Dockerfile. Because we are installing additional toolkits and initializing related configurations, we use a custom Dockerfile approach for web and celery components.

Compose/web/Dockerfile of the web container:

FROM python:3.6ENV PYTHONUNBUFFERED 1RUN mkdir / codeWORKDIR / codeCOPY. / requirements.txt / code/RUN pip install-- no-cache-dir-r requirements.txt\ & & rm-rf requirements.txtCOPY. / code/COPY. / compose/web/*.sh / code/RUN sed-I's /\ r entrypoint.shENTRYPOINT 'gunicorn.sh\ & & chmod + x gunicorn.sh\ & & sed-I's /\ r entrypoint.shENTRYPOINT\ & & chmod + x entrypoint.shENTRYPOINT ["/ bin/bash", "entrypoint.sh"]

Other files for the web container:

The startup script for the compose/web/entrypoint.sh web container that performs some initialization or detection logic. Compose/web/gunicorn.conf gunicorn configuration file. Startup script for compose/web/gunicorn.sh gunicorn.

Dockerfile of celery:

FROM python:3.6ENV PYTHONUNBUFFERED 1RUN mkdir / codeWORKDIR / codeCOPY. / requirements.txt / code/COPY. / compose/celery/*.sh / code/RUN pip install-no-cache-dir-r requirements.txt\ & & rm-rf requirements.txt & & sh init_env.shCOPY. / code/COPY. / compose/celery/*.sh / code/RUN sed-I's /\ r celery-beat.sh celery-beat.sh 'celery.sh\ & & chmod + x celery.sh\ & & sed-I's /\ r celery-beat.sh

Other files for celery:

Startup script for compose/celery/celery.sh celery. Startup script for compose/celery/celery-beat.sh celery-beat.

Write Compose startup configuration file

The docker-compose configuration is as follows:

Version: '2'services: redis: image: redis ports:-"6379image 6379" db: restart: always image: mysql:5.7.19 # command:-- character-set-server=utf8mb4-- collation-server=utf8mb4_unicode_ci volumes: -. / compose/mysql/:/etc/mysql/conf.d -. / db:/var/lib/mysql # for test ports:-"127.0.0.1Vera 3307image 3306" # (HOST:CONTAINER) env_file:-.env web: # restart: always build: context:. Dockerfile:. / compose/web/Dockerfile command: sh gunicorn.sh # ["/ bin/bash" "gunicorn.sh"] ports:-"8080 logs:/var/logs/ 8002" # (HOST:CONTAINER) volumes: -. / logs:/var/logs/ -. / collect_static:/code/collect_static -. / static:/code/static -. / templates:/code/templates -. / uploads:/code/uploads env_file: .env depends_on:-redis-db nginx: restart: always image: nginx : 1.13.0 volumes: -. / compose/nginx:/etc/nginx/conf.d/ -. / staticfiles:/code/staticfiles -. / logs:/var/log/nginx ports:-"80:80" # (HOST:CONTAINER) depends_on:-web celery: build: context:. Dockerfile:. / compose/celery/Dockerfile command: sh celery.sh volumes: -. / logs:/var/logs/ -. / uploads:/code/uploads depends_on:-redis-db env_file: .env celery-beat: build: context:. Dockerfile:. / compose/celery/Dockerfile command: sh celery-beat.sh volumes: -. / logs:/var/logs/ depends_on:-redis-db env_file: .env

Worker and beat of celery. Here we use the same image Dockerfile. According to the principle of one image and one process, start two containers to run the worker and beat processes respectively.

Compilation test

After writing the configuration file, compile the mirror test run:

Docker-compose build docker-compose up # can be run in the background after running docker-compose up-d # in the foreground.

Docker-compose ps can see the launched container:

$docker-compose ps Name Command State Ports- -dockerdjangodemo_celery-beat_1 sh celery-beat.sh Up dockerdjangodemo_celery_1 sh celery.sh Up dockerdjangodemo_db_1 docker-entrypoint.sh mysqld Up 127.0.0.1 dockerdjangodemo_celery-beat_1 sh celery-beat.sh Up dockerdjangodemo_celery_1 sh celery.sh Up dockerdjangodemo_db_1 docker-entrypoint.sh mysqld Up 3307-> 3306/tcpdockerdjangodemo_nginx_1 nginx-g daemon off Up 0.0.0.0 80-> 80/tcp dockerdjangodemo_redis_1 docker-entrypoint.sh redis... Up 0.0.0.0 bin/bash entrypoint.sh sh 6379-> 6379/tcp dockerdjangodemo_web_1 / bin/bash entrypoint.sh sh. Up 0.0.0.0 8080-> 8002/tcp

The mapped port can be adjusted according to its own actual situation.

problem

Here are a few issues to pay attention to during the build process.

Mysql coding problem

The mysql image provided by docker is encoded as latin1 by default, and garbled codes will be displayed when saving Chinese characters. Officials have provided a way to modify the encoding by specifying the encoding format after starting the script, which can be found here. Mysql container version 5.7.19 can directly follow the parameter-- character-set-server=utf8mb4-- collation-server=utf8mb4_general_ci after command in docker-compose.yml. In this way, you only modify the encoding on the server side. All encoding formats can be specified directly using configuration file overrides.

The configuration is as follows:

[mysqld] default-storage-engine=INNODBcharacter-set-server=utf8mb4collation-server=utf8mb4_general_ciinit-connect='SET NAMES utf8mb4'init_connect='SET collation_connection = utf8mb4_general_ci'skip-character-set-client-handshake # Skip the client's encoding configuration, and the client directly uses the server's encoding configuration bind-address = 0.0.0.0

Note: mysql 5.7.19 configuration file was successful, 5.7.4 and 5.7.17 failed, which can be used as a reference.

Web, wait for mysql to start before continuing.

The mysql container cannot accept database links before startup. During web startup initialization, if the database is not started properly, it will cause the web container to fail to start and exit directly. We can add a test script when the web container starts, and then continue after the database is connected.

The script is as follows:

#! / usr/bin/env bashset-o errexitset-o pipefailecho $MYSQL_PASSWORDecho $MYSQL_DATABASEecho $MYSQL_HOSTecho $MYSQL_USERecho $MYSQL_PORTfunction mysql_ready () {python & 2 echo "MySQL is unavailable-sleeping" sleep 1done > & 2 echo "MySQL is up-continuing..."

Summary

At this point, use docker to deploy the django technology stack service is complete, the complete project code, you can see docker-django-demo.

The article begins to say that this deployment method is not suitable for online production services of large websites, and there are many problems, such as high degree of coupling, difficult maintenance and so on. However, deploying your own sideproject or test environment is very good with limited hardware resources. In addition to reducing the hassle of deploying and building the environment, it is also very convenient to migrate.

In the demo project, there are also some cases of how to use docker in the development environment, but I have always thought that docker is more suitable for deployment, and it is not as flexible and convenient as building it directly in the development environment. You are welcome to leave a message and discuss the experience of using docker in development and deployment.

Referenc

Cookiecutter-django

The above is the whole content of this article, I hope it will be helpful to your study, and I also hope that you will support it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.