《CodePicnic的Docker Swarm之路》要點(diǎn)：
本文介紹了CodePicnic的Docker Swarm之路，希望對(duì)您有用。如果有疑問(wèn)，可以聯(lián)系我們。

在CodePicnic,Docker很早就成了基礎(chǔ)設(shè)施的核心部分.從0.11版本開(kāi)始,我們不但看到了Docker的成長(zhǎng),更看到了一整個(gè)相關(guān)生態(tài)的建立.

與此同時(shí),CodePicnic也在發(fā)展,我們有了不同于其他基于容器平臺(tái)的特性.這也導(dǎo)致我們開(kāi)始考慮在可擴(kuò)展并且控制成本的前提下,(使之成為)一個(gè)穩(wěn)定且高效的平臺(tái).

我們的應(yīng)用負(fù)責(zé)以一種簡(jiǎn)單高效的方式來(lái)管理容器平臺(tái).通過(guò)一系列規(guī)則,節(jié)點(diǎn)(裝有Docker引擎的AWS EC2實(shí)例)被選擇來(lái)部署新的容器.另一方面,當(dāng)需求上升時(shí),我們會(huì)通過(guò)AWS終端來(lái)增加節(jié)點(diǎn),并提供給新客戶.為此,我們開(kāi)始尋找一些容器編排系統(tǒng)來(lái)替換我們自身的解決方案.

我們首先選擇的是Kubernetes,這是一個(gè)由Google開(kāi)發(fā)的編排平臺(tái).

對(duì)于管理Docker集群而言,Kubernetes是一個(gè)復(fù)雜但是健壯的方案(可以選擇自動(dòng)擴(kuò)展節(jié)點(diǎn)、容器、監(jiān)視器、日志等).

Kubernetes使用Pod作為容器的通訊層.這就意味著,我們的應(yīng)用和Docker通訊的方式發(fā)生了改變.這里最大的挑戰(zhàn)在于,讓我們的架構(gòu)適應(yīng)Kubernetes的哲學(xué).這可以用書(shū)中的短語(yǔ)(http://kubernetes.io/docs/user-guide/services/)來(lái)概括：

我們的平臺(tái)依賴于持久化組件,這個(gè)事實(shí)促使我們尋找一個(gè)替代方案.

和Kubernetes相比,Docker Swarm是簡(jiǎn)單的：它為一組Docker引擎提供集群能力,并且它能在單個(gè)引擎中管理容器的編排.你可以向Swarm添加自己的Docker基礎(chǔ)架構(gòu),并且它們的API和Docker的API是兼容的,因此我們并不需要對(duì)應(yīng)用有較大的變動(dòng)以開(kāi)始使用它來(lái)管理容器.

如此一來(lái),我們就有了獨(dú)特的關(guān)于Swarm Master的接口,而不是管理N個(gè)Docker實(shí)例.Swarm作為容器化的應(yīng)用運(yùn)行,并負(fù)責(zé)調(diào)度在哪里部署新的容器.策略、約束和親和性共同決定了哪一個(gè)節(jié)點(diǎn)會(huì)被選擇.

雖然遷移簡(jiǎn)單,但是讓Docker Swarm管理集群中成千上萬(wàn)的容器和鏡像會(huì)有性能問(wèn)題,這使得我們修改Swarm的源碼以優(yōu)化容器的創(chuàng)建時(shí)間并避免調(diào)度器上的并發(fā)鎖.在未來(lái)的文章中,我們將會(huì)繼續(xù)討論我們的優(yōu)化.

編排和調(diào)度工作得不錯(cuò),但是監(jiān)控和擴(kuò)展性并不是方案的一部分.

我們的基礎(chǔ)架構(gòu)工作于AWS上,AWS本身已經(jīng)提供了這些問(wèn)題的解決方案.因此,我們開(kāi)始將系統(tǒng)和容器的度量數(shù)據(jù)發(fā)往AWS Cloudwatch.當(dāng)這些數(shù)據(jù)超過(guò)閾值后,一個(gè)警告就會(huì)被發(fā)往AWS Auto Scaling,它會(huì)提供一個(gè)或一個(gè)以上的新實(shí)例.一旦一個(gè)實(shí)例啟動(dòng),它便會(huì)在Docker Compose的協(xié)助下,自動(dòng)注冊(cè)到Docker Swarm.

另一個(gè)集成進(jìn)我們架構(gòu)的Docker特性是多host網(wǎng)絡(luò).這個(gè)特性使得AWS彈性負(fù)載均衡能夠和所有容器通信,無(wú)論它們?cè)谀膫€(gè)節(jié)點(diǎn)上.

Docker v1.1包含了一個(gè)嵌入DNS,它允許提供基于容器名和別名的服務(wù)發(fā)現(xiàn).在早期實(shí)現(xiàn)中,我們需要在host上為新創(chuàng)建的容器開(kāi)啟端口.這樣,應(yīng)用就能和容器通信以告訴終端用戶在哪里工作.如此實(shí)現(xiàn)存在幾個(gè)缺點(diǎn),我們需要記錄端口的使用,并且端口數(shù)量也受每個(gè)節(jié)點(diǎn)自身的限制(大約65535或更少一點(diǎn)).如今,我們有Nginx容器在內(nèi)部將請(qǐng)求路由到正確的容器和端口,這樣就不需要通過(guò)節(jié)點(diǎn)開(kāi)放多端口了.

圍繞著這個(gè)基礎(chǔ)設(shè)置,我們添加了額外的組件來(lái)自動(dòng)管理任務(wù).我們用來(lái)提供給不同終端的所有基礎(chǔ)鏡像(Ruby、Python、PHP、Swift等)都存儲(chǔ)在Docker Registry.

我們使用Jenkins來(lái)構(gòu)建鏡像并上傳到Registry.我們通過(guò)Jenkins使用的Ansible腳本,來(lái)更新AWS Auto Scaling提供新實(shí)例時(shí)所使用的AWS鏡像.

關(guān)于監(jiān)控方案,cAdvisor運(yùn)行在所有的節(jié)點(diǎn)中以收集來(lái)自容器的狀態(tài).我們使用InfluxData來(lái)收集度量信息,例如正在運(yùn)行的容器,執(zhí)行Docker命令的時(shí)間消耗等.這些度量信息反過(guò)來(lái)由Grafana顯示.

想象一下!未來(lái)會(huì)如何?我們已經(jīng)嘗試了新的Docker發(fā)行版,但是惡心的bug使得我們無(wú)法升級(jí)自己的平臺(tái),因此我們目前正在等待Docker v1.12以及未來(lái)的發(fā)行版.我們開(kāi)始向自己的Swarm集群添加基于Windows的Docker引擎.不久前,Docker發(fā)布了Swarmkit(https://github.com/docker/swarmkit),這是一個(gè)用于提供Kubernetes類似特性的編排平臺(tái).

正如我們之前說(shuō)過(guò),Docker和我們一樣正在發(fā)展.我們將會(huì)繼續(xù)添加最好的工具來(lái)改進(jìn)我們的平臺(tái),并向用戶盡可能提供更好的體驗(yàn).

文章出處：Docker(公眾號(hào)ID：Dockerone)

轉(zhuǎn)載請(qǐng)注明本頁(yè)網(wǎng)址：
http://www.fzlkiss.com/jiaocheng/4475.html