使用Renovate更新基本图像在某种程度上改变了图像的类型--是否有方法和方法可以进行修复，而不是改变类型？

Question

我正在玩更新的帮助，保持基本图像在我的Dockerfile最新。

我使用openjdk:17SIM作为映像来尝试这一点，我观察到以下内容：

大约两周前，如果你做了一个docker pull openjdk:17-slim，你会得到一个与沙sha256:a507bb03601e726027ad01ae3f540c8b936ec1ab75512767a4e2e732da4fe7e3的图像。

我将使用这作为我的测试沙，因为我想看看如何/什么翻新将更新我。

为了使用更新，您需要使用sha而不是标记，所以在我的Dockerfile中，我把-

FROM openjdk@sha256:a507bb03601e726027ad01ae3f540c8b936ec1ab75512767a4e2e732da4fe7e3

我下一次运行更新，它建议(通过合并请求)使用这个沙作为最新的-

FROM openjdk@sha256:ed71f9910039df3e8624c3a059215cfefa5e3c5aecf5a53e200a763311fccb6d

我注意到它有点大，当我抬头看沙时，它给我带来了这里，它没有给我任何细节(就像它是一张纤细的图片)-

接下来，我对原始sha和新sha进行了Trivy扫描，以查看CVE可能存在哪些差异，我注意到Trivy给出了运行它时的快速描述(很高兴知道！)。

对原始sha (以4Fe7e3结尾)的Trivy扫描表明是debian 11.3。

对sha (以ccb6d结尾)的Trivy扫描希望升级到oracle 8.5。

我对这两个图像进行了对接检查，它们都是基于openJDK 17的(这是这里最重要的)。

Trivy的报告确实在甲骨文图像中有最少的漏洞，而debian (苗条)的漏洞则是最小的。

所以我的问题是-

有没有办法进行翻新建议使用苗条包，而不是把它从苗条改为甲骨文？

2-除了大小(不是很大的差别)和漏洞(甲骨文中的漏洞要少得多)之外，还有什么其他原因我不应该使用修复建议的甲骨文？为什么叫甲骨文？

Answer 1

如果希望仅在同一标记中更新，则必须指定标记和sha256，如下所示：

FROM openjdk:17-slim@sha256:a507bb03601e726027ad01ae3f540c8b936ec1ab75512767a4e2e732da4fe7e3