GitLabCI-CD示例

还有一种自动化是使用[[../自动化/JenkinsHudson使用Maven构建war包]]

[[GitLab介绍]] CI/CD [[GitLab介绍#CI CD]] 类似Jenkins，可以用于自动构建、发布项目 流程：

1、安装GitLab、GitLab Runner [[GitLab介绍#GitLab Runner]]

2、将runner注册到GitLab上

3、在项目中添加.gitlab-ci.yml文件，指定构建工作的具体事务

需要的套件:GitLab、GitLab Runner

环境安装：

GitLab的安装参考上一篇文档[[GitLab安装记录]]

GitLab Runner安装

rpm安装：

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

gitlab-runner配置文件

vi /etc/gitlab-runner/config.toml

配置文件内容内容描述

concurrent = 10		# 同时进行作业的数量，默认为1
check_interval = 1	# 检查是否有新作业的间隔时间（秒）

[session_server]
  session_timeout = 1800
[[runners]]			# 添加runner后会自动生成的内容
  name = "git server runner"	# 本runner的描述
  url = "http://git2.jiaparts.com/"	# gitlab服务器地址
  token = "一串长度为20的字符串"	# 在gitlab上生成的api访问token，代替gitlab用户的密码
  executor = "ssh"	# 连接到runner机器的方式
  builds_dir = "/jpdata/backup/gitlabrunner/"	# runner作业的临时目录，默认在用户目录下
  [runners.custom_build_dir]
  [runners.ssh]			# 对应上面executor的配置
	user = "root"		# 到runner机器的用户
	host = "1.1.1.1"	# runner的IP
	port = "22"			# runner SSH 端口
	identity_file = "/home/gitlab-runner/.ssh/id_rsa"	# 通过私钥登录到runner服务器，以免输入密码
  [runners.cache]
	[runners.cache.s3]
	[runners.cache.gcs]

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

GitLab Runner注册

GitLab Runner类型分以下几种

• 实例 Runner：全局范围，适用于所有项目和群组。

• 群组 Runner：群组范围，适用于特定群组下的所有项目。

• 项目 Runner：项目范围，适用于特定项目。

如果不需要做细分，推荐用以实例类型注册Runner，就是在GitLab的管理中心注册，可以全局共用。 如果是群组内使用，例如PHP JAVA项目需要不同的环境，可以在对应的群组管理界面注册群组Runner。 单独为项目注册Runner，我的理解是用在特殊的环境要求下才会考虑，例如项目的编译系统要求比较特殊，可以考虑注册一个单独的Runner

注册时需要gitlab提供两个信息，一个是URL，一个是TOKEN，在gitlab上的如下位置可以找到

gitlab-runner 注册

rum安装注册，直接运行如下命令，然后按提示输入相关信息

gitlab-runner register

docker安装的runner则需要通过如下命令，启动一个容器来进行注册，其它操作相同

docker run --rm -t -i -v /srv/gitlab-runner/config:/etc/gitlab-runner gitlab/gitlab-runner register

注册完成之后就能在刚才查看runner信息的地方看到已经连接成功的runner

.GitLab-ci.yml示例

在项目的根目录下添加.gitlab-ci.yml文件，内容大致如下 ^340752

# 配置变量
variables:  
  project_name: "project_name"
  image_name: "image_name"
  docker_build: "images.domain.com/path"
  docker_name: "container_name"
  docker_env: "namespaces_name"
  docker_deploy: "k8s_deployment_file.yaml"

# 定义一个锚，方便后面重复调用下面命令
.job_template: &job_definition

  # 在作业前执行的命令
  before_script:
  - pwd && ls -al       # 查看当前工作目录
  - rsync -av config/$project_name/* $project_name      # 将项目的配置文件单独列了出来，不同环境使用不同内容的配置文件，这里同步相应环境的配置文件到项目中
  - echo `/bin/date +%Y%m%d%H%M` >> $project_name/ver.txt   # 将当前系统时间写入项目下的ver.txt文件
  - docker build -f docker/Dockerfile -t $docker_build/$image_name:`sed -n '1p' ${project_name}/ver.txt`-`sed -n '2p' ${project_name}/ver.txt` .        # 通过在docker目录下的Dockerfile来构建新镜像，并指定新镜像的名称和标签信息
  - docker push $docker_build/$image_name:`sed -n '1p' ${project_name}/ver.txt`-`sed -n '2p' ${project_name}/ver.txt`       # 将构建好的新镜像推送到镜像仓库
  - docker rmi -f $docker_build/$image_name:`sed -n '1p' ${project_name}/ver.txt`-`sed -n '2p' ${project_name}/ver.txt`     # 删除runner上构建的镜像，减少空间占用
  - docker images   # 查看runner上镜像列表

# 定义脚本步骤
stages:
- build
- deploy
- cleanup

# 定义build步骤内容
build:
  stage: build

  # 引用之前定义的锚
  <<: *job_definition

  # 定义build中其它要执行的命令
  script:
  - pwd && ls -al 

  # 定义何时开始job。可以是on_success(仅成功)，on_failure（仅失败），always（总是）或者manual（手动）
  when: manual 


deploy:
  stage: deploy
  environment:
	name: pro   # 环境描述，在运行CI脚本时，会提示部署到什么什么，这里写的是pro，就提示部署到pro。用于做环境识别，影响不大。
  <<: *job_definition 

  script:
  - pwd && ls -al  
  - cat $project_name/ver.txt
  - sed -i "s#${docker_build}.*#${docker_build}\/${image_name}:`sed -n '1p' ${project_name}/ver.txt`-`sed -n '2p' ${project_name}/ver.txt`#g" docker/$docker_deploy     # 通过sed命令将新构建的镜像名称替换到k8s_deployment.yaml中
  - cat docker/$docker_deploy   # 查看k8s_deployment.yaml文件内容

  # 在作业后执行的命令
  after_script:
  - kubectl apply -f  docker/$docker_deploy --record=true       # 通过k8s_deployment.yaml文件来部署，这里用的是apply，也可以create，两者的区别是前者只重新部署yaml文件中有变化的pod、svc、ingress等，没变化的不会重新创建；后者是全新创建所有yaml中的服务，如果有则报已存在的错误无法创建。
  - kubectl get pods -n $docker_env -o wide | grep $docker_name # 查看pod重新部署情况

  when: manual  

delete:     # 停止服务时，通过kubectl delete -f yaml_file 文件来删除所有的pod、svc、ingress等。
  stage: deploy
  environment:
	name: pro
  script:
  - pwd && ls -al docker  
  - kubectl delete -f docker/$docker_deploy
  - kubectl get pods -n $docker_env -o wide | grep $docker_name
  only:
  - master
  when: manual 

cleanup_job:
  stage: cleanup
  script:
  - pwd && ls -al
  when: always 

定义完在项目中启用Auto DevOps，指定要使用的runner即可

流水线计划条件配置入口

gitlab pages，需要配置runner

pages_external_url "http://dier.xyz/" 	# 同时配置dier.xyz域名的DNS解析，添加一个*主机的泛解析即可
gitlab_pages['enable'] = true

Docker容器的其他配置，如果以容器运行gitlab。必须修改如下配置，不然会导致访问pages时一直提示502网关错误 GitLab Pages守护程序在Docker容器中运行时无权绑定挂载。要解决此问题，您需要更改chroot行为：

编辑/etc/gitlab/gitlab.rb。 设置inplace_chroot到true为GitLab页数：

gitlab_pages['inplace_chroot'] = true

gitlab-runner 报如下错误，是git版本太低导致

Reinitialized existing Git repository in ///.git/ fatal: git fetch-pack: expected shallow list fatal: The remote end hung up unexpectedly

安装2.0以上版本

yum install http://opensource.wandisco.com/centos/7/git/x86_64/wandisco-git-release-7-2.noarch.rpm
yum install git -y

---

gitlab 环境变量列表

~~https://docs.gitlab.com/ce/ci/variables/README.html~~ 新的默认环境变量列表

如果在CI/CD脚本中需要配置敏感信息（例如密码、密钥等），可以在单个的项目或者群组或整个项目的 设置--CI/CD--变量 中进行提前定义。这样可以在.gitlab-ci.yaml脚本中可以直接调用对应的变量名来引用敏感信息而不会造成泄露

---

GitLab CI/CD流水线自定义触发规则

GitLab通过配置.gitlab-ci.yml文件中的when来定义对应流水线的统一触发规则

• always 总是自动触发

• manual 手动触发

• never 从不，手动触发也不会生效

如果有时希望部分操作可以自动触发流水线，就可以用到rules来进行定义

当提交信息中包含'deploy'时，则该流水线会被自动触发，用$CI_COMMIT_MESSAGE变量来判断

stages:
  - deploy

deploy:
  stage: deploy
  script:
    - echo "Deploying..."
  rules:
    - if: '$CI_COMMIT_MESSAGE =~ /deploy/'

当使用push同时提交信息中有关键字‘build'时触发build作业；当提交信息中有关键字'test'时，触发test作业

stages:
  - build
  - test

build:
  stage: build
  script:
    - echo "Building..."
  rules:
    - if: '$CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_MESSAGE =~ /build/'


test:
  stage: test
  script:
    - echo "Testing..."
  rules:
    - if: '$CI_COMMIT_MESSAGE =~ /test/'

根据提交内容选择是否自动执行

根据提交信息的开头是否匹配from git2来判断是否自动执行(when的默认策略是on_success)

job:
  rules:
    # 如果提交信息的开头不是"from git2"，则流水线为手动执行，
	# 否则就是自动执行(when的默认策略是on_success)
    - if: $CI_COMMIT_MESSAGE != /^from git2/
      when: manual

定时/计划任务流水线

有时候需要定时运某个作业，可以在项目中配置流水线计划。需要注意的是希望定时运行的作业触发条件不能是手动（ when: manual）。推荐使用Only关键字来配置。定义的值为schedules。 定时任务触发：左侧菜单栏的“构建”--“流水线计划”，在该界面添加定时任务计划即可

...
deploy app:
  stage: deploy
  script:
  - pwd && ls -al
  - echo "deploy 1"

  only:
    - schedules
...

定时任务触发：左侧菜单栏的“构建”--“流水线计划”，在该界面添加定时任务计划即可

如果同一个作业希望即可以定时任务，也可以手动触发，可以用rules来实现。或者将同一个作业复制成两份，一份配置when: manual。 下面以rules配置方法来示范

...
deploy app:
  stage: deploy
  script:
  - pwd && ls -al
  - echo "deploy 1"

  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule" # 定时计划触发
    - if: $CI_PIPELINE_SOURCE == "web"      # 手动触发

...

手动触发流程：左侧菜单栏的“构建”--“流水线”--右上角“运行流水线”。 定时任务触发：左侧菜单栏的“构建”--“流水线计划”，在该界面添加定时任务计划即可

---

更新快到期的token

修改~/.git-credentials中对应主机的token

---

使用token拉代码

# cat .gitconfig 
[user]
	name = root 
	email = [email protected]
[credential]
	helper = store

# cat .git-credentials 
http://root:[email protected]