转载

Docker 化运维方式

应用运维需要考虑的一个重要问题就是迁移, 在不同机器、机房、环境间迁移。迁移的原因有很多, 比如硬件过保(硬件故障), 机房迁移, 应用扩缩容等。

应用迁移的核心需求是:

简单。 迁移操作必须足够简单, 没有学习成本, 点击一下即可。
快速。 迁移过程能在极短的时间内完成。
无损。 迁移之后应用与原应用一模一样, 不丢失任何配置和数据。迁移之后应用功能和业务逻辑与原部署应用一模一样，无任何业务风险。

许多公司还在使用古老的 rhel 5/6 和 linux 2.6.x 内核, 难以充分发挥现代操作系统和硬件的能力, 部分原因也是受制于应用迁移技术不成熟, 不能保证快速无损迁移应用, 不敢迁移。

具备快速迁移的能力, 同样可将应用快速切换到任意版本, 实现快速回滚。

tomcat webapp 部署结构

我们看一下一个基于 tomcat 部署的 java webapp 应用部署结构如下:

apache-tomcat-8.0.35/
├── bin/
├── conf/
├── lib/
├── logs/
├── temp/
├── webapps/
├── work/
├── LICENSE
├── NOTICE
├── RELEASE-NOTES
└── RUNNING.txt

其主要分为两个部分:

静态二进制文件。包含 bin/ , lib/ 。这部分是三方软件包 tomcat 自带的内容。对应用而言, 这部分内容是只读访问的, 不会修改。
外部配置和数据。包含 conf/ , logs/ , temp/ , webapps/ , work/ 。这里的“外部”是指从 tomcat 软件包的角度来看, 对应用来说, 这部分才是真正的应用软件包。

注意: tomcat 软件包也包含 conf/ 。但应用可能会对 conf/ 进行修改, 所以应用使用了一个独立维护的 conf/ 副本, 而不是 tomcat 软件包自带的 conf/ 内容。

很显然, 要迁移这个应用, 只需要迁移第 2 部分, 即外部配置和数据即可。为了简化迁移, 许多应用被设计为无状态的, 即 logs/ , temp/ , work/ 等外部数据目录不包含任何影响应用功能的配置或数据, 这部分内容不需要迁移。只需要迁移 conf/ , webapps/ 目录, 这部分内容可打包为应用软件包。

这样, 在新环境部署应用, 只需要安装 tomcat 软件包和应用软件包即可。

新环境部署

在新环境上完成应用部署, 有两种玩法:

列一个软件包清单 (如上例中的 tomcat 和应用), 在新环境上按照清单完成软件包安装, 这是 juju 的玩法。
将所有软件包安装好并打包成一个二进制镜像, 拷贝到新环境上部署运行, 这是 docker 的玩法。Dockerfile 描述如何创建镜像, 类似于软件包清单。

docker 镜像不止是预安装软件包, 还包含基础操作系统环境, 统一的日志、数据路径, 环境变量等标准化应用运行环境。这可难不倒 juju, juju 同样基于一个标准镜像创建 vm 或 lxc 容器, 再安装软件包, 同样提供标准化的运行环境。这两种方式各有优缺点, 在此不作深究。但就使用成本来说, docker 目前在国内外发展火热, 技术和实践经验相对成熟, 更容易使用。

单机多实例隔离部署

使用 docker 应用容器部署应用, docker 容器为应用提供了标准一致且相互独立的运行环境, 这样应用使用相同的配置和路径, 也可以在单个宿主机上实现多实例部署。与 vm 的单机单部署模式相比, 应用容器要做的足够轻, 消除 vm 的额外开销, 并且完美支持微服务编排。

软件包与配置分层

有些软件包很好的实现了软件包默认配置与应用自定义配置的分离, 如 tomcat, 只需指定 CATALINA_BASE 目录与 CATALINA_HOME 目录分开, 将应用部署到 CATALINA_BASE 下, 即可实现应用自定义配置和 tomcat 软件包默认配置分离, 两者独立维护, 互不影响。

许多软件包没有实现这样的能力, docker 通过分层文件系统解决这个问题, 同时可以避免每个软件包都去考虑设计配置分离功能。

Docker 化运维方式