1008
業務運維如何做？Docker集群、監控來幫忙
在2017遊戲行業全球同服和安全攻防技術沙龍上，來自心動網絡的吳涵分享了《淺談Docker業務運維》。他主要從運維職責（部署階段、運行階段）、潛在的問題、選擇Docker的原因、Docker集群、Docker監控、Docker未來六個方麵以運維人員的角度分享了Docker的使用經驗。
以下內容根據直播視頻整理而成。
運維職責
大家對於Docker已經不陌生了，Docker產品在很多領域都比較火。心動網絡從2015年開始接觸Docker，發現Docker的整個產品模式比較適合遊戲領域公司的快速發展模式，包括打包部署和發布都契合需求。
部署階段
以前（比較大眾的時期），運維同事都需要做一些部署階段的工作，比如係統安裝、編譯環境、代碼上傳、執行編譯、啟動腳本。這些工作都需要運維人員在線上進行大量的手動操作，中間會出現許多問題需要人工進行定位和排查。
運行階段
在部署完成之後，運維人員需要做服務運行階段的工作和維護，包括配置更新、代碼更新、係統更新、監控采集、故障處理。這些都是在整個運行時期，運維人員需要時刻關注的問題。
潛在問題
在接觸Docker之前，心動網絡也是以傳統模式來部署業務和維護業務的，也遇到很多潛在問題。比如：編譯環境迭代更新導致庫版本升級使編譯出現兼容性問題；在機器數量比較龐大的情況下去上傳代碼，導致代碼有泄露的風險；開發部、安裝部的版本出現問題，導致代碼編譯無法通過；在編譯完成之後需要把整個服務打包，需要寫啟動腳本使其每次都能自己運行；代碼管理方麵，用到SVN或者GIT倉庫管理工具，有辦法去切換版本，但是發布二進製服務的時候需要很麻煩的做很多標簽來定位服務對應的維護版本；服務運行之後，監控服務的運行狀態比較困難；做大量工作之後發現最終高投入換來了低效率。
為何選擇Docker？
在內部的測試環境使用Docker之後，發現Docker有很多優勢：一次打包，各處運行；編譯和運行環境分離；服務端隻需安裝Docker運行組件；Docker鏡像標簽用作版本管理；API調度管理容器，實時監控容器的運行狀態；多種語言支持的SDK，可以與業務深度結合；部署模式統一，易於維護。使用Docker之後，大幅減少了在部署和監控上的精力，把更多的時間花在對接更高級的業務運行模式上。底層的很多東西直接使用Docker，時間成本大幅減少。
Docker集群
在機器節點非常龐大的情況下，由於Docker是單機的服務，所以會出現一些問題。心動網絡的測試環境都是以小量機器為規模，不是特別注重節點之間的管理，但是上線之後，在龐大的集群（以百、千為計量單位）中需要一個能夠統一管理的模式，即需要Docker集群模式。
在對比之後，最終選擇了Docker內置的集群模式Docker Swarm。Swarm在Docker1.12之前是以獨立進程的方式運行的。在Docker1.12之後，官方把Swarm集群模式集成在Docker Engine中。Swarm采用去中心化設計，分為很多角色，比如Manager和Worker，在各個節點之間的通信都是TS加密的，可以保障一定的通信安全。Swarm支持服務編排，可以把多個服務打包成一個Application來發布，比如采用Web+DB的模式。可伸縮性是指，比如定義集群裏的一個啟動數量為10，Swarm會根據預定的啟動值以自動調度的策略來保證整個集群的預設值能夠始終滿足需求。Swarm具有自愈能力，很多服務是無狀態的或者微服務，在一個集群裏會有很多的容器，其實本地是不留存信息的，而是集中化的存在緩存或者數據庫中，這些容器可以看作是一個Runtime環境，隻負責處理不負責存儲，自愈能力是針對這些服務出現Crash之後可以自動的在其他可用節點上再去啟動新的容器來彌補已經Crash的容器，保證整個集群裏的數量符合預期值。Swarm支持滾動更新，當滾動失敗或者更新失敗之後，需要進行回退，但是有些回退的操作比較複雜，需要回退所有的配置文件，基於Docker的滾動更新是比較方便的，因為是作為容器來發布，更新失敗後，隻要上一個版本的容器還存在就可以無縫切換過來，整個Runtime的環境可以保證一致。
Docker監控
關於Docker監控，官方一直沒有給出一個比較好的方法，反而是很多第三方的開源項目在實現Docker監控。此時就需要對Docker API的調度非常熟悉，但是很多時候大家隻是想能夠很快的起一個服務能夠調用Docker的API把數據存儲在自己的存儲中，通過前端的頁麵轉接出來。
Docker本地CLI有Docker state指令，可以關注比較通用的監控參數，包括CPU、內存、IO使用率、網絡使用率等。在有一定研發能力的基礎上，可以考慮使用Docker Remote API自己去抓監控數據，通過某種方式展現出來。Google Cadvisor是比較成熟的第三方項目，可以和Docker無縫貼合，能夠監控單台物理機上麵所有容器的狀態，其本身是不存儲數據的，但是支持加載後端的存儲把數據寫到存儲中。Shipyard是Docker的一個核心成員開發的，帶UI，本身不是做監控的，是作為Docker Front-end Web前端去管理Docker，也包含了對Docker API的調用，可以作為一個簡單的監控工具來使用。
Docker未來
Docker並不是完美無缺的，在以下方麵期待改進：Docker對高密度寫入場景並不是特別友好，不是作為存儲直接寫入數據到容器中，還需要通過加載第三方的Volume或者本地的主機目錄關聯到容器裏麵來實現，對數據庫寫入優化不適合；Docker Daemon API是中心化設計的，使用時如果Docker Daemon發生Crash，會導致所有的API不可用，此時不管通過命令行還是remote API都不能管理上麵的容器，隻能非常麻煩的重啟Docker Daemon，造成業務的閃斷或者各種各樣的問題；API是完全沒有驗證的，隻要抓到API地址就可以通過特定的協議交互，在內網環境問題不大，但是在外網開放API的風險成本比較高。最後更新：2017-04-19 09:30:42