首先說一下我們都用容器做什么。主要三大類，第一種是諸如testlink，jenkins這種基礎(chǔ)服務(wù)。第二種是產(chǎn)品的測試環(huán)境，這是占比最多的。然后就是我們的測試執(zhí)行機器了。例如UI自動化，我們采取的是分別將selenium hub和node docker化的做法。如下圖：

當(dāng)UI自動化的case增多的時候，分布式運行往往是最好的解決方案。 目前我們通過這種方式容器化了20個瀏覽器進行并發(fā)測試。這些鏡像都有官方的版本，使用起來還是蠻方面的。
然后說一下比較關(guān)鍵的網(wǎng)絡(luò)解決方案，我們從單機到集群，中途歷經(jīng)了集中網(wǎng)絡(luò)模型的變化。從一開始的端口映射，到利用路由規(guī)則給容器分配真實的ip，再到給每個容器在DHCP和DNS服務(wù)器上注冊和續(xù)租。到最后我們演進出了下面這個k8s的網(wǎng)絡(luò)模型。

我們知道每個docker宿主機都會自己維護一個私有網(wǎng)絡(luò)。如果想讓容器跨主機通訊或者外部訪問容器。一般就是通過三種方式： 端口映射，路由規(guī)則以及overlay網(wǎng)絡(luò)。我們選擇在k8s中引入的overlay網(wǎng)絡(luò)是weave，以解決夸主機通信問題。安裝kube-dns實現(xiàn)服務(wù)發(fā)現(xiàn)。之后為了能讓外部訪問容器服務(wù)， 使用了k8s提供的ingress機制來實現(xiàn)。這個ingress網(wǎng)絡(luò)其實就是在集群中啟動一個容器，這個容器既能訪問容器網(wǎng)絡(luò)的同是還監(jiān)聽了宿主機的80端口。容器里是一個nginx，它會負責(zé)幫忙轉(zhuǎn)發(fā)請求。nginx負責(zé)轉(zhuǎn)發(fā)的有servicename和path，這里我們是無法使用路徑進行轉(zhuǎn)發(fā)的。所以我們在公司內(nèi)部的DNS上做了泛域名解析。所有testenv為后綴的域名都會解析成集群的master節(jié)點的ip。這樣我們的請求就能命中nginx中固定的servicename并做轉(zhuǎn)發(fā)了。通過這種機制我們就可以很方面的訪問容器提供的服務(wù)。當(dāng)然ingress的缺點是暫時還無法做4層轉(zhuǎn)發(fā)。如果要訪問4層協(xié)議的服務(wù)暫時還是只能暴露node port。

我們這個測試環(huán)境的管理平臺主要的架構(gòu)是這樣的：

集群中所有的鏡像都過公司內(nèi)部搭建的鏡像倉庫進行共享，我們在集群之上安裝了各種服務(wù)來滿足測試環(huán)境的需要。例如使用NFS做數(shù)據(jù)持久化，Heapster+Grafana+InfluxDB做性能監(jiān)控，kube-DNS做服務(wù)發(fā)現(xiàn)，dashboard提供web管理界面，weave做集群網(wǎng)絡(luò)，ingress做服務(wù)的轉(zhuǎn)發(fā)。并且我們在這個整體上針對k8s的APIserver做了一層cli的封裝。我們嘗試過腳本管理，web服務(wù)管理，但是發(fā)現(xiàn)大家對這些方式的接受度都不高。我們面對的大多數(shù)都是一幫做夢都在寫代碼的人，所以我們換做提供一個cli的方式可以讓使用者更靈活來定制自己需要的服務(wù)。通過這種形式，我們在公司內(nèi)部搭建了一個可以提供測試資源的私有云，配合jenkins我們可以很方便的一鍵部署我們需要的環(huán)境并執(zhí)行UT,接口,UI自動化測試等等，并提供一個詳細的測試報告。下面是我們的部署一個環(huán)境后所提供的測試報告。