GitLab-CI 来自动创建 Docker 镜像
1.what is gitlab-ci docker image
CI/CD 自动化集成,自动化部署。简单的说就是把代码提交到gitlab管理的同时部署到指定的server,打成docker image方便部署。部署的时候只需要将image run container便可以运行。
传统做法,代码commit 到gitlab后,login in server执行git pull同步新提交的代码。每次更新代码都需要做这样的操作,本人很懒不喜欢浪费很多时间做重复的事情,所以看到gitlab 8.x集成了ci决定尝试一下。
2.CI env主要构成包括代码版本库 Gitlab,CI服务 Gitlab CI,CI运行器 GitLab Runner-docker。
3.持续集成相关概念
1.pipeline
一次 Pipeline 其实相当于一次构建任务,里面可以包含多个流程,如安装依赖、运行测试、编译、部署测试服务器、部署生产服务器等流程。
任何提交或者 Merge Request 的合并都可以触发 Pipeline,如下图所示:
+------------------+ +----------------+
| | trigger | |
| Commit / MR +---------->+ Pipeline |
| | | |
+------------------+ +----------------+
|
2.stages
Stages 表示构建阶段,说白了就是上面提到的流程。
我们可以在一次 Pipeline 中定义多个 Stages,这些 Stages 会有以下特点:
- 所有 Stages 会按照顺序运行,即当一个 Stage 完成后,下一个 Stage 才会开始
- 只有当所有 Stages 完成后,该构建任务 (Pipeline) 才会成功
- 如果任何一个 Stage 失败,那么后面的 Stages 不会执行,该构建任务 (Pipeline) 失败
因此,Stages 和 Pipeline 的关系就是:
+--------------------------------------------------------+
| |
| Pipeline |
| |
| +-----------+ +------------+ +------------+ |
| | Stage 1 |---->| Stage 2 |----->| Stage 3 | |
| +-----------+ +------------+ +------------+ |
| |
+--------------------------------------------------------+
|
3.jobs
Jobs 表示构建工作,表示某个 Stage 里面执行的工作。
我们可以在 Stages 里面定义多个 Jobs,这些 Jobs 会有以下特点:
- 相同 Stage 中的 Jobs 会并行执行
- 相同 Stage 中的 Jobs 都执行成功时,该 Stage 才会成功
- 如果任何一个 Job 失败,那么该 Stage 失败,即该构建任务 (Pipeline) 失败
所以,Jobs 和 Stage 的关系图就是:
+------------------------------------------+
| |
| Stage 1 |
| |
| +---------+ +---------+ +---------+ |
| | Job 1 | | Job 2 | | Job 3 | |
| +---------+ +---------+ +---------+ |
| |
+------------------------------------------+
|
4.搭建过程中的主要步骤:
- 在Gitlab上添加代码库(这个不多说了,不清楚的可以看我的git使用)
- 把代码库添加到Gitlab CI中(project中添加一个
.gitlab-ci.yml
文件,然后添加一个 Runner,即可进行持续集成) - 安装docker(参见 Docker官方文档)
- 搭建基础 docker image
- 设置Gitlab Runner-docker
- 编写测试脚本
- 编写构建脚本
- 优化过程
- 完成一个简单够用的持续集成环境