应用容器env化实战

2016-07-20 00:21:00

本文是数人云工程师方志浩在DockOne微信群分享的实录，与大家聊一聊应用容器在配置管理中遇到的问题以及解决方法。

随着Docker技术的火热发展， Docker在代码构建发布中扮演着越来越重要的角色。Docker让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到流行的Linux机器上。Docker非常适用于如下场景：

应用容器的自动化打包和发布；
自动化测试和持续集成、发布。

这次主要和大家聊聊应用容器在配置管理中遇到的问题。首先是介绍现有容器常用的配置文件加载方式，接下来重点介绍数人云组件在自动化打包和发布遇到的问题和解决方法。

现有的主要Docker加载配置的方式

首先简单介绍下现有容器的加载配置文件的方式。

挂载宿主机配置文件的方式

通过docker run -v 参数将宿主机上的配置文件挂载到容器指定目录中如：

docker run -v /myredis/conf/redis.conf:/usr/local/etc/redis/redis.conf --name myredis redis redis-server /usr/local/etc/redis/redis.conf

这种方式对于单实例应用比较方便。

下载配置中心文件的方式

这种方法首先需要建立配置中心，例如用Nginx等Web服务组件，提前将配置文件放在指定目录，在Dokcerfile entrypoint中拉取配置中心文件的脚本，之后容器启动就自动拉取配置中心的配置。

通过环境变量传入到容器中

通过docker run -e 参数将将环境变量传入到容器如：

docker run --name some-mysql -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql:5.6

应用容器的自动化打包和发布中遇到的问题

数人云组件采用微服务架构，将服务拆分，分别采用相对独立的服务对各方面进行管理，彼此之间使用统一的接口来进行交流，架构变得复杂，但优势非常明显。为了保证高可用，这些容器一般都运行在多个VM上，服务实例前是一层诸如HAPROXY的负载均衡器，它们负责在各个实例间分发请求。数人云分测试、演示、生产三种环境进行持续集成、发布，同时数人云组件通过Docker+Mesos+Marathon进行应用容器的封装下发和管理。首先说下我们容器发布遇到的问题——配置文件多，如何进行统一的管理？

我们由于采用微服务架构，就产生了各个模块的配置，导致配置文件过多；其次数人云的三套环境，如MySQL等基础组件IP、Port等配置不同，导致配置成倍增加；最后采用高可用架构，也造成了配置文件的增多。下面是数人云Mesos系统架构流程图：

Marathon、Jenkins作为Framework注册在mesos-master上，动态调度mesos-slave资源。

Marathon负责应用的发布
Jenkins负责代码打包、镜像构建

Mesos Framework截图如下：

若单纯-v的挂载方式需提前将配置文件放在mesos-slave所在的宿主机上，新加slave时也需进行相同的操作，且当配置文件需要更新时，需更新每台mesos-slave宿主机上的配置文件，这显然不够灵活，所以我们刚开始采用应用容器启动下载配置中心文件的方式。

早期的配置中心，如下图所示：

此时存在的问题有：

因为是多种环境，虽然把这些配置都在Configserver上集中配置，但是需要手动修改这些配置。手动修改容易出错，例如Dev更新了一个服务，可能过了一周才会更新到生产环境。那个时候再去修改生产就很容易出错，导致无法运行。
如果配置发生了Bug需要回滚，手动修改也是不合适的。

我们进行了改进，引进Jenkins后工作流程如下图：

我们用Jenkins把它们整体串起来，我们的第一个工作是把所有的配置文件抽象化，各种环境的文件抽象出来一个模板，放在GitLab上。它的数据是放在数据库里面，这样组合起来是一个完整的配置文件。各个环境的值是不一样的。我们的运维平台触发Jenkins，Jenkins去调度我们的ConfigCenter API，它传入两个参数，一个是需要更新的环境，另一个是更新哪个服务。之后API去做对比，从数据库去读现有的配置文件的模板Tag，再去读新模板的Tag进行对比。

如果这个文件需要更新，把它从数据库拉过来，数据做匹配，渲染成我们最终的配置文件，再传到Gitlab上。剩下的通过Jenkins 触发 Configserver去调Gitlab下载最新的配置文件到Configserver服务器，Jenkins再去调用Marathon去重启服务，服务就会成功更新配置文件。这很好解决了配置文件对应文件，但还是存在以下一些问题：

配置格式不统一，配置有env 、congfig.js 、.yaml 、.xml 等配置文件，各种配置文件需要在应用容器发布前进行替换，当新增配置文件项时，需重新编写模版，替换匹配内容较为繁琐。
Marathon发布应用采用了配置文件的方式，在Marathon界面看不到配置文件的内容，需后台查看，增加了运维复杂度。

后来我们对应用进行env化改造，统一配置文件格式，且配置通过变量传递给Marathon，使得所有配置在Marathon界面上可见。

以下是具体的工作，我们对开发进行了规约。

产品模块GitHub目录规约结构

除了代码和产品开发的一些文件外，还需要规约一下目录结构：

module_name -          |           -deploy -                    |                    -env                      |                    -deploy-marathon.sh                    |                    -compile.sh           |            -dockerfiles -                         |                         -Dockerfile_compile_env                         |                         -Dockerfile_runtime

在GitHub中更新env文件，这个由开发提供维护，里面有对应env文件如下图：

改进后具体的流程图如下：

以上主要对配置文件进行env化，减少配置替换复杂度，将配置存在于Marathon发布脚本中。

更新后产生的marathon applist：

单个应用容器配置：

采用env化有助于配置文件的统一维护和管理，新版Marathon很好的支持了应用的更新和回滚，除去了容器启动对静态配置文件的依赖，使应用容器更新发布、回滚更加方便。从界面上可以看到所有容器配置信息，使排错管理也变得方便。

线下数人云企业版组件采用和线上相同的镜像和env变量，通过API获取对应版本的envfile和Docker镜像，之后将所有配置文件抽离到一个配置文件中，实施的同事只需修改这张配置文件，从而省去修改其他配置文件的步骤，使得实施过程更加简单。

以上就是数人云组件配置管理碰到的问题，以及env化解决方式，欢迎大家提出宝贵意见。