想象一下，传统的开发流程中，从开发到部署的流程都要手动操作，如果开发流程包含很多部分或要分布部署，频繁的人为操纵会带来许多弊端，如：
工作量大（几乎都是重复工作量）
易遗漏某一环节
易出错
不易协同开发
等等
而使用CI/CD，则开发人员在前期完成相关配置之后，后期只需关注业务开发即可，其他的CI/CD会帮忙实现。Gitlab CI/CD流程如下：
image
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 - deploybuild_job: # 定义一个job stage: build # 设置job所属的stage，默认是test tags: # 定义tags，用来匹配相应的Runner来执行 - my-tag script: # 定义后面Runner来执行的具体脚本 - cd /root/test - git pull - npm installtest_job: stage: test tags: - my-tag script: - cd /root/test - npm testdeploy_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即可看到要求输入管理员的密码(具体的这里不详细展开)，登录后会进入项目管理页面，如下：
gitlab.png
添加一个项目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 registerRunning 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可以看到：
gitlab runner.png
对于centos，需要添加下/etc/hosts：
172.17.0.2 gitlab.example.com
具体的ip以实际容器分配ip为准。
验证结果
现在push一个commit到gitlab上，可以类似如下的结果：
pipeline.png
这样就完成了Gitlab CI的集成.
作者：keith666
链接：https://www.jianshu.com/p/86411a27f02a