docker搭建大規模測試環境的實踐

內容來源：2017年4月8日，第四範式資深測試開發工程師孫高飛在「餓了麼技術沙龍【第四彈】北京研發中心測試專場」進行《docker搭建大規模測試環境的實踐》演講分享。IT大咖說做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。
閱讀字數: 2592 用時: 9分鐘

摘要

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

嘉賓分享視頻地址：t.cn/R9UCnpq

困境

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

測試環境不一致。

由於搭建環境困難，環境很少，因此一套環境有多人使用，容易形成環境的互相踩踏問題。

隨着業務的發展和時間的積累，咱們發現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變向集羣化的時候，就面臨了鏡像如何在每個節點上進行分發的問題。因此要有一個鏡像倉庫來存放全部鏡像，每一個節點都會拉最新鏡像進行部署。

以上是我今天分享的內容，感謝聆聽！

福利贈票！

IT大咖說做爲第二屆APMCon中國應用性能管理大會的官方現場直播合做夥伴，特爲小夥伴們爭取了少許免費VIP票福利（原價￥1388）！

獲取方式：

掃碼加這位小姐姐微信（或加微信號：ITDKS666），她會告訴你咋獲取！（備註：聽雲社區）