Gitlab CI/CD 之 Gitlab Runner Docker Executor 缓存问题

定义一个流水线

在我们使用Gitlab的CICD的时候会定义一个Pipeline，Pipeline会由多个stage组成，stage整体是串行的，中间会存在并行任务。
如下是一个前端vue、后端.net的项目的自动化打包流水线

image: docker:20.10.5-dind

stages:
    - prebuild
    - build
    - test
    - publish-ui
    - publish-api
    - image

prebuild:
    image: node:15
    stage: prebuild
    tags:
        - builder
    only:
        changes:
            - app/package.json
    cache:
        key:
            files:
                - app/package.json
        paths:
            - app/node_modules/
    script:
        - cd app
        - npm install

build-ui:
    image: node:15
    stage: build
    tags:
        - builder
    only:
        changes:
            - app/**/*
    cache:
        key:
            files:
                - app/package.json
        policy: pull
        paths:
            - app/node_modules/
    script:
        - cd app
        - npm run build

build-api:
    image: dotnet/sdk:5.0
    stage: build
    only:
      changes:
        - api/**/*
    tags:
        - builder
    script:
        - cd api
        - dotnet build

test:
    image: dotnet/sdk:5.0
    stage: test
    only:
      changes:
        - api/**/*
    tags:
        - builder
    script: 
        - cd api
        - dotnet test

publish-ui:
    image: node:15
    stage: publish-ui
    tags:
        - builder
    only:
        refs:
            - main
    cache:
        - key: "$CI_COMMIT_REF_SLUG-ui"
          policy: push
          paths:
            - app/dist/
        - key:
            files:
                - app/package.json
          policy: pull
          paths:
            - app/node_modules/
    script:
        - cd app
        - npm run build

publish-api:
    image: dotnet/sdk:5.0
    stage: publish-api
    tags:
        - builder
    only:
        - main
    cache:
       key: "$CI_COMMIT_REF_SLUG-api"
       policy: push
       paths:
         - api/publish/
    script: 
        - dotnet publish -c Release -o api/publish

image:
    stage: image
    tags:
        - builder
    only:
        - main
    cache:
       - key: "$CI_COMMIT_REF_SLUG-ui"
         policy: pull
         paths:
            - app/dist/
       - key: "$CI_COMMIT_REF_SLUG-api"
         policy: pull
         paths:
            - api/publish/
    before_script:
        - docker login -u "$LOCAL_REGISTRY_USER" -p "$LOCAL_REGISTRY_PASSWORD" $LOCAL_REGISTRY
    script: 
        - docker build -f .gitlab/Dockerfile -t $LOCAL_REGISTRY/$CI_PROJECT_NAMESPACE/$CI_PROJECT_NAME:latest .
        - docker push $LOCAL_REGISTRY/$CI_PROJECT_NAMESPACE/$CI_PROJECT_NAME:latest
    after_script:
      - docker logout $LOCAL_REGISTRY

流水线中一共6个环节：prebuild、build、test、publish-ui、publish-api、image；其中build存在一个并行任务、其余都是串行

• prebuild
  prebuild只针对vue项目，用于安装npm的包，只有当package.json存在修改的时候才会执行，否则就使用缓存
• build
  每当有人push代码到服务器就会执行，检查代码是否能编译通过，如果不通过流水线失败，不能提mr
• test
  针对.net项目的单元测试，如果不通过流水线失败，不能提mr
• publish-ui
  发布前端项目，只有当main分支上有更改的时候发生
• publish-api
  发布后端项目，并把前端项目放在wwwroot下，只有当main分支上有更改的时候发生
• image
  打包镜像，只有当main分支上有更改的时候发生

引入缓存

我们知道Pipeline的每个Stage都是无状态的，运行完成后，产生的中间文件就会被丢弃掉，为了得到上一个Stage产生的文件，就需要将文件保存到缓存中，以便下一个Stage可以直接哪来使用。
缓存的几个属性：

• paths
  指定要缓存的文件或者文件夹，只能是本仓库文件夹下的相对路径，所以生成的中间文件也只能放在当前仓库路径下的相对路径中，不能以放在/开头的路径中(如：/app等)；
• key
  每个缓存的键值，如果不指定就是default，那么整个仓库就只有一份儿缓存（多个key就会有多个文件夹用来存放缓存文件），如果两个Stage中都有使用不同的缓存，那么下一个Stage会覆盖上一个Stage的缓存（一般情况下这样也没有任何问题，下一次Pipeline会先执行上一个Stage）。
• policy
  缓存策略，分为pull、push、pull-push，

1. pull表示当前Stage只会拉取缓存下来使用而不会对其进行改变；
2. push表示当前Stage只会对缓存进行上传
3. pull-push表示当前Stage会先拉下缓存，结束后会再次上传缓存
   默认策略是pull-push

缓存还可以全局定义(全局定义缓存与stages同一级即可)，具有继承特性，也可以禁用缓存。

// 此任务禁用缓存
job_name:
  cache: {}

带来的问题

缓存解决了文件在不同Stage中的共享问题，同时也引入了一个并行任务问题。

问题描述

当一个仓库中同时有两个流水线、或者有并行Stage需要用到Cache的时候，Cache会有问题：要么找不到Cache、要么用的老的Cache。

出现问题的原因

通过研究发现runner的缓存文件存放在：/var/lib/docker/volumes/下以runner-{runnerid}-开头的文件夹中，
每个项目的缓存存放方式：runner-{runnerid}-projects-{projectid}-concurrent-{num}-cache-3c3f060a0374fc8bc39395164f415a70|c33bcaa1fd2c77edfc3893b41966cea8
以3c3f060a0374fc8bc39395164f415a70结尾的文件夹中存放的就是缓存文件，以c33bcaa1fd2c77edfc3893b41966cea8结尾的文件夹中存放的是代码源文件。
当任务出现并行的时候runner会创建多个Pipeline实例文件夹concurrent-0、concurrent-1...每个文件夹中保存当前并行实例的缓存数据，且每个job的并行id是不固定的；
如下两个并行Pipeline A、B，有5个Stage，并行执行会产生10个job：

A:1-2-3-4-5
B:1-2-3-4-5

1. 第一种情况
   假如3、4Stage需要用到缓存，那么可能会出现什么情况？
   当A3在执行的时候缓存文件夹是concurrent-0、B3是concurrent-1，两个任务同时完成；
   当A4在执行的时候缓存文件夹是concurrent-1、B4是concurrent-0，这样两个缓存就出现了交叉，出现严重问题。
2. 第二种情况
   假如3、4Stage需要用到缓存，且3是一个并行任务（pub-ui、pub-api）
   那么就可能会同时出现4个并行实例，concurrent-0、concurrent-1、concurrent-2、concurrent-3；
   假如4需要3的两个缓存，那么4要么永远都拿不到3中的其中一个缓存，要么拿到老的缓存。
   这就造成了很验证的缓存错乱的问题。

如何解决此问题

1. 从根本上解决
   上分布式缓存（s3, gcs, azure.），这个没实践过官方反正这么说的；
2. 治标不治本
   同一个项目中并行的job不要用缓存、用到缓存的Stage走串行、不要同时发生多个使用到缓存的Pipeline实例。

环境说明：
以上问题的对应的gitlab-runner版本为v13.10.0
参考链接：
官方cache文档地址
官方问题issue地址