从0开始搭建一个微服务的持续交付系统，教你如何快速搭建
|
如图4所示，开发人员check in 代码到Git仓库后，Jenkins会自动地进行构建工作，并把打好的包上传到Repo server上。  图5 配置文件示例 作为统一方法的一部分，我们在每个微服务仓库上创建了CI目录，用于配置文件的打包，在CI目录里，只放入需要参数化的配置文件，执行脚本等，并会严格遵循原有系统的目录结构，如图5所示，我们要求有start.sh、stop.sh及service(用于Linux的init启停该微服务)。 图5中配置文件参数化内容，参数部分用”{{“与”}}”包围起来，在持续部署的时候会根据传入的参数替换为特定的值。 我们还定义了持续构建的统一输出，对每个微服务采用tgz的打包格式，微服务ms1持续构建的输出文件示例如下:
在可执行包里面要求把所有的依赖库(除了系统lib库)都包含在里面，对不同编程语言的微服务的构建工具没有强制要求，统一由Jenkins调用。C/C++我们推荐使用CMake，Java一般用Maven，Python直接打包。 配置文件包就是前面GIT仓库的CI目录直接打包而成。  图6 Bundle示例 同时为了在部署时不用具体指定每个微服务的版本号，我们引入了bundle的概念，如图6。在任何一个微服务构建之后，会触发bundle，sha512校验文件生成，并上传到Repo Server。 最后让我们看下持续交付上传到Repo Server的目录结构：  图7 目录结构 这样持续构建的工作就完成了，接下来就需要进行持续部署了。 快速搭建微服务的持续交付：持续部署 在开始持续部署的讨论之前，我们先描述一下软件运行注入配置的三个时点：  图8 配置注入的三个时间点打包时点，典型的是Java的war包，会把配置文件打包在一起。部署时点，在部署的时候利用专门的部署工具更新配置文件，这也是我们采用的方法;运行时点，程序运行时通过环境变量或注册中心/配置中心获得配置信息，如用Docker部署微服务时就要考虑通过这种方法来获得所需要的配置信息。  图9 采用salt进行部署 图9显示了我们对不同的环境统一采用salt进行部署。由于我们支持用户只输入bundle的版本信息来实现部署，这就要求在持续部署的时候，部署系统能自动获取每个微服务的版本号，为此我们对salt/foreman做了一点小改动，修改后返回的pillar格式包含各个微服务的版本，同时下载并解压对应的配置文件包到salt master的相应目录，以及关闭salt master file_list缓存：fileserver_list_cache_time: 0。  图10 foreman web界面以及Salt格式 图10左边表示我们在foreman web界面上设置的参数，右边表示通过salt pillar.items取得的格式，可以看到多了每个微服务的版本号信息。 下面我们按照部署三部曲(安装、配置注入、服务运行)来介绍部署规则文件(saltstate、sls文件)的编写： （编辑：西安站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
