在五月份，我们定下了技术方向的下一个短期发展目标：实现线上所有服务的容器化。

一个多月后，我们完成了这一目标。

[图片上传失败...(image-b1e628-1657591483107)]

这篇文章，就来和大家聊聊，Docker 是什么？为什么我们要迁移到 Docker？

Docker 是什么

Docker 是一个开源的应用容器引擎。

要想理解这个概念，我们首先需要知道容器是什么。

和现实生活中的容器一样，程序开发中的容器可以用来存储数据。

可以将容器看作轻量级的虚拟机，不同容器间的数据是隔离的。

而 Docker 就是一个管理容器的工具。

在 Docker 中，有几个常用的概念：

• 镜像
• 容器
• 存储卷
• 网络

镜像，和虚拟机的镜像一样，类似面向对象中的类，通过镜像来创建容器，就像通过类创建对象一样。

容器是无状态的，也就是相同镜像启动的容器，期望行为应当一致，因此，在容器化的应用程序中，”重新创建容器试试“替代了”重启试试“。

而容器中的数据，自然会在容器被销毁时被删除，我们需要一种方法将有用的数据保存起来，供新的容器使用，这就是存储卷。

我们可以将存储卷与容器内的某个目录建立双向关联，这样，只要在新的容器中挂载原有的存储卷，数据就可以继续使用。Docker 是一个开源的应用容器引擎

网络则更像是不同的局域网，相同局域网的容器可以互相访问，例如我有一个数据库容器 db，还有一个网页服务容器 web，它们位于同一个网络，现在网页服务容器需要访问数据库（开启于 27017 端口），只需要在连接时填入：

db:27017

Docker 会通过 iptables 帮你处理好网络问题，你不需要关心数据库容器位于何处。

Docker 有什么好处

Docker 最大的特点是环境与资源的隔离，因此，大大降低了程序员甩锅给环境的可能性，啊不是，降低了由于环境问题出现 Bug 的可能性。

以 Python 程序举例，已经停止维护的风语中需要用到 Wordcloud 模块进行词云图的生成，而还在活跃开发的简书小工具集中，则使用了 PyEcharts 实现相同的功能。（关于风语停止维护与技术选型的限制，参见 这篇文章）

在其它服务中，我们还需要用到 Apscheduler 实现任务的定时调度，gensim 实现文本数据挖掘，Pandas 实现数据处理等，这些服务如果都安装在服务器的 Python 环境上，很可能出现冲突，升级依赖版本时也可能造成部分服务不能正常运行。

之前，我们使用 Pipenv 进行项目的依赖管理，部署到服务器上时首先激活虚拟环境并安装依赖，然后在虚拟环境中运行，后来由于 Pipenv 的性能与维护问题，我们切换到了 Poetry。

但这一方案还存在明显的缺点：

• 依赖发生变动时，需要删除虚拟环境重新创建，而且删除过程是手动的
• 部分服务运行中产生的临时文件需要手动清除
• 无法实现资源隔离，有单一服务故障或受攻击影响其它服务的风险
• 如果服务崩溃，需要手动重启

而使用 Docker 部署容器时，这些问题均可以被轻松解决：

• 依赖变动时自动重新安装，没有变动时利用缓存加快构建速度
• 临时文件可以通过删除容器重新创建清除
• 可以针对特定镜像设置 CPU、内存、硬盘、网络限制
• 可以设置重启规则，在服务崩溃或故障后自动重启

其它优点如下，不一一展开：

• 基础平台无关，可以无缝切换云服务商
• 易于在不同运行时中测试服务
• 更高的安全性

我们如何使用 Docker

限于篇幅，这里只简要介绍发布新版本的过程。

以近期新上限的数据获取服务 JFetcher 为例。

首先，我们在本地进行开发，由于 VS Code 有官方的 Docker 扩展支持，需要本地调试时，只需要在 docker-compose.yml 文件上右键，选择 Compose Up，等待服务启动即可。

我们使用 VS Code 的任务功能自动化了版本发布流程，一般我们会在完成该版本的所有编码工作后，更新 docker-compose.yml 和 pyproject.toml 文件中的版本号，然后执行 Git - Release a new version 任务，该任务将自动：

• 切换到 main 分支
• 以 --no-ff 参数合并 dev 分支的更改
• 推送 main 和 dev 分支到远程仓库
• 切换回 dev 分支

之后，需要对照 Git 提交记录，在 GitHub 上撰写版本信息并发布。

通过 SFTP 将项目文件上传到服务器，切换到对应目录，执行命令：

docker compose up -d --build

Docker 将自动完成新镜像的构建（可能包含重新安装依赖），下线原有服务，重新创建容器，上线新版本服务。

查看日志，确认服务运行正常后，部署流程结束。

除撰写提交日志以外，其它过程可以在 3 分钟内完成，服务不可用的时间窗口下降到 5 秒左右。

Docker 最佳实践

以下是我们在使用 Docker 的过程中总结的经验，供大家参考：

1. 容器是无状态的，容器化服务应该做到”即使容器突然被删除后重新创建，也不会丢失任何数据“
2. 构建镜像的过程中，不要残留任何无用文件，例如缓存或构建的中间产物
3. 安装依赖的流程放在拷贝项目文件流程前，最大程度利用缓存提升构建速度
4. 旧版本镜像不要删除，如果新版本出现问题，直接修改版本号到旧版，重新上线即可回滚
5. 避免设置 restart: always，可能造成不必要的重启
6. 对无关文件设置忽略，如版本管理文件、缓存等
7. 不建议使用 docker-slim 工具，缩小单个容器体积的代价是更长的构建时间和缓存的失效

总结

Docker 为我们带来了一套现代化的服务开发、部署工作流。

我们的最终目标是成为综合性的创作服务平台，Docker 为我们提供了强大的基础架构，使我们能从部署过程中抽离出来，关注于功能研发。

以 Docker 为代表的容器化技术，已经被无数企业所采用，成为服务端程序部署的标准之一，我们需要探索，在探索中收获成长。