想象一下,传统的开发流程中,从开发到部署的流程都要手动操作,如果开发流程包含很多部分或要分布部署,频繁的人为操纵会带来许多弊端,如:
工作量大(几乎都是重复工作量)
易遗漏某一环节
易出错
不易协同开发
等等
而使用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
共同学习,写下你的评论
评论加载中...
作者其他优质文章