微服务项目部署实践：使用Gitlab Runner实现微服务项目的持续集成，持续交付和持续部署

概念

服务治理遇到的问题
- 在微服务项目中每个服务都是独立运行的项目
- 不可能对每个项目进行手动部署,涉及到自动化运维的问题

持续集成

持续集成(Continues Integration,简称CI)
持续集成指的是,频繁(一天多次)地将代码集成到主干,优点有两个:
- 快速发现错误: 每完成一点更新, 就集成到主干,可以快速发现错误,定位错误
- 防止分支大幅偏离主题: 如果不是经常集成,主干又在不断更新,会导致以后集成难度变大,甚至难以集成
持续集成强调:开发人员提交了新的代码之后,立即进行构建,(单元)测试,根据测试结果,确定新代码和原有代码能否集成到一起
与集成相关的概念还有持续交付和持续部署

使用GitLab持续集成

GitLab8.0以后,GitLab CI就已经集成在GitL中,只要在项目中添加一个 .gitlab-ci.yml文件,然后添加一个Runner,就可以进行持续集成
Pipeline
- Pipeline: 管道 ,一次Pipeline相当于一次构建任务,可以包含多个流程:安装依赖,运行测试,编译,部署测试服务器,部署生产服务器等流程
- 任何提交或者Merge Request的合并都可以触发Pipeline
Stages
- Stages表示构建阶段,也就是上面的流程,可以在一次Pipeline中构建多个Stages,这些Stages的特点:
  - 所有Stages会按照顺序运行: 即当一个Stage完成后,下一个Stage才会开始
  - 只有当所有Stages完成后,该构建任务(Pipeline)才会成功
  - 如果任何一个Stage失败,那么后续的Stages都不会执行,该构建任务(Pipeline)失败
Jobs
- Jobs表示构建工作,表示某个Stage里面执行的工作,可以在Stages里定义多个Jobs,这些Jobs特点:
  - 相同Stage中的Jobs会并行执行
  - 相同Stage中的Jobs都执行成功时,该Stage才会执行成功
  - 如果任何一个Job失败,那么该Stage失败,即构建任务(Pipeline)失败

持续交付

持续交付(Continuous Delivery):
- 频繁地将软件的新版本,交付给质量团队或用户以供评审
- 评审通过,代码就进入生产阶段
持续交付是持续集成的下一步,强调的是:不管怎么更新,软件是随时随地可以交付的
持续交付是在持续集成的基础上,将集成后的代码部署到更接近真实运行环境的类生产环境(production-like environment)中

持续部署

持续部署(Continuous Deployment)是持续交付的下一步,指的是代码通过评审后,自动部署到生产环境
持续部署的目标: 代码在任何时刻都是可部署的,可进入生产阶段
持续部署的前提: 自动化完成测试,构建,部署等步骤

GitLab Runner

GitLab CI

一般来说,构建任务会占用很多的系统资源(编译代码时),由于GitLab CI是GitLab的一部分,由GitLab CI来运行构建任务的化,GitLab的性能会大大下降
GitLab CI最大的作用: 是管理各个项目的构建状态

GitLab Runner

GitLab Runner可以安装到不同的机器上,在构建任务运行期间不会影响GitL的性能
基于Docker安装GitLab Runner:

1.创建工作目录: /usr/local/docker/runner
2.创建构建目录: /usr/local/docker/runner/environment
3.下载jdk-8u152-linux-x64.tar.gz复制到/usr/local/docker/runner/environment
4.下载apache-maven-3.5.3-bin.tar.gz复制到/usr/local/docker/runner/environment


daemon.json
1.在/usr/local/docker/runner/environment目录下创建daemon.json,用于配置加速器和仓库地址
{
    "registry-mirrors":[
        "https://registry.docker-cn.com"
    ],
    "insecure-registries":[
        "127.0.0.1:5000"
    ]
}