docker安装gitlab-runner-ci构建项目时缓存使用方法 |
发表者:admin分类:Devops2021-12-27 23:26:49 阅读[2444] |
docker安装gitlab-runner-ci构建项目时缓存使用方法
一,环境说明。
1,docker中安装gitlab-runner。
2,gitab仓库中添加的项目中配置ci/cd流水线后,gitlab-runner会新建容器来构建部署项目。
3,gitlab-runner,如果不使用缓存,那么构建项目时速度比较慢。因为每次使用容器构建时,都要重新下载相关依赖。
二,gitlab-runner在容器中使用缓存的项目中.gitlab-ci.yml配置具体内容。
1,具体内容如下:
1,一个项目,构建容器会产生两个挂载目录。
一个是存储仓库项目源码与构建产生的文件,一个是设置的缓存目录 same-key/cache.zip,就是产生的缓存文件。
如果不设置缓存,那么缓存目录会是空的。
如下图:
下面是官网ci/cd的缓存说明。
GitLab CI/CD 中的缓存所有层
缓存是作业下载并保存的一个或多个文件。使用相同缓存的后续作业不必再次下载文件,因此它们的执行速度更快。
若要了解如何定义文件中的缓存,请参阅缓存
参考。.gitlab-ci.yml
缓存与项目有何不同
对依赖项使用缓存,例如从 Internet 下载的包。缓存存储在安装 GitLab Runner 的位置,如果启用了分布式缓存,则会将其上传到 S3。
使用项目在阶段之间传递中间生成结果。工件由作业生成,存储在 GitLab 中,可以下载。
项目和缓存都定义了它们相对于项目目录的路径,并且无法链接到项目目录外部的文件。
缓存
- 使用关键字定义每个作业的缓存。否则,它将被禁用。
cache
- 后续管道可以使用缓存。
- 如果依赖项相同,则同一管道中的后续作业可以使用缓存。
- 不同的项目无法共享缓存。
良好的缓存做法
若要确保缓存的最大可用性,请执行下列一项或多项操作:
- 标记运行者,并在共享缓存的作业上使用该标记。
- 使用仅适用于特定项目的运行器。
- 使用适合您的工作流程的
密钥
。例如,您可以为每个分支配置不同的缓存。
要使运行器有效地使用缓存,您必须执行以下操作之一:
- 使用单个运行器完成所有作业。
- 使用具有分布式缓存的多个运行器,其中缓存存储在 S3 存储桶中。GitLab.com 共享的跑步者会以这种方式运行。这些运行器可以处于自动缩放模式,但不必处于自动缩放模式。
- 使用具有相同体系结构的多个运行器,并让这些运行器共享一个公共网络装载目录来存储缓存。此目录应使用 NFS 或类似内容。这些运行器必须处于自动缩放模式。
使用多个缓存
您最多可以有四个缓存:
test-job:
stage: build
cache:
- key:
files:
- Gemfile.lock
paths:
- vendor/ruby
- key:
files:
- yarn.lock
paths:
- .yarn-cache/
script:
- bundle install --path=vendor
- yarn install --cache-folder .yarn-cache
- echo Run tests...
如果将多个缓存与回退缓存密钥结合使用,则每次找不到缓存时都会提取回退缓存。
使用回退缓存键
在 GitLab Runner 13.4 中引入。
可以使用预定义的变量来指定cache:key
。例如,如果您的 是 ,则可以将作业设置为下载标记为 的缓存。$CI_COMMIT_REF_SLUG
$CI_COMMIT_REF_SLUG
test
test
如果未找到具有此标记的缓存,则可以使用此选项指定在不存在缓存时要使用的缓存。CACHE_FALLBACK_KEY
在下面的示例中,如果未找到 ,则作业将使用变量定义的键:$CI_COMMIT_REF_SLUG
CACHE_FALLBACK_KEY
variables:
CACHE_FALLBACK_KEY: fallback-key
job1:
script:
- echo
cache:
key: "$CI_COMMIT_REF_SLUG"
paths:
- binaries/
禁用特定作业的缓存
如果全局定义缓存,则每个作业都使用相同的定义。您可以为每个作业覆盖此行为。
要为作业完全禁用它,请使用空哈希:
job:
cache: []
继承全局配置,但覆盖每个作业的特定设置
您可以使用定位点覆盖缓存设置,而无需覆盖全局缓存。例如,如果要覆盖 for 一个作业:policy
cache: &global_cache
key: $CI_COMMIT_REF_SLUG
paths:
- node_modules/
- public/
- vendor/
policy: pull-push
job:
cache:
# inherit all global cache settings
<<: *global_cache
# override the policy
policy: pull
有关详细信息,请参阅缓存:策略
。
缓存的常见用例
通常,使用缓存来避免在每次运行作业时下载内容(如依赖项或库)。Node.js包,PHP包,Ruby gem,Python库等都可以缓存。
有关示例,请参阅GitLab CI/CD 模板。
在同一分支中的作业之间共享缓存
要使每个分支中的作业使用相同的缓存,请使用 :key: $CI_COMMIT_REF_SLUG
cache:
key: $CI_COMMIT_REF_SLUG
此配置可防止您意外覆盖缓存。但是,合并请求的第一个管道很慢。下次将提交推送到分支时,将重用缓存,并且作业运行得更快。
要启用每个作业和每个分支的缓存,请执行以下操作:
cache:
key: "$CI_JOB_NAME-$CI_COMMIT_REF_SLUG"
要启用每阶段和每分支缓存,请执行以下操作:
cache:
key: "$CI_JOB_STAGE-$CI_COMMIT_REF_SLUG"
在不同分支中的作业之间共享缓存
要在所有分支和所有作业之间共享缓存,请对所有内容使用相同的密钥:
cache:
key: one-key-to-rule-them-all
要在分支之间共享缓存,但每个作业都有唯一的缓存,请执行以下操作:
cache:
key: $CI_JOB_NAME
缓存节点.js依赖项
如果项目使用npm安装 Node.js 依赖项,则以下示例将全局定义,以便所有作业都继承它。默认情况下,npm 将缓存数据存储在主文件夹 () 中。但是,您不能将内容缓存在项目目录 之外。相反,请告诉 npm 使用 ,并按分支缓存它:cache
~/.npm
./.npm
#
# https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates/Nodejs.gitlab-ci.yml
#
image: node:latest
# Cache modules in between jobs
cache:
key: $CI_COMMIT_REF_SLUG
paths:
- .npm/
before_script:
- npm ci --cache .npm --prefer-offline
test_async:
script:
- node ./specs/start.js ./specs/async.spec.js
缓存 PHP 依赖项
如果您的项目使用Composer安装 PHP 依赖项,则以下示例将全局定义,以便所有作业都继承它。PHP 库模块安装在每个分支中并缓存在各个分支中:cache
vendor/
#
# https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates/PHP.gitlab-ci.yml
#
image: php:7.2
# Cache libraries in between jobs
cache:
key: $CI_COMMIT_REF_SLUG
paths:
- vendor/
before_script:
# Install and run Composer
- curl --show-error --silent "https://getcomposer.org/installer" | php
- php composer.phar install
test:
script:
- vendor/bin/phpunit --configuration phpunit.xml --coverage-text --colors=never
缓存 Python 依赖项
如果您的项目使用pip来安装 Python 依赖项,则以下示例将全局定义,以便所有作业都继承它。Python 库安装在 的虚拟环境中。pip 的缓存定义在 以下,并且两者都按分支缓存:cache
venv/
.cache/pip/
#
# https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates/Python.gitlab-ci.yml
#
image: python:latest
# Change pip's cache directory to be inside the project directory since we can
# only cache local items.
variables:
PIP_CACHE_DIR: "$CI_PROJECT_DIR/.cache/pip"
# Pip's cache doesn't store the python packages
# https://pip.pypa.io/en/stable/reference/pip_install/#caching
#
# If you want to also cache the installed packages, you have to install
# them in a virtualenv and cache it as well.
cache:
paths:
- .cache/pip
- venv/
before_script:
- python -V # Print out python version for debugging
- pip install virtualenv
- virtualenv venv
- source venv/bin/activate
test:
script:
- python setup.py test
- pip install flake8
- flake8 .
缓存 Ruby 依赖项
如果您的项目使用Bundler安装 gem 依赖项,则以下示例将全局定义,以便所有作业都继承它。Gem 安装在每个分支中并缓存在:cache
vendor/ruby/
#
# https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates/Ruby.gitlab-ci.yml
#
image: ruby:2.6
# Cache gems in between builds
cache:
key: $CI_COMMIT_REF_SLUG
paths:
- vendor/ruby
before_script:
- ruby -v # Print out ruby version for debugging
- bundle install -j $(nproc) --path vendor/ruby # Install dependencies into ./vendor/ruby
rspec:
script:
- rspec spec
如果您有需要不同 Gem 的工作,请使用全局定义中的关键字。此配置为每个作业生成不同的缓存。prefix
cache
例如,测试作业可能不需要与部署到生产的作业相同的 Gem:
cache:
key:
files:
- Gemfile.lock
prefix: $CI_JOB_NAME
paths:
- vendor/ruby
test_job:
stage: test
before_script:
- bundle install --without production --path vendor/ruby
script:
- bundle exec rspec
deploy_job:
stage: production
before_script:
- bundle install --without test --path vendor/ruby
script:
- bundle exec deploy
缓存 Go 依赖项
如果项目使用Go 模块安装 Go 依赖项,则以下示例在模板中定义任何作业都可以扩展的依赖项。Go 模块已安装并缓存用于所有项目:cache
go-cache
${GOPATH}/pkg/mod/
go
.go-cache:
variables:
GOPATH: $CI_PROJECT_DIR/.go
before_script:
- mkdir -p .go
cache:
paths:
- .go/pkg/mod/
test:
image: golang:1.13
extends: .go-cache
script:
- go test ./... -v -short
缓存的可用性
缓存是一种优化,但不能保证始终有效。您可能需要在每个需要缓存文件的作业中重新生成这些文件。
在.gitlab-ci.yml
中定义缓存后,缓存的可用性取决于:
- 运行者的执行器类型。
- 是否使用不同的运行器在作业之间传递缓存。
缓存的存储位置
为作业定义的所有缓存都存档在单个文件中。运行器配置定义文件的存储位置。默认情况下,缓存存储在安装了 GitLab Runner 的计算机上。位置还取决于执行器的类型。cache.zip
缓存的存储位置
为作业定义的所有缓存都存档在单个文件中。运行器配置定义文件的存储位置。默认情况下,缓存存储在安装了 GitLab Runner 的计算机上。位置还取决于执行器的类型。cache.zip
Runner executor | Default path of the cache |
---|---|
Shell | Locally, under the user’s home directory: . gitlab-runner /home/gitlab-runner/cache/<user>/<project>/<cache-key>/cache.zip |
Docker | Locally, under Docker volumes: . /var/lib/docker/volumes/<volume-id>/_data/<user>/<project>/<cache-key>/cache.zip |
Docker Machine (autoscale runners) | The same as the Docker executor. |
If you use cache and artifacts to store the same path in your jobs, the cache might be overwritten because caches are restored before artifacts.
如果使用缓存和项目在作业中存储相同的路径,则缓存可能会被覆盖,因为缓存是在项目之前还原的。
存档和数据提取的工作原理
此示例在两个连续的阶段中显示两个作业:
stages:
- build
- test
before_script:
- echo "Hello"
job A:
stage: build
script:
- mkdir vendor/
- echo "build" > vendor/hello.txt
cache:
key: build-cache
paths:
- vendor/
after_script:
- echo "World"
job B:
stage: test
script:
- cat vendor/hello.txt
cache:
key: build-cache
paths:
- vendor/
如果一台计算机安装了一个运行器,则项目的所有作业都在同一主机上运行:
- 管道启动。
job A
运行。before_script
执行。script
执行。after_script
执行。cache
运行,并将目录压缩到 .然后,此文件将根据运行器的设置和 .vendor/
cache.zip
cache: key
job B
运行。- 缓存已提取(如果找到)。
before_script
执行。script
执行。- 管道完成。
通过在单台计算机上使用单个运行器,您不会遇到可能在与 不同的运行器上执行的问题。此设置保证缓存可以在阶段之间重复使用。仅当执行从同一运行器/计算机中的阶段到阶段时,它才有效。否则,缓存可能不可用。job B
job A
build
test
在缓存过程中,还需要考虑以下几点:
- 如果具有其他缓存配置的其他作业将其缓存保存在同一 zip 文件中,则会覆盖该作业。如果使用基于 S3 的共享缓存,则文件将另外上传到基于缓存键的对象 S3。因此,具有不同路径但具有相同缓存密钥的两个作业将覆盖其缓存。
- 从 中提取缓存时,zip 文件中的所有内容都提取到作业的工作目录(通常是下拉的存储库)中,并且运行者不介意的存档是否覆盖了 的存档中的内容。
cache.zip
job A
job B
它以这种方式工作,因为为一个运行器创建的缓存在被另一个运行器使用时通常无效。不同的运行器可能在不同的体系结构上运行(例如,当缓存包含二进制文件时)。此外,由于不同的步骤可能由在不同计算机上运行的运行器执行,因此这是一个安全的默认值。
清除缓存
运行器使用缓存通过重用现有数据来加快作业的执行速度。这有时会导致不一致的行为。
有两种方法可以从缓存的新副本开始。
通过更改来清除缓存cache:key
更改文件中 的值。下次管道运行时,缓存将存储在其他位置。cache: key
.gitlab-ci.yml
手动清除缓存
在 GitLab 10.4 中引入。
您可以在 GitLab UI 中清除缓存:
- 在顶栏上,选择"菜单>项目",然后找到你的项目。
- 在左侧边栏上,选择"CI/CD">"管道"页。
- 在右上角,选择 清除运行器缓存。
下次提交时,CI/CD 作业将使用新的缓存。
cache-<index>
故障 排除
缓存不匹配
如果缓存不匹配,请按照以下步骤进行故障排除。
缓存不匹配的原因 | 如何修复它 |
---|---|
使用附加到一个项目的多个独立运行器(不在自动缩放模式下),而无需共享缓存。 | 对项目仅使用一个运行器,或使用启用了分布式缓存的多个运行器。 |
在自动缩放模式下使用运行器,而不启用分布式缓存。 | 将自动缩放运行器配置为使用分布式缓存。 |
安装运行器的计算机磁盘空间不足,或者,如果您设置了分布式缓存,则存储缓存的 S3 存储桶没有足够的空间。 | 确保清除一些空间以允许存储新的缓存。没有自动的方法可以做到这一点。 |
对于缓存不同路径的作业,您可以使用相同的方法。key | 使用不同的缓存键,使缓存存档存储到不同的位置,并且不会覆盖错误的缓存。 |
缓存不匹配示例 1
如果只为项目分配了一个运行器,则默认情况下,缓存将存储在运行器的计算机上。
如果两个作业具有相同的缓存键但路径不同,则可以覆盖缓存。例如:
stages:
- build
- test
job A:
stage: build
script: make build
cache:
key: same-key
paths:
- public/
job B:
stage: test
script: make test
cache:
key: same-key
paths:
- vendor/
job A
运行。public/
缓存为缓存.zip。job B
运行。- 以前的缓存(如果有)已解压缩。
vendor/
缓存为缓存.zip并覆盖前一个缓存。- 下次运行时,它使用的缓存不同,因此无效。
job A
job B
若要解决此问题,请为每个作业使用不同的。keys
缓存不匹配示例 2
在此示例中,您为项目分配了多个运行器,并且未启用分布式缓存。
管道第二次运行时,您希望并重用其缓存(在本例中是不同的):job A
job B
stages:
- build
- test
job A:
stage: build
script: build
cache:
key: keyA
paths:
- vendor/
job B:
stage: test
script: test
cache:
key: keyB
paths:
- vendor/
即使不同,如果作业在后续管道中的不同运行器上运行,则缓存的文件可能会在每个阶段之前被"清理"。key
转载请标明出处【docker安装gitlab-runner-ci构建项目时缓存使用方法】。
《www.micoder.cc》
虚拟化云计算,系统运维,安全技术服务.
Tags: | [阅读全文...] |
最新评论