每隔幾年，就會出現(xiàn)一種革命性的新技術來改變IT世界的工作方式。十年之前，虛擬化技術的出現(xiàn)鋪平了通往云服務和云計算的道路?，F(xiàn)在，容器及其創(chuàng)造出的充滿活力的生態(tài)系統(tǒng)勁頭正猛。本文將向你展示三星如何基于Mesos和Docker管理和運行物聯(lián)網規(guī)模的計算基礎設施的。

容器革命很大程度上要歸因于DevOps的進步，更要歸因于Docker的成功。容器是對流行的『微服務架構』的完美補充，正因如此，這也使得將軟件應用設計為獨立部署的服務成為可能。在三星，我們已經完全接受了這種新趨勢。

SAMI是個非常復雜的平臺，很多部分都是可替換和移動的。在撰寫本文時，我們已有40多項內部服務（增加中），以及目前最流行的一些后端技術，其中包括NoSQL數據存儲、消息代理、服務注冊表、配置存儲、圖形數據庫、HDFS、大數據處理器、內存緩存和傳統(tǒng)SQL數據庫。這個平臺仍在不斷發(fā)展，我們會不斷引進新技術和應用來應對物聯(lián)網所需的大數據處理過程中出現(xiàn)的問題和挑戰(zhàn)。我們負責設計和管理支持其工作負載的基礎設施，確?？蓴U展性、安全性和一致性，同時還要保持敏捷！

大約在一個月之前，我們把SAMI平臺搬到Mesos和Docker上運行?？梢园袽esos看做數據中心的內核，它抽象了所有的底層硬件和虛擬機，讓你把數據中心當成一個超級大電腦來編程。同時，Docker作為容器化技術，簡化了打包和搬運應用的方式。

這真正改變了我們對應用打包、部署、協(xié)調和監(jiān)督的思考方式。這要求我們對自動化流水線進行徹底的重新設計，引進令人振奮的新技術的同時，也要淘汰許多老工具。

向容器技術推進

在容器成為家喻戶曉的熱門話題之前，我們曾有一個相當不錯的全面自動化流水線，其核心是我們的配置管理（CM）系統(tǒng)。從配置到符合應用程序的部署，一切都通過我們的配置管理工具實現(xiàn)自動化。

但隨著我們平臺的增長，這些工具的缺點開始逐漸暴露出來。為了支持和衡量如SAMI般日益復雜的系統(tǒng)，一些新功能被迅速推出，我們意識到，我們急切需要一種新方法來部署和管理日益增多的微服務。

下面是一些需要解決的限制問題（注：這些都是CM工具中常有的陷阱，而未必是執(zhí)行時常見的）：

節(jié)點/機器專屬角度（Node/Machine-specific perspective）

聲明：Run ‘this’ on ‘that’ VM

靜態(tài)分區(qū)

多租戶需要手動配置

資源浪費

無資源隔離

配置和部署時間長

沒有依賴/工作流管理：可以不執(zhí)行“僅當部署Service-A之后且通過健康檢查再部署Service-B”

無自愈功能：機器宕機，操作員需手動更換死亡節(jié)點

異構基礎框架困難：幾乎所有的cookbook/module/playbook都不能跨越兩個發(fā)行版本

陡峭的學習曲線

要在物聯(lián)網規(guī)模下運行一個現(xiàn)代平臺，這些限制是我們不可接受的。

用Mesos和Docker過渡解決問題

開始，我們決定建立一個自動化的流水線，這將使以下成為可能：

構建有容錯、自愈功能的基礎設施。

使用現(xiàn)代集群管理/分布式初始化系統(tǒng)，確保應用程序定義副本始終都在運行。

使用Git作為唯一來源：所有工作配置都存放在Git中，這能降低建立一個修改管理/審計系統(tǒng)的難度。

把應用軟件打包成Docker鏡像，便于快速部署。

建立一個快速反應的協(xié)調系統(tǒng)。

把現(xiàn)有的基礎設施接入流水線。

最后，組建一個持續(xù)交付平臺。它能快速強大地完成工程（包括QA）進行生產部署。這是我們的使命所在，它能把我們從日常運營的開銷和冗雜中解放出來，把時間精力集中在發(fā)展新的服務和改善流程上，這樣，才能為組織貢獻更多價值。

為了實現(xiàn)以上目標，我們提出了以下設計：

高可用性（HA）Mesos集群將提供數據中心（DC）級別的抽象，正如典型操作系統(tǒng)提供工作站級別的抽象一樣。DC是一個新型因素。

Mesos將作為一個DC-wide資源管理器。

構建系統(tǒng)將會把應用程序打包成Docker鏡像。之后這些鏡像將會被push到Docker內部私有庫。

Marathon將作為DC-wide 初始系統(tǒng)/進程管理器。所有的長時運行作業(yè)會通過Marathon進行部署和管理。

Chronos將作為DC-wide cron系統(tǒng)。所有的短時/批處理作業(yè)會通過Chronos進行調度管理。

所有Marathon和Chronos的作業(yè)配置都將被check到Git?；A設施中的任何改動都會被追查到。

Git2Consul將用于同步Git倉庫到Consul的KV存儲，同時Consul的handler會監(jiān)視KV的改動并通過REST API報告給Marathon和Chronos。

Consul將繼續(xù)作為服務注冊表。用Registrator監(jiān)聽Docker事件和私有庫的改動并報告給Consul。這些最終將被Mesos-DNS所取代。

我們現(xiàn)在的工作流程大致如下幾步：

　　1. 當開發(fā)者提交時，Git Post-Receive Hook 會開啟Jenkins build。

2. Jenkins接著使用maven-dockr插件進行創(chuàng)建、標記和push Docker鏡像到Docker私有庫中。它也會在Consul的KV中更新鏡像標記。

3. Consul Handler監(jiān)視KV的更改并更新包含Marathon作業(yè)配置的Git repo。

4. Git2Consul獲取這些更改并將repo同步到Consul的另一個KV。

5. 另一個Handler監(jiān)視這個KV，將作業(yè)配置發(fā)送給Marathon。如果該服務尚未注冊，創(chuàng)建新服務。否則更新該服務。

6. Marathon作為集群管理者和分布式初始化系統(tǒng)。它用API調用Docker daemon來啟動容器。

7. Registrator（一個小型服務）監(jiān)聽Docker事件，更新Consul的服務目錄。

8. 服務注冊表的任何改動都能被Consul-Template捕捉到，這將刷新所有配置（主要是HAProxy）并重新加載相關服務。

如上所述，無需人工干預，應用程序會自動創(chuàng)建、打包和部署到各種環(huán)境中。如果你認真理一遍就會發(fā)現(xiàn)整個審計線是這樣的：每一步都被記錄在了Git上。這點非常重要，特別是你的團隊規(guī)模很大、堆棧復雜且有許多活動部分的時候。另外，如果每天進行各種版本服務的工程中的每個人都能做到這一點，你就能懂得為何部署中每一步的記錄是如此重要了。

通知（通過郵件、聊天室等）會及時的發(fā)送給團隊，告訴他們，他們的作業(yè)是成功還是失敗。在快速反饋回路中，這些結果能完全消除來自方程的Ops！

有了Mesos，我們就能更高效地運行基礎設施，控制云計算支出在預算范圍內。我們能夠實現(xiàn)更高效的資源利用率，而且由于資源隔離，我們能夠將多種服務（在Docker容器中運行）裝在同一臺主機上，建立真正意義上的多租戶部署，借助Cassandra and Kafka之類后端，其中的應用程序可以實現(xiàn)共存。

回望我們已經實現(xiàn)的

塵埃落定，從成立到實現(xiàn)生產，我們總共才花了三個月的時間。沒錯，我們動作就是快！但不論從管理還是技術角度上來說，前進的道路上必將迎來新的挑戰(zhàn)和阻礙。

新用戶需要了解很多Mesos/Docker世界的很多新概念和細微差別。而擺脫對應用、主機和數據中心的傳統(tǒng)思維方式不是件容易的事情。這需要一些內驅力來使不同的群體接受新概念。

從技術角度來說，盡管已有巨大的工作量，容器的生態(tài)環(huán)境仍不成熟。因此，我們在設計系統(tǒng)時要考慮這個因素，保證流水線的組織部分可以更改。更重要的是，你要將基礎設施設計成模塊化的，這樣你才能更加方便地根據需求進行工具和技術的更換。

結論

有了上文中我提到的新流水線，我們可以更快的提交代碼，更易于擴展，實現(xiàn)多租戶，確保最佳的資源利用率。我們能在一些預生產堆棧里的繁重工作負載中實現(xiàn)將近80%的資源利用率。真難以置信，因為行業(yè)標準中的數據中心資源利用率只有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團隊對新模式的轉變感到非常振奮。但它涉及到大量的研究、學習和努力的工作，才把我們帶到這個層次。如果你們之中有人想要深入研究，一定要記住，新系統(tǒng)需要的改變與你之前做過的東西相差很大。到目前為止，我們對結果已經感到非常開心了，而且我們相信這些變化能把我們指引到對的方向！