點擊上方藍字關注我們

基于領域知識的Docker鏡像自動構建方法

陳偉^1,2,?葉宏杰^1,2,?周家宏^1,2,?魏峻^1,2

1?中國科學院大學，北京 100190

2?中國科學院軟件研究所，北京 100190

?

摘要：Dockerfile是構建Docker應用鏡像的腳本代碼，包含軟件系統鏡像構建所需的軟件包及其依賴的下載、安裝和配置的所有指令。編寫Dockerfile需要豐富的領域知識，否則編寫的Dockerfile容易產生鏡像構建錯誤。針對此問題，提出一種基于領域知識的Docker鏡像自動構建方法。該方法通過對大規模Dockerfile的自動解析，分析提取構建Docker鏡像所需的軟件依賴及安裝配置等領域知識；在面向特定軟件系統構建鏡像時，從已構建的領域知識庫中分析推斷指定軟件的依賴關系及安裝操作，生成Dockerfile來構建Docker鏡像。實驗結果表明，該方法具有利用領域知識推斷系統依賴關系和軟件包安裝方式、生成不同軟件Dockerfile的能力。

關鍵詞：Docker,?Dockerfile,?知識圖譜,?軟件包,?系統依賴

論文引用格式：

陳偉, 葉宏杰, 周家宏,? 等. 基于領域知識的Docker鏡像自動構建方法[J]. 大數據, 2021, 7(1): 64-75.

CHEN W, YE H J, ZHOU J H, et al. An approach to automatically building Docker images by using domain knowledge[J]. Big Data Research, 2021, 7(1): 64-75.

1 引言

在傳統軟件開發過程中，開發部署和運行演化兩階段相互割裂，各階段數據匯聚與知識提煉、關聯與運用程度低，難以快速響應需求變化。為此，開發運維一體化（DevOps）被提出，旨在加強開發和運維部門之間的溝通協作，提高軟件運行演化過程中生產活動的效率和質量。DevOps的引入對軟件產品的開發、測試、交付和運維有重要意義。

Docker是當前主流的容器技術，在DevOps中被廣泛使用。Docker容器是Docker鏡像的實例，封裝了軟件應用程序及其系統依賴項（即操作系統和相關軟件包），構建了保證軟件系統能夠正常運行的環境。Docker鏡像成為DevOps中軟件系統構建和發布的主流制品形式，Docker容器則成為復雜分布式系統部署和運行的主流基本構成。Dockerfile是基于領域特定語言（domain specific language，DSL）編寫的腳本代碼，用于構建Docker鏡像，并實例化Docker容器。Dockerfile包含一組構建Docker鏡像的指令序列，聲明了構建鏡像時使用的操作系統、安裝的軟件包以及安裝順序等。

盡管Dockerfile被廣泛用于構建Docker鏡像，但人工編寫Dockerfile十分復雜且容易出錯，Dockerfile質量問題導致的Docker鏡像構建失敗案例普遍存在。一方面，Dockerfile指定了鏡像構建的系統環境配置，特別是軟件包之間的關聯和依賴、軟件包與操作系統的兼容性、軟件下載安裝的操作以及順序等，需要全面的領域知識；另一方面，人工編寫Dockerfile時的拼寫錯誤、語法錯誤、違反最佳實踐和Dockerfile壞味（bad smell）等質量問題難以避免。例如，在為Python代碼片段構建Docker容器運行環境時，開發人員平均要花費2 h編寫Dockerfile，但是仍難以保證Python代碼片段正確運行。

本文提出了一種基于領域知識的Dockerfile自動生成方法，用于支持Docker鏡像的自動構建。該方法首先自動解析Docker Hub上的大量Dockerfile，從中提取構建Docker鏡像所需的細粒度知識，包括基礎鏡像、操作系統、系統軟件包的下載和安裝配置等，并通過軟件包在Dockerfile中的出現順序和共現性推斷軟件包之間的關聯，構建領域知識庫。在面向特定軟件系統構建鏡像時，方法基于領域知識分析推斷指定軟件的系統依賴關系及其安裝操作，并生成Dockerfile，用于構建Docker鏡像。在最后的實驗中，本文選取了100個不同類型的軟件系統，并為其構建容器鏡像，本文方法能夠為其中的73個軟件系統成功構建Docker鏡像。實驗結果表明，本文方法在構建軟件鏡像時能夠應對軟件類型的多樣性，具有較好的鏡像構建成功率。本文的工作主要有以下兩點貢獻。

● 提出了一種面向Docker鏡像構建的領域知識圖譜自動構建方法。本文方法提出了Docker鏡像構建的領域知識圖譜元模型，并基于抽象語法樹（abstract language tree，AST）分析技術從大規模Dockerfile中提取各種類型的領域知識實體與關系，實現知識圖譜的構建。

● 提出了一種Dockerfile的自動生成方法。本文方法根據知識圖譜推斷構建目標軟件系統鏡像所需的基礎鏡像、需要安裝的所有軟件包及安裝順序和操作，生成指令，并合成Dockerfile。

2 相關工作

DockerizeMe和FRISK與本文工作相關度較高。DockerizeMe主要解決Python代碼中因缺少第三方依賴而導致的導入錯誤（import error）問題，并通過構建Docker鏡像來實現Python代碼的運行環境。針對Python包依賴問題，DockerizeMe收集Python軟件包索引（Python package index，PyPI）上流行的前1萬個Python包及其資源，并從安裝和導入包過程的日志中提取包之間的依賴關系，建立Python包依賴庫。對于給定的Python代碼，DockerizeMe根據依賴庫推斷代碼的第三方依賴包，并將Python:2.7.13作為基礎鏡像構建容器環境。FRISK的目標是為問答論壇（如Stack Overflow）中問題的解決方案構建復現環境，尤其是面向與服務器端開發相關的問題。FRISK預定義了幾個Dockerfile模板，用于創建具有多種語言環境和數據庫的服務器端Web框架運行環境，主要面向Express.js、Rails 5、Django、Flask等。通過FRISK，用戶可以從模板Dockerfile開始修改，創建符合要求的Dockerfile，進而生成相應的Docker容器環境。但是，DockerizeMe和FRISK都僅僅面向特定的問題場景，難以很好地應對軟件系統的多樣性及其資源依賴給Docker鏡像構建帶來的困難。

除了上述兩項工作，還有其他工作關注與Docker相關的知識圖譜構建和Dockerfile質量問題。DockerPedia是一個面向軟件之間依賴關系以及安全漏洞信息的知識圖譜，基于輕量級的本體論（ontology），建立了不同概念之間的聯系。Binnacle工具集針對Dockerfiles構建AST，然后使用頻繁子樹挖掘算法來挖掘Dockerfile編寫中的語義規則和最佳實踐。Lu Z G等人總結了Dockerfile中的4種壞味模式，并提出了一種基于狀態的靜態分析方法來檢測Dockerfile壞味。Wu Y W等人開展實證研究，總結了開源軟件中的Dockerfile壞味。Hassan F等人通過分析軟件環境的變化及其影響，向開發人員推薦Dockerfiles的更新。Cito J等人對Docker生態系統、Docker質量問題和Dockerfiles的演變進行了探索性的實證研究。

3 基于領域知識的Docker鏡像自動構建方法

如圖1所示，基于領域知識的Docker鏡像自動構建方法主要分為兩個階段：知識圖譜構建和Docker鏡像自動生成，其中第二階段的重點在于Dockerfile的自動生成。

圖1???基于領域知識的Docker鏡像自動生成構建流程

在知識圖譜構建階段，本文方法從Docker Hub上收集大量Dockerfile，并自動解析，從基于解析構建的Dockerfile AST中抽取出實體和關系，并基于定義的知識圖譜元模型構建知識圖譜。

在Docker鏡像自動生成階段，對于用戶指定需要安裝的目標軟件，本文方法從知識圖譜中推斷構建Docker鏡像所需的基礎鏡像和該軟件包關聯的其他軟件包，并確定相應的安裝配置順序和方式。最后，方法根據分析結果構造Dockerfile指令，并合成Dockerfile，進而基于Dockerfile構建鏡像。

4 數據收集與知識圖譜構建

數據收集與知識圖譜的構建主要包括以下步驟：

步驟1 基于網絡爬蟲獲取Docker Hub上的Docker項目及其對應的Dockerfile等數據；

步驟2 解析Dockerfile，并構建AST；

步驟3 從Dockerfile的AST中識別各種類型的實體以及實體間的關系；

步驟4 基于知識圖譜元模型，整合解析得到的各類型實體和關系，生成知識圖譜。

4.1 知識圖譜元模型

領域知識圖譜元模型M由實體集合En和關系集合Re構成，即M=(En,Re)。元模型結構如圖2所示，主要包括8種類型的實體（Docker項目、Dockerfile、Docker鏡像、操作系統、操作系統版本、軟件包安裝工具、軟件包版本、軟件）；以及8種類型的關系（包含、構建、基于、實例化、使用、安裝、兼容、關聯），涵蓋了Dockerfile自動生成所需的多種知識。元模型表達的語義知識包括：Docker項目包含Docker鏡像和構建該鏡像所使用的Dockerfile；Docker鏡像可以依賴其他鏡像，即將其他鏡像作為構建時的基礎鏡像；Docker鏡像中包含使用的操作系統信息，以及安裝的軟件包及其版本信息；軟件包可以通過包管理軟件安裝，或者通過下載、配置、編譯的方式安裝；操作系統有不同的版本，不同操作系統安裝軟件包的方式不同，不同版本的操作系統可安裝的軟件包也不同；軟件是軟件包安裝后的實例；軟件包之間可能存在關聯或依賴關系，這種關系決定了多個軟件包在下載安裝時需按照一定的先后順序執行。

圖2???領域知識圖譜元模型

4.2 數據獲取

構建知識圖譜需要將大量的Docker項目和Dockerfile作為知識源。Docker Hub是Docker官方維護的大型公共Docker倉庫，包含數以百萬計的Docker項目，但是沒有提供完整的項目列表和查詢接口。針對這些問題，本文設計并實現了一個高效的爬蟲工具，自動爬取Docker Hub中的海量項目數據。爬蟲工具的工作流程如下：

● 針對缺少完整Docker項目列表的問題，爬蟲實現了一個基于英文字母組合的檢索關鍵詞生成機制，使得檢索結果能夠覆蓋所有的Docker項目；

● 以不同的關鍵詞在Docker Hub上進行檢索，獲得以各個關鍵詞開頭的Docker項目列表；

● 針對海量數據的爬取效率問題，實現了基于多線程的并行爬取流程，通過多個線程的并行執行來提高Docker Hub上Docker項目的獲取效率。

目前本文工作已經收集了約110萬個Docker項目的信息和約96萬份Dockerfile。

4.3 Dockerfile解析

Dockerfile解析包括兩個階段：Dockerfile預處理；構建Dockerfile對應的AST。

Dockerfile中的指令主要包括FROM指令、ENV指令和RUN指令等。其中， FROM指令用于指定基礎鏡像，ENV指令用于定義環境變量，RUN指令用于聲明構建基礎鏡像時需要運行的bash命令行指令。例如，在圖3的Dockerfile中，第1行FROM指令指出當前Docker鏡像是基于centos鏡像、centos7版本構建的；第3行ENV指令定義了兩個環境變量LANG和LC_ALL，取值都為C.UTF-8；第6~8行RUN指令指出構建鏡像時需要運行yum install指令，安裝wget、bzip2、ca-certificates等軟件包。

圖3???示例Dockerfile(1)

Dockerfile預處理主要解析環境變量定義指令，并在隨后出現的指令中將環境變量替換為對應的值，即通過預處理實現環境變量的實例化。解析環境變量包括以下兩個步驟。

步驟1 解析環境變量定義指令。ENV指令的格式可以表示為“ENV key value”，其中，key表示環境變量的名稱， value表示環境變量的值。因此，可以構建名-值映射表Map＆lt;key,value＆gt;來存儲環境變量。對于每一條ENV語句，提取其中的key和value，并存入映射表中，實現對環境變量定義指令的解析。

步驟2 替換后續指令中出現的環境變量。在Dockerfile中使用環境變量時，環境變量以“$”開頭。以此為依據提取每一條指令中出現的環境變量的名稱，在映射表中查找對應的值，完成環境變量實例的替換。

圖4是一份帶有環境變量的Dockerfile，經過環境變量解析，共解析出ANDROID_NDK_VERSION、COCOS2D_X_VERSION、NDK_HOME 3個環境變量，并進一步對第5、8、9、10、11行環境變量的值進行替換，最終轉換成為如圖5所示的Dockerfile。

圖4???示例Dockerfile(2)

圖5???環境變量替換后的Dockerfile(2)

完成環境變量替換后，本文方法考慮Dockerfile指令和嵌套的bash指令的不同語法，設計了以下兩階段的Dockerfile指令解析方法，從而構建AST。

● 以Docker項目的名稱為根節點，將每條指令解析為根節點的一個葉節點，用指令的名稱表示；

● 關注指令后的文本。有些指令后的文本仍是Dockerfile指令的語法，如FROM、ENV等指令。對于這些指令，仍使用Dockerfile指令的語法解析器進行解析，生成相應的葉節點。有些語句指令后的文本嵌套的是bash指令的語法，如RUN、CMD等指令。對于這些指令，使用bash指令的語法解析器進行解析，生成相應的葉節點。

例如，圖3的Dockerfile生成的AST如圖6所示。其中，淺色節點是使用Dockerfile語法解析器解析生成的節點，深色節點是使用bash語法解析器解析生成的節點。

圖6???Dockerfile(1)對應的AST

4.4 實體和關系識別

得到Dockerfile對應的AST后，本文方法進一步從中識別實體及其之間關系，主要包括：基礎鏡像和操作系統識別、軟件包識別、軟件包關聯識別。

對于基礎鏡像和操作系統識別， Dockerfile中的FROM指令聲明了當前Docker鏡像的基礎鏡像。本文方法對AST中以FROM節點為根的子樹進行分析，得到基礎鏡像信息。鏡像具有傳遞依賴性，且依賴于某個操作系統鏡像。首先判斷當前鏡像img_df是否是操作系統鏡像，或者基礎鏡像img_base是否是操作系統鏡像，如果是，則得到操作系統信息；否則，解析img_base的Dockerfile，判斷img_base的基礎鏡像是否是操作系統鏡像，重復該過程，直到發現操作系統鏡像，得到操作系統信息。

對于軟件包識別，根據Dockerfile對軟件包的安裝方式，本文首先將軟件包分為官方軟件包（officially packaged software，OPS）和非官方軟件包（un officially packaged software，UOPS）兩類。OPS指登記在公共倉庫中、統一管理的軟件包，可以通過apt/apt-get、YUM等包管理工具自動安裝、管理和卸載。UOPS指無法通過包管理工具自動下載、安裝的軟件，通常以壓縮文件或Git倉庫的形式存在，并由唯一的統一資源定位器（uniform resource locator，URL）指定軟件包下載地址，開發者和用戶通常需要下載并進行解壓和編譯，再執行相應的安裝操作。以圖3的Dockerfile為例，第6行中的wget、bzip2等是OPS，可以通過包管理工具YUM進行下載；而第10行中的https://repo.continuum.io/archive/Anaconda35.1.0-Linux-x86_64.sh是UOPS，需要通過下載、解壓、切換工作目錄、運行安裝程序等步驟才能安裝。

對于OPS，如前所述，apt/apt-get、YUM、dnf等常見的包管理工具提供了OPS的安裝能力，可以通過相應的包管理器命令進行下載安裝。對RUN節點的子樹進行分析，得到bash語句中的指令節點和參數節點，當指令節點是包管理器的安裝命令（如apt-get install、yum install等）時，提取參數節點進一步分析。首先通過yumshowduplicates list、apt-cache pkgnames等命令獲取各個包管理器中所有可安裝的軟件包列表，之后通過包名匹配的方式確定當前語句安裝的軟件包及其版本。例如，對于圖3第6行（對應圖6中AST第三棵子樹），本文方法可以分析出語句安裝了wget、bzip2和ca-certificates等包。

對于UOPS，本文方法關注wget、cURL、Git等常用于下載UOPS的bash指令。由于UOPS并沒有對軟件進行統一命名，本方法使用下載的URL作為UOPS的唯一標識，并通過URL解析的方式，在下載指令的參數節點中確定安裝的UOPS。額外地，本文方法通過爬蟲驗證下載鏈接是否可訪問，以保證UOPS的有效性。

對于軟件包關聯識別，經過軟件包識別，本文方法可獲取當前Dockerfile安裝的軟件包集合PKG={pkg₁,pkg₂,…,pkg_n}。基于Dockerfile進行Docker鏡像構建時，軟件包的安裝是有序的。本方法以關聯<pkg_i,pkg_j>的形式記錄兩個包pkg_i和pkg_j在當前Dockerfile中的安裝順序，表示pkg_i先于pkg_j安裝，作為軟件包之間的關聯。

4.5 知識圖譜構建

基于第4.1節定義的知識圖譜元模型，本文方法將所有Dockerfile解析提取得到的實體和關系整合寫入知識圖譜G_df=(V,E)，其中，V為頂點集合，E為邊集合；V對應元模型M中的實體集合En，每個頂點v代表一個唯一的實體，其類型為Docker鏡像、軟件包、操作系統等；E對應M中的關系集合Re，邊e_ij代表兩個頂點v_i、v_j之間的關系（即兩個實體之間的關系），并用邊的權重表示該關系在所有Dockerfile中出現的頻數。當邊e_ij連接的兩個頂點v_i、v_j代表兩個軟件包時，則e_ij表示兩者之間的先后安裝順序，如果e_ij和e_ji同時出現在知識圖譜中，則說明兩個軟件包之間并沒有依賴關系，可以以任意順序安裝。

經過對約22萬份高質量的Dockerfile進行分析，本文方法建立了一個含有約90萬個頂點和約290萬條邊的知識圖譜。

5 Dockerfile自動生成方法

給定一個軟件包（尤其是UOPS，因為典型的OPS可以通過特定的包管理器自動下載安裝），生成對應的Dockerfile需要考慮以下幾方面：基礎鏡像、需要安裝的軟件包、軟件包的安裝順序。因此，本文方法的任務是根據給定的軟件包s，在知識圖譜Gdf中挖掘提取出三元組Ks=(imgbase,PKGs, seqs)，其中，imgbase表示安裝s時使用的基礎鏡像；PKGs表示安裝s時需要安裝的所有軟件集合（包括s本身）；seqs表示PKGs中所有軟件的安裝順序集合，安裝順序以軟件對＆lt;pkgi,pkgj＆gt;的形式出現。

5.1 基礎鏡像推薦

基礎鏡像推薦包括兩步：在Gdf中找到候選基礎鏡像集合；候選基礎鏡像排序。

首先，本文方法在Gdf中進行搜索，找到所有安裝了給定軟件包s的鏡像。如果用戶指定了操作系統，則再根據操作系統篩選出滿足用戶需求的鏡像，生成候選鏡像集合。

得到候選鏡像集合后，本文方法根據鏡像的流行度進行排序。鏡像的流行度指一個鏡像被選作其他鏡像的基礎鏡像的次數。排序后，將流行度最高的鏡像作為安裝s時使用的基礎鏡像imgbase。

5.2 關聯軟件包分析

軟件包間的關聯具有傳遞性，故在Gdf中，從s對應的頂點開始，采用廣度優先搜索（breadth first search，BFS）算法找到所有與s關聯的包，生成Gdf的子圖Gs。子圖中所有頂點即需要安裝的軟件包集合PKGs。

部分關聯出現次數較少，可信度較低。因此，本文方法提出關聯度cor(pkgi,pkgj)這一指標，評判兩個軟件包pkgi、pkgj之間存在關聯的可信度。BFS只會搜索關聯度高于設定閾值的邊。關聯度計算方法如下。

● 當軟件包pkgi和pkgj之間只存在一條邊時，cor(pkgi, pkgj)的計算方法如式（1）所示。其中，w(i, j)表示知識圖譜中邊eij的權重，即所有Dockerfile中pkgi和pkgj共同被安裝的次數。|pkgi|表示在所有Dockerfile中，pkgi被安裝的次數。若軟件包pkgi和pkgj之間只存在一條邊，且關聯度高于閾值，則說明pkgi和pkgj之間存在依賴關系，pkgi需要在pkgj之前安裝。

● 當軟件包pkgi和pkgj之間存在兩條邊時，cor(pkgi,pkgj)的計算方法如式（2）所示。其中，w(i, j)+w(j, i)表示在所有Dockerfile中pkgi和pkgj共同被安裝的次數，|pkgi|+|pkgj|表示所有Dockerfile中pkgi被安裝的次數和pkg?j被安裝的次數之和。軟件包pkgi和pkgj之間存在兩條邊，且關聯度高于閾值，只能說明兩個包之間存在關聯，兩個軟件包可以以任意順序安裝。

5.3 軟件包安裝順序推斷

為了確定軟件包的安裝順序，需要對子圖G_s中的各個頂點進行拓撲排序。排序前需要消除G_s中的環。如果環中的頂點數為2，則刪除環中的所有邊，因為這兩個軟件包可以以任意順序安裝；如果環中的頂點數大于2，則刪除環中關聯度最小的邊。消除環后，本文方法對各個頂點進行拓撲排序，排序的結果即軟件包的安裝順序seq_s。

5.4 Dockerfile生成

根據基礎鏡像、需要安裝的軟件包及安裝順序，本方法生成Dockerfile的步驟如下。

● 根據基礎鏡像img_base，生成指令FROMimg_base。

● 根據軟件包的安裝順序，逐條生成各個軟件包的安裝指令。

● 對于OPS，在知識圖譜中找到該軟件包對應的包管理器，生成運行包管理器安裝該軟件包的RUN指令。例如，若軟件包pkg的包管理器是apt-get，則會生成指令RUN apt-get install -y pkg[=version]，以安裝該軟件包。

● 對于UOPS，本文發現在Dockerfile中，每個UOPS安裝語句前后通常會有空行，形成一個獨立的指令塊（如圖3中第9~16行對anaconda的安裝）。因此，以空行進行劃分可以得到UOPS的安裝方式。從中選取使用頻率最高的安裝方式，生成對UOPS的安裝指令塊。

6 實驗與分析

本文所有實驗都在一臺8核3.50 GHz、32 GB內存的機器上進行，操作系統為Ubuntu 18.04.01 LTS，使用的Docker版本為19.03.6，設置的關聯度閾值為0.5。

6.1 實驗方法

本文通過實驗驗證筆者提出的方法是否能夠為給定的軟件包生成Dockerfile，并成功構建Docker鏡像。本文在開源社區（如GitHub、Apache Software Foundation等）中隨機選取了100個UOPS進行實驗，即使用本文方法生成Dockerfile，并驗證是否能根據該Dockerfile成功構建鏡像和運行UOPS。在100個UOPS中，49個來自GitHub，其余51個來自其他倉庫，并涵蓋了各種類型的軟件，如系統軟件、開發工具、應用軟件等。經過檢驗，這100個UOPS的下載鏈接均是有效的。表1列出了選取的100個UOPS的詳細信息。此外，為了進一步說明方法的有效性，本文嘗試生成8個常見的基于Docker的Web框架（包括Express. js、Rails 5和Django等）的Dockerfile，與FRISK進行對比。

本文使用以下兩個指標分析實驗結果。

● 構建成功率（build success rate， BSR）：表示Dockerfile成功構建鏡像的比率，計算方法如式（3）所示，其中|DF_total|表示生成Dockerfile的總數，|DF_bs|表示基于生成的Dockerfile能夠成功構建鏡像的數量。

● 配置成功率（configuration success rate，CSR）：表示Dockerfile成功構建鏡像，并使得給定軟件能夠正確運行的比率，計算方法如式（4）所示，其中|DF_cs|表示成功運行的鏡像的數量。

6.2 實驗結果與分析

通過本文方法生成Dockerfile后，使用“docker build”命令構建Docker鏡像，人工觀察構建結果，并統計分析構建失敗的原因。結果顯示，在10 0個軟件包中，73個軟件包對應的Dockerfile能夠成功構建鏡像（BSR=73%），59個軟件包對應的Dockerfile不僅可以成功構建鏡像，而且能正確運行鏡像中的軟件（CSR=59%）。另外，對于8個常見的Web框架，本文方法均成功生成Dockerfile，并使得框架能夠正確運行。結果表明，本文方法具有利用領域知識推斷系統依賴關系和軟件包安裝方式的能力，能夠自動生成不同軟件的Dockerfile。

本文對生成的100份Dockerfile進行分析，發現以下兩點。

● 最常被安裝的軟件包是cURL，其次是wget、tar、Git和GNU Make等，分布如圖7所示。這些軟件包主要用于下載、解壓和編譯UOPS。

● Ubuntu操作系統鏡像最常被作為基礎鏡像，被作為基礎鏡像的比率達到47%。

本文對構建失敗的Dockerfile進行分析。構建失敗的主要原因如下。

● 基礎鏡像獲取失敗：Docker Hub上存儲的基礎鏡像丟失或無法訪問，無法拉取基礎鏡像構建新的鏡像。5份Dockerfile構建失敗的原因是基礎鏡像獲取失敗。

● 依賴缺失：沒能在知識圖譜中建立軟件包完整的依賴關系，導致軟件包無法成功安裝。6份Dockerfile構建失敗的原因是依賴關系缺失。

● 文件路徑錯誤：構建Docker鏡像時，訪問了已經不存在的文件路徑。6份Dockerfile構建失敗的原因是文件路徑錯誤。

● 其他錯誤：包括字符集編碼錯誤、授權無效等。10份Dockerfile構建失敗的原因是其他錯誤。

同時，本文對配置失敗的Dockerfile進行分析，發現配置失敗的主要原因是不完整配置，即在軟件包安裝指令中，缺少一些必要的指令（如環境配置指令、文件操作指令等），使得Docker鏡像無法正確運行 。

筆者認為，可以從以下方面進一步改進，減少構建失敗和配置失敗。

● 完善知識圖譜：繼續從Docker Hub和GitHub等開源社區收集Docker項目，解析Dockerfile，并提取軟件包之間的關聯，進一步提高知識圖譜的完整性。

圖7???常用軟件包統計

● 資源有效性檢測：在使用資源（包括基礎鏡像和軟件包等）前預先訪問，以確保資源的有效和可訪問。

● UOPS配置模式總結：UOPS的安裝配置主要包括下載、解壓、編譯和建立鏈接等步驟，因此可以進一步總結UOPS的配置模式，用于完善軟件安裝所必需的相關指令。

7 結束語

本文提出了一種基于領域知識的Docker鏡像自動生成方法。該方法通過對數十萬的Dockerfile進行解析，提取其中與鏡像構建相關的實體和關系等知識，構建Docker領域知識圖譜。對于給定需要構建鏡像的軟件包，該方法通過知識圖譜推斷目標軟件的基礎鏡像、所有需要安裝的依賴軟件包以及安裝順序，在此基礎上生成Dockerfile，并進一步構建面向目標軟件的Docker鏡像。實驗結果顯示，該方法具有利用領域知識推斷系統依賴關系和軟件包安裝方式的能力，能夠自動生成面向不同軟件的Dockerfile和Docker鏡像。在未來的研究中，筆者認為可以從提高知識圖譜完整性、Dockerfile優化、語言層包依賴解析等方面著手，進一步提高Docker鏡像的自動生成能力。

作者簡介

陳偉（1980-），男，博士，中國科學院軟件研究所副研究員，中國計算機學會會員，主要研究方向為軟件工程、網絡分布式計算等。

葉宏杰（1996-），男，中國科學院軟件研究所碩士生，主要研究方向為軟件工程。

周家宏（1995-），男，中國科學院軟件研究所碩士生，主要研究方向為機器學習、知識圖譜等。

魏峻（1970-），男，博士，中國科學院軟件研究所研究員、博士生導師，主要研究方向為軟件工程、網絡分布式計算等。

聯系我們:

Tel:010-81055448

? ? ? ?010-81055490

? ? ? ?010-81055534

E-mail:bdr@bjxintong.com.cn?

http://www.infocomm-journal.com/bdr

http://www.j-bigdataresearch.com.cn/

轉載、合作：010-81055537

大數據期刊

《大數據（Big Data Research，BDR）》雙月刊是由中華人民共和國工業和信息化部主管，人民郵電出版社主辦，中國計算機學會大數據專家委員會學術指導，北京信通傳媒有限責任公司出版的期刊，已成功入選中文科技核心期刊、中國計算機學會會刊、中國計算機學會推薦中文科技期刊，并被評為2018年、2019年國家哲學社會科學文獻中心學術期刊數據庫“綜合性人文社會科學”學科最受歡迎期刊。

關注《大數據》期刊微信公眾號，獲取更多內容

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的基于领域知识的Docker镜像自动构建方法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。