實錄分享 | 那些年容器落地，企業爲Docker填過的坑

數人云「容器助力產品迭代力MAX」沙龍乾貨分享實錄持續上新，今天是來自人人貸高級運維工程師杜天鵬的分享，與咱們細數了人人貸容器化實踐過程當中遇到的問題以及解決方法。

很高興站在這裏和你們一塊兒交流容器技術，我叫杜天鵬，是人人貸的運維工程師。人人貸是一家作P2P的互聯網公司，如今業務量上升比較快，業務組件也比較多，這個過程給運維增長了很大的壓力，因此人人貸考慮了容器化技術。

爲何使用容器技術

Docker官網有一句話：build once，run anywhere，容器一次構建，在其餘服務器上就能夠運行。第二，容器使用的是Unionfs，在傳輸的過程當中，實際上傳遞的是變動的部分，而不須要拉取完整的image。第三，容器爲人人貸提供了一個隔離的環境，在測試的過程當中，一臺機器可能運行了不少服務，一旦測試或者開發人員更改服務器環境或者其餘參數，會致使其餘的測試環境運行不起來。容器帶來了環境的隔離性，一個容器只需運行一個Docker，能夠避免不少問題。第四，容器可以結合Jenkins以及如Hudson、Teamcity這些持續交付軟件來進行持續交付、持續集成、持續部署。第五，容器能夠結合如K8S、Mesos、Swarm等調度器而後進行橫向擴展。

這是人人貸的傳統上線流程。首先開發人員推送他們的代碼到Git倉庫，人人貸使用的是Stash，測試人員在測試的時間輸入倉庫名稱和版本號，來進行使用Jenkins構建。在測試環境中，測試完成以後會從新構建一次，而後推送代碼到類生產環境。這個類生產環境實際上使用的是生產環境的配置，只不過再作一次校驗，防止出現問題。最後運維人員使用Ansible推送代碼到生產環境，在這個過程當中會產生不少問題。

好比剛纔說的環境不統一，或者是無心中修改了環境，或者有臨時的需求上線的時間，須要準備新的虛擬機。這個臨時的需求或許很是着急，可是從運維的角度來看，建立服務器，修改配置，初始化操做都須要一個過程，所以會影響總體的工做進展。Docker解決了這個問題，由於可使用提早準備好的Docker鏡像進行全部的初始化操做，讓運維能夠從容應對突發的狀況。

還有資源浪費的問題。在開發或者測試環境，人人貸運維人員爲開發建立了不少測試虛擬機，假如不作按期巡檢的話，就沒法得知這個虛擬機是否正在被開發或者測試人員使用，致使了資源的浪費。使用了Docker技術後，運維就能夠隨時爲開發或者測試同事部署一套環境，而且作按期的清理。對於大規模的部署過程，能夠實現靈活調度，由於人人貸的業務峯值是不同的。好比白天交易系統比較繁忙，能夠調整交易系統節點數量；晚上要作計算和統計，計算資源則會多跑一些任務。

爲何選擇Mesos

人人貸在使用Docker時，考慮了三種容器技術，分別是Mesos，Kubernetes以及Swarm。最終選擇Mesos主要基於三點考慮：最主要的是學習成本，對於Kubernetes，它的功能不少也很強大，可是它更新迭代很是快，裏面不少功能如今仍處於Beta版本，可是官方並無明確其使用環境。第二，成熟度的問題，Mesos推出時間早，實踐的公司也比較普遍，成熟度高於其餘兩個技術。第三，Mesos有不少調度器例如Marathon，在界面上能夠有一個直觀的展現。而Kubernetes和Swarm以前是沒有界面的，如今Kubernetes有一個Dashboard，可是功能尚不完整。

遷移到虛擬機的種種問題

人人貸從物理機遷移到虛擬機過程當中遇到不少問題，一個完整的技術就是一個成熟的技術在應用到生產環境中，這個過程當中的問題並非技術引發的，而是落地的過程當中沒有標準，因此人人貸須要有一個標準化來面對需求。

首先，配置不可見。運行在Docker內部的程序，並不不推薦進入容器，由於Docker就是一個容器，須要鏈接到裏面來看配置項。在Marathon上面就能夠看到配置項，具體配置項是經過ENV傳入的。

第二，項目沒法相互調用。人人貸的業務比較多，全部的項目須要相互調用，包括交易所、 P2P以及基金，它們之間須要進行資源交互。可是因爲人力精力有限，Docker技術在整套系統的實現尚須要一個過程。

第三，沒法經過SSH鏈接Docker。好比在測試環境中測試或開發進行一些debug操做，須要經過SSH鏈接上去，瞭解Docker如今的配置。

第四，容器IP不可見。

如何解決這些問題

接下來我會經過運用的技術來爲你們解釋人人貸是如何解決這些問題的，Docker落地過程當中主要有七點須要關注。

第一，編排。Marathon是使用json文件進行部署的，裏面會寫到具體的資源配置，鏡像名稱以及掛載目錄。首先進行配置文件模板化，在人人貸，運維人員分別負責不一樣業務部門的運維工做，因此運維並不清楚其餘部門是如何配置的，模板化以後只須要讓開發人員按照規則來表述，就能夠清晰地傳遞和表達。

例如上圖中兩個配置，這是exchange（人人貸的一個項目名）環境裏面的MySQL以及服務。開發只要按照這個標準往裏面寫配置，運維就能夠明白項目和配置項。而後進行配置項ENV化，配置都是經過ENV傳入，經過命令進行渲染，固然也可使用shell命令或者其餘的程序進行配置渲染。以後修改上線json，由於每一次json文件並非一成不變的，須要更改文本配置。

第二，網絡。人人貸使用的是Calico，它自己能夠劃分網段，來指定範圍。咱們在路由器上面添加了路由，讓開發環境能夠直接訪容器內部的網絡。Calico自己能夠支持Docker1.10版本後，能夠經過 - 指定 --IP。人人貸使用的是CNM模式，Calico是支持CNI與CNM的，人人貸使用的是calico-containers，所以可使用Docker命令，而且指定驅動爲Calico，很是便於管理。指定路由後，能夠直接訪問，再也不須要使用例如Marathonlb這些指定端口，也不須要維護端口列表。Calico使用BGP協議，不須要封包。對於Mesos來講，我比較推薦使用Calico。

第三，服務發現。人人貸使用Calico能夠固定IP地址，雖然並不推薦把容器做爲一個虛擬機來使用，可是對於固定IP地址這種狀況可能仍須要一個容器。當其餘服務須要靈活調度時，則須要IP動態劃分。人人貸使用Mesos-DNS來獲取動態分配的IP，全部的組件配置域名相互調用，測試環境一樣使用的配置域名化，即服務調度之間都是使用域名來調用的。所以Mesos-DNS只須要轉發現有域名服務器的域名解析，就能夠直接調用原有的服務，在裏面寫域名，而不須要知道其IP地址，亦不須要配置。

第四，存儲。對於一些須要持久化的數據，人人貸使用的是本地化持久卷，這個綁定在host上，當這個容器掛掉以後，它會在物理機上從新起一個容器。Docker一般運行的都是無狀態應用，因此若是MySQL裏面的數據很是重要，我仍是更推薦使用物理機或者虛擬機進行部署。對於分佈式如MongoDB或者其餘具備高可用性的數據庫，部署在Docker裏面也仍是能夠的。

第五，監控。人人貸使用的就是Cadvisor+Influxdb+Grafana這套開源方案，Cadvisor是谷歌的一個開源產品，Influxdb是一個時序數據庫，Grafana是一個漂亮的界面展現。對於Zabbix，人人貸用過一個叫Zabbix-Grafana的插件，能夠在Grafana裏面顯示Zabbix的數據。Cadvisor主要起到做用就是收集容器裏面的資源使用狀況，例如內存，CPU以及磁盤IO，而後存入到Influxdb中。固然監控的同時，也可使用Dockerstats等實現一些數據採集。

第六，日誌收集。人人貸如今主要使用的是ELK的數據方案。爲了實現SSH登陸容器內部， Docker是須要一個前臺進程來保持Docker程序不退出的，所以人人貸全部的容器都是使用SSHD守護進程，來保持Docker一直運行下去。

人人貸有一個start的腳本，例如Tomcat，咱們會在這個SSHD進程啓動以前來啓動它。因此日誌經過Docker logs是看不到的，只能在容器裏面部署一個Logstash agent，可是會加劇容器的負擔。對於沒有接入容器內部需求的同窗，能夠直接接入運行進程，將日誌打入到Docker控制檯，經過Docker logs進行日誌收集，在Docker的宿主機上面指定Docker日誌的產出目錄實現收集，而再也不須要在Docker裏面部署agent。

第七，鏡像倉庫。Docker官方的鏡像倉庫自己是沒有認證功能的，可是在真實生產環境中，須要有鏡像的權限劃分。如今Registry用的比較多就是Apphouse以及Habor，據我以前瞭解，Habor的BUG比較多一點，因此人人貸使用了Apphouse。可是如今我瞭解到Habor支持分佈式以及主從關係進行主從複製，因此未來人人貸可能會棄用Apphouse，使用Habor來作私有倉庫。Habor是一個開源產品，能夠看到它內部的實現原理，Apphouse雖然免費，可是它是閉源的。

最終流程及總結

最終人人貸落地實現了這個過程，由開發人員提交代碼到Stash，輸入版本號以及分支名經過Jenkins進行構建，推送到image。在發佈的時間經過調用Marathon的API進行發佈，拉取image，最終運行在Mesos Slave節點上。

接下來人人貸但願實現部署多套環境，對於項目名稱進行模板化處理，而且經過Jenkins實現徹底自動化。我的認爲落地的過程當中，主要問題就在於配置管理。謝謝你們。