來自三星的基于Docker和Mesos的容器解決方案
每隔幾年，就會出現一種革命性的新技術來改變IT世界的工作方式。十年之前，虛擬化技術的出現鋪平了通往云服務和云計算的道路。現在，容器及其創造出的充滿活力的生態系統勁頭正猛。本文將向你展示三星如何基于Mesos和Docker管理和運行物聯網規模的計算基礎設施的。
容器革命很大程度上要歸因于DevOps的進步，更要歸因于Docker的成功。容器是對流行的『微服務架構』的***補充，正因如此，這也使得將軟件應用設計為獨立部署的服務成為可能。在三星，我們已經完全接受了這種新趨勢。
SAMI是個非常復雜的平臺，很多部分都是可替換和移動的。在撰寫本文時，我們已有40多項內部服務（增加中），以及目前***的一些后端技術，其中包括NoSQL數據存儲、消息代理、服務注冊表、配置存儲、圖形數據庫、HDFS、大數據處理器、內存緩存和傳統SQL數據庫。這個平臺仍在不斷發展，我們會不斷引進新技術和應用來應對物聯網所需的大數據處理過程中出現的問題和挑戰。我們負責設計和管理支持其工作負載的基礎設施，確保可擴展性、安全性和一致性，同時還要保持敏捷！
大約在一個月之前，我們把SAMI平臺搬到Mesos和Docker上運行。可以把Mesos看做數據中心的內核，它抽象了所有的底層硬件和虛擬機，讓你把數據中心當成一個超級大電腦來編程。同時，Docker作為容器化技術，簡化了打包和搬運應用的方式。
這真正改變了我們對應用打包、部署、協調和監督的思考方式。這要求我們對自動化流水線進行徹底的重新設計，引進令人振奮的新技術的同時，也要淘汰許多老工具。
向容器技術推進
在容器成為家喻戶曉的熱門話題之前，我們曾有一個相當不錯的全面自動化流水線，其核心是我們的配置管理（CM）系統。從配置到符合應用程序的部署，一切都通過我們的配置管理工具實現自動化。
但隨著我們平臺的增長，這些工具的缺點開始逐漸暴露出來。為了支持和衡量如SAMI般日益復雜的系統，一些新功能被迅速推出，我們意識到，我們急切需要一種新方法來部署和管理日益增多的微服務。
下面是一些需要解決的限制問題（注：這些都是CM工具中常有的陷阱，而未必是執行時常見的）：
- 節點/機器專屬角度（Node/Machine-specific perspective）
- 聲明：Run ‘this’ on ‘that’ VM
- 靜態分區
- 多租戶需要手動配置
- 資源浪費
- 無資源隔離
- 配置和部署時間長
- 沒有依賴/工作流管理：可以不執行“僅當部署Service-A之后且通過健康檢查再部署Service-B”
- 無自愈功能：機器宕機，操作員需手動更換死亡節點
- 異構基礎框架困難：幾乎所有的cookbook/module/playbook都不能跨越兩個發行版本
- 陡峭的學習曲線
要在物聯網規模下運行一個現代平臺，這些限制是我們不可接受的。
#p#
用Mesos和Docker過渡解決問題
- 開始，我們決定建立一個自動化的流水線，這將使以下成為可能：
- 構建有容錯、自愈功能的基礎設施。
- 使用現代集群管理/分布式初始化系統，確保應用程序定義副本始終都在運行。
- 使用Git作為唯一來源：所有工作配置都存放在Git中，這能降低建立一個修改管理/審計系統的難度。
- 把應用軟件打包成Docker鏡像，便于快速部署。
- 建立一個快速反應的協調系統。
- 把現有的基礎設施接入流水線。
- ***，組建一個持續交付平臺。它能快速強大地完成工程（包括QA）進行生產部署。這是我們的使命所在，它能把我們從日常運營的開銷和冗雜中解放出來，把時間精力集中在發展新的服務和改善流程上，這樣，才能為組織貢獻更多價值。
為了實現以上目標，我們提出了以下設計：
- 高可用性（HA）Mesos集群將提供數據中心（DC）級別的抽象，正如典型操作系統提供工作站級別的抽象一樣。DC是一個新型因素。
- Mesos將作為一個DC-wide資源管理器。
- 構建系統將會把應用程序打包成Docker鏡像。之后這些鏡像將會被push到Docker內部私有庫。
- Marathon將作為DC-wide 初始系統/進程管理器。所有的長時運行作業會通過Marathon進行部署和管理。
- Chronos將作為DC-wide cron系統。所有的短時/批處理作業會通過Chronos進行調度管理。
- 所有Marathon和Chronos的作業配置都將被check到Git。基礎設施中的任何改動都會被追查到。
- Git2Consul將用于同步Git倉庫到Consul的KV存儲，同時Consul的handler會監視KV的改動并通過REST API報告給Marathon和Chronos。
- Consul將繼續作為服務注冊表。用Registrator監聽Docker事件和私有庫的改動并報告給Consul。這些最終將被Mesos-DNS所取代。
我們現在的工作流程大致如下幾步：
1. 當開發者提交時，Git Post-Receive Hook 會開啟Jenkins build。
2. Jenkins接著使用maven-dockr插件進行創建、標記和push Docker鏡像到Docker私有庫中。它也會在Consul的KV中更新鏡像標記。
3. Consul Handler監視KV的更改并更新包含Marathon作業配置的Git repo。
4. Git2Consul獲取這些更改并將repo同步到Consul的另一個KV。
5. 另一個Handler監視這個KV，將作業配置發送給Marathon。如果該服務尚未注冊，創建新服務。否則更新該服務。
6. Marathon作為集群管理者和分布式初始化系統。它用API調用Docker daemon來啟動容器。
7. Registrator（一個小型服務）監聽Docker事件，更新Consul的服務目錄。
8. 服務注冊表的任何改動都能被Consul-Template捕捉到，這將刷新所有配置（主要是HAProxy）并重新加載相關服務。
如上所述，無需人工干預，應用程序會自動創建、打包和部署到各種環境中。如果你認真理一遍就會發現整個審計線是這樣的：每一步都被記錄在了Git上。這點非常重要，特別是你的團隊規模很大、堆棧復雜且有許多活動部分的時候。另外，如果每天進行各種版本服務的工程中的每個人都能做到這一點，你就能懂得為何部署中每一步的記錄是如此重要了。
通知（通過郵件、聊天室等）會及時的發送給團隊，告訴他們，他們的作業是成功還是失敗。在快速反饋回路中，這些結果能完全消除來自方程的Ops！
有了Mesos，我們就能更高效地運行基礎設施，控制云計算支出在預算范圍內。我們能夠實現更高效的資源利用率，而且由于資源隔離，我們能夠將多種服務（在Docker容器中運行）裝在同一臺主機上，建立真正意義上的多租戶部署，借助Cassandra and Kafka之類后端，其中的應用程序可以實現共存。
#p#
回望我們已經實現的
塵埃落定，從成立到實現生產，我們總共才花了三個月的時間。沒錯，我們動作就是快！但不論從管理還是技術角度上來說，前進的道路上必將迎來新的挑戰和阻礙。
新用戶需要了解很多Mesos/Docker世界的很多新概念和細微差別。而擺脫對應用、主機和數據中心的傳統思維方式不是件容易的事情。這需要一些內驅力來使不同的群體接受新概念。
從技術角度來說，盡管已有巨大的工作量，容器的生態環境仍不成熟。因此，我們在設計系統時要考慮這個因素，保證流水線的組織部分可以更改。更重要的是，你要將基礎設施設計成模塊化的，這樣你才能更加方便地根據需求進行工具和技術的更換。
結論
有了上文中我提到的新流水線，我們可以更快的提交代碼，更易于擴展，實現多租戶，確保***的資源利用率。我們能在一些預生產堆棧里的繁重工作負載中實現將近80%的資源利用率。真難以置信，因為行業標準中的數據中心資源利用率只有8%左右！
舉個例子，這里是高工作負載下我們預生產堆棧中的一個Mesos集群資源利用率情況：
- curl http://10.20.0.201:5050/metrics/snapshot
- {
- ..
- "master\/cpus_total":247,"master\/cpus_used":192,
- "master\/mem_total":583573,"master\/mem_used":415378,
- ..
- }
總之，SAMI團隊對新模式的轉變感到非常振奮。但它涉及到大量的研究、學習和努力的工作，才把我們帶到這個層次。如果你們之中有人想要深入研究，一定要記住，新系統需要的改變與你之前做過的東西相差很大。到目前為止，我們對結果已經感到非常開心了，而且我們相信這些變化能把我們指引到對的方向！
