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

2023-08-23 03:34| 来源: 网络整理| 查看: 265

定义一个流水线

在我们使用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， pull表示当前Stage只会拉取缓存下来使用而不会对其进行改变； push表示当前Stage只会对缓存进行上传 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 第一种情况假如3、4Stage需要用到缓存，那么可能会出现什么情况？当A3在执行的时候缓存文件夹是concurrent-0、B3是concurrent-1，两个任务同时完成；当A4在执行的时候缓存文件夹是concurrent-1、B4是concurrent-0，这样两个缓存就出现了交叉，出现严重问题。第二种情况假如3、4Stage需要用到缓存，且3是一个并行任务（pub-ui、pub-api）那么就可能会同时出现4个并行实例，concurrent-0、concurrent-1、concurrent-2、concurrent-3；假如4需要3的两个缓存，那么4要么永远都拿不到3中的其中一个缓存，要么拿到老的缓存。这就造成了很验证的缓存错乱的问题。如何解决此问题从根本上解决上分布式缓存（s3, gcs, azure.），这个没实践过官方反正这么说的；治标不治本同一个项目中并行的job不要用缓存、用到缓存的Stage走串行、不要同时发生多个使用到缓存的Pipeline实例。

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

【本文地址】

公司简介

联系我们