如何找到docker映像的基础映像

我有一个docker图像，我想知道它是从哪个图像创建的。当然有多个层，但我想找出最后一个图像（dockerfile中用于此图像的FROM语句）

我尝试使用

docker image history

和

docker image inspect

，但在其中找不到此信息

我试图使用以下命令，但它给我一个错误消息

alias dfimage="sudo docker run -v /var/run/docker.sock:/var/run/docker.sock --rm xyz/mm:9e945ff"
dfimage febae8978318

这是我收到的错误信息

container_linux.go:235: starting container process caused "exec: \"febae8978318\": executable file not found in $PATH"
/usr/bin/docker-current: Error response from daemon: oci runtime error: container_linux.go:235: starting container process caused "exec: \"febae8978318\": executable file not found in $PATH".

---

您可以使用此答案中建议的方法：

首先，拉动chenzj/d图像：

docker pull chenzj/dfimage

docker run -v /var/run/docker.sock:/var/run/docker.sock --rm chenzj/dfimage <IMAGE_ID>

获取图像的ID：

docker images | grep <IMAGE_NAME> | awk '{print $3}'

如果您觉得这太难，只需拉动

chenzj/dImage

图像，然后 使用以下

docker get dockerfile.sh

脚本：

#!/usr/bin/env sh

if [ "$#" -lt 1 ]
then
    printf "Image name needed\n" >&2
    exit 1
fi

image_id="$(docker images | grep "^$1 " | awk '{print $3}')"
if [ -z "$image_id" ]
then
    printf "Image not found\n" >&2
    exit 2
fi

docker run -v /var/run/docker.sock:/var/run/docker.sock --rm chenzj/dfimage "$image_id"

您需要将图像名称作为参数传递。用法示例：

$ ./docker-get-dockerfile.sh alpine
FROM alpine:latest
ADD file:fe64057fbb83dccb960efabbf1cd8777920ef279a7fa8dbca0a8801c651bdf7c in /
CMD ["/bin/sh"]

简单的方法是使用

docker image history deno

上面的命令将提供如下输出

然后只需查看图像列并获取图像ID，该ID位于第一个

的正上方

那就照我说的做

对于Linux

docker image ls | grep a24bb4013296

窗户

docker image ls | findstr a24bb4013296

这将为您提供基本图像名称

---

确切地说，这些信息实际上并不存在。图像将包含其父层的层，但没有简单的方法将层摘要从语句反转回

，除非您碰巧拥有（或能够找出）包含这些层的图像

如果您手头上有父图像（或可以找到它们），则可以通过交叉引用图层来推断图像用于FROM语句（或祖先）的图像

理论例子
假设您的图像
FOO
，包含层
123456
。如果在包含层的系统上有另一个图像，
BAR
，则可以推断图像
BAR
是图像
FOO
的祖先，即，在其层次结构中的某个点上会使用来自BAR的
）

进一步假设您有另一个图像，
BAZ
，其中包含层
123445
。您可以推断图像
BAZ
的祖先中有图像
BAR
，图像
A
继承自图像
BAZ
（因此间接继承自
BAR
）

根据这些信息，您可以推断这些图像的DockerFile可能如下所示：

# Dockerfile of image BAR
FROM scratch
# layers 1 2 and 3
COPY ./one /
COPY ./two /
COPY ./three /

通过查看每个图像的
docker图像历史记录
，您可以获得确切的命令

然而，这里需要记住的一件重要事情是，docker标记是可变的；维护人员创建新图像并将标签移动到这些图像。因此，如果您今天使用python:3.8.1
中的
构建了一个图像，它将不会包含与几周前使用
行中相同的
构建的图像相同的层。您需要SHA256摘要以确保使用的是完全相同的图像

实例，本地图像
现在，我们了解了识别图像及其基础背后的理论，让我们用一个真实的例子来实践它

注意：因为我使用的标签会随着时间的推移而改变（参见上面的RE:tag Mutatability），所以我将使用SHA256摘要来提取本例中的图像，以便观众可以重现这个答案

假设我们有一个特定的图像，我们想找到它的基础。我们将在这里使用官方的
maven
图像

首先，我们来看看它的层

#maven:3.6-jdk-11-slim在撰写本文时，在我的平台上
IMAGE=“docker.io/maven@sha256：55f1c145a04e01706233d68fe0b6b20bf76f765ab32f3fe6e29c8ef933917af6“
docker pull$图像
docker image inspect$image | jq-r'.[].RootFS.Layers[]'

这将输出层：

sha256:6e06900bc10223217b4c78081a857866f674c462e4f90593b01894da56df336d
sha256:eda2f4da9b1e70500ac340d40ee039ef3877e8be13b9a24cd345406bf6693412
sha256:6bdb7b3c3e226bdfaa911ba72a95fca13c3979cd150061d570cf569e93037ce6
sha256:ce217e530345060ca0973807a3288560e1e15cf1a4eeec44d6aa594a926c92dc
sha256:f256c980a7d17a00f57fd42a19f6323fcc2341fa46eba128def04824cafa5afa
sha256:446b1af848de2dcb92bbd229ca6ecaabf2f48dab323c19f90d02622e09a8fa67
sha256:10652cf89eaeb5b5d8e0875a6b1867b5cf92c509a9555d3f57d87fab605115a3
sha256:d9a4cf86bf01eb170242ca3b0ce456159fd3fddc9c4d4256208a9d19bae096ca

现在，从这里，我们可以尝试找到其他具有这些层（严格）子集的图像。假设您手头有图像，您可以通过交叉引用磁盘上的图像层来找到它们，例如，使用
docker image inspect

在本例中，我恰好知道这些图像是什么，并且手头上有它们（我将在后面讨论如果您手头上没有这些图像，您可能会做什么），因此我们将继续提取这些图像并查看图层

如果您想继续：

#openjdk:11.0.10-jdk-slim在撰写本文时，在我的平台上
OPENJDK='docker.io/openjdk@sha256：fe6a46a26ff7d6c31b258e07b3d53f0c42fe68f55f646cc39d60d0b17cbc827b'
#debian:buster-20210329-slim在我的平台上写作时
DEBIAN='docker.io/debian@sha256：088BE7D6017AD3AE98325F4707112E1F61687C371BE1865E55D5E5531CA97FD'
docker pull$OPENJDK
docker拉$DEBIAN

如果我们检查这些图像并将它们与
docker image inspect
的
maven
图像输出中看到的层进行比较，我们可以确认
openjdk
和
debian
中的层存在于原始
maven
图像中

$ docker image inspect $DEBIAN | jq -r '.[].RootFS.Layers[]'
sha256:6e06900bc10223217b4c78081a857866f674c462e4f90593b01894da56df336d

$ docker image inspect $OPENJDK | jq -r '.[].RootFS.Layers[]'
sha256:6e06900bc10223217b4c78081a857866f674c462e4f90593b01894da56df336d
sha256:eda2f4da9b1e70500ac340d40ee039ef3877e8be13b9a24cd345406bf6693412
sha256:6bdb7b3c3e226bdfaa911ba72a95fca13c3979cd150061d570cf569e93037ce6
sha256:ce217e530345060ca0973807a3288560e1e15cf1a4eeec44d6aa594a926c92dc

如上所述，因为这5层是maven图像8层的严格子集，所以我们可以得出结论，
openjdk
和
debian
图像至少都在
maven
图像的祖先路径中

$ docker image inspect $DEBIAN | jq -r '.[].RootFS.Layers[]'
sha256:6e06900bc10223217b4c78081a857866f674c462e4f90593b01894da56df336d

$ docker image inspect $OPENJDK | jq -r '.[].RootFS.Layers[]'
sha256:6e06900bc10223217b4c78081a857866f674c462e4f90593b01894da56df336d
sha256:eda2f4da9b1e70500ac340d40ee039ef3877e8be13b9a24cd345406bf6693412
sha256:6bdb7b3c3e226bdfaa911ba72a95fca13c3979cd150061d570cf569e93037ce6
sha256:ce217e530345060ca0973807a3288560e1e15cf1a4eeec44d6aa594a926c92dc

我们可以进一步推断，最后3层很可能来自
maven
图像本身（或者，可能是一些未知图像）

注意事项，当您在本地没有图像时
现在，当然，上面的方法只起作用，因为我碰巧手头上有所有的图片。所以，你要么需要这些图像，要么能够通过图层摘要来定位它们

您仍然可以使用Docker Hub或您自己的私有存储库等注册中心提供的信息来解决这个问题

对于官方图像，包含有关官方图像的历史信息，包括图层摘要
$ docker image inspect $DEBIAN | jq -r '.[].RootFS.Layers[]'
sha256:6e06900bc10223217b4c78081a857866f674c462e4f90593b01894da56df336d

$ docker image inspect $OPENJDK | jq -r '.[].RootFS.Layers[]'
sha256:6e06900bc10223217b4c78081a857866f674c462e4f90593b01894da56df336d
sha256:eda2f4da9b1e70500ac340d40ee039ef3877e8be13b9a24cd345406bf6693412
sha256:6bdb7b3c3e226bdfaa911ba72a95fca13c3979cd150061d570cf569e93037ce6
sha256:ce217e530345060ca0973807a3288560e1e15cf1a4eeec44d6aa594a926c92dc

$ get-remote-layers $IMAGE
sha256:6fcf2156bc23db75595b822b865fbc962ed6f4521dec8cae509e66742a6a5ad3
sha256:96fde6667c188c81fcddee021ccbb3e054ebe83350fd4609e17a3d37f0ec7f9d
sha256:74d17759dd2a1b51afc740fadd96f655260689a2087308e40d1865a0098c5fae
sha256:bbe8ebb5d0a64d265558901c7c6c66e1d09f664da57cdb2e5f69ba52a7109d31
sha256:b2edaadd7dd62cfe7f551b902244ee67b84bc5c0b6538b9480ac9ca97a0a4986
sha256:0fca65d33e353bdfdd5edd8d4c8ab5efde52c078bd25e2dcf454f995e5420725
sha256:d6d771d0512387eee1e419a965b929a9a3b0365cf1935b3719d60bf9feffcf63
sha256:dee8cd26669373102db07820072127c46bbfdad340a586ee9dfe60ae933eac2b

$ get-remote-layers $DEBIAN
sha256:6fcf2156bc23db75595b822b865fbc962ed6f4521dec8cae509e66742a6a5ad3

$ get-remote-layers $OPENJDK
sha256:6fcf2156bc23db75595b822b865fbc962ed6f4521dec8cae509e66742a6a5ad3
sha256:96fde6667c188c81fcddee021ccbb3e054ebe83350fd4609e17a3d37f0ec7f9d
sha256:74d17759dd2a1b51afc740fadd96f655260689a2087308e40d1865a0098c5fae
sha256:bbe8ebb5d0a64d265558901c7c6c66e1d09f664da57cdb2e5f69ba52a7109d31