一、前言
在上章内容中，简单介绍了使用docker部署项目的优势以及如何在Linux环境下安装docker，本章内容将主要讲解如何构建容器来部署项目。
二、Docker的组成
镜像： 一个只读模板，其中配置了容器运行所需要的环境数据
容器： 使用镜像创建的实例，可以简单理解为是一个虚拟机，要注意的是容器与容器之间是相互隔离的，容器与外界操作环境之间也是相互隔离的
仓库： 类似Nginx、Mysql这样的常用组件，如果我们每次部署项目时都得自己编写镜像配置文件来构建镜像，那不是很麻烦？所以早有人将这些常用组件镜像上传至公共的远程仓库中，我们只要拉取就行，当然我们也可以上传自己的镜像到仓库中，是不是感觉和Github很类似！目前docker默认的公共仓库是docker官方维护的Dockerhub。
上述镜像和容器的关系，我们可以简单的理解为：镜像是一个对象类型，容器是这个对象类型的实例。
三、构建Django的容器
在上章内容中我们提到过，如果项目由多个组件组成，我们最好是为每个组件都构建一个容器，使其能单独运行，方便复用。此处我们需要部署的项目由Django+Nginx+Mysql三个组件组成，我们需要为这三个组件分别单独构建一个容器。首先是为Django构建容器。
构建镜像
我们先创建一个Django项目，这个项目我们就暂时命名为room，我们在其中创建一个叫做deployment（可以随意命名）的文件夹，用于存放我们部署使用的配置文件，因为我们一般开始时会区分测试与正式环境，所以我们再在deployment文件夹下创建一个dev文件夹，用于存放测试环境下的部署配置文件，项目的最终目录结构如下：
｜—— room
｜ ｜——deployment # 存放部署使用的配置文件
｜ ｜ ｜——dev # 存放部署测试环境使用的配置文件
｜ ｜ ｜ ｜——app # django相关
｜ ｜ ｜ ｜ ｜——Dockerfile # django项目的镜像配置文件
｜ ｜ ｜ ｜ ｜——startapp.sh # 启动django项目的脚本文件
｜ ｜ ｜ ｜——gunicron # gunicorn相关
｜ ｜ ｜ ｜ ｜——gunicorn.conf.py # gunicorn的配置文件
｜ ｜ ｜ ｜——nginx # nginx相关
｜ ｜ ｜ ｜ ｜——nginx.conf # nginx的配置文件
｜ ｜ ｜ ｜——docker-compose.yml # 容器的配置文件
｜ ｜ ｜——wait-for-it.sh # 控制服务顺序执行的脚本文件
｜ ｜——room
｜ ｜——static
｜ ｜——templates
｜ ｜——manage.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
可以看到，目录结构中存在两个sh文件，这两个sh文件的作用如下：
startapp.sh: 编写了启动Django项目的命令行，因为运行项目时需要执行多条命令，我们将这些命令都写入一个shell脚本中，我们后面会通过执行这个sh文件来运行项目
wait-for-it.sh: 有些服务启动需要一定的时间，而其他服务需要等这些服务启动完成后才能执行，此文件的作用就是确保服务可以按顺序启动
编写Django项目的镜像配置文件
我们在项目中的Dockerfile的文件中写入如下内容：
# 从仓库拉取带有python3.8的Linux环境
FROM python:3.8
# 镜像维护者的姓名和邮箱地址
MAINTAINER albertlii <albertlii@163.com>
# 因为墙的关系，有时安装库可能会很慢或者失败，所以推荐使用国内镜像源
# 此处是创建一个指向阿里云镜像源的参数，以便后面引用
ARG pip_url=http://mirrors.aliyun.com/pypi/simple/
ARG pip_host=mirrors.aliyun.com
# 定义一个变量，其值为项目在docker容器中的工作目录
ARG work_home=/room
# 设置python环境变量
ENV PYTHONUNBUFFERED 1
# 容器默认的时间是UTC时间，此处设置为上海时间
RUN cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
# 在容器中创建room文件夹
RUN mkdir ${work_home}
# 将容器中的room文件夹设置为工作目录
WORKDIR ${work_home}
# 将当前目录内容复制到容器的room目录，因为build中指定的context环境目录为project这一层，所以当前目录即项目目录
COPY . ${work_home}
# 更新pip
RUN pip install pip -U
# 安装所有依赖库
RUN pip install -r requirements.txt -i ${pip_url} --trusted-host ${pip_host}
# 将deployment/dev下的startapp.sh 文件拷贝到容器的根目录下
COPY deployment/dev/app/startapp.sh /startapp.sh
# 将deployment下的wait-for-it.sh文件拷贝到容器的根目录下
COPY deployment/wait-for-it.sh /wait-for-it.sh
# 修改文件权限 ，为sh文件增加可执行
RUN chmod +x /startapp.sh
RUN chmod +x /wait-for-it.sh
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
下面对上述的指令语句做一些简单介绍：
FROM python:3.8: 从仓库拉取一个包含Python3.8的Linux操作环境
WORKDIR: 这个指令是针对容器的，功能是将容器中的指定目录设置为工作目录
COPY: 将宿主机中的指定目录拷贝到容器中的指定目录中，docker中还有一个ADD指令与COPY指令功能相似，但是ADD指令在拷贝后会自动解压压缩包，COPY指令不会
RUN: 这个指令是针对容器的，主要是在容器中执行你想要执行的指令
Dockerfile是默认的配置文件名称，docker在创建镜像时会默认去指定路径（即指定的上下文环境目录）中寻找名为Dockerfile的配置文件。当然，我们也可以修改名称，只需要我们重新手动指定一下配置文件的路径即可，在下面内容中我们会讲到。
startapp.sh文件内容如下：
#!/bin/sh
python manage.py migrate
python manage.py collectstatic --noinput
gunicorn -c ./deployment/dev/gunicorn/gunicorn.conf.py room.wsgi:application
1
2
3
4
5
wait-for-it.sh是直接从Github上下载的，链接如下:
https://github.com/vishnubob/wait-for-it
至此，Django相关的镜像配置到此结束，我们还缺少Nginx与Mysql的镜像配置。但是，我们在文章开头就提到过，类似Nginx与Mysql这类常用的镜像，早就有人帮我上传到公共仓库中，我们只需要直接从公共仓库中拉取即可，不需要在自己手动编写，所以我们真正需要自己自定义的镜像文件，只有我们的Django项目。
使用Docker-compose
前面我们多次提到不要将多个组件放在一个容器中，而是分别为每个组件创建一个容器。而当我们要构建和运行多个组件的容器时，我们如果每个容器都去使用命令单独去构建和运行岂不是很麻烦？此时我们就可以使用Docker-compose来解决这一问题。Docker-compose可以同时编排多个容器，将多个容器的构建与启动操作放到一起执行。我们在docker-compose.yml文件中写入如下内容：
version: "3"
# 定义用于共享的数据卷
volumes:
# 定一个名称为static-volumn的数据卷
static-volume:
# 定一个名称为media-volumn的数据卷
media-volume:
# 定义两个网络，只有处于同一网络下的容器才能通讯
networks:
web_network:
driver: bridge
db_network:
driver: bridge
services:
app:
# 除正常工作外，容器会在任何时候重启，比如遭遇 bug、进程崩溃、docker 重启等情况
restart: always
build:
# 构建镜像的上下文环境所在目录，相对当前docker-compose.yml的位置
context: ../../
# 指定用于构建镜像的Dockerfile（ps: 命名不需要一定为Dockerfile）
dockerfile: ./deployment/dev/app/Dockerfile
# 设置容器名字
container_name: room_dev
image: room_dev
command: "/wait-for-it.sh mysql:3306 -- /startapp.sh"
# 数据卷，使宿主机的内容可以映射到容器中，当宿主机指定目录的内容更新时，容器中的指定目录中的内容也会相应更新
# 所以使用数据卷时，一定要注意路径是否正确，否则会出现文件找不到或不存在的情况
volumes:
- ../../:/room
- static-volume:/room/collected_static
- media-volume:/room/media
# 暴露端口，但不暴露给宿主机，只给连接的服务访问
expose:
- "8000"
networks:
- web_network
- db_network
mysql:
image: mysql:5.7
restart: always
container_name: mysql
hostname: mysql # host的名字，在django中需要使用
environment:
- MYSQL_HOST=localhost # mysql的主机
- MYSQL_PORT=3306 # mysql的端口号
- MYSQL_ROOT_PASSWORD=123456 # root用户的密码
- MYSQL_DATABASE=room_dev # 数据库的名字
- MYSQL_USER=dev # 用户名
- MYSQL_PASSWORD=123456 # dev用户的密码
- MYSQL_ALLOW_EMPTY_PASSWORD=no # 设置是否允许root用户的密码为空
command:
--default-authentication-plugin=mysql_native_password
--character-set-server=utf8mb4
--collation-server=utf8mb4_general_ci
--explicit_defaults_for_timestamp=true
volumes:
# mysql的数据目录
- ../../../room_dev_db:/var/lib/mysql
ports:
- "3306:3306"
networks:
- db_network
nginx:
image: nginx:latest
restart: always
container_name: nginx
# 宿主机和容器的端口映射
ports:
- "8001:8001"
volumes:
- static-volume:/collected_static
- media-volume:/room_media_dev
- ./nginx:/etc/nginx/conf.d # 修改nginx的配置
networks:
- web_network
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
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
Docker-compose的安装请参考上章内容
上述文件内容有些多，我们逐一分析。在文件开头，有个version，代表docker-compose.yml的版本，目前最新版为3，我们不需要改动它。然后文件下面的内容大致分为volumes、networks、app、mysql、nginx五个模块。其中app、mysql、nginx都是容器的配置，app容器使用的镜像是我们上述的自定义镜像，mysql与nginx容器使用的镜像则是直接从公共仓库中拉取的镜像，我们先看下容器中的配置项：
restart： 除正常工作外，容器会在任何时候重启，比如遭遇 bug、进程崩溃、docker 重启等情况。
command： 运行容器所需要执行的操作，这边是直接执行一个shell脚本，当然也可以直接执行命令，比如python manage.py runserver 127.0.0.1:8000
container_name： 设置容器的名字
image： 镜像的名字，在app这种使用自定义镜像的情况中，表示的是设置自定义镜像的名字。在mysql和nginx这种从仓库中拉取镜像的情况中，表示的是要从仓库中获取的镜像的名字，而不是重新设置镜像名字
expose： 容器对外暴露端口，因为容器与外界隔离是连端口一起隔离的，但是web服务是需要调用端口的，因此需要将容器的端口对外暴露，但是要注意此命令不会对宿主机（即外界的系统操作环境）暴露端口，仅仅是对其他容器暴露端口
ports：定义了宿主机与容器之间的端口映射，写法是宿主机的端口号:容器的端口号，例如8000:5000即表示访问宿主机的8000端口就是访问容器的5000端口，与expose一样起到对外暴露端口的作用，但是ports是针对宿主机而expose是针对其他容器的
build： 用于指定构建镜像的上下文路径
context： 指定构建镜像的上下文环境所在目录，是相对配置文件docker-compose.yml的所在目录，../../表示docker-compose.yml所在目录的上级目录的上级目录，即最外层的room目录，注意上述镜像配置文件中COPY命令所涉及到的宿主机目录就是由context指定的，例如COPY deployment/dev/app/startapp.sh /startapp.sh中，因为context指向最外层的room目录，所以deployment/dev/app/startapp.sh指的是最外层room目录下的对应文件
dockerfile： 指定用于构建镜像的配置文件，即我们的前面编写的Dockerfile文件，其根路径就是上述context指定的路径，即最层的room，./deployment/dev/app/Dockerfile即表示最外层room目录下对应的文件
depends_on： 一个容器需要依赖另一个容器，例如上述配置中app容器需要依赖mysql容器，只有mysql容器启动后，app容器才能正常使用。但是mysql容器第一次启动后，初始化需要一定的时间，而depends_on并不会去等待mysql初始化完成，再去启动app，这时app启动会因为mysql没有初始化完成而失败，所以这时我们可以使用上述提到的wait-for-it.sh脚本，使用方法是/wait-for-it.sh 容器名:容器端口号 -- 后续执行的命令，例如/wait-for-it.sh mysql:3306 -- /startapp.sh
因为我们使用到了mysql，所以django中的配置需要做如下修改：
# *************************
# 数据库相关
# *************************
DATABASES = {
# 默认使用mysql数据库
"default": {
"ENGINE": "django.db.backends.mysql", # 数据库引擎
"NAME": "room_dev", # 数据库名
"USER": "dev", # 用户名
"PASSWORD": "123456", # 密码
"HOST": "mysql", # HOST，配置文件中的hostname
"POST": 3306, # 端口
"OPTIONS": {"charset": "utf8mb4"},
},
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
在上述容器配置项介绍中，除了volumes与networks外，对于其他配置项我们已经有了一些了解。下面我们单独讲解一下volumes与networks，尤其是volumes，其在容器中起到至关重要的作用。
volumes
volumes我们一般称为容器的卷。因为容器与容器以及容器与宿主机是相互隔离的，但有时我们又需要它们可以互相连通，例如当宿主机上的项目代码更新了，容器中的项目代码也需要更新，如果我们每次都去手动更新，岂不是很麻烦？另外，当容器被删除时，容器中的数据也会丢失，如果数据库的容器被误删，这导致的结果也不是我们可以接受的。而卷正好解决这些问题！
卷大致可以分为两种使用形式，
第一种：使用绝对路径
app:
......
volumes:
- ../../:/room
1
2
3
4
上述配置中，:是分割符，:的左边../../是宿主机的目录（这个路径是相对docker-compose.yml所在的目录，此处为docker-compose.yml所在的目的上级目录的上级目录，即最外层的room目录），:的右边/room是容器中的目录，此时表示宿主机的../../与容器的/room目录是连通的，当宿主机中的指定目录中的项目代码更新，容器中的/room目录中的代码也会更新。
mysql:
......
volumes:
- ../../../room_dev_db:/var/lib/mysql
1
2
3
4
我们再看容器mysql中的配置，../../../room_dev_db表示在最外层room目录外新建了一个room_dev_db文件夹与mysql容器中的/var/lib/mysql（mysql存放数据的地方）目录连通。因为一开始room_dev_db目录是空的，所以/var/lib/mysql中的数据会映射到room_dev_db中，这样在宿主机中就持有了数据库中的数据，即使我们不小心误删了mysql容器，我们在宿主机中也有数据库的数据，不会造成数据丢失，当我们再次创建mysql容器时，数据会自动恢复。
第二种：使用卷标
# 定义用于共享的数据卷
volumes:
# 定一个名称为static-volumn的数据卷
static-volume:
# 定一个名称为media-volumn的数据卷
media-volume:
1
2
3
4
5
6
在文件的头部，我们定义了两个卷，分别名为static-volume与media-volume。这两个卷目前是空的，没有任何数据。然后在app容器中有一段配置：
app:
......
volumes:
......
- static-volume:/room/collected_static
1
2
3
4
5
static-volume:/room/collected_static中，:左边的static-volume是我们在一开始在宿主机中定义的卷，:右边的/room/collected_static指的是容器中的目录，但此时的static-volume只是个卷的名字，不是具体的宿主机中的路径，此处将容器中的/room/collected_static的内容映射到宿主机的原来的空static-volume卷中，使得static-volume持有/room/collected_static中的数据，而static-volume的具体存储，则默认由宿主机上的docker统一管理。
nginx:
......
volumes:
- static-volume:/collected_static
1
2
3
4
在nginx容器中有一段static-volume:/collected_static，因为在上面app容器中已经使static-volume卷拥有了数据，使其不再是空的状态，此处是将static-volume卷中的数据映射到nginx容器的/collected_static目录中，使得nginx容器也可以访问static资源，起到了数据共享的作用，这样app与nginx就是共用static-volume这个卷，起到数据共享的作用。
在上述介绍数据卷时，我们几次提到数据卷的空状态与非空状态，其实从中可以看出，挂载空卷和非空卷是有区别的，所以我们需要记住以下数据卷的重要特性:
容器启动时，如果挂载一个空的数据卷到容器中的一个非空目录中，那么这个目录下的文件会被复制到数据卷中；
如果挂载一个非空数据卷到容器中的一个目录中，那么容器中的目录中会显示数据卷中的数据；如果原来容器中的目录中有数据，那么这些原始数据会被隐藏掉
举个例子，就以collected_static的数据卷static-volume来说，只要卷初始化完成后，容器原始的 collected_static目录就被隐藏起来不再使用了，新增的文件也只存在于static-volume卷中，容器中是没有的。
networks
# 定义两个网络，只有处于同一网络下的容器才能通讯
networks:
web_network:
driver: bridge
db_network:
driver: bridge
app:
……
networks:
- web_network
- db_network
mysql:
……
networks:
- db_network
nginx:
……
networks:
- web_network
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
在docker中可以给每个容器定义其工作网络，定义网络后可以隔离容器的网络环境，容器只有在相同的网络之中才能进行通讯。此处一共定义了两个网络web_network和db_network。在配置文件中可以看出，app与nginx都处于web_network网络，且app与mysql处于db_network网络，nginx与mysql因为所处网络不同，无法通讯。
四、总结
关于使用Docker+Django+Gunicorn+Mysql+Nginx部署项目的介绍就到此结束了，博主对于Docker的使用也只是停留在基础层面，如有不足之处，欢迎指正。有兴趣的同学可以关注公众号「Code满满」或者是博客「李益的小站」。另外此处推荐一个比较详细的系列文章：《Django+Docker容器化部署》，本文亦参考了此系列文章。
最后附上gunicorn与nginx的配置文件内容：
gunicorn
# -*- coding: utf-8 -*-
import multiprocessing
from pathlib import Path
BASE_DIR = Path(__file__).resolve(strict=True).parent.parent.parent.parent
debug = False
# ============================================================
# gunicorn要切换到的目的工作目录
# ============================================================
chdir = str(BASE_DIR)
# ============================================================
# server socket相关
# ============================================================
# 指定绑定的ip和端口
bind = "0.0.0.0:8000"
# 服务器中排队等待的最大连接数，建议值64-2048，超过2048时client连接会得到一个error
backlog = 2048
# ============================================================
# 调试相关
# ============================================================
# 当代码有修改时，自动重启workers，适用于开发环境
reload = False
# 以守护进程形式来运行Gunicorn进程，其实就是将这个服务放到后台去运行
daemon = False
# ============================================================
# worker进程相关
# ============================================================
# 用于处理工作的进程数
workers = multiprocessing.cpu_count() * 2 + 1
# worker进程的工作方式，有sync、eventlet、gevent、tornado、gthread, 默认是sync,
# django使用gevent容易造成阻塞, 使用gthread的方式好一些
worker_class = 'gthread'
# 指定每个工作进程开启的线程数
threads = multiprocessing.cpu_count() * 2
# 访问超时时间
timeout = 30
# 接收到restart信号后，worker可以在graceful_timeout时间内，继续处理完当前requests
graceful_timeout = 60
# server端保持连接时间
keepalive = 30
# ============================================================
# 日志相关
# ============================================================
"""日志文件格式，其每个选项的含义如下：
h remote address
l '-'
u currently '-', may be user name in future releases
t date of the request
r status line (e.g. ``GET / HTTP/1.1``)
s status
b response length or '-'
f referer
a user agent
T request time in seconds
D request time in microseconds
L request time in decimal seconds
p process ID
"""
access_log_format = '%(t)s %(h)s "%(r)s" %(s)s %(b)s "%(f)s" "%(L)s"'
LOG_DIR = Path(BASE_DIR, 'log')
if not LOG_DIR.exists():
LOG_DIR.mkdir(parents=True)
# 错误日志输出等级，访问日志的输出等级无法设置
loglevel = "error"
# 正常的日志文件路径，'-'表示输出到终端
accesslog = '-'
# 错误日志文件路径，'-'表示输出到终端
errorlog = str(LOG_DIR / 'gunicorn_error.log')
# ============================================================
# 进程名相关
# ============================================================
# 设置进程名称，默认是gunicorn
proc_name = 'gunicorn_room'
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
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
nginx
#user root;
# 将请求分发到upstream池中的服务器中
upstream app {
ip_hash;
server app:8000;
}
server {
# nginx监听的端口
listen 8001;
server_name localhost;
# 限制用户上传文件大小
client_max_body_size 5M;
location /media {
alias /room_media_dev;
}
# 访问一些其他静态文件，直接交给nginx处理，可以指向django项目中配置的STATIC_ROOT路径
# 这里的 /static 的意思就是你的域名加上/static/就访问里面的那个路径/项目了
# alias：直接查询指定路径
location /static {
alias /collected_static/;
}
location / {
proxy_pass http://app/; # 将指定的ip或者域名的http请求转发到upstream池中
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
————————————————
版权声明：本文为CSDN博主「李益99」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/liyi1009365545/article/details/115204087
920
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
