這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。
【編者的話】介紹魅族雲的情境需求，如何引入Docker，在網路、儲存、鏡像技術的選擇，如何落地的等等。主要內容：
- 魅族雲業務情境
- 魅族雲Docker化設計理念
- 網路、儲存、鏡像技術的選擇
- Docker化落地情況
1、魅族雲業務情境
魅族雲的需求情境可以分為以下幾大塊：
- 鏡像需求：應用想上Docker就需要鏡像，我們跟業務營運一起定好鏡像的Dockerfile，push到鏡像倉庫，這個私人倉庫儲存了公司內部使用的所有鏡像。然後我們會在承載Docker的宿主機預熱這些鏡像，加快速度；
- 機器申請：我們有使用KVM的曆史包袱的，所以在機器申請的時候就會走不同的通道，有KVM的和Docker的；
- 業務發布：這是應用用得最多的情境，上了Docker就涉及到一個問題，如何屏蔽掉KVM和Docker機器的區別，我們有一套自研的發布系統，它會自動屏蔽掉兩者的區別，各自走各自的發布流程；
- 監控：對容器生命週期的監控。
從這些情境或者需求裡面可以知道，在使用Docker之前，我們是有曆史包袱的，不僅來自KVM的使用，還有更多的是營運工具鏈/營運平台的搭建。
魅族營運體系
我們的營運體系已經很完整了，標準化、自動化、平台化、安全每一塊都已建設完畢。在這完善的體系下要引入Docker，就註定了我們不能照搬傳統Docker的實踐，這裡我們抽象出一些理念，這些理念也決定了我們到底怎麼玩Docker，如何完成Docker實踐。
2、Docker設計理念
Docker建立的Container需要長時間運行
這個理念尤其重要，就是說我們的Docker Container一旦建立就會運行相當長的時間，表現出一台虛擬機器的特性。
做這個特性的第一大歷史原因是我們有監控系統，需要把整個虛機的曆史狀態記錄下來，在出現問題的時候，我們需要對比這台機器，以IP為標識的這台機器，在一周內的整個行為舉止，記憶體、CPU、磁碟等等的狀況。如果Container很快被幹掉，發一次包， Container就變成了全新的，這是不可接受的，曆史監控資料全沒了。
Container擁有獨立、唯一的IP
每個Container擁有終生的/唯一的代號，這個代號就是內網IP，這個IP從它建立到最終銷毀是不會改變的。
主機間Container的通訊是通過大二層網路，並通過vlan進行隔離
開啟ssh
這個主要是考慮到用慣KVM的營運和開發，如果直接把ssh關閉，會被吐槽，最終我們是開啟了ssh，並通過Bastion Host進行許可權控制和審計。
這就是我們開始Docker實踐的幾個支撐理念，它讓我們的Container表現得像一台KVM虛擬機器一樣，以此來滿足業務的需求和適應現有的營運平台。
3、 技術選型
主要是我們在網路、儲存、鏡像技術的選擇。
網路：OVS & VLAN
網路我們是在大二層架構上做的，就是OVS加VLAN的方式。
- 宿主機安裝OVS，在OVS上配置橋接器
- Container的網卡跟OVS的橋關聯起來
- vlan tag打在OVS的橋上，讓OVS進行封裝和解鎖裝
- OVS跟物理網卡綁定，用
bond主備模式連上物理交換器，保證高可用
- 宿主機物理網卡跟交換器間配的是
trunk模式
- Container跟OVS的串連，用
ovs internal port模式
儲存：Devicemapper+LVM
- Docker的儲存系統我們選擇發展比較早也比較成熟穩定的DeviceMapper，並且DeviceMapper底層我們直接使用裸裝置作為pool，來提高IO效能
- 資料盤儲存使用LVM，把磁碟劃分成多個邏輯卷，每個容器分配一個卷當作資料盤的儲存，這樣做除了能對容器使用的卷進行限額，還可以達到線上調整容器卷大小的目的
鏡像儲存與同步
- 鏡像管理使用Distribution，前端設定LVS做負載平衡，保證Distribution的高可用
- 鏡像儲存使用Ceph分布式儲存，為鏡像讀寫提供高效能，也保證了鏡像儲存的可靠性
- 不同資料中心間鏡像的同步，則是通過Distribution的通知機制加後端的同步機制來完成的
監控
監控/警示可以說是營運體系最核心的功能之一，我們已經有一套很成熟的監控警示平台，而且營運和開發的同學都已經習慣了這套平台。重新開發一個監控警示平台會花費很多精力，而且意義也不大。
我們在每個容器內部運行一個Agent，從/proc下面擷取CPU/記憶體/網路IO等資訊，然後上報到監控警示平台。預設情況下，容器內部的proc顯示的是宿主機的資訊，我們通過擷取CGroup中的統計資訊來覆蓋掉這部分proc資訊。
4、 Docker實踐落地
鏡像建立
鏡像的建立我們通過平台來做的，當然直接用Dockerfile來build也沒問題，但是在可控性方面會比較弱，我們通過平台來做這件事情，降低了學習成本，也提高了鏡像的品質和安全，比如可以限制哪些包可以安裝，哪些連接埠不能開放等等。
容器建立
在我們的平台上容器的地位跟虛擬機器是一樣的，唯一的區別就是type類型，一個type是KVM，一個是Docker，其他的跟以前的玩法都是一樣的，營運和開發接入學習的成本非常低。
Auto Scaling
- 可以對Container進行擴容和縮容，以提高資源的利用率，這裡注意縮容可能會導致服務不可用
- 按照業務來水平擴容，一次交付多個容器給業務方
容器發布
容器的發布，我們跟KVM虛擬機器發布是一樣的，把一個war包放到Maven，虛擬機器再從Maven上把包拉下來，然後跑起來。
總結
- 提供類似KVM虛擬機器的使用者體驗
- 利用Docker進行高密度部署
- 快速Auto Scaling
在Docker容器化引入的過程中，我們的理念在於想提供一個類似KVM一樣的虛擬機器使用者體驗，讓使用者可以無障礙使用容器，我們引入容器的目的在於它的輕量和低開銷，能夠高密度的部署，壓榨物理機資源，提高資源的利用率，從而節約成本，在彈性方面，利用容器的輕量/便捷，我們可以快速的建立/銷毀，滿足業務的彈性需求。
Q&A
Q：請問下負載平衡LVS是怎麼和容器結合的？
A：現階段我們的容器是當虛機來用，有固定IP，所以LVS按照傳統方式使用即可，在容器裡面配上VIP，如果是FullNAT方式則不需要。
Q：魅族雲的編排工具優選哪個，有混合雲的計劃嗎？
A：現階段我們是原來的平台上做適配。今天的內容我們講的都是對內的私人雲端，公用雲端正在開發測試階段。
Q：你們的縮容，具體是怎麼做的？
A：CPU、記憶體是修改CGroup配置，磁碟則通過LVM進行縮容。
Q：請問，日誌集中儲存與日誌查看怎麼實現的？
A：我們有基於ELK實現的統一日誌管理中心，日誌都發往日誌中心儲存，可在管理平台上進行查看。
Q：“預設情況下，容器內部的proc顯示的是宿主機的資訊，我們通過擷取CGroup中的統計資訊來覆蓋掉這部分proc資訊” 這個Agent是你們自研的？ 方便說下細節嗎？謝謝！
A：簡單點說就是通過攔截系統和程式讀取proc目錄下cpuinfo、meminfo等資源檔，讓它去讀取我們通過CGroup算好的檔案，從而得到正確的容器資源使用方式。
Q：容器式虛擬機器和虛擬機器式容器之間，在業務上落地方案是怎麼樣的，傾向於哪個？
A：因為我們有虛擬機器的曆史包袱，所以落地方案上會選擇虛擬機器式容器， 如果沒有曆史包袱，直接可以上容器。
Q：容器有分有狀態和無狀態麼，容器如果是有狀態的容器分布式儲存是怎麼處理的呢？
A：有狀態的容器儲存有兩種方式：一種是將本地目錄掛載到容器，一種是在容器裡面掛載分布式儲存。
Q：請問一下容量系統主要用來監控哪些裝置？有沒有容量不足會提前預知的功能？
A：監控業務資源是使用方式。業務容量不足或者容量浪費都會有預警。
以上內容根據2016年10月25日晚群分享內容整理。分享人
林鐘洪，2014年加入魅族研發中心，任營運架構師，負責魅族雲平台虛擬化及魅族日誌平台研發，主要包括：KVM虛擬化，Docker容器化、分布式儲存、集中式日誌系統。 DockOne每周都會組織定向的技術分享，歡迎感興趣的同學加：liyingjiesz，進群參與，您有想聽的話題或者想分享的話題都可以給我們留言。
