內容來源：2017年4月8日，第四正規化資深測試開發工程師孫高飛在“餓了麼技術沙龍【第四彈】北京研發中心測試專場”進行《docker搭建大規模測試環境的實踐》演講分享。IT大咖說作為獨家視訊合作方，經主辦方和講者審閱授權釋出。

摘要

Docker是一個開源的應用容器引擎，第四正規化資深測試開發工程師將從四個方面來分享關於docker搭建大規模測試環境的實踐。

大咖演講視訊

http://t.cn/RKm8iVo

困境

當今網際網路行業發展迅速，產品架構逐漸複雜，導致環境搭建困難。

測試環境不一致。

因為搭建環境困難，環境不多，所以一套環境有多人使用，容易造成環境的互相踩踏問題。

隨著業務的發展和時間的積累，我們發現case越來越多。我們希望能夠用分散式的執行方式在多臺機器上併發執行，以提升執行速度。但是測試機器稀缺，速度依然無法提升。

解決方案

自動化

搭建一個環境必須做到一鍵部署，在遷移、實踐和刪除環境中也要做到自動化。

標準化

標準化用來解決測試環境不一致的問題。我們希望測試環境、開發環境甚至生產環境都是一致的。

叢集化

根據以往的經驗發現，測試資源是一種比較稀缺的資源。要把測試環境擴充套件到一定的量級，使稀缺資源變成普通的、人人都能簡單獲取的一種資源，這樣就省去了複雜的流程和排隊等待的過程。

DOCKER

容器技術相較於虛擬機器來說還是非常節省資源的。Docker不需要執行完整的作業系統。在一個宿主機上執行的所有容器都是共享宿主機的核心，所以每啟動一個容器，都比虛擬機器節省了一個核心的空間。

簡化了運維成本，極大降低部署環境的學習門檻。

假如公司新進了一批機器，要把環境遷移到某些環境上來，只要把它做成映象，就可以很方便地進行遷移。而且這些映象都是一致的，通過製作映象可以解決標準化的問題。

容器的啟動速度和刪除速度都是秒級的，有些不是長時間執行的服務在用完後就能將其刪除。這樣docker的宿主機就始終能保持一個低壓力的狀態。

把應用程式當成一個個集裝箱，全都放在docker裡。主要是放基礎容器、測試環境和測試執行機器。也可把執行測試機器全部製作成映象，在需要使用的時候啟動它並放進docker裡。

網路的玩法

埠對映

在docker預設的啟動模式是bridege模式的情況下，docker為我們建立了一個叫docker0的網橋，這個網橋專門負責為容器進行轉發。它會給容器分配很多虛擬IP，但這些IP只能在容器內部溝通使用。要是想與容器進行通訊，最常用的方法就是埠對映，把容器埠對映到宿主機上。

這種方式的優點是簡單，不用做任何配置。當然它的缺點也很明顯，要維護一個很龐大的埠列表，記住每一個環境容器的埠是什麼，對外暴露的埠是什麼。

固定IP

我們希望這些容器能像虛擬機器一樣，給它分配真實的IP去訪問它。但這個做法會稍微有些麻煩，docker不支援這樣做，我們需要利用一些轉化規則。

建立一個新的網橋br0，給它分配一個真實的IP，把宿主機的網絡卡掛到網橋上，同時改變docker的啟動引數，預設啟動的時候連到br0上。重新劃分網段，把所有容器的網段全都分配成和宿主機在相同的網段上。這樣啟動容器時分配的就是真實IP，並與宿主機相處於同一個網段。

這種方式讓外界使用者感受不到是在使用容器還是虛擬機器，是對測試環境非常友好的一種方式。

但它並不適合在大規模的測試環境中使用。所有環境都有了真實IP，都被放到了真實的網路環境中，如果容器太多就會出現廣播風暴的問題。

環境部署

Container模式

Container模式的特點是可以把所有容器繫結到一個IP地址上。

雖然所有模組都裝在不同的容器裡，但它們都有同樣的IP，只是它們用不同的埠對外暴露服務。

它的優點是配置管理，效率高，是對開發最友好的一種模式。

缺點是標準化。因為我們公司產品的一些特性，產品環境並不是這樣去部署的，所以可能會出現環境不一致帶來的一系列問題。

打包模式

有多少模組就併發啟動多少容器，這些容器的網路模式可以用host。Host的特性是把所有容器的網路環境掛載到宿主機上。把這些併發編譯後上傳到FTP上，然後啟動一個或多個部署容器。

打包模式的優點就是標準化。但它的效率不如Container模式高。

儲存的玩法

外部儲存

把資料庫放到容器外面，在容器內部和資料庫進行溝通，保證資料庫不會造成資料的丟失。

Volume儲存

這是docker比較推薦的一種方式。它允許把容器中的某個路徑掛載到外部裝置上。比如掛載到宿主機上，容器實時向檔案中寫資料，宿主機上同時也會儲存這份資料。

叢集

我們想要提供一個統一介面去管理叢集上所有節點，所以考慮使用一些開源的分散式框架。目前在業界最火的三種框架就是mesos、Kubernetes、swarm mode。

Mesos誕生的時間非常早，專注於資源排程，後來docker火了之後才相容了docker。它的排程框架的二次排程，只裝一個mesos是不夠的，還依賴於很多其它的東西。Mesos發展得越來越複雜，需要專業運維去支援，所以mesos並不適合作為測試環境的框架來使用。

Kubernetes是google內部叢集框架block的一個開源版本。它當時是為docker設計的，而現在Kubernetes慢慢開始相容其它平臺。Kubernetes原本應該是最複雜的叢集管理框架，google提供了客戶端工具，把很多內部細節封裝起來，簡化了它的使用方式。它最近推行的容器化部署也極大降低了Kubernetes的使用門檻。

Swarmmode是從docker1.12版本開始內建到docker引擎當中的，非常簡單。它把所有需要的東西全都內建到了一條命令上。只要執行一次這條命令，所有的服務發現、跨節點溝通等等的負載均衡都已經做好了。Swarm mode是三種框架中最簡單的一種，但並不靈活，功能也沒有那麼強大了。

K8S基本概念

POD

Pod是Kubernetes一個邏輯的概念，是一組容器的組合，是Kubernetes在一個節點上控制的最小的邏輯單元。

Deployment

可以把Deployment看成一個守護程序，如果把一個Pod掛載到Deployment上面，它能保證Pod始終執行。要是監控到定義的這組Pod某一個節點掛了，容器也都掛了，它會利用排程系統找一個合適的節點啟這些Pod。Deployment可以關聯多組Pod。

Service

Service同樣可以關聯到多組環境上，幫我們做負載均衡。當有請求過來的時候，Service會自動分配到各種不同的Pod上去。假如出現了運維事故或IT事故，一個節點掛了，它會自動切換到其它幾個節點的容器上去執行，不會影響到它的服務，保證了PM的環境是始終存在的。

安裝服務

從單點擴充套件到叢集，複雜度就提升了。

首先要關注的就是跨主機通訊問題。Docker分配的是虛擬IP，只能在一個節點的容器中互相溝通。擴充套件到叢集之後，要裝一個網路外掛來解決問題。

容器之間要互相溝通，必須知道對方的IP地址。Docker在每次啟動的時候IP地址都會改變，要有一個DNS去註冊域名，在配置檔案中做通訊的時候執行這個域名就可以了。

要知道容器執行消耗了多少資源，應該再安裝一個服務來做容器級的監控。

Docker變向叢集化的時候，就面臨了映象如何在每一個節點上進行分發的問題。所以要有一個映象倉庫來存放所有映象，每個節點都會拉最新映象進行部署。