使用 gitlab-ci 的缓存 docker 镜像

发布于 2025-01-13 22:33:59 字数 171 浏览 3 评论 0原文

我想知道是否可以在 gitlab-ci 的 gitlab 注册表中使用缓存的 docker 镜像? 例如,我想使用 node:16.3.0-alpine docker 镜像,我可以将其缓存在我的 gitlab 注册表中并从中提取它并加速我的 gitlab ci 而不是从 docker hub 提取它?

I was wondering is it possible to use cached docker images in gitlab registry for gitlab-ci?
for example, I want to use node:16.3.0-alpine docker image, can I cache it in my gitlab registry and pull it from that and speed up my gitlab ci instead of pulling it from docker hub?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

请别遗忘我 2025-01-20 22:33:59

我正在使用一个企业 Gitlab 实例,由于某种原因,依赖代理功能已被禁用。您的另一个选择是在本地计算机上创建一个新的 Docker 映像,然后将其推送到您的个人 Gitlab 项目的 Container Registry 中。

# First create a one-line Dockerfile containing "FROM node:16.3.0-alpine"
docker pull node:16.3.0-alpine
docker build . -t registry.example.com/group/project/image
docker login registry.example.com -u <username> -p <token>
docker push registry.example.com/group/project/image

其中图像标签应根据项目的私有容器注册表页面上给出的示例构建。

现在,在 CI 作业中,您只需将 image:node:16.3.0-alpine 更改为 image:registry.example.com/group/project/image。您可能必须在 before_script 部分中运行 docker login 命令(使用部署令牌作为凭据,请参阅设置 -> 存储库)——我认为可能是较新版本的Gitlab 将让运行程序使用系统凭据向私有容器注册表进行身份验证,但这可能会根据其配置方式而有所不同。

I'm using a corporate Gitlab instance where for some reason the Dependency Proxy feature has been disabled. The other option you have is to create a new Docker image on your local machine, then push it into the Container Registry of your personal Gitlab project.

# First create a one-line Dockerfile containing "FROM node:16.3.0-alpine"
docker pull node:16.3.0-alpine
docker build . -t registry.example.com/group/project/image
docker login registry.example.com -u <username> -p <token>
docker push registry.example.com/group/project/image

where the image tag should be constructed based on the example given on your project's private Container Registry page.

Now in your CI job, you just change image: node:16.3.0-alpine to image: registry.example.com/group/project/image. You may have to run the docker login command (using a deploy token for credentials, see Settings -> Repository) in the before_script section -- I think maybe newer versions of Gitlab will have the runner authenticate to the private Container Registry using system credentials, but that could vary depending on how it's configured.

轻许诺言 2025-01-20 22:33:59

是的,GitLab 的 依赖代理 功能允许您将 GitLab 配置为“< a href="https://docs.docker.com/registry/recipes/mirror/" rel="nofollow noreferrer">拉取缓存"。这对于 解决 dockerhub 等上游来源的速率限制

在大多数情况下,使用依赖代理应该更快,但不一定如此。例如,dockerhub 可能比小型自托管服务器性能更高。 GitLab 运行程序相对于注册表来说也是远程的,并且不一定比互联网上的任何其他注册表“更接近”GitLab 注册表。所以,请记住这一点。

顺便说一句,检索缓存图像的绝对最快方法是自行托管 GitLab 运行器并将图像直接保存在主机上。这样,当作业启动时,如果主机上已存在映像,则作业将立即启动,因为它不需要拉取映像(取决于您的拉取配置)。 (也就是说,假设您在作业的 image: 声明中使用图像)

Yes, GitLab's dependency proxy features allow you to configure GitLab as a "pull through cache". This is also beneficial for working around rate limits of upstream sources like dockerhub.

It should be faster in most cases to use the dependency proxy, but not necessarily so. It's possible that dockerhub can be more performant than a small self-hosted server, for example. GitLab runners are also remote with respect to the registry and not necessarily any "closer" to the GitLab registry than any other registry over the internet. So, keep that in mind.

As a side note, the absolute fastest way to retrieve cached images is to self-host your GitLab runners and hold images directly on the host. That way, when jobs start, if the image already exists on the host, the job will start immediately because it does not need to pull the image (depending on your pull configuration). (that is, assuming you're using images in the image: declaration for your job)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文