GitLab-CI 从安装到差点放弃

故事是这样的..
咱们源码从github迁移到自主搭建的gitlab服务器管理，之前用github的时候是使用jenkins进行持续集成的，原本应用上jenkins我只要配一下webhook就能够了，可我就是任性。
我心想，既然已经迁移到gitlab了，为什么不用用gitlab-ci呢，更况且gitlab宣称集成了gitlab-ci，应该很快就能应用上。
我正是这样把本身推动坑的。

名词解释

进坑前先理清一些名词，以及他们之间的关系。

1. Gitlab

GitLab是一个利用Ruby on Rails开发的开源应用程序，实现一个自托管的Git项目仓库，可经过Web界面进行访问公开的或者私人项目。
它拥有与GitHub相似的功能，可以浏览源代码，管理缺陷和注释。能够管理团队对仓库的访问，它很是易于浏览提交过的版本并提供一个文件历史库。团队成员能够利用内置的简单聊天程序（Wall）进行交流。它还提供一个代码片断收集功能能够轻松实现代码复用，便于往后有须要的时候进行查找。

2. Gitlab-CI

Gitlab-CI是GitLab Continuous Integration（Gitlab持续集成）的简称。
从Gitlab的8.0版本开始，gitlab就全面集成了Gitlab-CI,而且对全部项目默认开启。
只要在项目仓库的根目录添加.gitlab-ci.yml文件，而且配置了Runner（运行器），那么每一次合并请求（MR）或者push都会触发CI pipeline。

3. Gitlab-runner

Gitlab-runner是.gitlab-ci.yml脚本的运行器，Gitlab-runner是基于Gitlab-CI的API进行构建的相互隔离的机器（或虚拟机）。GitLab Runner 不须要和Gitlab安装在同一台机器上，可是考虑到GitLab Runner的资源消耗问题和安全问题，也不建议这二者安装在同一台机器上。

Gitlab Runner分为两种，Shared runners和Specific runners。
Specific runners只能被指定的项目使用，Shared runners则能够运行全部开启 Allow shared runners选项的项目。

4. Pipelines

Pipelines是定义于.gitlab-ci.yml中的不一样阶段的不一样任务。
我把Pipelines理解为流水线，流水线包含有多个阶段（stages），每一个阶段包含有一个或多个工序（jobs），好比先购料、组装、测试、包装再上线销售，每一次push或者MR都要通过流水线以后才能够合格出厂。而.gitlab-ci.yml正是定义了这条流水线有哪些阶段，每一个阶段要作什么事。

5. Badges

徽章，当Pipelines执行完成，会生成徽章，你能够将这些徽章加入到你的README.md文件或者你的网站。

徽章的连接形如：
http://example.gitlab.com/namespace/project/badges/branch/build.svg
咱们用gitlab项目的徽章做为例子：

安装配置

这里跳过Gitlab的安装，请自行谷歌。可是对于安装gitlab有一点提醒，就是建议使用官方推荐的集成安装包的方式安装，经过源码安装会有不少坑踩不完。

安装gitlab-ci-multi-runner

1. 若是想要使用docker runner，则须要安装docker。（可选）
   curl -sSL https://get.docker.com/ | sh

由于docker须要linux内核在3.10或以上，安装前能够经过uname -r查看Linux内核版本。

1. 添加Gitlab的官方源：

   # For Debian/Ubuntu
   curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.deb.sh | sudo bash
   
   # For CentOS
   curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh | sudo bash

2. 安装

   # For Debian/Ubuntu
   sudo apt-get install gitlab-ci-multi-runner
   
   # For CentOS
   sudo yum install gitlab-ci-multi-runner

3. 注册Runner
   Runner须要注册到Gitlab才能够被项目所使用，一个gitlab-ci-multi-runner服务能够注册多个Runner。

   $ sudo gitlab-ci-multi-runner register
   
   Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com )
   https://mygitlab.com/ci
   Please enter the gitlab-ci token for this runner
   xxx-xxx-xxx
   Please enter the gitlab-ci description for this runner
   my-runner
   INFO[0034] fcf5c619 Registering runner... succeeded
   Please enter the executor: shell, docker, docker-ssh, ssh?
   docker
   Please enter the Docker image (eg. ruby:2.1):
   node:4.5.0
   INFO[0037] Runner registered successfully. Feel free to start it, but if it's
   running already the config should be automatically reloaded!

4. 更新Runner
   若是须要更新Runner，只须要执行如下脚本：

   # For Debian/Ubuntu
     sudo apt-get update
     sudo apt-get install gitlab-ci-multi-runner
     
     # For CentOS
     sudo yum update
     sudo yum install gitlab-ci-multi-runner

5. Runner高级配置
   经过gitlab-ci-multi-runner register注册的Runner配置会存储在/etc/gitlab-runner/config.toml中，若是须要修改可直接编辑该文件。详见这里

   concurrent = 4
   check_interval = 0
   
   [[runners]]
     name = "test"
     url = "http://your-domain.com/ci"
     token = "your-token"
     executor = "docker"
     [runners.docker]
       tls_verify = false
       image = "node:4.5.0"
       privileged = false
       disable_cache = false
       volumes = ["/cache"]
     [runners.cache]
     [runners.kubernetes]
       host = ""
       cert_file = ""
       key_file = ""
       ca_file = ""
       image = ""
       namespace = ""
       privileged = false
       cpus = ""
       memory = ""
       service_cpus = ""
       service_memory = ""

到这里咱们的Runner就安装配置好了，接下来是对项目根目录中.gitlab-ci.yml进行配置。

配置构建任务

1. 在项目根目录添加.gitlab-ci.yml文件
   关于该文件的各项配置请见

2. 示例：

   # 这里使用了我本身的docker image，配置了本身须要的环境
   image: wuyanxin/node
   
   variables:
   MYSQL_DATABASE: wan_ark-unit
   MYSQL_ALLOW_EMPTY_PASSWORD: "yes"
   
   # 关于service请见: http://docs.gitlab.com/ce/ci/docker/using_docker_images.html#what-is-service
   services:
   - mysql:5.6
   - redis:3.2.4
   
   stages:
   - test
   - eslint
   - deploy
   
   before_script:
   - echo 'REDIS_HOST=redis' >> .env
   - echo 'DB_HOST=mysql' >> .env
   - yarn install
   
   test_service:
   stage: test
   script:
   - npm run build
   - npm test
   
   eslint_src: 
   stage: eslint
   script:
   - npm run lint
   allow_failure: true
   
   deploy:
   stage: deploy
   script:
   - echo 'deployd!'
   only: 
   - master

   这里使用了nodejs项目做为例子，其余语言相似语法。

3. 执行结果
   

最后

这是我最近对于Gitlab CI的实验记录，对于Gitlab CI的使用体验我给82分。虽然在实验过程当中踩了不少坑，真的踩到差点放弃了，因此记录一下个人实验过程，但愿对他人有帮助。
关于在这个过程当中踩到的坑以及构建速度优化请关注我下期文章。

参考

1. https://zh.wikipedia.org/wiki...

2. https://docs.gitlab.com/ce/ci...