微服务项目部署实践:使用 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:
构建镜像并启动
在/usr/local/docker/runner 目录下执行:
注册 Runner
启动容器在/usr/local/docker/runner 目录下执行命令启动:
进入容器自动执行注册流程,在/usr/local/docker/runner 目录下执行(后面 gitlab-runner register 时脚本命令):
打开 GitLab,进入持续集成设置界面
在交互式终端中填入 Git Lab 提供的 URL 和 token
使用 Runner
在项目工程下编写 .gitlab-ci.yml 文件:
提交项目之后,就会执行 Runner
在项目工程下创建 docker 文件夹,创建 Dockerfile
Dockerfile:
删除所有为<none>的镜像
在 docker-compose.yml 中配置默认使用已经存在的网络
版权声明: 本文为 InfoQ 作者【攻城狮Chova】的原创文章。
原文链接:【http://xie.infoq.cn/article/ed3c7744cb2bee67eef363f81】。文章转载请联系作者。
评论