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