原文連結：https://www.cnblogs.com/Stephen/p/17561440.html

隨著Docker Hub和TreeScale等公共Docker Registry變得越來越流行，管理員和開發人員下載不明來源的Docker映象變得越來越常見。在大多數情況下，便利性勝過可預知的風險。在通常情況下，當一個Docker映象被髮布後，它會直接出現在列表中、git倉庫中或透過相關連結提供。有時候映象並沒有提供Dockerfile。即使提供了Dockerfile，我們也很難保證預構建的映象就是由給出的Dockerfile構建的，這些映象對於我們而言，就是一個黑盒子，我們甚至無法保證其使用的安全性。

也許您並不關心安全漏洞, 您可能只是想更新平時用的比較多的映象，例如nginx，使其能夠執行在最新版本的Ubuntu上。又或者，你會想要釋出一個更最佳化的映象，因為另一個發行版的編譯器更適合在編譯時生成二進位制檔案。

不管什麼原因，我們都需要將映象恢復成Dockerfile的選項。Docker映象並不是一個黑盒子。重建Dockerfile所需的大部分資訊都可以被檢索到。透過觀察Docker映象內部並檢查其內部結構，我們將能夠從一個任意的預編譯容器中重建一個Dockerfile。

在本文中，我們將展示如何使用兩個工具從映象中重建Dockerfile：前面提及的Dedockify是一個的Python指令碼，Dive是一個Docker映象瀏覽工具。使用的基本流程如下。

使用 Dive

Dive demo

為了快速瞭解映象是如何組成的，我們將使用Dive學習一些高階的、可能對我們來說不熟悉的Docker概念。Dive工具可以檢查Docker映象的每一層(Layer)。

讓我們建立一個簡單的Dockerfile，用於測試。

把這個程式碼段直接貼到裝有Docker的linux主機命令列中：

mkdir$HOME/test1cd$HOME/test1cat > Dockerfile << EOF ; touch testfile1 testfile2 testfile3FROM scratchCOPY testfile1 /COPY testfile2 /COPY testfile3 /EOF

輸入以上內容並回車，我們就建立了一個新的Dockerfile，並在同一目錄下填充了3個零位元組的測試檔案。

$ lsDockerfile testfile1 testfile2 testfile3

現在，讓我們使用這個Dockerfile構建一個映象，並標記為example1。

docker build . -t example1

構建example1映象時會產生以下輸出：

Sending build context to Docker daemon  3.584kBStep 1/4 : FROM scratch--->Step 2/4 : COPY testfile1 /---> a9cc49948e40Step 3/4 : COPY testfile2 /---> 84acff3a5554Step 4/4 : COPY testfile3 /---> 374e0127c1bcSuccessfully built 374e0127c1bcSuccessfully tagged example1:latest

現在我們剛構建的example1映象就已經完成了：

$ docker imagesREPOSITORY          TAG                 IMAGE ID            CREATED             SIZEexample1            latest              374e0127c1bc        31 seconds ago      0B

由於沒有可執行檔案，所以該映象將無法執行。我們僅將其作為一個簡化的示例，說明如何在Docker映象中檢視儲存層(Layer)。

我們可以從映象的大小看出，這裡沒有源映象。我們使用scratch來代替源映象，它讓Docker使用一個零位元組的空白映象作為源映象。然後，我們透過複製三個額外的零位元組測試檔案來修改空白映象，並將修改標記為example1。

現在，讓我們用Dive來檢視這個新映象。

docker run --rm -it \ -v /var/run/docker.sock:/var/run/docker.sock \ wagoodman/dive:latest example1

執行上述命令將自動從Docker Hub拉取wagoodman/dive映象，併產生Dive的輸出。

Unabletofindimage'wagoodman/dive:latest'locallylatest:Pullingfromwagoodman/dive89d9c30c1d48:Pullcomplete5ac8ae86f99b:Pullcompletef10575f61141:PullcompleteDigest:sha256:2d3be9e9362ecdcb04bf3afdd402a785b877e3bcca3d2fc6e10a83d99ce0955fStatus:Downloadednewerimageforwagoodman/dive:latestImage Source:docker://example-imageFetchingimage...(thiscantakeawhileforlargeimages)Analyzingimage...Buildingcache...

在列表中上下選擇映象的三個圖層，在右側顯示的目錄樹中找到三個檔案。

我們可以看到右側的內容隨著選擇每一層而變化。當每個檔案被複制到一個空白的Docker從頭映象時，它被儲存為一個新的層。

如果您注意到的話，我們還可以看到生成每個層所使用的命令。我們還可以看到原始檔和更新檔案的雜湊值。

如果我們注意到Command:部分，我們應該看到以下內容：

#(nop) COPY file:e3c862873fa89cbf2870e2afb7f411d5367d37a4aea01f2620f7314d3370edcc in /#(nop) COPY file:2a949ad55eee33f6191c82c4554fe83e069d84e9d9d8802f5584c34e79e5622c in /#(nop) COPY file:aa717ff85b39d3ed034eed42bc1186230cfca081010d9dde956468decdf8bf20 in /

每個命令都提供了Dockerfile中用於生成映象的原始命令。但是，原始檔名丟失了。看來恢復該資訊的唯一方法是觀察目標檔案系統的變化，或者根據其他細節進行推斷。稍後再詳述。

Docker History

除了像dive這樣的第三方工具之外，我們還可以隨手使用的工具是docker history。如果我們在example1映象上使用docker history命令，就可以檢視我們在Dockerfile中建立該映象時使用的條目。

docker history example1

執行玩應該得到以下結果：

IMAGE               CREATED             CREATED BY                                      SIZE                COMMENT374e0127c1bc        25 minutes ago      /bin/sh -c #(nop) COPY file:aa717ff85b39d3ed…   0B84acff3a5554        25 minutes ago      /bin/sh -c #(nop) COPY file:2a949ad55eee33f6…   0Ba9cc49948e40        25 minutes ago      /bin/sh -c #(nop) COPY file:e3c862873fa89cbf…   0B

CREATED BY列中的所有內容都被截斷了。這些是透過Bourne shell傳遞的Dockerfile指令。這些資訊對於重新建立我們的Dockerfile可能很有用，雖然在這裡被截斷了，但是我們也可以透過使用no-trunc選項來檢視完整的資訊：

$ docker history example1 --no-truncIMAGE                                                                     CREATED             CREATED BY                                                                                           SIZE                COMMENTsha256:374e0127c1bc51bca9330c01a9956be163850162f3c9f3be0340bb142bc57d81   29 minutes ago      /bin/sh -c #(nop) COPY file:aa717ff85b39d3ed034eed42bc1186230cfca081010d9dde956468decdf8bf20 in /    0Bsha256:84acff3a5554aea9a3a98549286347dd466d46db6aa7c2e13bb77f0012490cef   29 minutes ago      /bin/sh -c #(nop) COPY file:2a949ad55eee33f6191c82c4554fe83e069d84e9d9d8802f5584c34e79e5622c in /    0Bsha256:a9cc49948e40d15166b06dab42ea0e388f9905dfdddee7092f9f291d481467fc   29 minutes ago      /bin/sh -c #(nop) COPY file:e3c862873fa89cbf2870e2afb7f411d5367d37a4aea01f2620f7314d3370edcc in /    0B

雖然這有一些有用的資訊，但從命令列還原它可能還有些挑戰。我們也可以使用docker inspect。然而，在本文中，我們將專注於使用Python的Docker Engine API。

使用 Python Docker Engine API

Docker釋出了一個針對Docker Engine API的Python庫，允許在Python中管理Docker。在下面的示例中，我們可以透過執行下面的Python 3程式碼來恢復與docker history類似的資訊：

#!/usr/bin/python3import dockercli = docker.APIClient(base_url='unix://var/run/docker.sock')print (cli.history('example1'))

輸出結果如下:

[{'Comment': '', 'Created': 1583008507, 'CreatedBy': '/bin/sh -c #(nop) COPY file:aa717ff85b39d3ed034eed42bc1186230cfca081010d9dde956468decdf8bf20 in / ', 'Id': 'sha256:374e0127c1bc51bca9330c01a9956be163850162f3c9f3be0340bb142bc57d81', 'Size': 0, 'Tags': ['example:latest']}, {'Comment': '', 'Created': 1583008507, 'CreatedBy': '/bin/sh -c #(nop) COPY file:2a949ad55eee33f6191c82c4554fe83e069d84e9d9d8802f5584c34e79e5622c in / ', 'Id': 'sha256:84acff3a5554aea9a3a98549286347dd466d46db6aa7c2e13bb77f0012490cef', 'Size': 0, 'Tags': None}, {'Comment': '', 'Created': 1583008507, 'CreatedBy': '/bin/sh -c #(nop) COPY file:e3c862873fa89cbf2870e2afb7f411d5367d37a4aea01f2620f7314d3370edcc in / ', 'Id': 'sha256:a9cc49948e40d15166b06dab42ea0e388f9905dfdddee7092f9f291d481467fc', 'Size': 0, 'Tags': None}]

根據輸出結果，我們可以發現，如果重建Dockerfile的內容，只需要解析所有相關資料並將其順序反轉一下。但是正如我們之前看到的，我們也注意到在COPY指令中有一些被雜湊(Hash)過的內容。如前所述，這裡的被雜湊過的內容代表從層外使用的檔名。這些資訊無法直接恢復。然而，正如我們在 Dive 中看到的，當我們搜尋對該映象層所做的更改時，我們可以推斷出這些名稱。有時，在原始複製指令將目標檔名作為目標的情況下，也可以推斷出這些檔名。在其他情況下，檔名可能並不重要，允許我們使用任意檔名。而在其他情況下，雖然更難評估，但我們可以推斷出在系統中其他地方被反向引用的檔名，例如在指令碼或配置檔案等支援依賴中。但無論如何，搜尋層之間的所有變化是最可靠的。

Dedockify

讓我們再深入幾步。為了更好地逆向該映象轉換為Dockerfile，我們需要解析所有內容並將其重新格式化為可讀的形式。為了簡化我們的實驗，以下程式碼已經可以從GitHub上的Dedockify倉庫獲取。感謝 LanikSJ 所有基礎工作和編碼。

from sys import argvimport dockerclassImageNotFound(Exception):passclassMainObj:def__init__(self):super(MainObj, self).__init__()        self.commands = []        self.cli = docker.APIClient(base_url='unix://var/run/docker.sock')        self._get_image(argv[-1])        self.hist = self.cli.history(self.img['RepoTags'][0])        self._parse_history()        self.commands.reverse()        self._print_commands()def_print_commands(self):for i in self.commands:print(i)def_get_image(self, img_hash):        images = self.cli.images()for i in images:if img_hash in i['Id']:                self.img = ireturnraise ImageNotFound("Image {} not found\n".format(img_hash))def_insert_step(self, step):if"#(nop)"in step:            to_add = step.split("#(nop) ")[1]else:            to_add = ("RUN {}".format(step))        to_add = to_add.replace("&&", "\\\n    &&")        self.commands.append(to_add.strip(' '))def_parse_history(self, rec=False):        first_tag = False        actual_tag = Falsefor i in self.hist:if i['Tags']:                actual_tag = i['Tags'][0]if first_tag andnot rec:break                first_tag = True            self._insert_step(i['CreatedBy'])ifnot rec:            self.commands.append("FROM {}".format(actual_tag))__main__ = MainObj()

生成初始 Dockerfile

如果您已經完成了這一步，那麼在您實驗的主機上應該有兩個映象：wagoodman/dive和我們自定義的example1映象。

$ docker imagesREPOSITORY          TAG                 IMAGE ID            CREATED             SIZEexample1            latest              374e0127c1bc        42 minutes ago      0Bwagoodman/dive      latest              4d9ce0be7689        2 weeks ago         83.6MB

在我們使用dedockify對example1映象中執行此命令，最終將產生以下結果：

$ python3 dedockify.py 374e0127c1bcFROM example1:latestCOPY file:e3c862873fa89cbf2870e2afb7f411d5367d37a4aea01f2620f7314d3370edcc in /COPY file:2a949ad55eee33f6191c82c4554fe83e069d84e9d9d8802f5584c34e79e5622c in /COPY file:aa717ff85b39d3ed034eed42bc1186230cfca081010d9dde956468decdf8bf20 in /

我們提取到的資訊與之前使用 Dive 解析映象時看到的幾乎一致。注意FROM指令顯示的是example1:late而不是scratch。在這種情況下，我們的程式碼對基礎映象做出了不正確的假設。

作為對比，我們對wagoodman/dive映象做同樣的處理.

$ python3 dedockify.py 4d9ce0be7689FROM wagoodman/dive:latestADD file:fe1f09249227e2da2089afb4d07e16cbf832eeb804120074acd2b8192876cd28 in /CMD ["/bin/sh"]ARG DOCKER_CLI_VERSION=RUN |1 DOCKER_CLI_VERSION=19.03.1 /bin/sh -c wget -O- https://download.docker.com/linux/static/stable/x86_64/docker-${DOCKER_CLI_VERSION}.tgz |     tar -xzf - docker/docker --strip-component=1 \    &&     mv docker /usr/local/binCOPY file:8385774b036879eb290175cc42a388877142f8abf1342382c4d0496b6a659034 in /usr/local/bin/ENTRYPOINT ["/usr/local/bin/dive"]

與example1相比，這個映象顯示了更多的錯誤。我們看到ADD指令就在FROM指令之前。我們的程式碼再次做出了錯誤的假設。我們不知道ADD指令添加了什麼。然而，我們可以直觀地做出假設，即我們不確定基礎映象是什麼。ADD指令可能是用來提取本地的tar檔案到根目錄。也有可能是用這種方法載入另一個基礎映象。

Dedockify limitation testing

讓我們透過建立一個示例Dockerfile來進行實驗，在這個示例中我們明確定義了基礎映象。和我們之前做的一樣，在一個空目錄下，直接從命令列執行下面的程式碼。

mkdir $HOME/test2cd $HOME/test2cat > Dockerfile << EOF ; touch testfile1 testfile2 testfile3FROM ubuntu:latestRUN mkdir testdir1COPY testfile1 /testdir1RUN mkdir testdir2COPY testfile2 /testdir2RUN mkdir testdir3COPY testfile3 /testdir3EOF

然後build映象，將我們的新映象標記為example2。這將建立一個與之前類似的映象，只不過不使用scratch，而是使用ubuntu:latest作為基礎映象。

$ docker build . -t example2Sending build context to Docker daemon  3.584kBStep 1/7 : FROM ubuntu:latest ---> 72300a873c2cStep 2/7 : RUN mkdir testdir1 ---> Using cache ---> 4110037ae26dStep 3/7 : COPY testfile1 /testdir1 ---> Using cache ---> e4adf6dc5677Step 4/7 : RUN mkdir testdir2 ---> Using cache ---> 22d301b39a57Step 5/7 : COPY testfile2 /testdir2 ---> Using cache ---> f60e5f378e13Step 6/7 : RUN mkdir testdir3 ---> Using cache ---> cec486378382Step 7/7 : COPY testfile3 /testdir3 ---> Using cache ---> 05651f084d67Successfully built 05651f084d67Successfully tagged example2:latest

由於我們現在有了一個稍微複雜一些的Dockerfile來重建，而且我們也有了生成這個映象所使用的Dockerfile，因此我們可以做一個對比。

$ docker imagesREPOSITORY          TAG                 IMAGE ID            CREATED             SIZEexample2            latest              05651f084d67        2 minutes ago       64.2MBexample1            latest              374e0127c1bc        1 hour ago          0Bubuntu              latest              72300a873c2c        9 days ago          64.2MBwagoodman/dive      latest              4d9ce0be7689        3 weeks ago         83.6MB

執行dedockify指令碼

$ python3 dedockify.py 05651f084d67FROM ubuntu:latestRUN /bin/sh -c mkdir testdir1COPY file:cc4f6e89a1bc3e3c361a1c6de5acc64d3bac297f0b99aa75af737981a19bc9d6 in /testdir1RUN /bin/sh -c mkdir testdir2COPY file:a04cdcdf5fd077a994fe5427a04f6b9a52288af02dad44bb1f8025ecf209b339 in /testdir2RUN /bin/sh -c mkdir testdir3COPY file:2ed8ccde7cd97bc95ca15f0ec24ec447484a8761fa901df6032742e8f1a2a191 in /testdir3

這與最初的Dockerfile非常吻合。這次沒有ADD指令，而FROM指令也是正確的。只要我們的基礎映象是在原始Dockerfile中定義的，並且避免使用scratch或者避免使用ADD指令從tar檔案建立基礎映象，我們應該能夠比較準確地重建Dockerfile。然而，我們仍然不知道被複制的原始檔案的名稱。

任意 Dockerfile 重建

現在，讓我們嘗試使用我們已經討論過的工具，以正確的方式逆向工程一個Docker容器。我們將使用的容器在上面的示例基礎上進行了修改。我們之前的Dockerfile被修改為example3。透過新增一個小的二進位制可執行檔案，該映象已具備執行的功能。在Dedockify的GitHub倉庫中可以找到原始碼。由於這個映象非常小，我們不需要構建或拉取它。我們可以透過下面的程式碼段將整個容器複製貼上到我們的Docker環境中，來展示我們的命令列技巧 🙂

uudecode << EOF | zcat | docker loadbegin-base64 600 -H4sICMicXV4AA2V4YW1wbGUzLnRhcgDtXVtvG8cVVnp56UN/QJ/YDQokgETNzJkrgTykjgsbDSzDURMkshDM5YzFhiJVkkpiCELzH/pP+tYfkf/UsxRNXdxIspe7lqv5IJF7PTM7Z87MmY9nZxgL2qG1DkN2nkXmtTecQwYrMMfsBHgXgFuVeXLCI5c26sxdNHQsie2Nm8GYZEYp+l7g6vdim4MWBrgyBjaY4MbIjZ66hezGOJ7N/ZSyMp1M5tddd9P5qw/3noA11f+XD5998XjnybVpcMa0lNfoH67oHxiIjV4nhXjP9c/7701WC1pAY/v/+2wyvimNG+zfgLpi/0KbYv+d4KQapmpQNa0G1WZ15Kc4npMsr7JUjGGMyLUzPEXJc1RCWqFkTtoEL5TgEaLSKlmOiXHnUSlKjYsQSFacop9jnTHuDNtinP52GRss/r6pL5iM5344xum3tJWHL6rBSfVoMpuP/SHSXXTFZ5NDuuB8/28znJ5tfTqf+3jwxTwNx9Ug+9EMLxybHM9fP4jT6erg7vzlanvnCMeX5Sz2dsYRV0cejr+vBuPj0WizenCYXm0+PvQvlhn7cjI6PsTZqzNfTabfDccvPhsuc/twPJ++PJoM66I9u2Jn/Ofj4Wgl6nMfcLS8/XSzmtBmNRqOj3+sTm+h/8b2P/IvcdqvbeiX07je/uXr/h9oZor9dwF/dHQbF74R3sz/F1RfuKbLi//fAWr993846C/+J0f/aCONRR9/g/4vbXNQShb7LygoKGgTTDkP1tiEUvkgJajgnTZRA0pAplFqZ1m02hqXjc4+aaVTztx4pzywfvPxH7X1V/0/oZgu7X8XOKn8NB4M5xjnx9N6ROIPk5ZnI6y7P67aq55+uvvok+3j2XR7NIl+tD0Lw/Hgwv5q9/zEYuNslz6q/f85MJsd0CBVD4SHEDhGkM4LDIqHQN4JjU5s5NqiJguRAr3nKpgICoRhyLNiCgHQOLxhfLdN7teVMd7e4uD2AY5Gkzpv14/2VuPgegyvDA3aOATr5cJkJUs0tMsRacytE6MsGZnp/piCEMaiijHmJJOIihvNbh5WX0zh/7kqkA5od3t2QI+yFenjw4/Gk6OPe7Wqnuw++/rpzuMnu7295xdU9bzar29/X6rPyenpRZZFMMG2GGwxsStgoPhAQF8KrZ1grqZb0iR+R5Xie5zOhpPxgpbpM+hrOnUwnM0nU1LY3sm1AnnfOXCgDDPfnDM834aX9XOclXZvK/aWJf3VzrO/fvb4WW97jjPS95RXp5vXyxd9Qd0MSCnsLeQ/2Hn6dS8PRzgAIbLLTiBEJ9Ej8hRZEmCURW6CcTaD8+h18BhtdsrJIFDGmBigS6w3HPfqTNbCeO8W2SQjVBK4lW9RDOIW8hUZv+PG8XdWDOI2xWA4mYGkKvYWxQC3kO+YdMYxod5ZMcDNxQB9Zpkg38iJNymG2uxvFi005+RJwRsVQAAIkmURmaF+gwUXvAZjApistWaSJyWFoAaKOS1DFJrKR0omQSSNVvO6ABaNz20e/mITc0MOe9c1vJsVHh7NX3674CKrwXx6jKf7l6jQzar233Ld8lXzl0d1E724eFY3bsOcvx2mWd14LtttriUXQXJAZFJn5MLriMHJTA6yT44zHZjHQJ2qZM5watCpBeeevFdMdANJXUkC7ZMxjCq7TI6cbW+zUkEpqj/RMrBeWInCUuFqj3QZTxays9RrBNT+XBJDh2QwwQkfqXcAqjZK5RA5SNIJzywKSTKTMGiYjkoknwJjzgVg1vBwLilYbbwhFzszLYTTwqNgRiMEZhMYK7zztZ9gmHUZap8/0WOROCXRenUhT1Q8IlhltBbOihhRZhOtoucgwVRolD3DkqprS6bHZzlbmxMNOBJGRYVxLsmDcSGZJBkTjkdlEtW3IKj4nA0oUJHDYgP5MZQ3qjHKZCrDqJSylvwZhAtPF5PRMfJEt4I0kjvms/QqU4VVnp6O6jD3PJpaujKcLqJqaNF5TlrR5lxS5jQ2IfVRv22MAhbInjAaiNIpzkSGCAacVmAj0IPWDVoKPFCjQMXi0VX7p7eh4N8phI70kElxeg7vhJIKZYpaqOy9J9Vpck3Qkx2I2qOMIUrSQ46GKrzkqHRb8R+cF/63CzTWfyvxH8LI8vtPJyjxH/cbje1/DfEfWvDX4j8YL/bfBZbxH02rQYnZ6DBmY51obP/txH8oUX7/7QSv+LU2g0DezP/nVF+EBij+fxdY6b/FIJC6PN4s/kOqWv/F/gsKCgrag2JgEIxFl3RyIWQB2bjkDIiYFeTIUuLJy6SNNUG4wKPl3GeXEgSfWuL/BNTxv6X/bx+N9d/O+18gVen/u0Dh/+43Gtt/K+9/gWDF/jvBkv9rWg0uvf/lBSZQEqIiYUoB50E7iU4JFD4ESbcok5Kq6SWbIWjFpbFSCOmUYaxwiR1yiY3tvxX+T3JR3v/sBK8Cy+4O/yfO+L/y/lcnWOn/rvF/hf8vKCgoaBXGQgwYvEKWwNmY0euoAs/cks/mFGMgBI+BfD7jaJtrHaMnhx1ZMAF9a/M/6dL/d4HG+m9r/qfS/3eCwv/dbzS2/7bmfyr23wmW/F/TanCR/7PKBZAyeI7SuGDqd0Y9ahVYZj6nJFFqpZS2UieBDAC05HRxNBKE06nwfx3yf43tv6X5n3iJ/+0Er96ovHP8X/H/O8FK/3eN/yu//xUUFBS0iqbOekv8nzSs9P9doLH+23n/V4ky/1cnKPzf/UZj+2+H/wNd7L8TLPm/NXB2K/5vDbGEhf/riv9rbP/t8H/Ayvt/naDE/xX9L/S/mrxv/Wnc7P9f1P+C/5OyxP8WFBQUtIqmizW1Ff9X+v9u0Fj/Lc3/Z4r/3wkK/3e/0dj+W4r/K/P/dIMl/7eGNRtX/N8aYgkL/9cV/9fY/lua/0+xYv9doMT/Ff0v9L9atWL9abwV/1fi/wsKCgpaRdPJetqK/6vX/y39f/torP+W4v94+f2vExT+736jsf23FP+niv13glf8X/M5+1b8X1lL5H3i/5rafzv8n9Bl/a9OcPfW/1jyf8X/7wQr/a/WMF5/Gm/F/xX+v6CgoKBVJPK8tUkQIUjIXCXMBoJj0oPO3BtujJc86SyRWaFFDOhQ8QxKJ8uya2n9D6bK+h+doLH+25n/j/My/0cnKPzf/UZj+2/O/wmQr63/a0r8TzdY8n9Nq8FF/o+xoB1a6zBk51lkXpMADhmswByzE+BdAG5V5skJj1zaSKm4aOhYEpf4P8EE22KwxcSugIHiAwF9KbR2grlLRGCdsKrfXuUQrJe25hYlS5SRHDFpoxNDACOzDxhToCpmUcUYc5JJRMWNZjfzihdTuGsc41719NPdR59sH8+m26NJ9KPtWRiOBxf2V7vnJxYbZ7v0Ue0vScq9qt7dnh3Qo2xF+vjwo/Hk6ONezUc+2X329dOdx092e3vPq21/dLR9gKPR5Hm1X9/+iticHXih9EB4CIFjBOm8wKB4CIxMnRkbubaokRoGgd5zFUwEBcIw5FkxRbpC4/AGfrRO/gpHunchT3WGfoEtPTk93azSJH5Hqv4ep7PhZLxgm/sM+vqsItx9WnmdKr/MS9919S3Jbj+NB8M5xvnxtM61P0y6tst3uJ72+4bG/X9z/l+9Pv4DXd7/6Qa1sbWdxhuP/znXqsT/doJVY9tiGrX9X6t/Y67w/9SPlPF/J/jnw8//8sFq78Fvf7Xx640/0Hf9/xs68h9OG//+/c8//am38cHGv37+6VFdWTZ7P0ymo/TH3727jBcUFBQUNMKhHw8zzub9W/B4b4sb/H8O0lzyBemIEuX9n06wd1I9WFIdFVPOgzU2oVQ+SAkqeKdN1IASaKiPUrsFr2aNy0Znn8hNTzlz453ywBZ1iIbfz/BosutfzOrRPP7oD49GCIORryNM6iH95/WIcXGyaaTg+eCTUl1fJBsJW9+yuCRsfXPskbD1LdhRl9na3v4lYU1530vC1sdLVPun+8VP/SVMyVZnw/lkOsRZW2nc9PsvB7ja/pNBlPa/C5ysWuia61420mv4Pej0tNhcQUFBwV3GfwHMszUXAMIAAA======EOF

直接從命令列執行後會載入一個新的映象 example3:latest。

$ docker imagesREPOSITORY TAG IMAGE ID CREATED SIZEexample3 latest 059a3878de45 5 minutes ago 63B

現在，讓我們嘗試重建Dockerfile。

$ python3 dedockify.py 059a3878de45FROM example3:latestWORKDIR /testdir1COPY file:322f9f92e3c94eaee1dc0d23758e17b798f39aea6baec8f9594b2e4ccd03e9d0 in testfile1WORKDIR /testdir2COPY file:322f9f92e3c94eaee1dc0d23758e17b798f39aea6baec8f9594b2e4ccd03e9d0 in testfile2WORKDIR /testdir3COPY file:322f9f92e3c94eaee1dc0d23758e17b798f39aea6baec8f9594b2e4ccd03e9d0 in testfile3WORKDIR /appCOPY file:b33b40f2c07ced0b9ba6377b37f666041d542205e0964bc26dc0440432d6e861 in helloENTRYPOINT ["/app/hello"]

這為我們提供了一個基礎Dockerfile。由於example3:latest是這個映象的名稱，我們可以從上下文假設它使用了`scratch`。現在，我們需要看看有哪些檔案被複制到了/testdir1、/testdir2、/testdir3和/app。讓我們在Dive中執行這個映象，看看如何恢復丟失的資料。

docker run - rm -it \ -v /var/run/docker.sock:/var/run/docker.sock \ wagoodman/dive:latest example3:latest

如果您向下選擇到最後一層，您將能夠看到所有丟失的資料填充到右側的目錄樹中。每個目錄都複製了名為testfile1、testfile2和testfile3的零位元組檔案。在最後一層中，一個名為hello的63位元組檔案被複制到了/app目錄中。

讓我們恢復這些檔案！由於無法直接從映象中複製檔案，因此我們需要先建立一個容器。

$ docker run -td --name example3 example3:latest6fdca182a128df7a76e618931c85a67e14a73adc69ad23782bc9a5dc29420a27

現在，讓我們使用下面從Dive恢復的路徑和檔名將我們需要的檔案從容器複製到主機。

mkdir $HOME/test3cd $HOME/test3docker cp example3:/testdir1/testfile1 .docker cp example3:/testdir2/testfile2 .docker cp example3:/testdir3/testfile3 .docker cp example3:/app/hello .

我們可能得先檢查我們的容器是否仍在執行。

$ docker psCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES6fdca182a128 example3:latest "/app/hello"2 minutes ago Up 2 minutes wizardly_lamport

如果容器由於某種原因沒有執行，沒關係。我們可以驗證它的狀態，看看它是否已經停止。

$ docker container ls -a

我們還可以檢視執行日誌。

$ docker logs 6fdca182a128Hello, world!

它似乎在執行一個輸出Hello, world!程式。實際上，在這種情況下，Hello, world!程式並不是被設計成始終執行的。在19.03.6版本的Docker中，可能存在一個錯誤，導致程式無法正常終止。目前這是可以接受的。容器可以活動或停止；應用程式不需要持久化來恢復我們需要的任何資料。處於任何狀態的容器都只需要從我們正在提取資料的源映象中生成。

透過執行恢復的可執行檔案來驗證其行為，我們應該看到以下內容：

$ ./helloHello, world!

使用我們之前生成的Dockerfile，我們可以更新它以包含所有新的細節。這包括將FROM指令更新為從頭開始，以及我們在使用Dive探索時發現的所有檔名。

FROM scratchWORKDIR /testdir1COPY testfile1 .WORKDIR /testdir2COPY testfile2 .WORKDIR /testdir3COPY testfile3 .WORKDIR /appCOPY hello .ENTRYPOINT ["/app/hello"]

再次，將所有檔案合併到一個共享資料夾中，我們就可以執行我們逆向工程的Dockerfile了。

讓我們先構建一個映象。

$ docker build . -t example3:recoveredSending build context to Docker daemon 4.608kBStep 1/10 : FROM scratch - ->Step 2/10 : WORKDIR /testdir1 - -> Running in 5e8e47505ca6Removing intermediate container 5e8e47505ca6 - -> d30a2f002626Step 3/10 : COPY testfile1 . - -> 4ac46077a588Step 4/10 : WORKDIR /testdir2 - -> Running in 8c48189da985Removing intermediate container 8c48189da985 - -> 7c7d90bc2219Step 5/10 : COPY testfile2 . - -> 5b40d33100e1Step 6/10 : WORKDIR /testdir3 - -> Running in 4ccd634a04dbRemoving intermediate container 4ccd634a04db - -> f89fdda8f059Step 7/10 : COPY testfile3 . - -> 9542f614200dStep 8/10 : WORKDIR /app - -> Running in 7614b0fdba42Removing intermediate container 7614b0fdba42 - -> 6d686935a791Step 9/10 : COPY hello . - -> cd4baca758ddStep 10/10 : ENTRYPOINT ["/app/hello"] - -> Running in 28a1ca58b27fRemoving intermediate container 28a1ca58b27f - -> 35dfd9240a2eSuccessfully built 35dfd9240a2eSuccessfully tagged example3:recovered

然後我們來執行這個映象:

$ docker run - name recovered -dt example3:recovered0f696bf500267a996339b522cf584e010434103fe82497df2c1fa58a9c548f20$ docker logs recoveredHello, world!

為了進一步驗證，讓我們再次使用 Dive 檢查映象。

docker run - rm -it \ -v /var/run/docker.sock:/var/run/docker.sock \ wagoodman/dive:latest example3:recovered

此映象顯示的檔案與原映象相同。將兩個映象並排比較，它們都完全匹配。兩者顯示的檔案大小相同。兩者的功能完全相同。

以下是用於生成example3映象的原始Dockerfile。

FROM alpine:3.9.2RUN apk add - no-cache nasmWORKDIR /appCOPY hello.s /app/hello.sRUN touch testfile && nasm -f bin -o hello hello.s && chmod +x helloFROM scratchWORKDIR /testdir1COPY - from=0 /app/testfile testfile1WORKDIR /testdir2COPY - from=0 /app/testfile testfile2WORKDIR /testdir3COPY - from=0 /app/testfile testfile3WORKDIR /appCOPY - from=0 /app/hello helloENTRYPOINT ["/app/hello"]

我們可以看到，雖然我們不能完美地重建它，但我們能夠大致重建它。像這樣使用多階段(stage)構建的Dockerfile是無法重建的。這些資訊根本就不存在。我們唯一的選擇是重建我們實際擁有的映象的Dockerfile。如果我們有早期構建階段的映象，我們可以為每個階段重構一個Dockerfile，但在這種情況下，我們只有最終構建階段的映象。但不管怎樣，我們還是成功地從Docker映象中重現了一個有用的Dockerfile。

後記

透過使用與Dive類似的方法，我們應該能夠更新Dedockify的原始碼，使其能夠自動分析每一層，以恢復所有有用的檔案資訊。此外，該程式還可以更新為能夠自動從容器中恢復檔案並將其儲存到本地，同時還能自動對Dockerfile進行適當的更新。最後，還可以對程式進行更新，使其能夠輕鬆推斷出基礎層是否使用了Scratch或其他基礎映象。透過對恢復的Dockerfile語法進行一些額外的修改，Dedockify有可能被更新為在大多數情況下完全自動地將Docker映象逆向工程為一個功能性的Dockerfile。

END

想要學習Linux系統的讀者可以點選"閱讀原文"按鈕來了解書籍《Linux就該這麼學》，同時也非常適合專業的運維人員閱讀，成為輔助您工作的高價值工具書！