測試環境docker化(一)—基於ndp部署模式的docker基礎鏡像製做

本文來自網易雲社區html

做者:孫婷婷java


背景git

我所在測試項目組目前的測試環境只有一套,在項目版本迭代過程當中,開發或產品偶爾會在測試環境進行數據校驗,QA人數在不斷增長,各我的員在負責不一樣模塊工做時也會產生髒數據,致使QA在功能測試和接口測試過程當中須要清理測試環境增長工做量,同時QA組在進行異常測試等多維度質量保障時也但願有多套環境進行數據隔離。但目前測試環境多套隔離操做麻煩,每隔離一套環境須要修改大量配置、數據庫從新建表到調試可用,在開發的幫助下至少須要3天的時間,在這種場景下,咱們借鑑組內大數據QA的思路和探索路線,考慮嘗試引入docker技術來解決測試環境問題。web

在實踐測試環境docker化的過程當中,考慮到項目的部署流程都已經遷移至運維的ndp平臺,因爲項目屬於多模塊項目,同時爲儘可能保證docker化後的測試環境能與現有生產環境的配置和結構保持一致,咱們設計借鑑ndp的發佈配置和模式進行docker化後的測試環境部署。docker


ndp部署流程數據庫

通過學習、對比和摸索,瞭解到ndp的部署流程基本以下圖所示(基本都是本身摸索,未專門請求運維同事,若是運維部的同事發現有錯誤,歡迎指正(*^▽^*))tomcat

  1. 用戶在ndp管理平臺配置代碼地址、構建文件build.xml、部署定製配置(主要配置端口號、內存分配、應用名、應用入口等)安全

  2. 當點擊項目構建時,ndp服務器會拉取代碼,而後按照編寫的構建文件build.xml對項目模塊進行ant構建,模塊構建完成後進行模塊打包服務器

  3. 當點擊項目部署時,將打包模塊分發至部署服務器,進行項目部署app

基於以上背景,考慮設計docker化的環境發佈接口爲1個compile容器+多個deploy模塊容器接口,首先啓動一個compile容器完成全部模塊的編譯,並啓動一個httpServer發佈端口號,而後逐個啓動deploy容器,拉取打包模塊完成整個項目部署。所以,首先須要設計compile和deploy兩類基礎鏡像。

基礎編譯鏡像compile

  1. 咱們的鏡像使用Dockerfile製做,首先安裝項目編譯須要的軟件,包括jdk(注意是jdk不是jre)、ant、maven,其中,maven須要配置公司的依賴倉庫,所以能夠經過COPY將公司的settings.xml放入鏡像中相應位置;

  2. 容器經過git下載代碼時須要ssh權限,能夠經過找一臺服務器生成一個ssh-key,公鑰放入git上相關項目的deploy-key中獲取下載權限,私鑰經過COPY放入鏡像root下的.ssh文件中;

  3. 機器首次git clone代碼時git會提示「Are you sure you want to continue connecting (yes/no)?」,因爲須要容器運行後自動下載代碼編譯,中間不須要任何人工操做,則須要去除這條提示,經過網上搜索,解決辦法是能夠修改/etc/ssh_config文件中的配置來跳過此處詢問,以下所示去掉文件中「StrictHostKeyChecking」前的「#」。能夠事先修改好配置,經過COPY替換鏡像中相應文件便可。

#   CheckHostIP yes#   AddressFamily any#   ConnectTimeout 0
    StrictHostKeyChecking no#   IdentityFile ~/.ssh/identity

將以上操做經過Dockerfile命令方式寫入後運行docker build就能夠生成咱們定製的compile鏡像,建立容器時經過掛載的方式將項目各模塊的build.xml加載到容器中,指定容器運行代碼爲一個entry.sh文件,該entry.sh主要實現代碼拉取、各模塊ant構建和最後啓動一個httpServer的功能,啓動httpServer後compile容器即發佈成功!


基礎部署鏡像javaappp和tomcat

因爲項目中模塊基本都是javaapp和javaweb項目,咱們就考慮製做了兩個鏡像,一個爲javaapp鏡像,專門用於部署javaapp模塊,對應於ndp上的應用類型爲java app;一個爲tomcat鏡像,專門用於部署java web模塊,對應於ndp上的應用類型爲java web。

a. javaapp鏡像

  1. javaapp鏡像主要用於運行javaapp應用,只須要有jre環境便可,所以首先安裝jre;

  2. 將現有測試環境服務器部署模塊中生成的config文件放入自定義路徑下,該文件用於定製化jvm參數、內存分配、應用名、端口號等,對應ndp上模塊-配置-發佈配置頁面內容,以下圖

   3. 將現有測試環境服務器部署模塊中的appCtrl.sh經過COPY放置在自定義路徑下,該文件爲調用config參數後啓動java的項目啓動文件,須要啓動項目時只需運行./appCtrl.sh start便可,具體其餘功能可學習該文件。

建立容器時經過掛載的方式將entry.sh文件加載到容器中,該entry.sh主要實現從compile容器拉取部署模塊、修改config配置(增長特定入口main方法)和啓動appCtrl.sh的功能,啓動模塊後該模塊容器即發佈成功!


b. tomcat鏡像

  1. 因爲web項目須要使用tomcat,鏡像首先安裝jre和tomcat

  2. 將現有測試環境服務器部署模塊中的default_tomcat文件放入自定義路徑下,該文件用於定製化內存分配、應用名、端口號等,對應ndp上模塊-配置-發佈配置頁面內容

  3. 修改tomcat中server.xml,主要是將docBase的路徑指定爲後續打包模塊的存放路徑,好比我是指定爲"/usr/local/compressed"(因爲一個容器中只會運行一個模塊,因此此處可固定填寫)

  4. 將現有測試環境服務器部署模塊中的用於tomcat服務啓動的tomcat腳本文件放入自定義路徑下,該文件相似於javaapp鏡像中的appCtrl.sh文件((需刪除java、修改start-stop-daemon路徑))。同時因爲該文件調用了init-functions和rotatelogs,需修改init-functions的調用路徑爲系統文件路徑,並在自定義路徑下加入rotatelogs用於日誌切割

建立容器時經過掛載的方式將entry.sh文件加載到容器中,該entry.sh主要實現從compile容器拉取部署模塊、修改配置和啓動tomcat的功能,啓動模塊後該模塊容器即發佈成功!


總結  

此部署結構和鏡像一方面對標了ndp的環境部署方式;另外一方面,部分jar包會被其餘其餘模塊依賴,但基於安全緣由未上傳至倉庫,而是先打包後給其餘模塊使用,此時集中在一個容器中打包則不須要在各個模塊編譯的時候重複打包依賴jar包;同時保證各個模塊屬於同一個版本的代碼,保證每套環境部署時各個模塊的版本一致性。

從目前實踐結果來看,本組項目已基本完成各個模塊的容器發佈,只要一套環境發佈的各個配置文件、build.xml、entry.sh整理好,便可實現三行命令發佈一套環境的需求,大大縮減了測試環境部署時間。故在這裏寫出來給有須要的小夥伴參考,也但願有相似經歷的同事能夠多提建議,多多指教。


有實踐就會有坑,此處簡單羅列鏡像製做過程當中的各類奇怪的坑,以免夥伴們重複踩坑!

1. 在tomcat鏡像製做過程當中,使用的基礎鏡像是docker-library中的tomcat的Dockerfile,可是該鏡像在執行過程當中會再安裝一遍jdk,在安裝後刪除致使build到一半時找不到jdk,解決方法:刪除從新安裝的代碼。

2. ndp上build.xml中的執行工具mvn的名稱默認爲服務器中的mvn名稱「mvnJDK7」,須要修改成咱們安裝在鏡像中的mvn名稱,通常爲「mvn」。

3. 注意修改各COPY到鏡像中的可執行文件的執行權限,如rotatelogs/config/default-tomcat等

4. 在compile+deploy結構中,我最終在compile容器中起了一個httpServer,各deploy經過wget獲取編譯後的文件夾,可是若文件夾中有index.html,wget會默認讀取index.html及index.html中的連接文件,這樣就違背了我但願獲取全部文件的預期,最後解決辦法是先將文件夾壓縮,經過wget獲取後再解壓

5. 容器入口使用entry.sh運行,最後運行完./tomcat start或./appCtrl start後會退出容器,緣由是docker容器中的前臺線程結束即會退出。解決辦法,能夠在腳本最後添加命令「tail -f /dev/null」使線程始終掛起。


網易雲容器服務爲用戶提供了無服務器容器,讓企業可以快速部署業務,輕鬆運維服務。容器服務支持彈性伸縮、垂直擴容、灰度升級、服務發現、服務編排、錯誤恢復及性能監測等功能,點擊可免費試用


網易雲免費體驗館,0成本體驗20+款雲產品!

更多網易研發、產品、運營經驗分享請訪問網易雲社區


相關文章:
【推薦】 Wireshark對HTTPS數據的解密

相關文章
相關標籤/搜索