實錄分享|一篇文章看CNTV的容器化探索和平臺搭建

中國開源雲聯盟容器工做組成立後的第一次活動——數人云對話Docker&Mesos沙龍活動圓滿落下帷幕。本篇文章是活動的實錄分享，介紹了CNTV容器技術的探索與實踐，在以高安全、高可用和彈性伸縮爲需求的前提下，容器技術具體在CNTV是如何落地的。

本文內容主要有如下五點：第一，CNTV爲何要用容器，第二，CNTV容器管理平臺的選型，第三，容器在CNTV的發展與現狀，第四，案例分享，第五，容器將來發展。

張航源，CNTV技術中心高級工程師
2009年加入CNTV，現任技術中心高級工程師，主要負責CNTV容器化的探索和平臺搭建，存儲平臺的架構和運維，以及ELK平臺的建設等工做。

分享實錄：

CNTV是中國網絡電視臺的簡稱，是中國中央電視臺旗下的一個網絡媒體播出機構，於2009年12月28日正式開播。中國網絡電視臺能夠理解爲基於視頻內容爲主的一個互聯網網站。在今年6月，CNTV很榮幸地加入了中國開源雲聯盟容器工做組，咱們有更多的機會來參與容器技術的討論，與你們一塊兒學習。

爲何要容器

首先來談一談CNTV爲何要用容器，主要是要解決哪方面的問題或者說咱們的痛點在哪裏。其實咱們當時的想法很簡單，就是爲了更好的應對CNTV面臨的重大活動。怎麼來理解這個「重大活動」？好比像去年的「九三閱兵」，剛剛結束的「歐洲盃」，即將要開始的奧運會，「世界盃」，以及每一年的春節聯歡晚會，這些都是CNTV傳統的一些重要保障活動。在活動重保期間，咱們主要面臨三個問題，即高安全、高可用和彈性伸縮。

高安全怎麼理解呢？我相信每一個企業都會把安全放在第一位，咱們公司也一樣是這樣，咱們把安全放在一個高強度和常態化的現象當中。在重保期間內，安全方面的調整並非特別多。在高可用方面，咱們更多的理解是系統的底層架構，它在重保期間每每也不會變更。因此，咱們的重心就放在了彈性伸縮，也就是說，如何在重大活動期間更合理、更快速、更平穩地分配咱們的資源，這也是咱們這幾年制定的奮鬥目標。

這是咱們私有云團隊提供的一張PPT，以IaaS資源申請爲例，和你們闡述目前在CNTV申請資源的工做流的狀況。咱們有傳統的一些虛擬化工具，KVM、Xen、VMware等等，包括咱們目前在大力發展的OpenStack平臺。當有業務申請資源時，咱們會根據業務的需求，開出一臺虛機，而後開發或運維人員經過SSH登陸到機器上部署程序和代碼。平臺工程師將把這個虛機作成模板，用來批量製做、測試上線、後期資源回收，並部署其它業務。其實，在活動的重保期，每一個環節基本上是不須要過多調整的，每每就是在資源如何彈性伸縮方面，咱們會作一些事情。所以，基於業務上的壓力，以及領導給的一些任務指標和咱們系統工程師對新技術的渴望，咱們調研了容器技術。

在咱們前期調研容器和搭建測試環境的時候，咱們發現容器資源池一直從申請到下線，整個工做流和咱們的IaaS平臺沒有太大的區別，工做流方向大體是同樣的，都是提交代碼、Build鏡像、Push Pull鏡像、啓用容器、測試上線、刪除容器、資源回收。而不一樣則在於，容器具備動態擴容和縮容的特性，也就是你們說的彈性伸縮。同時，容器的建立速度，以及更少的人爲干預這兩點，也是咱們這幾年一直在追求的地方，因此咱們認爲容器技術與咱們在重大活動期間每每常態要調整的操做是很是契合的。

容器管理平臺的選型

肯定了容器這個方向，接下來就是內部討論容器接下來要如何作，平臺如何選型，咱們的業務如何調整，以及須要哪些部門來配合。Mesos、Kubernetes、Swarm是你們在容器裏面常常能聽到的一些編排工具，所以，咱們當時主要基於前三個（Mesos、Kubernetes、Swarm）來作調研，包括和業界、以及互聯網的一些從業朋友進行討論，包括與去哪兒網的徐磊同窗也進行了深度的交流，他們給了咱們好多中肯的建議。最終，咱們選定了能夠支持多種frameworks、組件衆多、部署相對容易、高可用、能支持更龐大架構的Mesos，並選定了數人云做爲合做廠商，和咱們一塊兒創建CNTV的容器平臺。

簡單介紹下咱們的發展，真正啓動容器項目是從2015年8月開始，Docker的版本是從1.7開始，而後到1.8.一、1.9.1，咱們前兩天升級到1.11.2版本；Registry版本也是從V1到V2；日誌管理測試了log-driver、logspout、logging，logging是數人云的日誌採集工具，把它放在咱們的ELK日誌分析系統上面。在容器監控方面，咱們先測試了小米的open-falcon，第二個是你們最熟悉的Cadvisor+Influxdb+Grafana。目前整個業務的容器實例大概是1000+左右，物理服務器大概是30臺左右。這個容器實例跟物理服務器沒有比例關係，只是說咱們當時給容器申請更多的資源而已。

容器在CNTV的發展與現狀

咱們主要改造的是如下三個系統，第一，央視網圖文源站；第二，Time系統，用於PC端和移動端節目時間表的調用，以及網站的年月日時間顯示；第三，API接口項目，全部央視網APP在回調素材時都會訪問這個統一接口平臺，包括央視影音、央視新聞、央視體育等APP。

最終的平臺是這個樣子，首先是監控平臺，咱們目前使用的是Cadvisor+Influxdb+Grafana。日誌系統是經過log-driver模式，而後打到一臺logstash，最終經過logstash入口，再入ES，這是咱們本身的一套日誌分析系統。編排工具是Mesos+Marathon+Docker，用數人云作底層的技術支持。鏡像倉庫，咱們目前選用了開源的組件，帶UI界面，是V2的版本。後端咱們掛了一個GlusterFS，作了高可用。

從容器監控提及，在階段一咱們用了Cadvisor，第二階段咱們用了Cadvisor+Influxdb+Grafana這套架構，保證數據的持久化。到第三階段，咱們的ELK系統是在容器平臺以前搭建完成的，咱們把容器、物理機、虛擬機都統一放到Grafana上作統一的展示。

容器日誌方面，階段一跟你們走過的路都差很少，就是volume模式到宿主機的路徑。第二個階段，由於當時咱們的經驗也不是特別多，咱們把logstash_agent打到了容器裏面。第三個階段，是經過log-driver、logspout或數人云的logging等模式，log-driver經過-log-opt參數到syslog，包括HTTP協議或TCP協議，IP，端口，直接就收走了。

容器日誌大概的模型是這樣，方式一：log-driver把日誌打到syslog裏面。方式二在宿主機上會有一個logspout的容器，最終入到ELK系統上面。

容器進程管理方面，咱們和去哪兒的兄弟也溝通了很長時間，由於你們更傾向於一個容器裏面一個應用，由於這樣的使用方式對容器是最好的。可是程序每每不是一個，咱們如今以兩個居多，包括Nginx加php這兩種狀況。容器長時間運行須要前臺進程，所以，咱們一開始前期測試也是經過top或tail-f保持長時間運行，可是裏面的Nginx服務死掉的話是感知不到的，這樣應用會受影響。所以，在階段二咱們就用了supervisor，supervisor在CNTV已經使用了幾年了，不少都是用supervisor來管理的，後來咱們又發現了S6進程管理，supervisor每次拉服務就三次，而S6有一個好處是無限拉、無限起這個服務，並且還有一個finish，也就是說，若是容器的進程死掉的話就把容器幹掉，不必再重複的去拉里面的進程或服務，包括Nginx也好，PHP也好，直接幹掉就OK了，咱們通過對比認爲，S6比supervisor要好一些，所以咱們用S6來管理這兩個前臺進程。

鏡像倉庫用了AppHouse，咱們把它的配置文件，包括數據鏡像的相關數據放在GlusterFS上，前面頂了Nginx作負載均衡，暫時實現了一個高可用。後期咱們也許會逐漸轉到Harbor上，據說Harbor 0.3的功能仍是比較好的，包括mirror等功能，因此，咱們後期可能要轉過去。

CI/CD方面，咱們在這個架構上沒有作過多的調整，咱們把Dockerfile打到SVN，SVN會上傳代碼到Jenkins Build鏡像，而後Push到鏡像倉庫裏，包括如何與數人云或其餘平臺作CD。咱們的Jenkins作的是單機部署，沒有作集羣部署，咱們的應用如今仍是比較少，後期包括Jenkins on Mesos或一些集羣部署和一些其它類的CI工具，咱們也在逐漸進行嘗試。

案例分享

這是一個案例分享，就是剛纔前面說到的移動端回調素材的時候訪問的一個統一的接口方。咱們這個業務主要分爲五層，第一層就是web層，主要是Nginx+PHP的應用，第二層是一個接口緩存層Memcache，第三個是Tomcat，也是一個接口層，第四層是數據庫的緩存，第五層是Oracle。三個機房提供服務的支撐，咱們目前已經作到了第三層，可是第三層尚未上線，咱們上線的是前兩層。咱們打算再作一下第四層，近期一到四層全能改造完，中間是用VIP來調度或者是DNS來調度，可能咱們還得進一步去討論。

這裏把API項目的Dockerfile列出來了，比較簡單，就是一個基礎鏡像包括一個Time的時間區域，yum安裝一些必要的程序，在這個位置咱們把S6封裝進來了，下面是咱們Nginx業務的一個腳本，這是後端的一個啓動腳本。咱們web前端的Dockerfile大概是這樣。爲了更好的區別日誌來自哪裏，咱們就在Nginx日誌裏面加了四個字段，即類型、地點、業務類型和Container ID。咱們的Container ID封裝在S6 run的文件夾裏面，最後用sed給它替換掉，由於容器起來的時候，咱們獲取它的Hostname。真實的日誌打出來就是這樣，就是咱們線上ELK的日誌就是這樣。

這裏面有一個小插曲，一下子到後面我可能有時間會提一下。

主要業務就分享完了。咱們發現一個問題，之前咱們用的是1.9.1的版本，咱們在用log-driver的時候有一個OPT的參數，咱們相關係統工程師把鏡像名字打進去了，他認爲看日誌的人有可能想知道這個容器是從哪一個鏡像出來的。可是如今回頭想一想其實沒有任何做用。升級到1.11.2這個版本的時候，咱們發現經過Log-driver出來的時候，它前面會帶出來一個時間、Docker和一個Container ID，它自己就會有這些屬性，因此咱們後期會把Nginx裏面加的Container ID去掉，直接從Log-driver裏面出來的Container ID用Logstash作切割匹配就OK了。

將來發展

這是一個將來發展，這段時間咱們跟數人云也在作進一步的溝通，包括咱們的業務如何作配置中心，容器ENV化，把更多的環境變量或者參數從鏡像裏面提取出來，由於咱們好可能是徹底打到鏡像裏面，可能有一些改動包括配置文件等等就要從新打一遍鏡像，太繁瑣，跟數人云也在進一步溝通這件事情。

對於咱們來講，咱們選用一個底層平臺，包括咱們是否是之後用Docker，咱們還在繼續探索，可能咱們後期也會嘗試一下其它的容器。

我大概分享就是這些內容，謝謝你們！