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

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

1 引言

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

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

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

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

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

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

2 相關(guān)工作

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

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

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

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

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

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

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

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

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

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

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

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

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

4.1 知識(shí)圖譜元模型

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

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

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

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

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

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

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

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

4.3 Dockerfile解析

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

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

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

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

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

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

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

● 以Docker項(xiàng)目的名稱為根節(jié)點(diǎn)，將每條指令解析為根節(jié)點(diǎn)的一個(gè)葉節(jié)點(diǎn)，用指令的名稱表示；

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

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

圖3 示例Dockerfile(1)

圖4 示例Dockerfile(2)

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

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

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

對(duì)于基礎(chǔ)鏡像和操作系統(tǒng)識(shí)別，Dockerfile中的FROM指令聲明了當(dāng)前Docker鏡像的基礎(chǔ)鏡像。本文方法對(duì)AST中以FROM節(jié)點(diǎn)為根的子樹進(jìn)行分析，得到基礎(chǔ)鏡像信息。鏡像具有傳遞依賴性，且依賴于某個(gè)操作系統(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)信息。

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

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

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

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

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

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

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

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

5 Dockerfile自動(dòng)生成方法

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

5.1 基礎(chǔ)鏡像推薦

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

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

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

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

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

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

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

5.3 軟件包安裝順序推斷

為了確定軟件包的安裝順序，需要對(duì)子圖Gs中的各個(gè)頂點(diǎn)進(jìn)行拓?fù)渑判?。排序前需要消除Gs中的環(huán)。如果環(huán)中的頂點(diǎn)數(shù)為2，則刪除環(huán)中的所有邊，因?yàn)檫@兩個(gè)軟件包可以以任意順序安裝；如果環(huán)中的頂點(diǎn)數(shù)大于2，則刪除環(huán)中關(guān)聯(lián)度最小的邊。消除環(huán)后，本文方法對(duì)各個(gè)頂點(diǎn)進(jìn)行拓?fù)渑判颍判虻慕Y(jié)果即軟件包的安裝順序seqs。

5.4 Dockerfile生成

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

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

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

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

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

6 實(shí)驗(yàn)與分析

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

6.1 實(shí)驗(yàn)方法

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

本文使用以下兩個(gè)指標(biāo)分析實(shí)驗(yàn)結(jié)果。

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

表1 實(shí)驗(yàn)UOPS詳細(xì)信息

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

6.2 實(shí)驗(yàn)結(jié)果與分析

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7 結(jié)束語

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