资讯专栏INFORMATION COLUMN

gitlab-ci坑后感与指北

jerry / 3100人阅读

摘要:本文的目的最主要是备忘其次是分享疗效并不能让你一下子掌握这只是一个比较完整的解决方案其他基础知识自行补充基调首先这不是屠龙刀不要奢望一篇文章可以走遍天下这里只是提供一个具体的落地方案一个具体的技术选型阶段代码仓库关于代码仓库本文选取的方案是

本文的目的:

最主要是备忘, 其次是分享

疗效:

并不能让你一下子掌握CI/CD, 这只是一个比较完整的解决方案,其他基础知识,自行补充.


基调
首先,这不是屠龙刀,不要奢望一篇文章可以走遍天下.这里只是提供一个具体的落地方案, 一个具体的技术选型.

阶段1: 代码仓库

关于 代码仓库, 本文选取的方案是 gitlab

gitlab的搭建:

以目前的情况来说, 推荐使用docker来搭建你的系统, 不然你会陷入各种膜明其妙的问题.

docker的知识, 请自行补充一下,篇幅有限不能展开细说.

在这里我推荐一个:

https://hub.docker.com/r/sameersbn/gitlab/

打开以后直接搜索Quick Start, 按照docker-compose的方式启动你的gitlab.

不要对英文心存恐惧 ---- 孔子

下载好 docker-compose.yml之后不要急着启动, 需要修改几个参数:

需要学习一点点yml的知识, 大约5分钟, 自行google

GITLAB_SECRETS_DB_KEY_BASE,

GITLAB_SECRETS_SECRET_KEY_BASE,

GITLAB_SECRETS_OTP_KEY_BASE

上面三个是gitlab用于加密时用的key, 随便给个长度64的字符串, 这块不做 深究.

GITLAB_ROOT_EMAIL

GITLAB_ROOT_PASSWORD

上面两个就是初始化时管理员账号的账号密码, 按自己的需要填写

GITLAB_HOST

这是 gitlab 内部使用的地址, 这关系到你gitlab页面上的项目地址,没设置的话, 到时候显示的是127.0.0.1, 这个鬼才能clone下来.

这个 host 一旦设置, 初始化完就改不了了, 所以一定要在第一次启动之前 就设置好.
启动

docker-compose up

一系列的初始化信息以后, 你就能访问你的gitlab了.

默认是 http://{你的IP}:10080

其他关于gitlab的使用技巧, 就不深入了.
能关注这篇文章的都不是萌新了,这些内容自己补充吧.

阶段2: 提交触发

接上文.

gitlab-ci在最新版的gitlab已经是内置的了, 只要项目里有.gitlab-ci.yml,同时有对应的gitlab-runner, 就能实现CI, 相比之下不需要太多的配置.

名词解释:

.gitlab-ci.yml:

这是gitlab-ci使用的任务描述文件, 里面主要是定义CI的过程需要执行哪些行为, 简单说就是, 要进行哪几个步骤, 每个步骤是哪些命令.

gitlab-runner:

另一个程序, 也可以用docker启动, 就是负责执行 CI 任务的机器人, runner这块后面会展开讲.


启动并注册gitlab-runner

我们还是使用docker来启动,这是一个大方向

docker run -d --name gitlab-runner --restart always 

-v /srv/gitlab-runner/config:/etc/gitlab-runner 

-v /var/run/docker.sock:/var/run/docker.sock 

gitlab/gitlab-runner:latest


想深入了解的话, 请看 

https://docs.gitlab.com/runne...

敲黑板!!

在这里, 我们将宿主机的docker.sock映射进去,让runner可以跟宿主用同一个daemon, (意味着你进去runner内部执行docker images是可以看到外面的镜像列表的), 这样做是埋下一个伏笔, 以便后面阶段使用dind(docker in docker)时, 获得更好的体验.


继续

好了, 这个时候你启动了一个runner, 你要告诉它应该到哪里去"服役",

这一步叫做: 注册

注册runner的方式请看 

https://docs.gitlab.com/runne...

不过, 还是请你使用以下命令来注册:

docker exec -it gitlab-runner gitlab-runner register 

--docker-volumes /var/run/docker.sock:/var/run/docker.sock 

--docker-privileged

这里使用了两个参数, 都是为了 docker in docker 能得到更好的体验而服务的.

输入以上命令后, 根据提示填写信息, 其中:

host,token 这些, 请打开你刚装好的gitlab, 进入 Admin area-Runners ,然后照着填写就是了

特别注意期间会让你选一个executor 类型, 个人推荐最好的方式是docker , 至于shell这种方式, 玩玩可以,实际使用时副作用太多.

更多参数的细节, 自行研究.

完成以上步骤之后, 你在gitlab - Admin area-Runners 页面就能看到注册好的runner了, 当然你现在还是感觉不到它的作用.

这个环节内容比较多, 操作比较多, 走到这里建议休息一下喝杯茶.



阶段3: Runner Job

这个阶段, 是指代码提交以后, gitlab-runner会自动读取项目的.gitlab-ci.yml, 运行里面定义的每个Job.

这里给出一个极简的.gitlab-ci.yml例子,

它做的就是, 在提交代码以后, 自动的测试, 自动的构建, 自动的发布 :

stages:
  - test
  - build
  - deploy

job_01:
  stage: test
  image: dev_tool/node_builder:1.0.0
  script: 
   - npm install --registry=https://registry.npm.taobao.org
   - node server.js &
   - node test_api.js

job_02:
  stage: build
  image: gitlab/dind
  script:
  - docker build -t ci-demo:latest .
   
job_03:
  stage: deploy
  image: dev_tool/rancher-cli:latest
  script:
  - rancher-tool init
  - rancher up -d  --pull --force-upgrade --confirm-upgrade

一目了然, 上面的第一个定义: stages 数组,

意思是这个项目的CI/CD过程要执行三个步骤(stage),

分别是test测试-build编译-deploy发布

然后下面的三个job_*,名字是随意的, 重点是里面的stage属性,

告诉gitlab-ci这个任务是在哪个stage执行的,

一个stage你可以写很多个job

敲黑板!!!

需要注意的是, 我们之前选择了docker executor, job里面就要声明image属性,指定这个Jobscripts要在哪个image里面运行.

重点说明!! 再次大力敲黑板!!

这里第二步使用了gitlab/dind , 仔细看script, 这是在一个容器里面去构建一个镜像, 为了整体体验构建效率着想, 我们之前注册runner的时候,将宿主机的docker.sock映射进去是十分必要的!!
(重新翻上去看吧)

看到这里, 聪明的朋友已经发现了,

我们需要自己打造一批用于运行Job的基础镜像, 这些镜像里要预先安装好我们需要的依赖环境.

举个栗子:

你要在build这一步做webpack打包的话, 你要准备好一个内部安装好webpack的镜像(相关的node,npm之类就更不用说了)

听起来好麻烦?

也不是, 这是个 功在当代,利在千秋 的行为, 前期打造好基础镜像, 后面的项目就可以很容易写CI Job了.

更多 gitlab-ci.yml 的高级写法,还是建议看官方文档
https://docs.gitlab.com/ee/ci...

阶段4: 坐享其成 && 总结

如果按照上面的步骤把这个系统搭建起来以后, 你应该已经能够感受到gitlab-ci带来的好处了.

现在你只管提交代码, 就能快速看到新功能集成到相应的环境了.

此后, 你只要写好每一步的Job 就可以了.

尤其是测试这个环节.

尤其是测试这个环节.

尤其是测试这个环节.


后记

gitlab 真的很吃资源, 虚拟机玩够呛, 团队用的话, 建议装一台PC来搭建.

基础镜像别偷懒, 多打磨,让你的scripts可以更简洁

更进一步的话, 自己开发一系列的命令行工具, 让你的scripts更强大.

有事找我, 包教会.

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/28033.html

相关文章

  • 持续集成之.gitlab-ci.yml篇

    摘要:因为可以安装到不同的机器上,所以在构建任务运行期间并不会影响到的性能。注册打开中的项目页面,在项目设置中找到在运行的机器上,用命令行注册,比如按照提示一步一步安装就可以了。任务将按此顺序执行。当然,这是不符合语义的。 在介绍.gitlab-ci.yml之前,我们先看几个概念: GitLab Runner 一般来说,构建任务都会占用很多的系统资源 (譬如编译代码),而 GitLab CI...

    Ajian 评论0 收藏0
  • React Native项目自动化打包发布

    摘要:所以在此给大家分享一下不使用构建工具实现项目自动化打包发布的思路。对于一个前端项目来说,自动化的构建是很有必要的,同时我们也可以通过实现更多的功能比如代码检测,单元测试等等。另外这种思路同样适用于其他项目等前端项目,等移动端项目。 今天这篇文章的目的是在rn项目的构建,并不会涉及到rn框架或者使用的讲解,说起构建,特别是前端构建大家应该很快会想到webpack、Grunt、 Gulp等...

    desdik 评论0 收藏0
  • 基于 GitLab CI 搭建前端自动构建环境

    摘要:什么是持续集成持续集成,简称指的是,频繁地一天多次将代码集成到主干。如图什么是一次其实相当于一次构建任务,里面可以包含多个流程,如安装依赖运行测试编译部署测试服务器部署生产服务器等流程。参考链接用进行持续集成 什么是持续集成 ? 持续集成(Continuous integration,简称CI)指的是,频繁地(一天多次)将代码集成到主干。 GitLab CI 什么是 GitLab CI...

    Warren 评论0 收藏0
  • webkit内核浏览器自定义滚动条样式

    摘要:滚动条两端的按钮。内层轨道,滚动条中间部分除去。有如下功能若是水平滚动条,则属性不起作用,属性用来控制滚动条相应部分竖直方向高度若是竖直滚动条,则属性不起作用,属性用来控制相应部分的宽度。 CSS ::-webkit-scrollbar { /* 1 */ } ::-webkit-scrollbar-button { /* 2 */ } :...

    testbird 评论0 收藏0
  • webkit内核浏览器自定义滚动条样式

    摘要:滚动条两端的按钮。内层轨道,滚动条中间部分除去。有如下功能若是水平滚动条,则属性不起作用,属性用来控制滚动条相应部分竖直方向高度若是竖直滚动条,则属性不起作用,属性用来控制相应部分的宽度。 CSS ::-webkit-scrollbar { /* 1 */ } ::-webkit-scrollbar-button { /* 2 */ } :...

    Achilles 评论0 收藏0

发表评论

0条评论

jerry

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<