這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。
【編者的話】容器化技術作為“攪局者”，勢必面臨適配公司已有架構的挑戰，本文將為大家介紹360如何讓Docker落地。主要包括三方面內容：一，結合公司業務特點，如何使Docker適配現有技術架構 ，完成線上環境快速部署擴容；二，“讓產品失敗的更廉價”，使用Docker構建PaaS環境加速中小業務快速孵化上線；三，使用Docker技術，在構建持續整合環境方面的一些積累。
容器化技術作為“攪局者”，勢必面臨適配公司已有架構的挑戰，本文將為大家介紹360如何讓Docker落地。主要包括三方面內容：一，結合公司業務特點，如何使Docker適配現有技術架構 ，完成線上環境快速部署擴容；二，“讓產品失敗的更廉價”，使用Docker構建PaaS環境加速中小業務快速孵化上線；三，使用Docker技術，在構建持續整合環境方面的一些積累。
以Docker為主的容器化技術現在可謂風生水起，大家都覺得它可能會顛覆整個IT格局。我們剛開始接觸到Docker的時候也覺得它非常好，有很多優點吸引我們。因為它的顛覆性我們稱它為“攪局者”。
改造“攪局者”Docker
我們先來看看這位攪局者的優點：
- Namespace、CGroups虛擬化， 相比傳統虛擬化會有更好效能，反映在生產環境中就是能更大程度的利用資源。
- 啟動速度快，虛擬機器最快也得30秒-1分鐘，它的啟動建立都是秒級。
- 鏡像分層技術，解決了快速變更環境的問題。
這些優點很吸引我們，我們非常希望把它用在生產環境中，但是我們發現理想很美好，現實很殘酷。我們之前基礎架構都是使用傳統虛擬機器化技術就是虛擬機器。我們要使用Docker就會面臨這幾個問題 ：
- 不能SSH，緊急問題怎麼排查？
- 怎麼監控？
- 基礎服務如何對接？
- 最重要的問題： 這東西穩定麼，線上業務當然不能出問題。
所以，在應用Docker的時候，我們犯了猶豫，因為按照它推薦的方式，我們無法直接立馬就線上上業務使用。因為Docker本身也對業務的架構設計有一定要求，比如我們常說的容器無狀態，容器中不要留中間資料。我們發現公司的業務架構改造起來困難很大，涉及到方方面面，所以我們決定要Docker去適應公司的架構。
接下來我們就是要解決Docker技術”落地”的問題。
我們對Docker改造點主要有：
- 容器內部綁定獨立IP。
- 容器內部開啟多進程服務。
- 自動添加監控。
- CPU配額硬限制。
- 容器綁定獨立IP這樣外部可直接SSH了。
我們考慮在容器內部運行多個進程服務，因為預設容器只開啟一個進程，這無法滿足我們要求，所以我們大膽進行了改造。我們甚至在鏡像裡實現了
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，進群參與，您有想聽的話題可以給我們留言。
