Docker 方式部署的应用的版本更新

前言

公司使用 Docker-Compose 的方式部署 Jenkins/Gitlab/Sonar/Confluence/Apollo/Harbor/ELK/MySQL 等一系列开发工具/测试数据库。
而每过三五个月，我们就要评估这些软件新版本的变更、新特性，决定是否需要升级。

通过使用 Docker 部署这些应用，好处就是方便升级、部署、备份，而且能保证环境绝对一致。

配置仓库

首先，我们有一个基础设施配置仓库，专门存放各应用的部署配置文件，每个应用一个文件夹，里面有这些文件：

1. docker-compose.yml：docker-compose 的配置文件
   1. harbor 除外，因为它的 docker-compose.yml 是从它自己的配置文件生成的。
   2. 应用数据一般直接映射到 ./xxx_data，这样数据和配置文件放在一起，方便统一管理。
2. Dockerfile: 如果镜像需要自己构建或者做定制，就会有 Dockerfile
3. README.md：说明文档，介绍部署、升级、备份的步骤与注意事项。
4. 其他配置文件：如 harbor 需要 harbor.yml.

升级步骤

方案一

查看官方的升级说明，一般直接升级 Docker 镜像就行。

有不兼容的更新时，官方基本都会给出说明和升级建议，比如先升级到某个中间版本，再逐步升级到最新版。
或者在升级前按说明去运行某个数据库表结构修改的 sql。

通用的流程如下：

1. 备份原有数据卷/映射文件夹，最好是直接和相应的配置文件一起备份。
   • 如果数据量太大不方便备份，你也很相信该软件的升级不会破坏数据，也可以不备份。。
2. 更新镜像版本号（升级到最新版本，或者中间版本），然后 docker-compose up -d 启动。
3. 有问题再回退。。。

如果应用比较重要，需要保证稳定可用，可以先把数据拷到新虚拟机上并通过新镜像部署，测试一段时间，确认没问题了再正式更新。

方案二

使用软件自带的“导入导出/主从复制”这样的功能，通过 api/cli/ui 进行数据的迁移。这样的好处是不会遇到兼容性问题，但是前提是软件本身有这样的功能。

比如 Harbor 仓库，基本都可以通过它的同步功能进行数据迁移。

例外是同步 API 有不兼容变更的情况，比如 harbor 1.8 升级到 1.10，同步 api 发生了变更，官方也没给出兼容方案。
这时就只能退回到方案一了：备份数据，然后下载新的 harbor 安装包进行部署。

画外

大概的更新流程就是上面这些。

我了解到很多公司的运维从来只管搭建与维护环境，让它能用就 OK。从来不考虑新版本，不考虑升级。

我觉得稳定性固然重要，但是这种从来不考虑新变化，一棍子打死所有新版本的做法，也太「乌龟」了一些。这个现象也导致国内大量企业内部仍然使用着早就过时，没人维护的产品支撑着业务。
长此以往，版本越老，从旧版本升级到新版本的难度就越大，也就更不可能去升级了，久而久之这就成了一座垃圾山。

这大概就是「养老」型运维人员吧。。。

个人认为正确的运维观念，应该是定期检查各产品的版本，首先评估一番：

1. 好处：新版本有没有引入什么新特性？这个特性对我们而言有多大价值？
2. 难处：新版本有没有不兼容变更？更新难度高不高？

两相权衡，再由大家讨论来决定是否立即升级，还是再延后一段时间。

如果是使用 AWS 云服务，会发现它们是强制淘汰制，会提前几个月通知用户提前升级，到了时间点甚至会强制将所有被淘汰的版本升级到较新版本。

这当然也会造成麻烦，毕竟任何升级对运维而言都是有风险的，需要额外付出精力去做这种吃力不讨好的事，有种在帮 AWS 擦屁股的感觉。

但是如果 AWS 方能给出比较稳妥、对业务影响很小的升级方案来，我们还是乐见其成的。毕竟我之前就说过，版本跨度越大，往往升级就越难，这种事最好不要拖太久，除非你们的系统压根不需要迭代。