DockOne微信分享（一二七）：Docker的另類用法，就是這麼簡單粗暴

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。
【編者的話】現在業內一提到Docker就必然說到Kubernetes、Mesos。然後就提到重寫Kubernetes、Mesos，最佳化Ubuntu核心等等。作為一個資源緊缺的使用者我只能表示用不起。我就是喜歡把事情簡單化，用最小的力氣做事。簡單粗暴沒什麼不好。

【3 天燒腦式容器儲存網路訓練營 | 深圳站】本次培訓以容器儲存和網路為主題，包括：Docker Plugin、Docker storage driver、Docker Volume Pulgin、Kubernetes Storage機制、容器網路實現原理和模型、Docker網路實現、網路外掛程式、Calico、Contiv Netplugin、開源企業級鏡像倉庫Harbor原理及實現等。

我說另類是指我就用了原生的功能，這些對我們來說基本夠用了。還省去了很多開發維護的工作量。

1. 最小化的使用Docker，保證資源利用最大化和服務分鐘級切換。

現在業內一提到Docker就必然說到Kubernetes、Mesos。然後就提到重寫Kubernetes、Mesos，最佳化Ubuntu核心等等。作為一個資源緊缺的使用者我只能表示用不起。那麼真的需要這麼用嗎？Docker內建的工具可以嗎?

其實我們經常處於消費過剩，需求過剩的狀態。很多需求都是偽需求，沒必要什麼都做到100%。為了達到這目標需要的資源比做到70%要多幾十倍。我們使用工具目標是用最少的投入來解決問題。簡單粗暴沒什麼不好。

首先我們使用Docker是為瞭解決服務穩定性和資源緊缺的問題。現存很多關鍵系統（非生產）都跑在古老的伺服器上，說掛就掛。很多系統跑在VM上，宿主機資源不足。說不定突然VM就崩了。甚至於宿主機直接掛了，再也啟動不了。想上新系統，機櫃也沒空間。所以為了保證這些系統的穩定和高效，就決定把這些系統遷移到Docker系統。

先用一批新機器安裝Docker，配成Swarm叢集。然後把用的服務一個個做成image，上傳到叢集上的Docker Hub。所有服務的連接埠全部固定，人為錯開。網路全部使用Host模式。所有的資料全部從外部儲存掛載。就是這麼簡單粗暴。

然後把所有服務啟動在Swarm上，看看負載情況，不行就手動指定機器。全部啟動完成後，把IP和Port填入DNS和Nginx。其他人就可以通過網域名稱來訪問到對應的服務。如果服務掛了，重啟這個服務，然後修改對應的DNS和Nginx。如果服務代碼變了，直接JENKINS編譯出新版本image到Docker Hub。停服務，拉鏡像，重啟，修改DNS，這些都可以通過指令碼完成。

下一步在所有鏡像裡添加自主開發的Agent來完成服務監控，完成服務自發現。再加上服務監控。基本就可以用一段時間，不用折騰了。

這個方案的缺點就是如果是JIRA這種有License的軟體，必須手工重新去擷取機器資訊，然後重新申請License。不過正常情況服務就這麼起個一年，也不用管它。系統監控通過Zabix和我們自己開發的Agent來進行。也能滿足日常監控需求。

這樣搭建整個環境，2個人搞兩周就行了。

2. 中等規模測試環境Docker的規劃，環境網路隔離及持續整合。

因為我們是金融公司，所以目前生產系統還沒有打算上Docker。在測試環境還是可以用Docker的。

由於多個測試環境需要互相隔離，而且服務一般都部署在80連接埠，所以就要比前一個用法進階一點了。用Contiv進行VLAN的隔離。各個環境互相隔離。IP也自動分配，不用自己管了。服務啟動後自己上報資訊，修改DNS和Nginx的資訊，內部外部都可以訪問。

針對不同的測試環境建不同的Jenkins，可以產生對應的鏡像部署到對應的測試環境。缺點是不能做到按需建立和銷毀環境。那個還需要進行很多開發工作。整個Docker的動態伸縮也沒在考慮過程中。畢竟規模不大。預先劃分出5，6套測試環境足夠使用。

這樣就把整個CI內建到測試環境中了。

Q&A

Q：請問從開始看Docker到完成環境搭建大概用了多長時間？

A：前期的學習和選型用了2個月。後面基礎搭建用了1個月，耗時最長的是舊服務的Docker化，這個到現在還沒全部完成，因為技術債太多。

Q：可以說明下為什麼生產環境不用Docker嗎，跟你們是金融公司屬性有什麼關係？

A：因為金融公司對於穩定性有非常高的要求，同時對於生產伺服器數量和空置率又不敏感。所以Docker這樣的新技術應用還是需要不會那麼快切入。同時營運團隊也要去學習，技術儲備等都是阻礙。所以現在很多銀行也只是在周圍不重要，變化頻繁的系統開始嘗試Docker。

Q：主要想瞭解下你們整合的流程？

A：CI的流程和普通的CI類似。代碼變動後觸發Jenkins，Jenkins會編譯，打包，產生一個對應的發布單元的新容器版本。然後觸發對應的指令碼來停服務，取鏡像，啟動容器。

Q：為什麼不考慮在私人雲端平台上玩？

A：因為資源限制，從硬體及人力上都不足。另外就幾十台伺服器，沒必要。如果有幾百台就要考慮資源調度等因素。

Q：請問容器做編排管理，你們選用什麼工具

A：我們只用了原生的Swarm。這樣不用考慮開源軟體二次開發及工具間的版本相容問題。

Q：如何讓宿主機掛載到儲存之後，讓容器全部跑在儲存裡面？

A：容器本身還是在Docker主機的磁碟中，但其他資料：例如設定檔都是從SAN上掛載到容器中。這樣保證如果Docker主機down了，容器可以在其他主機上重啟恢複。

Q：z387的ip如何分配？

A：Contiv會幫你分配IP的，不用自己管理。

Q：為什麼把JIRA也Docker？

A：因為資源不足，沒有強大的主機來跑JIRA，也沒有辦法主備。所以乾脆把這些重要系統都放到容器裡。這樣就可以用較少的主機來保證效能和可用性。

Q：鏡像帶環境變數屬性嗎？

A：看情況，我們跑自動化測試的鏡像有環境變數屬性，因為有很多可變參數。

Q：如果服務掛了，重啟服務。重新修改DNS和Nginx，問題1：服務掛了，Swarm可以負責重啟吧？問題2：為什麼重啟後需要改DNS Nginx。Swarm的ingress網路可以從任何一台node路由到對應的Container吧。

A：如果鏡像down了，Swarm會管理的。但如果是服務不可用，Swarm是不知道的。這時候就需要在服務監控那裡觸發重啟。由於服務還有連接埠的問題，所以是在Nginx上轉寄到真實的服務連接埠上。DNS基本都是配置到Nginx上，如果Nginx掛了，就要把DNS重新指向。

Q：應用是Java的嗎，根據環境不同的設定檔如何處理？

A：大部分是Java的，也有Python等。我們自己開發了一套設定檔管理的系統，同時對設定檔裡的配置項進行命名規範，這樣從一套環境到另一套大部分情況是直接自動進行修改的。

Q：如何做多版本環境隔離測試？

A：目前我們沒有這樣的需求。測試環境基本上都是和生產對齊。特殊情況是在Jenkins上來選擇特定的代碼版本來進行部署。所以在不同的環境裡可以部署不同的代碼。

Q：請問Ngin配置的是Container的IP還是物理機IP？

A：Nginx是暴露出80連接埠在容器宿主機上的。

Q：不同環境的設定檔是在鏡像層面替換進去還是在容器層面替換進去

A：是在容器層面的。每個容器上有個Agent，負責去拉取設定檔。

以上內容根據2017年06月20日晚群分享內容整理。分享人 壽佳炎，盛付通品質流程中心經理。在通訊和互連網跌打滾爬近20年。幾乎幹過研發體系內各種崗位。從初級碼農到管理層。中國第一批EXIN DEVOPS MASTER認證通過者。 DockOne每周都會組織定向的技術分享，歡迎感興趣的同學加：liyingjiesa，進群參與，您有想聽的話題或者想分享的話題都可以給我們留言。