时间戳

首页 > 解决方案 > Gitlab CI 服务和 docker hub auth

docker - Gitlab CI 服务和 docker hub auth

问题描述

由于对 docker hub 非身份验证拉取的新限制，您如何为 gitlab-ci 服务验证您的 docker hub 帐户？

这是gitlab 文档中的示例 CI 配置：

# from official documentation 
services:
  - postgres:12.2 # <---- this will fail at some point because it's a non-authenticated pull

variables:
  POSTGRES_DB: nice_marmot
  POSTGRES_USER: runner
  POSTGRES_PASSWORD: ""
  POSTGRES_HOST_AUTH_METHOD: trust

这会在一段时间后导致以下错误：

ERROR: Preparation failed: Error response from daemon: 
toomanyrequests: You have reached your pull rate limit. 
You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit (executor_docker.go:188:1s)

由于服务在脚本运行之前被拉取，我们不能docker login在脚本部分。我在 gitlab 中找不到任何关于 url auth 或环境变量 auth 的文档。

一个理想的解决方案不需要管理员访问 gitlab-ci 服务器或 gitlab-ci 运行器，也不需要设置自定义运行pull_policy = never器（我们最终这样做了，但它极大地减慢了我们的 CI 与 e2e 的单个运行器瓶颈测试）

标签： dockergitlab-cidockerhub

解决方案

如果改进的依赖代理可以提供帮助，请使用GitLab 13.7 （2020 年 12 月）检查：

避免 Docker 速率限制并加快您的管道

为了更快、更可靠的构建，您可以使用 Dependency Proxy 缓存托管在 Docker Hub 上的容器映像。

但是，当 Docker 开始对来自 Docker Hub 的拉取请求实施速率限制时，您注意到即使您的图像是从缓存中拉出的，Docker 也会将其计入您的限制。
这是因为 Dependency Proxy 只缓存图像的层（或 blob），而不是包含有关如何构建给定图像的信息的清单。
由于需要清单，因此仍然需要拉取请求。这也意味着如果 Docker Hub 不可用，您将无法拉取镜像。

展望未来，依赖代理将缓存图像的层和清单。

因此，第一次 pullalpine:latest时，图像将被添加到 Dependency Proxy 缓存中，并计为一次 pull 对您的速率限制。
下次您 pullalpine:latest时，它将从缓存中拉出，即使 Docker Hub 不可用并且不会计入您的速率限制。

不要忘记，从里程碑 13.6 开始，依赖代理在 Core 中可用。所以，试一试，让我们知道你的想法。或者更好的是，考虑为一个未解决的问题做出贡献。

请参阅文档和问题。

和：

仍然使用GitLab 13.7（2020 年 12 月）

将预定义变量与 Dependency Proxy 一起使用

通过代理和缓存来自 Docker Hub 的容器映像，依赖代理可以帮助您提高管道的性能。

即使代理打算与 CI/CD 大量使用，但要使用该功能，您必须在gitlab.ci-yml文件中定义自己的变量或硬编码值。
这使得个人难以入门，并使其无法成为可扩展的解决方案，尤其是对于具有许多不同组和项目的组织而言。

展望未来，您可以使用预定义的环境变量作为使用依赖代理的直观方式。支持以下变量：

  • CI_DEPENDENCY_PROXY_USER：用于登录依赖代理的 CI 用户。
  • CI_DEPENDENCY_PROXY_PASSWORD：用于登录依赖代理的 CI 密码。
  • CI_DEPENDENCY_PROXY_SERVER：用于登录依赖代理的服务器。
  • CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX：通过依赖代理拉取镜像的镜像前缀。

试一试，让我们知道您的想法！

请参阅文档和问题。

这甚至适用于私人项目（2020 年 12 月）

将依赖代理与私有项目一起使用

您可以使用 GitLab 依赖代理来代理和缓存来自 Docker Hub 的容器图像。直到最近，该功能仅适用于公共团体，导致你们中的许多人无法使用它。

您现在可以将依赖代理与私有项目一起使用。
您可以通过缓存容器映像以备将来使用来减少对 Docker Hub 的依赖。

因为依赖代理将 Docker 映像存储在与您的组关联的空间中，所以您必须使用您的 GitLab 用户名和密码进行身份验证，或者使用您的个人访问令牌进行身份验证，范围设置为至少read_registry.

请参阅文档和问题。

使用GitLab 13.9（2021 年 2 月）：

使用依赖代理时自动进行身份验证

通过代理和缓存来自 Docker Hub 的容器映像，依赖代理可以帮助您提高管道的性能。

即使代理打算与 CI/CD 大量使用，但要使用该功能，您必须将凭据添加到CI/CD 变量或在管道中DOCKER_AUTH_CONFIG手动运行。docker login这些解决方案运行良好，但是当您考虑.gitlab-ci.yml需要更新多少文件时，如果 GitLab Runner 可以自动为您进行身份验证会更好。

由于 Runner 已经能够通过集成的 GitLab Container Registry 自动进行身份验证，因此我们能够利用该功能来帮助您通过 Dependency Proxy 自动进行身份验证。

现在可以更轻松地使用 Dependency Proxy 代理和缓存来自 Docker Hub 的容器映像，并开始拥有更快、更可靠的构建。

请参阅文档和问题。

请参阅GitLab 13.10（2021 年 3 月）

将依赖代理与 'containerd' 和 Docker 20+ 一起使用

GitLab 依赖代理是一个本地代理，您可以将其用于从 Docker Hub 经常访问的上游图像。在 CI/CD 的情况下，依赖代理接收请求并从注册表返回上游映像，充当拉通缓存。这有助于减少 CI 分钟数并提高可靠性。

但是，您无法通过摘要提取图像，摘要作为不可变标识符可确保您使用特定图像和标签的确切版本。由于containerdDocker 20+ 都依赖于 pull-by-digest，这意味着你们中的许多人被阻止使用依赖代理。

我们很高兴地说，您现在可以通过摘要从 Docker Hub 中提取容器映像。您可以通过将 URL 添加到.gitlab-ci.yml文件、从命令行手动拉取图像或使用 Dockerfile 来使用依赖代理。查看文档并开始节省构建时间。

请参阅文档和问题。

推荐阅读