博客

一、安装GitLab（单独）

1. yum源安装

这个方法比较方便，傻瓜式安装即可

1. 配置yum源

   vim /etc/yum.repos.d/gitlab-ce.repo
   复制以下内容：
   
   [gitlab-ce]
   name=Gitlab CE Repository
   baseurl=https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el$releasever/
   gpgcheck=0
   enabled=1
   

2. 更新yum缓存

   
yum clean && yum makecache


3. 安装，默认安装最新版本

   
yum install -y gitlab-ce


2. Docker安装

1. 下载镜像，默认案子最新版

   
docker pull gitlab/gitlab-ce


2. 运行镜像，指定需要映射出的端口

   # -d：后台运行
   # -p：将容器内部端口向外映射
   # --name：命名容器名称
   # -v：将容器内数据文件夹或者日志、配置等文件夹挂载到宿主机指定目录
   docker run -d  -p 443:443 -p 80:80 -p 222:22 --name gitlab --restart always -v /etc/gitlab/config:/etc/gitlab -v /etc/gitlab/logs:/var/log/gitlab -v /etc/gitlab/data:/var/opt/gitlab gitlab/gitlab-ce
   

3. 修改配置文件

使用yum源安装的时候，后台使用了nginx做了代理，但是使用docker安装的时候，使用的是Docker镜像自己的HostName。

1. 修改
   
/etc/gitlab/gitlab.rb


# gitlab.rb文件内容默认全是注释
# 配置http协议所使用的访问地址,不加端口号默认为80
external_url 'http://ip:23333'
# 配置ssh协议所使用的访问地址和端口
gitlab_rails['gitlab_ssh_host'] = 'ip'
gitlab_rails['gitlab_shell_ssh_port'] = 23334 # 此端口是run时22端口映射的222端口

2. 重启GitLab

   # yum源
   gitlab-ctl start
   # docker
   docker restart gitlab
   

二、安装GitRunner（单独）

1. 获取rpm安装包

   curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh | sudo bash
   

2. 安装

   
yum install -y gitlab-ci-multi-runner


3. 设置Docker权限

   # 主要是后续的Runner需要使用Docker
   usermod -aG docker gitlab-runner
   

三、安装Gitlab+GitRunner（Docker-compose）# 不推荐

一般来说，构建任务都会占用很多的系统资源 (譬如编译代码)，而

GitLab CI

又是

GitLab

的一部分，如果由

GitLab CI

来运行构建任务的话，在执行构建任务的时候，

GitLab

的性能会大幅下降。


GitLab CI

最大的作用是管理各个项目的构建状态，因此，运行构建任务这种浪费资源的事情就交给

GitLab Runner

来做。

所以把

GitLab Runner

安装到不同的机器上，在构建任务运行期间并不会影响到

GitLab

的性能。

这也就是为什么不推荐使用这种办法安装。

1. 配置文件
   
docker-compose.yml


   version: '3'  #1
   services:
       gitlab:
         image: gitlab/gitlab-ce:latest  #2
         container_name: "gitlab"
         restart: unless-stopped
         privileged: true
         hostname: "172.17.193.109:7780"  #3
         environment:
           #4
           GITLAB_OMNIBUS_CONFIG: |
             # external_url 'http://172.17.193.109:7780'
             gitlab_rails["time_zone"] = "Asia/Shanghai"
             gitlab_rails["gitlab_shell_ssh_port"] = 7722
             nginx["listen_port"] = 80
         #5
         ports:
           - "7780:80"
           - "7722:22"
         #6
         volumes:
           - /home/cache/gitlab/config:/etc/gitlab
           - /home/cache/gitlab/data:/var/opt/gitlab
           - /home/cache/gitlab/logs:/var/log/gitlab
       gitlab-runner:
         container_name: gitlab-runner
         image: gitlab/gitlab-runner:latest  #7
         restart: always
         volumes:
           - "/var/run/docker.sock:/var/run/docker.sock"
           - "/home/cache/gitlab/runner-config:/etc/gitlab-runner"
   

   • #1：为 docker-compose 文件的版本号，它和 docker 版本有一个对应，具体在 docker 官方文档中有明确说明。一般写 3 就可以了。
   • #2：当前部署使用 Gitlab 官方最新版的镜像。
   • #3：hostname 填写的是部署成功后，Gitlab 的入口地址。由于我使用的 docker 不在本地，所以配置了一个 ip 地址，本地写 localhost 就可以了。当前配置的意思为，通过 172.17.193.109 的 7780 端口访问 Gitlab 页面。
   • #4：GITLAB_OMNIBUS_CONFIG 为 Gitlab 的配置参数，对应
     
/etc/gitlab/gitlab.rb

     。该文件下的所有键值对都可以在这里进行配置，容器启动时会自动配置进去。当然也可以在 Gitlab 容器启动后，手动修改 gitlab.rb 文件。
   • #5：配置了需要用到的两个端口。默认 Gitlab 容器内部 80 端口用于 Gitlab 页面的访问，22 用于 ssh 连接远程仓库。分别对其进行外网映射。
   • #6：volume 映射，三个 volume 和官方文档一致就可以了。
   • #7：这里用的是 gitlab-runner 镜像，部分博客使用的 gitlab-ci-multi-runner 是旧版本，最新的镜像统一修改为 gitlab-runner。

2. 运行：
   
docker-compose -f docker-compose up -d --build


四、GitLab配置GitRunner以及使用

1. 创建一个项目

略

2. 注册Runner

1. 打开创建好的项目；Setting —> CI/CD —> Runners —> Expand；

2. 进入安装了GitRunner服务的服务器；

3. 配置Runner，执行：
   
gitlab-runner register

   ；

   Runtime platform                                    arch=amd64 os=linux pid=43 revision=a987417a version=12.2.0
   Running in system-mode.
   
   Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
   ${gitlab项目配置中显示的ip}
   Please enter the gitlab-ci token for this runner:
   ${gitlab项目配置中显示的token}
   Please enter the gitlab-ci description for this runner:
   [bb6040f1cd04]: ${这个runner的说明}
   Please enter the gitlab-ci tags for this runner (comma separated):
   ${这个runner需要运行哪些tag，比如maven,test,java等等标签}
   Registering runner... succeeded                     runner=zpzZ-shs
   Please enter the executor: docker-ssh, shell, ssh, virtualbox, docker+machine, custom, parallels, docker-ssh+machine, kubernetes, docker:
   ${这个runner需要运行在哪？docker或者shells等}
   Please enter the default Docker image (e.g. ruby:2.6):
   ${选择docker之后，需要配置这个runner默认的根镜像}
   Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!
   

4. 注册完毕之后，刷新Gitlab项目页面，就可以看到刚才注册的Runner。

3、配置Runner

由于刚刚只是根据流程配置了一些基本的信息，还有额外的参数要配置就需要修改对应的配置文件了。

可以直接修改映射到本地的配置文件：

config.toml

。每配置一个 runner 就会在配置文件中生成一个

[[runners]]

。

# 文件的目录，根据安装方式的不同，目录也不同。
# yum安装目录:/etc/gitlab-runner/config.toml
# docker安装目录：配置文件映射的；

# 修改runner
[[runners]]
  name = "hello,spring boot!"
  url = "http://172.17.193.109:7780/"
  token = "u8_Y5rLQazUmBZar9eys"
  executor = "docker"
  [runners.custom_build_dir]
  [runners.docker]
    tls_verify = false
    image = "docker:latest"
    privileged = true  # 默认为 false，需改为 true。自动跳过health check。
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    volumes = ["/cache","/usr/local/maven:/root/.m2"] # 修改cache目录。
    shm_size = 0

# 别的参数基本没有修改，只是修改了cache缓存目录，修改成了本地的maven。这样在处理依赖时可以直接使用本地的环境，并且可以用阿里云镜像源。

五、CI/CD的测试以及使用

1. 文件目录以及配置文件说明

├── Dockerfile	# 构建Docker镜像的配置文件
├── .gitlab-ci.yml	# 构建Gitlab CI/CD的配置文件
├── pom.xml		# 项目maven依赖
└── src		# 项目代码
    ├── main
    │   ├── java
    │   │   └── com
    │   │       └── example
    │   │           └── demo
    │   │               └── DemoApplication.java
    │   └── resources
    │       └── application.properties
    └─────────────────────────────────────

2. 测试代码

• 
DemoApplication.java


  package com.example.demo;
  
  import org.springframework.boot.*;
  import org.springframework.boot.autoconfigure.*;
  import org.springframework.web.bind.annotation.*;
  
  @SpringBootApplication
  @RestController
  public class DemoApplication {
  
  	@GetMapping("/")
  	String home() {
  		return "Hello i'm mengli!";
  	}
  
  	public static void main(String[] args) {
  		SpringApplication.run(DemoApplication.class, args);
  	}
  }
  

• 
application.properties


  server.port=11111
  

3.

Dockerfile

文件修改

# Dockerfile的具体解释此处就不详解了
# 依赖的构建镜像
FROM maven:3.5-jdk-8
# 进入tmp目录
VOLUME /tmp
# 复制jar包
ADD target/demo-0.0.1-SNAPSHOT.jar app.jar
# 抛出11111端口号
EXPOSE 11111
# 需要执行的语句
ENTRYPOINT ["java","-Djava.security.egd=file:/dev/./urandom","-jar","/app.jar"]

4.

.gitlab-ci.yml

文件修改

# 当前runner依赖的基础镜像
image: docker:latest
# 声明一些参数
variables:
  DOCKER_HOST: tcp://{dockerIp}:2375
  TAG: minerunner:v1
# 声明当前ci需要执行的步骤
stages:
  - package
  - develop
# 相当于创建一个全局函数
.tagsFlag: &tagsFlagDef # 创建一个锚，'tagsFlagDef'
  # 声明当前任务是在哪个runner下执行
  tags:
    - maven
  # 声明哪几个分支提交的时候,执行.
  only:
    - master
    - pro
# 同上
.imageFlag: &imageFlagDef # 创建一个锚，'imageFlagDef'
  image: maven:3.5-jdk-8
  <<: *tagsFlagDef
# 开始编写任务细则
# 这个名字无所谓,随便起
package:
  # 这个参数后面声明的就是上面stages里面声明的
  stage: package
  # 引入上面的函数
  <<: *imageFlagDef
  # 需要执行的操作
  script:
    - mvn clean package -Dmaven.test.skip=true
  artifacts:
    paths:
      - target/*.jar
# 部署
develop:
  stage: develop
  <<: *tagsFlagDef
  script:
    - docker build -t $TAG .
    - docker rm -f runnerdemo || true
    - docker run -d -p 11111:11111 --name runnerdemo $TAG

4.1

.gitlab-ci.yml

配置详解

更具体的解释可以详见这篇博文：

https://segmentfault.com/a/1190000011881435


4.2 更具体的配置文件

# 定义 stages（阶段）。任务将按此顺序执行。
stages:
  - build
  - test
  - deploy

# 定义 job（任务）
job1:
  stage: test
  tags:
    - XX #只有标签为XX的runner才会执行这个任务
  only:
    - dev    #只有dev分支提交代码才会执行这个任务。也可以是分支名称或触发器名称
    - /^future-.*$/ #正则表达式，只有future-开头的分支才会执行
  script:
    - echo "I am job1"
    - echo "I am in test stage"

# 定义 job
job2:
  stage: test    #如果此处没有定义stage，其默认也是test
  only:
    - master    #只有master分支提交代码才会执行这个任务
  script:
    - echo "I am job2"
    - echo "I am in test stage"
  allow_failure: true #允许失败，即不影响下步构建    

# 定义 job
job3:
  stage: build
  except:
    - dev #除了dev分支，其它分支提交代码都会执行这个任务
  script:
    - echo "I am job3"
    - echo "I am in build stage"
  when: always #不管前面几步成功与否，永远会执行这一步。它有几个值：on_success （默认值）\on_failure\always\manual（手动执行）

# 定义 job
.job4:    #对于临时不想执行的job，可以选择在前面加个"."，这样就会跳过此步任务，否则你除了要注释掉这个jobj外，还需要注释上面为deploy的stage
  stage: deploy
  script:
    - echo "I am job4"

# 模板，相当于公用函数，有重复任务时很有用
.job_template: &job_definition  # 创建一个锚，'job_definition'
  image: ruby:2.1
  services:
    - postgres
    - redis

test1:
  <<: *job_definition           # 利用锚'job_definition'来合并
  script:
    - test1 project

test2:
  <<: *job_definition           # 利用锚'job_definition'来合并
  script:
    - test2 project

#下面几个都相当于全局变量，都可以添加到具体job中，这时会被子job的覆盖    

before_script:
  - echo "每个job之前都会执行"

after_script:
  - echo "每个job之后都会执行"

variables:    #变量
  DATABASE_URL: "postgres://postgres@postgres/my_database"  #在job中可以用${DATABASE_URL}来使用这个变量。常用的预定义变量有CI_COMMIT_REF_NAME（项目所在的分支或标签名称），CI_JOB_NAME（任务名称），CI_JOB_STAGE（任务阶段）
  GIT_STRATEGY: "none" #GIT策略，定义拉取代码的方式，有3种：clone/fetch/none，默认为clone，速度最慢，每步job都会重新clone一次代码。我们一般将它设置为none，在具体任务里设置为fetch就可以满足需求，毕竟不是每步都需要新代码，那也不符合我们测试的流程

cache:    #缓存
  #因为缓存为不同管道和任务间共享，可能会覆盖，所以有时需要设置key
  key: ${CI_COMMIT_REF_NAME}  # 启用每分支缓存。
  #key: "$CI_JOB_NAME/$CI_COMMIT_REF_NAME" # 启用每个任务和每个分支缓存。需要注意的是，如果是在windows中运行这个脚本，需要把$换成%
  untracked: true    #缓存所有Git未跟踪的文件
  paths:    #以下2个文件夹会被缓存起来，下次构建会解压出来
    - node_modules/
    - dist/  

5. 提交测试

1. 提交代码；

2. 打开Gitlab项目界面 —> CI/CD；
   
   

3. 随便点击一个进去就可以看见详细的构建过程。

4. 忽略构建。

# 在commit的时候，在提交信息中添加 [ci skip] 或者 [skip ci] 就可以使此次提交不构建CI/CD
# 就好像上图中的最顶上那个，状态为： skippend
# ex:
git commit -m '测试一下忽略构建CI [ci skip]'

5. 构建成功之后,访问测试。

# 访问
crul localhost:1111
# 返回
Hello i'm mengli!