基于領(lǐng)域知識的Docker鏡像自動構(gòu)建方法

陳偉，葉宏杰，周家宏，魏峻

1. 中國科學(xué)院大學(xué)，北京 100190；2. 中國科學(xué)院軟件研究所，北京 100190

1 引言

在傳統(tǒng)軟件開發(fā)過程中，開發(fā)部署和運行演化兩階段相互割裂，各階段數(shù)據(jù)匯聚與知識提煉、關(guān)聯(lián)與運用程度低，難以快速響應(yīng)需求變化。為此，開發(fā)運維一體化（DevOps）[1]被提出，旨在加強開發(fā)和運維部門之間的溝通協(xié)作，提高軟件運行演化過程中生產(chǎn)活動的效率和質(zhì)量。DevOps的引入對軟件產(chǎn)品的開發(fā)、測試、交付和運維有重要意義。

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

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

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

● 提出了一種面向Docker鏡像構(gòu)建的領(lǐng)域知識圖譜自動構(gòu)建方法。本文方法提出了Docker鏡像構(gòu)建的領(lǐng)域知識圖譜元模型，并基于抽象語法樹（abstract language tree，AST）分析技術(shù)從大規(guī)模Dockerfile中提取各種類型的領(lǐng)域知識實體與關(guān)系，實現(xiàn)知識圖譜的構(gòu)建。

● 提出了一種Dockerfile的自動生成方法。本文方法根據(jù)知識圖譜推斷構(gòu)建目標(biāo)軟件系統(tǒng)鏡像所需的基礎(chǔ)鏡像、需要安裝的所有軟件包及安裝順序和操作，生成指令，并合成Dockerfile。

2 相關(guān)工作

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

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

3 基于領(lǐng)域知識的Docker鏡像自動構(gòu)建方法

圖1 基于領(lǐng)域知識的Docker鏡像自動生成構(gòu)建流程

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

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

在Docker鏡像自動生成階段，對于用戶指定需要安裝的目標(biāo)軟件，本文方法從知識圖譜中推斷構(gòu)建Docker鏡像所需的基礎(chǔ)鏡像和該軟件包關(guān)聯(lián)的其他軟件包，并確定相應(yīng)的安裝配置順序和方式。最后，方法根據(jù)分析結(jié)果構(gòu)造Dockerfile指令，并合成Dockerfile，進而基于Dockerfile構(gòu)建鏡像。

4 數(shù)據(jù)收集與知識圖譜構(gòu)建

數(shù)據(jù)收集與知識圖譜的構(gòu)建主要包括以下步驟：

步驟1基于網(wǎng)絡(luò)爬蟲獲取Docker Hub上的Docker項目及其對應(yīng)的Dockerfile等數(shù)據(jù)；

步驟2解析Dockerfile，并構(gòu)建AST；

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

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

4.1 知識圖譜元模型

圖2 領(lǐng)域知識圖譜元模型

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

4.2 數(shù)據(jù)獲取

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

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

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

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

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

4.3 Dockerfile解析

Dockerfile解析包括兩個階段：Dockerfile預(yù)處理；構(gòu)建Dockerfile對應(yīng)的AST。

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

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

步驟1解析環(huán)境變量定義指令。ENV指令的格式可以表示為“ENV key value”，其中，key表示環(huán)境變量的名稱，value表示環(huán)境變量的值。因此，可以構(gòu)建名-值映射表Map來存儲環(huán)境變量。對于每一條ENV語句，提取其中的key和value，并存入映射表中，實現(xiàn)對環(huán)境變量定義指令的解析。

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

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

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

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

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

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

圖3 示例Dockerfile(1)

圖4 示例Dockerfile(2)

圖5 環(huán)境變量替換后的Dockerfile(2)

4.4 實體和關(guān)系識別

得到Dockerfile對應(yīng)的AST后，本文方法進一步從中識別實體及其之間關(guān)系，主要包括：基礎(chǔ)鏡像和操作系統(tǒng)識別、軟件包識別、軟件包關(guān)聯(lián)識別。

對于基礎(chǔ)鏡像和操作系統(tǒng)識別，Dockerfile中的FROM指令聲明了當(dāng)前Docker鏡像的基礎(chǔ)鏡像。本文方法對AST中以FROM節(jié)點為根的子樹進行分析，得到基礎(chǔ)鏡像信息。鏡像具有傳遞依賴性，且依賴于某個操作系統(tǒng)鏡像。首先判斷當(dāng)前鏡像imgdf是否是操作系統(tǒng)鏡像，或者基礎(chǔ)鏡像imgbase是否是操作系統(tǒng)鏡像，如果是，則得到操作系統(tǒng)信息；否則，解析imgbase的Dockerfile，判斷imgbase的基礎(chǔ)鏡像是否是操作系統(tǒng)鏡像，重復(fù)該過程，直到發(fā)現(xiàn)操作系統(tǒng)鏡像，得到操作系統(tǒng)信息。

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

圖6 Dockerfile(1)對應(yīng)的AST

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

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

對于軟件包關(guān)聯(lián)識別，經(jīng)過軟件包識別，本文方法可獲取當(dāng)前Dockerfile安裝的軟件包集合PKG={pkg1,pkg2,…,pkgn}?；贒ockerfile進行Docker鏡像構(gòu)建時，軟件包的安裝是有序的。本方法以關(guān)聯(lián)的形式記錄兩個包pkgi和pkgj在當(dāng)前Dockerfile中的安裝順序，表示pkgi先于pkgj安裝，作為軟件包之間的關(guān)聯(lián)。

4.5 知識圖譜構(gòu)建

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

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

5 Dockerfile自動生成方法

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

5.1 基礎(chǔ)鏡像推薦

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

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

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

5.2 關(guān)聯(lián)軟件包分析

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

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

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

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

5.3 軟件包安裝順序推斷

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

5.4 Dockerfile生成

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

● 根據(jù)基礎(chǔ)鏡像imgbase，生成指令FROM imgbase。

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

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

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

6 實驗與分析

本文所有實驗都在一臺8核3.50 GHz、32 GB內(nèi)存的機器上進行，操作系統(tǒng)為Ubuntu 18.04.01 LTS，使用的Docker版本為19.03.6，設(shè)置的關(guān)聯(lián)度閾值為0.5。

6.1 實驗方法

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

本文使用以下兩個指標(biāo)分析實驗結(jié)果。

● 構(gòu)建成功率（build success rate，BSR）：表示Dockerfile成功構(gòu)建鏡像的比率，計算方法如式（3）所示，其中|DFtotal|表示生成Dockerfile的總數(shù)，|DFbs|表示基于生成的Dockerfile能夠成功構(gòu)建鏡像的數(shù)量。

表1 實驗UOPS詳細信息

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

6.2 實驗結(jié)果與分析

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

本文對生成的100份Dockerfile進行分析，發(fā)現(xiàn)以下兩點。

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

● Ubuntu操作系統(tǒng)鏡像最常被作為基礎(chǔ)鏡像，被作為基礎(chǔ)鏡像的比率達到47%。

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

● 基礎(chǔ)鏡像獲取失?。篋ocker Hub上存儲的基礎(chǔ)鏡像丟失或無法訪問，無法拉取基礎(chǔ)鏡像構(gòu)建新的鏡像。5份Dockerfile構(gòu)建失敗的原因是基礎(chǔ)鏡像獲取失敗。

● 依賴缺失：沒能在知識圖譜中建立軟件包完整的依賴關(guān)系，導(dǎo)致軟件包無法成功安裝。6份Dockerfile構(gòu)建失敗的原因是依賴關(guān)系缺失。

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

● 其他錯誤：包括字符集編碼錯誤、授權(quán)無效等。10份Dockerfile構(gòu)建失敗的原因是其他錯誤。

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

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

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

圖7 常用軟件包統(tǒng)計

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

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

7 結(jié)束語

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