应用容器env化实战

本文是数人云工程师方志浩在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化解决方式，欢迎你们提出宝贵意见。

Q&A

Q：请问MySQL数据库怎么随Docker迁移？备份和恢复有什么好的建议吗？

A：MySQL如今是固定主机主从同步，没有对MySQL作迁移，咱们的数据如今备份是定时全备份，正在尝试使用MariaDB集群Galera Cluster ，但尚未上生产，固然有共享存储的话就最好不过啦。

Q：请问配置文件的话生产环境和开发环境怎么区分？

A：生产环境和测试环境都是隔离的，配置文件配置不一样的参数便可。

Q：请问对相似Java应用jdbc、spring.xml等配置文件如何管理？

A：XML配置经过sed替换传入的环境变量。

Q：生产上配置项变动怎么操做？

A：生产配置的值须要修改时 ，在configcenter页面中修改，再触发Jenkins更新配置文件的job， 生产新的配置文件 ，再调用marathon API 更新task进行更新。

Q：业务的配置是和环境配置放在一块儿的么？

A：是的，都是经过envfile进行统一的。

Q：请问大家对环境变量是采用什么样的管理方法？有相应的命名规范吗？环境变量多了，会出现管理方面的问题吧。

A：环境变量键值由开发维护，运维须要提早了解新增环境变量，目前在配置中内心维护，容器环境变量变量命名规范很重要，咱们目前采用服务名＋需链接的组件名＋属性 进行命名的，且环境变量所有大写。