docker安装gitlab-runner-ci构建项目时缓存使用方法

发表者：admin分类：Devops2021-12-27 23:26:49 阅读[1866]

docker安装gitlab-runner-ci构建项目时缓存使用方法

一，环境说明。

1，docker中安装gitlab-runner。

2，gitab仓库中添加的项目中配置ci/cd流水线后，gitlab-runner会新建容器来构建部署项目。

3，gitlab-runner,如果不使用缓存，那么构建项目时速度比较慢。因为每次使用容器构建时，都要重新下载相关依赖。

二，gitlab-runner在容器中使用缓存的项目中.gitlab-ci.yml配置具体内容。

1，具体内容如下：

image: node:14
masterbuild:
    tags:
    - cicdrunner
    stage: build
    cache:
      key: same-key
      paths:
        - node_modules/
    script:
      - npm install --registry=https://registry.npm.taobao.org
      - npm run build
    only:
      - master
    artifacts:
      expire_in: 1 week
      paths:
        - build


	2，以下三项目是主要内容。paths就是要缓存目录，也可以是文件。其中key项值可以随意填写，但如果不同的作业阶段需要共享缓存，
	那么在不同的作业阶段中key值需要一样。

    cache:
      key: same-key
      paths:
        - node_modules/

三，服务器中查看docker的缓存目录，

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_SLUGtesttest

如果未找到具有此标记的缓存，则可以使用此选项指定在不存在缓存时要使用的缓存。CACHE_FALLBACK_KEY

在下面的示例中，如果未找到，则作业将使用变量定义的键：$CI_COMMIT_REF_SLUGCACHE_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 库模块安装在每个分支中并缓存在各个分支中：cachevendor/

#
# 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 的缓存定义在以下，并且两者都按分支缓存：cachevenv/.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 安装在每个分支中并缓存在：cachevendor/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 的工作，请使用全局定义中的关键字。此配置为每个作业生成不同的缓存。prefixcache

例如，测试作业可能不需要与部署到生产的作业相同的 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 模块已安装并缓存用于所有项目：cachego-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

缓存的存储位置

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.zipcache: key
job B运行。
缓存已提取（如果找到）。
before_script执行。
script执行。
管道完成。

通过在单台计算机上使用单个运行器，您不会遇到可能在与不同的运行器上执行的问题。此设置保证缓存可以在阶段之间重复使用。仅当执行从同一运行器/计算机中的阶段到阶段时，它才有效。否则，缓存可能不可用。job Bjob Abuildtest

在缓存过程中，还需要考虑以下几点：

如果具有其他缓存配置的其他作业将其缓存保存在同一 zip 文件中，则会覆盖该作业。如果使用基于 S3 的共享缓存，则文件将另外上传到基于缓存键的对象 S3。因此，具有不同路径但具有相同缓存密钥的两个作业将覆盖其缓存。
从中提取缓存时，zip 文件中的所有内容都提取到作业的工作目录（通常是下拉的存储库）中，并且运行者不介意的存档是否覆盖了的存档中的内容。cache.zipjob Ajob B

它以这种方式工作，因为为一个运行器创建的缓存在被另一个运行器使用时通常无效。不同的运行器可能在不同的体系结构上运行（例如，当缓存包含二进制文件时）。此外，由于不同的步骤可能由在不同计算机上运行的运行器执行，因此这是一个安全的默认值。

清除缓存

运行器使用缓存通过重用现有数据来加快作业的执行速度。这有时会导致不一致的行为。

有两种方法可以从缓存的新副本开始。

通过更改来清除缓存`cache:key`

更改文件中的值。下次管道运行时，缓存将存储在其他位置。cache: key.gitlab-ci.yml

手动清除缓存

在 GitLab 10.4 中引入。

您可以在 GitLab UI 中清除缓存：

在顶栏上，选择"菜单>项目"，然后找到你的项目。
在左侧边栏上，选择"CI/CD">"管道"页。
在右上角，选择清除运行器缓存。

下次提交时，CI/CD 作业将使用新的缓存。

每次手动清除缓存时，都会更新内部缓存名称。该名称使用格式，索引递增 1。旧缓存不会被删除。您可以从运行器存储中手动删除这些文件。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 Ajob B

若要解决此问题，请为每个作业使用不同的。keys

缓存不匹配示例 2

在此示例中，您为项目分配了多个运行器，并且未启用分布式缓存。

管道第二次运行时，您希望并重用其缓存（在本例中是不同的）：job Ajob 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：

[阅读全文...]

网站已经关闭评论

搜索

日志分类

系统导航

友情链接

最新文章

最新评论

日志同步发布到QQ微博

docker安装gitlab-runner-ci构建项目时缓存使用方法

GitLab CI/CD 中的缓存
所有层

缓存与项目有何不同

缓存

良好的缓存做法

使用多个缓存

使用回退缓存键

禁用特定作业的缓存

继承全局配置，但覆盖每个作业的特定设置

缓存的常见用例

缓存节点.js依赖项

缓存 PHP 依赖项

缓存 Python 依赖项

缓存 Ruby 依赖项

缓存 Go 依赖项

缓存的可用性

缓存的存储位置

缓存的存储位置

如果使用缓存和项目在作业中存储相同的路径，则缓存可能会被覆盖，因为缓存是在项目之前还原的。

存档和数据提取的工作原理

清除缓存

通过更改来清除缓存`cache:key`

手动清除缓存

故障排除

缓存不匹配

缓存不匹配示例 1

缓存不匹配示例 2

©2009-2024 Designed by 联系站长

搜索

日志分类

系统导航

友情链接

最新文章

最新评论

日志同步发布到QQ微博

docker安装gitlab-runner-ci构建项目时缓存使用方法

GitLab CI/CD 中的缓存所有层

缓存与项目有何不同

缓存

良好的缓存做法

使用多个缓存

使用回退缓存键

禁用特定作业的缓存

继承全局配置，但覆盖每个作业的特定设置

缓存的常见用例

在同一分支中的作业之间共享缓存

在不同分支中的作业之间共享缓存

缓存节点.js依赖项

缓存 PHP 依赖项

缓存 Python 依赖项

缓存 Ruby 依赖项

缓存 Go 依赖项

缓存的可用性

缓存的存储位置

缓存的存储位置

如果使用缓存和项目在作业中存储相同的路径，则缓存可能会被覆盖，因为缓存是在项目之前还原的。

存档和数据提取的工作原理

清除缓存

通过更改来清除缓存cache:key

手动清除缓存

故障 排除

缓存不匹配

缓存不匹配示例 1

缓存不匹配示例 2

©2009-2024 Designed by 联系站长

GitLab CI/CD 中的缓存
所有层

通过更改来清除缓存`cache:key`

故障排除