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

posted @ 2019-08-28 22:22  於清樂  阅读(6585)  评论(0编辑  收藏  举报