gitlab runner 使用案例

接上文GitLab-Runner 从安装到配置以一个使用案例说明docker runner的使用

1. 配置文件的大概说明

因为gitlab使用的docker版本的：gitlab/gitlab-ce:12.10.14-ce.0，所以gitlab-runner采用docker的版本是：gitlab/gitlab-runner:v12.10.3。所以gitlab-runner的docker-compose配置内容如下：

  gitlab-runner:
    hostname: gitlab-runner
    container_name: gitlab-runner
    image: gitlab/gitlab-runner:v12.10.3
    restart:
      always
    userns_mode:
      "host"
    volumes:
     - /etc/localtime:/etc/localtime:ro
     - /var/run/docker.sock:/var/run/docker.sock
     - $PWD/gitlab-runner/config:/etc/gitlab-runner

经过修改后的gitlab-runner的gitlab-runner/config/config.toml 配置文件如下：

concurrent = 1
check_interval = 0

[session_server]
  session_timeout = 1800

[[runners]]
  name = "gitlab-runner"
  url = "http://192.168.xxxx"
  token = "tGeDQLKxxxx"
  executor = "docker"
  environment = ["CI_REGISTRY=registry.cn-guangzhou.aliyuncs.com"]
  [runners.custom_build_dir]
  [runners.cache]
    [runners.cache.s3]
    [runners.cache.gcs]
  [runners.docker]
    tls_verify = false
    image = "docker:19.03.13"
    pull_policy="if-not-present"
    userns_mode = "host"
    privileged = true
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    shm_size = 0
    volumes = ["/var/run/docker.sock:/var/run/docker.sock","/root/.docker/config.json:/root/.docker/config.json","/cache"]

这里的volumes 挂载了/root/.docker/config.json:/root/.docker/config.json的目的是为了在执行自动化的时候，可以不用每次都登录远端的registry才能推送镜像。

2. gitlab 上 runner 的情况

使用root用户登录了gitlab后，在Runners页添加runner后的信息如下：

3. 创建部署用户

在需要部署的机器上，创建一个用于操作docker的普通用户，以dku为例：

useradd -u 5000 dku
mkdir /home/dku/.ssh
chmod 700 /home/dku/.ssh
usermod -G docker dku
cp -r /root/.docker/ /home/dku
chown -R dku:dku /home/dku/.docker/

复制/root/.docker/到/home/dku 是因为.docker 目录里有一个config.json文件，后面需要使用这个用户来拉取镜像，就需要这个文件。

另外还需要创建一个 SSH 密钥：
GitLab CI/CD 将使用密钥登录服务器并执行部署例程。

su - dku
ssh-keygen

生成完秘钥后，需要将公钥复制到authorized_keys中：

cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

此时，id_rsa和id_rsa.pub备份下来后可以删除了。在要部署的客户机上，只需要有一个authorized_keys文件即可。

4. 将私钥添加到 GitLab CI/CD 变量中

将 SSH 私钥存储在 GitLab CI/CD 文件变量中，方便Pipelines管道可以使用该密钥登录到服务器。
当 GitLab 创建 CI/CD 管道时，它会将所有变量发送到相应的运行器，并且这些变量将被设置为作业持续时间的环境变量。特别是，文件变量的值存储在文件中，环境变量将包含该文件的路径。
在设置变量部分时，还可以服务器 IP 和服务器用户等信息添加在web页面里。也可以添加在.gitlab-ci.yml文件里。
这里只添加一个密钥的文件变量：
在Gitlab的项目中的Settings > CI / CD > Variables并单击Add Variable。填写如下：

• Key： ID_RSA
• Value：id_rsa文件里的内容
• Type：File
• Environment scope：All (default)
• Protect variable：未选中
• Mask variable：未选中

这里即使勾选的Mask variable掩码值，也不会被屏蔽，因为它不符合正则表达式要求（具体看masked-variables说明）
Protect variable保护变量，如果勾选了，就需要在受保护分支和标签上才能使用这个变量值。

5. 配置.gitlab-ci.yml文件

这里的.gitlab-ci.yml样例文件如下：

variables:
  PUSH_CI_REGISTRY_IMAGE: registry.cn-guangzhou.aliyuncs.com/demo
  CI_REGISTRY_IMAGE: registry-vpc.cn-guangzhou.aliyuncs.com/demo
  SERVER_IP: 8.134.***
  SERVER_USER: dku
  TARGET_DIR: /data/
  COMPOST_FILE: docker-compose.yml

stages:
  - build
  - deploy

build:
  stage:
    build
  only:
    - tags
  tags:
    - ing
  when:
    manual
  script:
    - docker build -t "$PUSH_CI_REGISTRY_IMAGE":"$CI_COMMIT_TAG" -f Dockerfile .
    - docker push "$PUSH_CI_REGISTRY_IMAGE:$CI_COMMIT_TAG"

deploy:
  stage:
    deploy
  only:
    - tags
  tags:
    - ing
  when:
    manual
  script:
    - chmod 600 "$ID_RSA"
    - ssh -i "$ID_RSA" -o StrictHostKeyChecking=no  "$SERVER_USER"@"$SERVER_IP" "cd $TARGET_DIR ; sed -ri 's#'$CI_REGISTRY_IMAGE'(.*)#'$CI_REGISTRY_IMAGE':'$CI_COMMIT_TAG'#' $COMPOST_FILE ; docker-compose up -d"

文件说明：

• 这里variables中的PUSH_CI_REGISTRY_IMAGE和CI_REGISTRY_IMAGE分开两个，是因为推送镜像地址和客户机下载镜像的地址不是同一个，所以分开两个。
• 这里variables中的SERVER_IP、SERVER_USER、TARGET_DIR、COMPOST_FILE，分别是服务器的IP、操作的用户、目标服务器的目录、compose文件名。
• 两个stages 的when都是设置成manual，在gitlab页面上手动点启动。
• 都是只有在打了tag标签推送，才会触发这个管道。
• deploy的script里有两条命令，一条是更改密钥文件的权限，一条是ssh登录到远程服务器，然后执行sed更改docker-compose.yml文件的image镜像tag版本号，然后去启动。
• -o StrictHostKeyChecking=no确保绕过是否信任这个问题。无论您是否信任远程主机，这个问题在管道等非交互式上下文中无法回答。

推送到 gitlab后，就可以看到这个Pipelines在等待执行：

接下来点操作就可以了。

这里主要注意的地方就是，因为在.gitlab-ci.yml中，是以普通用户执行sed更新docker-compose.yml文件的。sed修改文件需要在当前目录有写权限，因为sed原理是在当前目录创建一个临时文件，修改临时文件，然后用修改好的临时文件替换源文件，然后删除临时文件。所以目标机器的这个文件和这个目录，也需要有这个普通用户的w写入权限。
如果这个目录没有写入权限的话，就会报couldn't open temporary file的错误。