原文地址: https://www.jianshu.com/p/86411a27f02a
想象一下，传统的开发流程中，从开发到部署的流程都要手动操作，如果开发流程包含很多部分或要分布部署，频繁的人为操纵会带来许多弊端，如：
- 工作量大（几乎都是重复工作量）
- 易遗漏某一环节
- 易出错
- 不易协同开发
- 等等
而使用CI/CD，则开发人员在前期完成相关配置之后，后期只需关注业务开发即可，其他的CI/CD会帮忙实现。Gitlab CI/CD流程如下：
1. Gitlab CI/CD 工作原理
- push一个commit到Gitlab项目仓库(该项目需要有
.gitlab-ci.yml文件)。 - Runner会执行Pipelines中的jobs。
相关概念介绍
-
.gitlab-ci.yml: 配置文件，定义需要CI/CD做到工作。 - Runner: 运行在其他独立机器或虚拟机或Docker中到程序，通过Gitlab CI到coordinator API来进行通行
- Pipelines: 在配置文件中定义的各stage中执行的jobs
所以，实现Gitlab CI/CD的步骤可以总结为:
- 在项目的根目录添加一个
.gitlab-ci.yml文件。 - 给项目配置一个Runner。
下面介绍.gitlab-ci.yml和Runner的配置
1.1 .gitlab-ci.yml配置说明
Gitlab CI使用的是YAML格式的文件(.gitlab-ci.yml)来作为配置文件，并且要放置在项目的根目录，否则不能识别。
先看一个配置实例：
before_script: # 定义在job执行之前的执行脚本(就一次)
- echo "hello gitlab ci"
stages: # 定义Pipeline的阶段，可以多个
- build
- test
- deploy
build_job: # 定义一个job
stage: build # 设置job所属的stage，默认是test
tags: # 定义tags，用来匹配相应的Runner来执行
- my-tag
script: # 定义后面Runner来执行的具体脚本
- cd /root/test
- git pull
- npm install
test_job:
stage: test
tags:
- my-tag
script:
- cd /root/test
- npm test
deploy_job:
stage: deploy
tags:
- my-tag
script:
- cd /root/test
- npm start &
上述配置中定义了一个before_script，一个stages和三个job，其中，stages中的执行流程是按定义的流程执行的，在该示例中的执行顺序即：build->test->deploy，也就是stage为build的job最先执行，成功之后执行下一个stage的job。如果多个job属于同一个stage，则会并行执行。
.gitignore中的文件在每个job启动时都会被删除，可以使用cache或artifacts来实现文件重用。
1.2 Runner配置说明
在Gitlab CI中，Runners是用来执行配置文件中定义的脚本的，它可以只服务于特定的项目，也可以服务于所有项目(称为Shared Runner)。
最好不要跟Runner与应用部署在同一台服务器上，因为Runner可能会占用很高的内存。
Runner分类：
- Shared Runners：适用相似的项目的执行，job的pick算法为fair usage，可以避免因某个项目堵死而导致整个Runner停滞。
- Specific Runners：适用于有特定需求的项目，使用FIFO来执行job。
- Group Runners：给同个Group的项目使用的。
Runner需要注册才能使用。
2. Gitlab CI/CD 实践
2.1 数据准备
Docker镜像准备：
REPOSITORY TAG IMAGE ID CREATED SIZE
gitlab/gitlab-runner latest 886bc7da4e1a 8 days ago 371MB
gitlab/gitlab-ce latest a6cd10f85c07 3 weeks ago 1.47GB
centos latest e934aafc2206 2 months ago 199MB
其中：
- gitlab-runner是Gitlab Runner。
- gitlab-ce镜像是作为Gialab代码仓库管理。
- centos镜像是用作模拟部署Node.js应用的服务器。
Node.js项目准备：
.
├── README.md
├── index.js # 主文件
├── node_modules
├── package-lock.json
├── package.json
└── test # 测试目录
└── test.js # 测试文件
其中:
- index.js存放的只是简单的Node.js Guides中的项目
- package.json中的部分内容如下：
"scripts": {
"test": "./node_modules/mocha/bin/mocha",
"start": "node index.js"
}
2.2 实践
- 启动Gitlab
sudo docker run --detach
--publish 443:443 --publish 80:80 --publish 22:22 \
--name gitlab \
--volume /srv/gitlab/config:/etc/gitlab \
--volume /srv/gitlab/logs:/var/log/gitlab \
--volume /srv/gitlab/data:/var/opt/gitlab \
gitlab/gitlab-ce:latest
Gitlab启动会比较慢，稍等几分钟在浏览器中输入localhost即可看到要求输入管理员的密码(具体的这里不详细展开)，登录后会进入项目管理页面，如下：
添加一个项目test到仓库，将本地的Node.js项目与该仓库绑定：
kk$ git remote -v
origin git@127.0.0.1:root/test.git (fetch)
origin git@127.0.0.1:root/test.git (push)
- 注册Gitlab Runner
启动Gitlab Runner：
docker run -d --name gitlab-runner
-v /srv/gitlab-runner/config:/etc/gitlab-runner \
-v /var/run/docker.sock:/var/run/docker.sock \
gitlab/gitlab-runner:latest
进入gitlab-runner镜像中输入gitlab-runner register进行注册：
kk$ docker exec -it gitlab-runner /bin/bash
root@01f8889472f7:/# gitlab-runner register
Running in system-mode.
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
xxx
Please enter the gitlab-ci token for this runner
xxx
Please enter the executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell:
ssh
- 这个token在项目的
Settings-CI/CD-General pipelines Settings-Runner token, 完整的可以参考：Registering Runners- 这里的executor选的是ssh，所以需要在Node.js应用部署的环境中开启ssh服务，同时也要事先安装下Node.js环境(这个只是针对本例子，也可以在脚本中安装)
注册完之后在项目中的Settings-CI/CD-Runners settings可以看到：
对于centos，需要添加下/etc/hosts：
172.17.0.2 gitlab.example.com
具体的ip以实际容器分配ip为准。
- 验证结果
现在push一个commit到gitlab上，可以类似如下的结果：
这样就完成了Gitlab CI的集成.
