使用 gitlab-ci 的缓存 docker 镜像
我想知道是否可以在 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 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我正在使用一个企业 Gitlab 实例,由于某种原因,依赖代理功能已被禁用。您的另一个选择是在本地计算机上创建一个新的 Docker 映像,然后将其推送到您的个人 Gitlab 项目的 Container Registry 中。
其中图像标签应根据项目的私有容器注册表页面上给出的示例构建。
现在,在 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.
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
toimage: registry.example.com/group/project/image
. You may have to run thedocker login
command (using a deploy token for credentials, see Settings -> Repository) in thebefore_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.是的,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)