[[170286]]

當(dāng)我們構(gòu)建好Docker鏡像并利用多套容器共同組合成應(yīng)用程序，建立起持續(xù)交付通道，了解了如何將新創(chuàng)建的鏡像納入到生產(chǎn)或者測試環(huán)境當(dāng)中之后，新的問題來了——我們該如何測試自己的Docker容器?

測試的策略多種多樣，反映了各種各樣的測試性格：天真型，懶人省事型，超前理想主義型，完美主義處女座型……那么你是哪一型?

下面我們就對其各自的方案利弊進(jìn)行逐一分析。

“天真”型方案

大多數(shù)人會將此作為默認(rèn)方案。其利用CI服務(wù)器實現(xiàn)任務(wù)執(zhí)行。在這項方案中，開發(fā)人員利用Docker作為軟件包管理器，其實際效果優(yōu)于jar/rpm/deb方案。CI服務(wù)器對應(yīng)用程序代碼進(jìn)行編譯，而后執(zhí)行測試(包括單元、服務(wù)及功能等)。Docker中的build可復(fù)用以生成新的鏡像，由此生成的鏡像不僅包含應(yīng)用程序的“二進(jìn)制代碼”，同時亦擁有運行時所必需的依賴性及配置。

不過為了實現(xiàn)應(yīng)用程序的可移植性，我們需要放棄開發(fā)與測試的可移植能力。在這種情況下，我們無法在CI之外重新建立同樣的開發(fā)與測試環(huán)境。為了創(chuàng)始這樣一套新的測試環(huán)境，我們需要設(shè)置測試工具(正確版本與插件)、配置運行時與操作系統(tǒng)設(shè)定，同時獲取相同版本的測試腳本與測試數(shù)據(jù)。

為了解決上述難題，我們需要考慮以下方案。

應(yīng)用&測試容器方案

現(xiàn)在我們嘗試創(chuàng)建單一捆綁包，其中應(yīng)用程序“二進(jìn)制代碼”中包含全部必需的軟件包、測試工具(包括對應(yīng)版本)、測試工具插件、測試腳本以及其它各類測試環(huán)境元素。

這套方案的優(yōu)勢包括：

• 測試環(huán)境自身擁有可重復(fù)性——我們能夠在CI、開發(fā)、分段或者生產(chǎn)環(huán)境當(dāng)中使用完全相同的測試工具實現(xiàn)完全相同的測試效果。
• 我們能夠立足特定時間點捕捉測試腳本，所以可將其復(fù)用于任意環(huán)境。
• 我們不需要對測試工具進(jìn)行二次設(shè)置與配置——其已經(jīng)成為鏡像中的組成部分。

但這種方式也存在著顯著弊端：

• 鏡像體積直線增長——這是因為其中包含有測試工具、必要軟件包、測試腳本甚至是測試數(shù)據(jù)。
• 特定測試配置可能對鏡像運行時環(huán)境造成污染，甚至引入不必要的依賴性(集成測試中需要用到)。
• 我們還需要考慮如何處理測試結(jié)果與記錄日志;如何將其導(dǎo)出以及向哪里導(dǎo)出。 通過以下經(jīng)過簡化的 Dockerfile，我們可以了解上述方案的整個流程。

FROM "<bases image>":"<version>" 
WORKDIR "<path>" 
# install packages required to run app and tests 
RUN apt-get update && apt-get install -y \ 
    "<app runtime> and <dependencies>" \  # add app runtime and required packages 
    "<test tools> and <dependencies>" \     # add testing tools and required packages 
    && rm -rf /var/lib/apt/lists/* 
# copy app files 
COPY app app 
COPY run.sh run.sh 
# copy test scripts 
COPY tests tests 
# copy "main" test command 
COPY test.sh test.sh 
# ... EXPOSE, RUN, ADD ... for app and test environment 
# main app command 
CMD [run.sh, "<app arguments>"] 
# it's not possible to have multiple CMD commands, but this is the "main" test command 
# CMD [/test.sh, "<test arguments>"] 

點此下載 Dockerfile。

毫無疑問，應(yīng)該有更好的容器內(nèi)測試方案可供選擇。

測試感知型容器方案

目前，Docker承諾以“Build -> Ship -> Run”這一簡單操作完成鏡像構(gòu)建、發(fā)布至注冊表并在其它位置運行等任務(wù)。不過恕我直言，其中還缺少了Test這一重要環(huán)節(jié)。正確且完整的流程應(yīng)該是Build -> Test -> Ship -> Run。 下面讓我們看看能夠為Docker命令提供“測試友好”型語法與擴展的Dockerfile是如何建立而成的。當(dāng)然，其中并不涉及真正的語法，只是我個人更偏好這樣表述。我定義出了自己的“理想”版本(真的只是理想版本，僅供大家借鑒其中的思想，小數(shù)注)，大家應(yīng)該能夠看出其中可用于實踐的指導(dǎo)思路。

ONTEST [INSTRUCTION] 

首先定義一條特殊的ONTEST指令，其與現(xiàn)有ONBUILD指令非常相似。ONTEST指令會向鏡像添加一條觸發(fā)指令，其在隨后鏡像接受測試時自動執(zhí)行。任意build指令都可被注冊為觸發(fā)條件。

ONTEST指令可由一條新的docker test命令進(jìn)行識別。

docker test [OPTIONS] IMAGE [COMMAND] [ARG...] 

事實上，docker test命令的語法與docker run命令非常相似，二者只存在一項區(qū)別：前者會自動生成一套新的“可測試”鏡像，甚至為其提供-test 標(biāo)簽(向原始鏡像標(biāo)簽中添加‘test’標(biāo)簽)。此可測試鏡像將由初始應(yīng)用鏡像生成，執(zhí)行全部build操作，于ONTEST命令后進(jìn)行定義并執(zhí)行ONTEST CMD(或者ONTEST ENTRYPOINT)。其中若測試發(fā)生錯誤，docker test命令應(yīng)當(dāng)返回一段非零代碼。此測試結(jié)果應(yīng)當(dāng)被寫入至自動生成且指向/var/tests/results文件夾的VOLUME。

下面我們來看看經(jīng)過修改的Dockerfile——其中包含新的ONTEST指令。

FROM "<base image>":"<version>" 
WORKDIR "<path>" 
# install packages required to run app 
RUN apt-get update && apt-get install -y \ 
    "<app runtime> and <dependencies>" \  # add app runtime and required packages 
    && rm -rf /var/lib/apt/lists/* 
# install packages required to run tests    
ONTEST RUN apt-get update && apt-get install -y \ 
           "<test tools> and <dependencies>"    \     # add testing tools and required packages 
           && rm -rf /var/lib/apt/lists/* 
# copy app files 
COPY app app 
COPY run.sh run.sh 
# copy test scripts 
ONTEST COPY tests tests 
# copy "main" test command 
ONTEST COPY test.sh test.sh 
# auto-generated volume for test results 
# ONTEST VOLUME "/var/tests/results" 
# ... EXPOSE, RUN, ADD ... for app and test environment 
# main app command 
CMD [run.sh, "<app arguments>"] 
# main test command 
ONTEST CMD [/test.sh, "<test arguments>"] 

點此下載 Dockerfile。

如何實現(xiàn)“測試感知容器”

我們相信，Docker應(yīng)該會將docker-test作為容器管理生命周期中的組成部分。當(dāng)下我們都需要更為簡便的解決方案，因此我在這里提出一套接近于理想情況的實現(xiàn)辦法。

如之前所提到，Docker擁有ONBUILD這樣一條非常實用的指令。該指令允許我們在已經(jīng)成功的build之上觸發(fā)另一build指令。其基本思路是在運行docker-test命令的同時，使用ONBUILD指令。

以下為docker-test命令的執(zhí)行流程：

1. docker-test將在應(yīng)用程序Dockerfile當(dāng)中搜索ONBUILD指令，而后……
2. 利用初始Dockerfile生成一條臨時的Dockerfile.test
3. 執(zhí)行docker build -f Dockerfile.test [OPTIONS] PATH，其中包含受docker build命令支持的其它選項：-test將自動被添加至tag選項當(dāng)中。
4. 如果構(gòu)建成功，則執(zhí)行 docker run -v ./tests/results:/var/tests/results [OPTIONS] IMAGE:TAG-test [COMMAND] [ARG...]
5. 移除Dockerfile.test文件

那么，為什么不創(chuàng)建一個無需配合ONBUILD指令的Dockerfile.test文件?

這是因為，為了測試正確的鏡像(及標(biāo)簽)，我們需要保證FROM始終在測試目標(biāo)的image:tag中得到更新。

不過前面提到的方案仍然存在局限——其不適用于“onbuild”鏡像(即用于自動化構(gòu)建應(yīng)用的鏡像)，例如Maven:onbuild。

下面來看一條簡單的docker-test命令實現(xiàn)流程。其中強調(diào)了一大重要概念：docker-test命令應(yīng)當(dāng)能夠處理build與run命令選項，同時能夠妥善處理錯誤狀況。

#!/bin/bash 
image="app" 
tag="latest" 
echo "FROM ${image}:${tag}" > Dockerfile.test && 
docker build -t "${image}:${tag}-test" -f Dockerfile.test . && 
docker run -it --rm -v $(pwd)/tests/results:/var/tests/results "${image}:${tag}-test" && 
rm Dockerfile.test 

讓我們把注意力集中在最值得關(guān)注的重要部分。

集成測試型容器方案

假設(shè)我們的應(yīng)用程序由數(shù)十甚至數(shù)百項微服務(wù)構(gòu)建而成，同時假設(shè)我們已經(jīng)擁有一套自動化CI/CD通道，其中每項微服務(wù)都由CI進(jìn)行構(gòu)建與測試，并在之后被部署到某種環(huán)境當(dāng)中(例如測試、分段或者生產(chǎn)環(huán)境)。聽起來不錯，對吧?我們的CI會對各項微服務(wù)進(jìn)行分別測試——運行單元與服務(wù)測試(或者API合同測試)。甚至有可能進(jìn)行微集成測試——即將測試運行在特設(shè)的子系統(tǒng)之上(例如使用docker compose)。

但這又會帶來一些新問題：

• 實際集成測試或者長期運行測試該如何完成(例如性能與壓力測試)?
• 彈性測試該如何實現(xiàn)(例如‘混亂猴子’測試)?
• 如何實現(xiàn)安全掃描?
• 那些需要耗費較長時間且運行在完整操作系統(tǒng)之上的測試與掃描要如何完成?

應(yīng)該有一種更好的辦法來替代這種直接將新的微服務(wù)版本交付至生產(chǎn)環(huán)境的作法，我們也需要更為密切的監(jiān)控手段。

應(yīng)當(dāng)存在一類特殊的集成測試容器。這些容器將僅包含測試工具與測試元素：測試腳本、測試數(shù)據(jù)、測試環(huán)境配置等等。為了簡化此類容器的編排與自動化流程，我們應(yīng)當(dāng)定義并遵循某些約定并使用元數(shù)據(jù)標(biāo)簽(Dockerfile中的LABEL指令)。

集成測試標(biāo)簽

• test.type – 測試類型，負(fù)責(zé)定義integration; 可屬于 integration, performance, security, chaos 或者其它任意文本之一; 此標(biāo)簽代表其屬于一套集成測試容器
• test.results – 用于存放測試結(jié)果的VOLUME ; 默認(rèn)位置為 /var/tests/results
• test.XXX -任何其它相關(guān)元數(shù)據(jù)，僅使用test.后綴名作為標(biāo)簽名稱

集成測試容器

集成測試容器其實就是一種常規(guī)Docker容器，其中不包含任何應(yīng)用程序邏輯及代碼。它的惟一用途就是創(chuàng)建可重復(fù)且可移植的測試流程。以下為建議納入集成測試容器的內(nèi)容：

• 測試工具 - Phantom.js, Selenium, Chakram, Gatling, …
• 測試工具運行時 - Node.js, JVM, Python, Ruby, …
• 測試管理配置 – 環(huán)境變量, 配置文件, 引導(dǎo)腳本, …
• 測試 -作為經(jīng)過編譯的軟件包或者腳本文件存在
• 測試數(shù)據(jù) – 任何用于測試的數(shù)據(jù)文件類型: json, csv, txt, xml, …
• 測試啟動腳本 -用于運行測試的部分“main”啟動腳本，僅負(fù)責(zé)創(chuàng)建test.sh并借此啟動該測試工具。

集成測試容器應(yīng)當(dāng)運行在全部微服務(wù)都已經(jīng)部署到位的運營環(huán)境之下，包括測試、分段或者生產(chǎn)環(huán)境。這些容器可與其它服務(wù)采取完全一致的部署方式。其利用同樣的網(wǎng)絡(luò)層，因此能夠訪問多項其它服務(wù);使用選定的服務(wù)發(fā)現(xiàn)方法(通常為DNS)。在實際集成測試當(dāng)中，我們必須對多項服務(wù)進(jìn)行訪問——旨在模擬并驗證自身系統(tǒng)是否能夠在多種不同環(huán)境下正常運行。將集成測試納入應(yīng)用服務(wù)容器不僅會增加容器自身體積，同時亦會在各服務(wù)之間帶來不必要的依賴性。因此，我們將所有依賴性都限制在集成測試容器當(dāng)中。一旦測試(以及相關(guān)測試工具)被打包在該容器內(nèi)，我們亦可在包括開發(fā)者設(shè)備在內(nèi)的任意環(huán)境下重復(fù)運行同樣的測試流程。大家還能夠?qū)崿F(xiàn)回滾，即根據(jù)需要運行任意集成測試容器版本。