前端微服务通过Gitlab-CI实现检查、构建并自动部署虚拟机

一、背景

最近开发了个大前端项目，用前端微服务来实现，由于涉及到十几个子项目，如果每个项目都手动或者脚本部署，人力成本和出错的概率就会很高，所以需要接入Gitlab-CI/CD，方便统一部署和后续灰度系统的接入。

实现的过程中需要考虑的问题：

• 涉及到十几个子项目，后面会持续扩展，所以需要统一的发布方式
• 需要考虑后续接入灰度系统的问题
• 项目支持中英文，所以除了语言文件和一些特殊的文件中，其他代码中不允许有中文
• 部署的虚拟机需要经过跳板机，Gitlab Runner需要可以直接将文件发布到虚拟机
• 一些变量不适合共享给所有用户，需要隐藏

这里以前端服务为例子，但实现方案也适用于后端服务

二、实践概述

1、原理图

1.统一的gitlab-config配置文件，前端服务通过include引入
2.当提交代码触发CI，则会在Gitlab Runner中执行CI配置文件
3.如果涉及到定制的镜像，会将镜像推送到镜像仓库
4.Runner执行多个任务，在最后部署的任务中，将代码推送到虚拟机
5.如果存在跳板机，要提前处理密钥，获取访问权限

2、前期准备

• 1、需要Gitlab版本>=8.x，支持CI/CD
• 2、最好用私有仓库来串联和部署，也可以使用公开的镜像
• 3、Gitlab Runner默认已经注册好了，可以供这些服务使用，不明白可以看我之前的文章Gitlab CI/CD执行流程和Gitlab Runner安装和注册
• 4、Gitlab Runner必须和虚拟机、跳板机网络相通
• 5、准备一个Public权限的Gitlab仓库gitlab-config，用来存放公用的CI配置
• 6、在Gitlab中新建Group，命名App，App下有多个项目包括：sms、account、services

3、一些必要的CI配置说明

字段	说明
include	通过remote引入远程仓库的配置文件
variables	定义全局变量或局部变量供脚本使用
extends	引用公用的属性和方法
dependencies	执行当前Job依赖的任务
tags	指定执行Jobs的Runner
only	指定CI触发条件
cache	缓存文件，比如node_modules
artifacts	上传指定文件到Gitlab，供所有的Job使用

三、gitlab-config项目说明

该项目用来统一管理其他项目使用的CI配置文件、提前构建CI要使用的镜像、CI要执行的逻辑等，供其他项目引入

1、配置文件

新建gitlab仓库gitlab-config，项目结构为：

├── README.md
├── console_ci_Dockerfile
├── .gitlab-ci-app-sshkey-add.yml
├── .gitlab-ci-app.yml
├── .gitlab-ci.yml
├── console_deploy_Dockerfile
└── scripts├── build.sh├── deploy.sh├── npm_install.js├── check-prettier.sh├── check-unittest.sh├── check-eslint.sh└── run_cmd.js 

• scripts目录用来存放执行的脚本，例如:* 需要接入灰度系统，就可以将打包后的文件信息写入灰度系统；* 单元测试，代码检查，eslint插件等检查逻辑* 代码统计和分析
• .gitlab-ci-app.yml 用来保存子应用需要引入的ci配置文件* 在子项目或需要CI部署的项目中，通过include字段来引入
• .gitlab-ci-sshkey.yml 用来引入一些其他yml文件中使用的公共部分，这里为写入SSHKey* 主要通过extends字段引用* 如果你的生产环境像我一样要通过跳板机间接登录，统一在Runner中写入SSHKey作为一个公共部分
• .gitlab-ci.yml 用来为当前项目构建镜像* Runner中需要不同的镜像，那么我们就可以在提交该仓库代码时，构建镜像，上传镜像仓库
• app_ci_Dockerfile 用来构建代码检测阶段的镜像
• app_deploy_Dockerfile