我们有一个 GitLab CI 管道,它基于 Hashicorp Vault 机密后端的外部 ETCD 快照构建新的 Docker 映像。该映像用于灾难恢复,因此我们对在注册表中保留旧版本没有任何兴趣。
有没有办法清除早于某个日期的 GitLab 注册表容器映像。或者保留最大数量的最近图像并删除其余图像?
谢谢
秒
如果你只需要一个图像,一个简单的方法就是总是推送到 eg registry.example.com/group/project/image:latest。这将覆盖现有的。
如果您想使用提交哈希或类似内容标记图像,则更加困难。不幸的是,目前还没有办法自动清理旧图像,但这是一个非常需要的功能,请参阅未解决的问题:
目前,人们已经做出了解决方法。例如
两者都是有趣的项目,现在可以为您提供帮助。如果您可以等待,我希望 GitLab 将在未来几个月内实现实际的注册表清理功能。
2019-08 更新
从 GitLab 版本 11.10 开始, gitlab-ctl registry-garbage-collect 命令有一个 --delete-manifests 标志,可以删除所有未标记的 Docker 镜像。不再需要这个项目。 https://github.com/sciapp/gitlab-registry-cleanup#deprecation-notice
GitLab 12.8(2020 年 2 月)引入了“标签过期策略”。
和GitLab 13.0(2020年5)增强了与特点:
定义策略以确保永远不会删除重要图像
在使用GitLab的Image Expiration Policy的时候,没有办法表达“无论如何,都不要删除这个标签”之类的东西。
这会给删除过程带来风险,因为可能会删除发行版或主映像,而这些映像应该是不可变的。
在 13.0 中,我们很高兴地宣布您现在可以更新项目的过期策略以识别您永远不想删除的图像。
只需启用该策略并使用正则表达式来识别您要保留的图像。
使用GitLab 13.5(2020 年 10 月):
Container Registry 清理策略的重大改进
在使用标记清理策略从 Container Registry 中删除不需要的标记时,您可能已经注意到,标记并不总是像您期望的那样被删除。
因此,您很可能不得不手动干预,使用 GitLab API批量删除注册表标签,或者您忽略了该问题并随后经历了更高的存储成本。有两个潜在问题可能导致问题。第一个问题与gitlab-#219915 相关。这个问题解决在用户界面中创建了一些政策是失败的错误,因为
user并没有传递给DeleteTagService。此外,您可能遇到了策略运行但仅部分完成的问题。当策略尝试删除许多图像而超时时会发生这种情况。如果发生这种情况,它将在策略的下一次计划运行中继续删除标签。继续前进,您将看到一个警告,表明仍有部分运行的策略。这样您就可以决定是否要手动干预。
| 归档时间: |
|
| 查看次数: |
9175 次 |
| 最近记录: |