360的容器化之路

容器化技術作為“攪局者”，勢必面臨適配公司已有架構的挑戰，本文將為大家介紹360如何讓Docker落地。主要包括三方面內容：一，結合公司業務特點，如何使Docker適配現有技術架構 ，完成線上環境快速部署擴容；二，“讓產品失敗的更廉價”，使用Docker構建PaaS環境加速中小業務快速孵化上線；三，使用Docker技術，在構建持續集成環境方面的一些積累。

容器化技術作為“攪局者”，勢必面臨適配公司已有架構的挑戰，本文將為大家介紹360如何讓Docker落地。主要包括三方面內容：一，結合公司業務特點，如何使Docker適配現有技術架構 ，完成線上環境快速部署擴容；二，“讓產品失敗的更廉價”，使用Docker構建PaaS環境加速中小業務快速孵化上線；三，使用Docker技術，在構建持續集成環境方面的一些積累。

以Docker為主的容器化技術現在可謂風生水起，大家都覺得它可能會顛覆整個IT格局。我們剛開始接觸到Docker的時候也覺得它非常好，有很多優點吸引我們。因為它的顛覆性我們稱它為“攪局者”。

改造“攪局者”Docker

1. Namespace、CGroups虛擬化， 相比傳統虛擬化會有更好性能，反映在生產環境中就是能更大程度的利用資源。
2. 啟動速度快，虛擬機最快也得30秒-1分鐘，它的啟動創建都是秒級。
3. 鏡像分層技術，解決了快速變更環境的問題。
</ol>
這些優點很吸引我們，我們非常希望把它用在生產環境中，但是我們發現理想很美好，現實很殘酷。我們之前基礎架構都是使用傳統虛擬機化技術就是虛擬機。我們要使用Docker就會面臨這幾個問題 ：


1. 不能SSH，緊急問題怎么排查？
2. 怎么監控？
3. 基礎服務如何對接？
4. 最重要的問題： 這東西穩定么，線上業務當然不能出問題。
</ol>
所以，在應用Docker的時候，我們犯了猶豫，因為按照它推薦的方式，我們無法直接立馬就在線上業務使用。因為Docker本身也對業務的架構設計有一定要求，比如我們常說的容器無狀態，容器中不要留中間數據。我們發現公司的業務架構改造起來困難很大，涉及到方方面面，所以我們決定要 Docker去適應公司的架構。

接下來我們就是要解決Docker技術”落地”的問題。

我們對Docker改造點主要有：


1. 容器內部綁定獨立IP。
2. 容器內部開啟多進程服務。
3. 自動添加監控。
4. CPU配額硬限制。
5. 容器綁定獨立IP這樣外部可直接SSH了。
</ol>
我們考慮在容器內部運行多個進程服務，因為默認容器只開啟一個進程，這無法滿足我們要求，所以我們大膽進行了改造。我們甚至在鏡像里實現了chkconfig讓以前的RPM包原生可用。

自動添加監控讓創建的容器自動添加到Zabbix中。CPU配額硬限制 Docker 1.7版本已經支持了，我們在這之前自己實現了一套。

改造Docker支持這些功能后，我們又開發了一套調度系統，負責管理調度在集群上如何創建容器，我們也調研了一些開源的調度系統，發現都不滿足需求，所以自己開發了一套。

通過這些手段我們就可以讓Docker技術“落地”了，而帶來的好處是，之前的體系我們要上線新的業務大約需要40分鐘，使用Docker縮短到了5分鐘。

這是分享的第一部分因為“攪局者”Docker使用遇到了困境，所以我們對它進行了一些改造，更好適配公司場景，讓技術“落地”。


基于Docker做一個內部PaaS平臺

緊接著我們基于Docker做了一個內部PaaS平臺。公司每天會上線很多業務，這些業務有些是體量很大的重要業務，有些是帶有試錯性質的小業務。

傳統業務上線的步驟會非常得嚴謹，流程會比較長，這些流程其實也對業務穩定性會有保障。有些試錯性質的小業務，使用同樣的流程變得不太合適，所以我們就想加速小業務上線流程，讓他們可以快速上線，驗證自己得價值。基于這種考慮，而且Docker天生的特點就特別適合干這個。

這是界面的一個截圖，主要是前端Web UI去訪問一個調度層 ，調度層通過調用Docker API來創建容器。目前PaaS平臺支持PHP、Node.js、Python、Java等語言。



除了創建容器，我們還需要，創建Git倉庫、配置訪問代理等，總之研發一鍵就可以讓業務進入待上線狀態，只要他傳完代碼就可以上線了。

目前這個平臺跑了300+業務，讓很多研發只要有一個idea，就可以快速實施上線，很受他們歡迎。

這也是我們應用Docker的第二部分，通過私有PaaS平臺，加速業務孵化。


關于持續集成

第三部分是關于持續集成。

持續集成當然是Docker最純粹的玩法了，通過『Dockerfile-構建鏡像-創建新容器』來完成環境的變更。

這塊比較復雜，我們大致分了9個模塊，比如調度模塊、監控模塊、存儲模塊等。

首先我們做了一個配置轉換模塊來轉換Dockerfile，這樣即可以統一鏡像構建標準，同時也降低了編寫Dockerfile的學習成本。

調度模塊就直接用的Mesos和Marathon，鏡像Registry直接使用了 Registry V2因為它性能更好對高并發支持也很好，最后是鏡像構建模塊，使用的是Jenkins CI。

但是我們發現一個問題：鏡像構建在高并發下其實并不快。 比如裝一個RPM包，SSH肯定會比重新build快得多。所以我們做了很多優化在鏡像構建這一塊，現在結果是100個任務同時構建我們也能達到和傳統集群管理如Puppet一樣的效率。


Q&A

問：開發自己的調度系統大概花了多久，有遇到特別的技術難點嗎？
答：大約2個工程師一個月樣子，沒有太多得困難。因為調度邏輯比較簡單。

問：您剛才說，通過綁定獨立的IP就可以直接使用SSH了。
答：通過綁定獨立的IP就可以直接使用SSH了，官方關于network那篇文檔有介紹實現方案。

問：一般Docker的服務封裝是no daemon的，這時如果重啟服務，容器也會退出的，如何debug？
答：可使用supvirsod或者monit等將no daemon封裝一下。

問：你們服務的注冊發現用的是什么？
答：我們基礎架構組開發了一個，名字叫QConf，已經開源在GitHub上。

問：你說Zabbix做的一個容器監控，那有沒有一個基于宿主機的監控方式？因為據我所知你這樣的話每個容器都要運行一個代理吧。
答：我們就是使用宿主機里安裝Zabbix代理，通過Zabbix自發現來動態獲取容器列表，再基于自定義的監控腳本獲得每個容器的監控數值。

問：你們的那些業務跑在Docker里了？
答：目前360的很多Web2.0業務已經跑在了上面，像影視、新聞、免費WIFI等。

問：Docker建議無狀態，那么是否意味著不建議存放數據？比如MySQL，還是說通過-v來解決？
答： 這其實是數據存儲問題，你可以使用分布式存儲來存儲數據，只要數據和邏輯分離容器就無狀態了。

問：Docker建議無狀態，那么是否意味著不建議存放數據？比如MySQL，還是說通過-v來解決？
答：我理解就是容器無狀態就是基于鏡像創建的馬上就能線上使用。

問：線上Docker的穩定性如何？
答：目前運行都很穩定，沒有出現容器異常崩潰等情況。

問：Container中跑多個進程，那么PID為1的進程你們是由什么控制的，直接由對應的應用程序還是其他什么？
答：之前用了supervisord 現在使用S6。

問：Registry面對大量的并發，有測試出大致的性能占比嗎，整個registry是mirror還是其他架構？
答：Registry目前我們更新到了V2，我們測試V2在高并發pull和push上性能非常好，鏡像存儲使用共享存儲，這樣Registry也可以橫向擴展。

問：如果容器配置用戶可以直接訪問的IP，在宿主虛擬機中是否可以基于Open vSwitch實現，否則會太依賴虛擬機網絡？
答：這個可以的，實際上我們也測試過沒問題，當時基于穩定性考慮沒有使用。

問：奇虎的CPU配額管理是如何實現的？
答：這個Docker 1.7已經實現了，我們和官方的實現思路是一致的。

問：關于容器中數據存儲是怎么做的，如果是共享存儲如何進行對應？
答： 可以試試GlusterFS或者Ceph。

問：容器綁IP，容器重啟后IP要重新綁吧，IP會變嗎？
答：需要重新綁，可做成自動化腳本。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
以上內容根據2015年8月18日晚微信群分享內容整理。分享人許斯亮（微信siliang5625633），2011年加入奇虎360，從事業務一線運維工作，在線上業務運維和架構設計上有豐富的經驗。參與了Hulk私有云平臺架構設計和實施，主導內部PaaS平臺的設計和開發。 DockOne每周都會組織定向的技術分享，歡迎感興趣的同學加微信：liyingjiesx，進群參與，您有想聽的話題可以給我們留言。

來自：http://dockone.io/article/600