应用运维需要考虑的一个重要问题就是迁移,在不同机器、机房、环境间迁移。迁移的原因有很多,比如硬件过保(硬件故障),机房迁移,应用扩缩容等。
应用迁移的核心需求是:
简单。迁移操作必须足够简单,没有学习成本,点击一下即可。
快速。迁移过程能在极短的时间内完成。
无损。迁移之后应用与原应用一模一样,不丢失任何配置和数据。迁移之后应用功能和业务逻辑与原部署应用一模一样，无任何业务风险。
许多公司还在使用古老的rhl5/6和linux.6.x内核,难以充分发挥现代操作系统和硬件的能力,部分原因也是受制于应用迁移技术不成熟,不能保证快速无损迁移应用,不敢迁移。
具备快速迁移的能力,同样可将应用快速切换到任意版本,实现快速回滚。
tomcatwbapp部署结构我们看一下一个基于tomcat部署的javawbapp应用部署结构如下:
apach-tomcat-8.0.35/
├──bin/
├──conf/
├──lib/
├──logs/
├──tmp/
├──wbapps/
├──work/
├──LICENSE
├──NOTICE
├──RELEASE-NOTES
└──RUNNING.txt
其主要分为两个部分:
静态二进制文件。包含bin/,lib/。这部分是三方软件包tomcat自带的内容。对应用而言,这部分内容是只读访问的,不会修改。
外部配置和数据。包含conf/,logs/,tmp/,wbapps/,work/。这里的“外部”是指从tomcat软件包的角度来看,对应用来说,这部分才是真正的应用软件包。
注意:tomcat软件包也包含conf/。但应用可能会对conf/进行修改,所以应用使用了一个独立维护的conf/副本,而不是tomcat软件包自带的conf/内容。
很显然,要迁移这个应用,只需要迁移第部分,即外部配置和数据即可。为了简化迁移,许多应用被设计为无状态的,即logs/,tmp/,work/等外部数据目录不包含任何影响应用功能的配置或数据,这部分内容不需要迁移。只需要迁移conf/,wbapps/目录,这部分内容可打包为应用软件包。
这样,在新环境部署应用,只需要安装tomcat软件包和应用软件包即可。
新环境部署在新环境上完成应用部署,有两种玩法:
列一个软件包清单(如上例中的tomcat和应用),在新环境上按照清单完成软件包安装,这是juju的玩法。
将所有软件包安装好并打包成一个二进制镜像,拷贝到新环境上部署运行,这是dockr的玩法。Dockrfil描述如何创建镜像,类似于软件包清单。
dockr镜像不止是预安装软件包,还包含基础操作系统环境,统一的日志、数据路径,环境变量等标准化应用运行环境。这可难不倒juju,juju同样基于一个标准镜像创建vm或lxc容器,再安装软件包,同样提供标准化的运行环境。这两种方式各有优缺点,在此不作深究。但就使用成本来说,dockr目前在国内外发展火热,技术和实践经验相对成熟,更容易使用。
单机多实例隔离部署使用dockr应用容器部署应用,dockr容器为应用提供了标准一致且相互独立的运行环境,这样应用使用相同的配置和路径,也可以在单个宿主机上实现多实例部署。与vm的单机单部署模式相比,应用容器要做的足够轻,消除vm的额外开销,并且完美支持微服务编排。
软件包与配置分层有些软件包很好的实现了软件包默认配置与应用自定义配置的分离,如tomcat,只需指定CATALINA_BASE目录与CATALINA_HOME目录分开,将应用部署到CATALINA_BASE下,即可实现应用自定义配置和tomcat软件包默认配置分离,两者独立维护,互不影响。
许多软件包没有实现这样的能力,dockr通过分层文件系统解决这个问题,同时可以避免每个软件包都去考虑设计配置分离功能。
应用自定义配置在软件包安装层的上层,运行容器时覆盖默认配置,但在软件包安装层升级软件包时看不到应用自定义配置,不会受应用自定义配置影响。需要注意的是,软件包升级后是否兼容旧的应用自定义配置,是否需要更新自定义配置,需要应用负责人白斑医院排名北京最佳白癜风医院