ThreadFix團隊是如何把Docker應用到測試環境？
互聯網+的時代已經到來了，Docker+的時代還遠嗎？ThreadFix團隊成功將Docker運用到測試環境的案例告訴我們，Docker+的時代已經來臨。下面希云把ThreadFix團隊成功運用Docker的案例和大家做個分享。
ThreadFix的技術團隊發現他們經常要面臨一些非常通用的問題：如何快速構建應用實例。從開發部門到質量控制部門都有這個需求，因為它帶來的好處非常明顯，能讓用戶用上最新、最穩定的代碼版本。我們基于Docker構建的容器系統（我們內部稱為"ThreadFix + Docker"），使實現這個需求前所未有的簡單。
組件
這小節會概述一下“ThreadFix + Docker”系統的組件。
Docker以及Docker守護進程
這個系統最不可或缺的一塊就是Docker守護進程，這個進程部署在一個遠程Ubuntu虛擬機上，它和相關的文件組成了"ThreadFix + Docker"的后端。
簡單來說，Docker就是一個工具，能讓我們動態地生成容器，或者說是能與系統進程空間共存的輕量獨立進程空間。這讓我們能不用在全虛擬化的虛擬機中部署獨立的ThreadFix實例，也就是說虛擬機相關的負載也可以省了下來。
Docker守護進程運行在宿主虛擬機上，等待著指令來創建新的容器，當它接收到相應的指令，它就會以一個鏡像作為模板來創建新的容器。Docker鏡像代表容器一啟動時就會擁有的系統環境，而鏡像又是通過一個面向過程的配置腳本來生成（稱為"Dockerfile")，這套系統能非常迅速地啟動一個開箱即用的容器。我們會在本文的“Jenkins持續集成“小節中講到這部分內容。
這是一個簡單的Dockerfile。
sh FROM tomcat:7.0.65-jre7 ADD ./threadfix /usr/local/tomcat/webapps/threadfix LABEL branch="Dev-QA" LABEL version="Enterprise"
這是"ThreadFix + Docker"界面上的可用鏡像列表，以及各自的創建時間：
Docker API
Docker提供了一套REST風格的API，通過簡單的配置修改，我們把Docker守護進程的API暴露在虛擬機上的Unix端口上，“ThreadFix + Docker”中有兩個組件會通過這個通道與Docker進程通訊。
管理Shell腳本
我們有一個交互式shell腳本，用來與虛擬機中的Docker進程通訊，從而實現創建或者殺死容器，由于這個腳本中是使用Unix的<code>curl</code>程序來調用Docker的REST接口，所以這個腳本也能在用戶的機器上運行，而不一定必須從宿主機上運行。這個腳本可以指定這些參數：
- 顯示容器的名稱(用于AngularJS界面）
- ThreadFix的git版本和分支(社區版或企業版，開發版或穩定版，等等)
- 虛擬機暴露出來的端口
- ThreadFix實例要用到的數據庫文件
- 要調用的數據庫操作(創建 或者 更新）
輕量的AngularJS客戶端
終端用戶主要會用到的“ThreadFix + Docker”組件是web界面，這個頁面是由AngularJS構建的，它會直接調用GET請求與Docker進程通訊，從而獲取到Docker中可用鏡像和容器的相關信息。
對每個運行中的容器來說，都有一個鏈接是帶有ThreadFix實例的映射端口，用戶訪問這些鏈接會跳轉到具體某個ThreadFix實例首頁。
另外，還有一個鏈接是可以查看那個容器的運行日志，這對于測試團隊來說是非常方便的，能簡化發現以及重現問題的流程。
最后，警告圖標會告訴用戶容器還沒構建，他們所使用的鏡像和代碼很可能不是最新的。
更有趣的是，ThreadFix + Docker的Web界面它本身也運行在一個容器中。
Jenkins持續集成
拼圖上最后一塊是把我們現有的Jenkins持續集成任務也整合到這套系統中，我們利用了現有的CI任務，特別是那些會在代碼更改后構建ThreadFix包，以及會作單元測試來驗證代碼質量的任務，這些任務被修改成了把構建好的包復制到Docker運行著的虛擬機中，然后運行腳本去構建新的Docker鏡像，并指定特定的ThreadFix版本號。這樣的話，當用戶操作一個ThreadFix實例時，他們就能確保是正在使用由最新代碼所構建的鏡像。
背后原理
現在我們將討論一下ThreadFix + Docker背后的進程，當一個ThreadFix容器被管理腳本創建，在界面上將能調用REST API來配置一些運行時參數。
作為參數傳進腳本的端口號，會把在容器內的ThreadFix 應用8080端口，映射到宿主虛擬機上，這樣實現了用戶通過不同端口同時訪問他們的實例。
ThreadFix 的版本和分支(社區版或企業版，開發版或穩定版，等等)讓Docker進程知道啟動容器時應該使用哪個鏡像，正如上邊所說，Jenkins任務會確保這些鏡像是最新構建的。
數據庫名稱參數會在虛擬宿主機上查找同名的目錄，如果這個目錄不存在將會被創建。ThreadFix容器會關聯這個目錄作為“卷”，掛載容器中的一個路徑到這個卷上。在Docker術語中，一個“卷”是宿主機上的文件路徑，這個路徑會被映射到容器中的一個路徑上。我們的ThreadFix應用利用了這個特性，應用中把生成的HSQL數據庫文件放在卷中，這樣的話，當這個容器以新的鏡像啟動，只要關聯回這個卷上，那數據仍然是完整的。
數據庫操作參數同樣也是利用了卷的特性，如果你指定“創建”操作，ThreadFix + Docker會替換默認的jdbc.properties文件，類似地，“更新”會使用一個“update. jdbc.properties“文件來建立數據庫連接。
最后，一定要記得ThreadFix + Docker并沒有用到獨立的后端，而是直接與Docker進程通訊了。要存儲容器的元數據，我們依賴于Docker的“標簽"，這些鍵值對可以生成鏡像前在Dockerfile中指定，然后你們在Web界面上看到這些信息，諸如容器名稱、版本、分支等等。
管理腳本打印出來的創建容器結果是一串Json，以下是一段摘要：
json
Craft JSON Data for Create Call
json="{\"OpenStdin\": true, \"Image\": \"threadfix/${version}\", \"Tty\": true, \"Labels\": {\"user\":\"${name}\", \"db\": \"${database}\", \"dbMethod\": \"${dbMethod}\"},\"HostConfig\": {${databaseJson} \"PortBindings\": { \"8080/tcp\": [{ \"HostPort\": \"${port}\" }]}, \"DnsSearch\": [\"denimgroup.com\"]}}"
總結
上邊我們介紹了ThreadFix + Docker系統的各個組件，我們另外還遇到另一些用例，也是希望能通過Docker來提升我們的效率的，例如在一個遠程ThreadFix容器中連接一個本地Mysql數據庫，或者運行一個SQL Server數據庫實例來作數據庫驅動測試。
就目前來說，ThreadFix + Docker已經顯著地減少了我們的構建時間，并且提高了我們產品的魯棒性，使有時需要10分鐘的工作量變成了現在的30秒。無論是開發第三方集成應用，排查問題，跟蹤缺陷或者使新成員快速上手，Docker帶給我們的好處不止上邊這些。
來自： http://dockone.io/article/979