EC2容器服務(wù)(ECS)是亞馬遜web服務(wù)(AWS)新發(fā)布的一款產(chǎn)品。
ECS的目的是讓Docker容器變的更加簡(jiǎn)單，它提供了一個(gè)集群和編排的層，用來(lái)控制主機(jī)上的容器部署，以及部署之后的集群內(nèi)的容器的生命周期管理。
ECS是諸如Docker Swarm,Kubernetes,Mesos等工具的替代，它們工作在同一個(gè)層，除了作為一個(gè)服務(wù)來(lái)提供。這些工具和ECS不同的地方在于，前者需要你自己來(lái)部署和管理，而ECS是“作為服務(wù)”來(lái)提供的。
ECS是基于一種專(zhuān)有的集群技術(shù)，而不是通過(guò)諸如Docker Swarm,Kubernetes,Mesos等引擎實(shí)現(xiàn)的。這可以和Google容器引擎(GCE)作一對(duì)比，GCE后臺(tái)使用的就是基于Kubernetes的。
我們?yōu)槭裁葱枰萜骶幣牛?/strong>
由ECS，Swarm，或者Kurbernetes所提供的容器編排這一層，在整個(gè)部署和運(yùn)行基于容器的應(yīng)用程序的整個(gè)藍(lán)圖中占有非常重要的位置。
首先，我們?yōu)榱丝蓴U(kuò)展性需要容器組成集群。隨著我們負(fù)載的增長(zhǎng)，我們需要增加更多的容器，橫向的擴(kuò)展它們，跨服務(wù)器來(lái)并行的處理更高的負(fù)載。
第二，我們需要組建容器集群來(lái)保證健壯性和高可用性。當(dāng)一臺(tái)主機(jī)或一個(gè)容器失效時(shí)，我們希望容器可以重新構(gòu)建，或許是在另外一臺(tái)健康的主機(jī)上重新啟動(dòng)，從而讓整個(gè)系統(tǒng)不會(huì)受到任何的影響。
最后，編排層的工具所提供的一個(gè)重要功能就是抽象，讓開(kāi)發(fā)者遠(yuǎn)離具體的底層實(shí)現(xiàn)細(xì)節(jié)。在容器化的世界中，我們毋需關(guān)心每個(gè)獨(dú)立的主機(jī)，只需要關(guān)注我們期望的容器有多少在運(yùn)行，在‘適當(dāng)?shù)牡胤?rsquo;運(yùn)行。編排和集群工具為我們做這些，讓我們能夠輕松的將容器部署到集群中，而且還能夠計(jì)算出最佳的調(diào)度方式，從而決定容器應(yīng)該運(yùn)行在哪些主機(jī)上。
設(shè)計(jì)健壯性和高性能分布式集群系統(tǒng)的難度是非常大的。所以諸如Kubernetes和Swarm這樣的工具讓我們自己毋需去構(gòu)建集群。ECS借此更進(jìn)一步，通過(guò)簡(jiǎn)化編排層的設(shè)置、運(yùn)行和管理來(lái)實(shí)現(xiàn)毋需人工參與?；诖司壒?，ECS無(wú)疑是哪些使用容器來(lái)運(yùn)行應(yīng)用的開(kāi)發(fā)者們應(yīng)該密切關(guān)注的項(xiàng)目。
ECS架構(gòu)
ECS并非是一個(gè)黑匣子的服務(wù)，它運(yùn)行在你的EC2服務(wù)實(shí)例中，你可以使用SSH登錄，像管理其它的EC2服務(wù)一樣進(jìn)行管理。
在集群中的EC2服務(wù)均會(huì)運(yùn)行著一個(gè)ECS代理，ECS代理是一個(gè)連接主機(jī)到中心的ECS服務(wù)的輕量級(jí)進(jìn)程。ECS代理響應(yīng)主機(jī)注冊(cè)到ECS服務(wù)，且掌控所有的請(qǐng)求，用于容器的部署或者是諸如啟動(dòng)／停止容器之類(lèi)的生命周期事件。順便說(shuō)一下，使用go實(shí)現(xiàn)的ECS代理已經(jīng)開(kāi)源。
當(dāng)創(chuàng)建一個(gè)新的服務(wù)器時(shí)，我們既可以選擇手動(dòng)的配置ECS代理，也可以選擇使用預(yù)構(gòu)建的已經(jīng)配置完畢的AMI鏡像。
通過(guò)亞馬遜CTO Werner Vogels的博客,我們得知集中的服務(wù)已經(jīng)邏輯上分為集群管理和在主機(jī)上控制容器部署的調(diào)度。這背后的緣由就是讓容器的調(diào)度成為可插拔式的，所以我們甚至可以使用其它的調(diào)度器，例如Mesos或者是其它開(kāi)發(fā)者自定義的調(diào)度器。自定義調(diào)度器的文檔在本文撰寫(xiě)時(shí)還在開(kāi)發(fā)當(dāng)中，但是我們可以閱讀此博客以及參考其源代碼，這是目前為止最佳的參考實(shí)踐。
下面的示意圖很好的演示了ECS集群的邏輯層次：容器實(shí)例包含多個(gè)任務(wù)，任務(wù)包含多個(gè)容器，EC2容器實(shí)例集群可以分散到多個(gè)可用區(qū)域中，Elastic Load Balancers可以用于跨任務(wù)的動(dòng)態(tài)分布負(fù)載。此圖可以幫助讀者在閱讀接下來(lái)的內(nèi)容整理思路。
服務(wù)和任務(wù)
在ECS中，Docker負(fù)載被描述為任務(wù)。
一個(gè)任務(wù)本質(zhì)上是定義了一個(gè)或多個(gè)容器，其中包括你打算運(yùn)行的容器的名稱（和Docker Hub的名稱保持一致），以及在容器實(shí)例啟動(dòng)時(shí)相應(yīng)的端口和磁盤(pán)卷的映射信息。
當(dāng)任務(wù)運(yùn)行時(shí)，則啟動(dòng)了底層的容器。當(dāng)所有的容器進(jìn)程完成使命時(shí)，任務(wù)也就結(jié)束了。任務(wù)既可以是很短的也可以是長(zhǎng)時(shí)間運(yùn)行的，舉例來(lái)說(shuō)，提供一個(gè)數(shù)據(jù)處理任務(wù)的短的事件驅(qū)動(dòng)，或者是一個(gè)web服務(wù)進(jìn)程。
這里需要提醒一件事情，那就是架構(gòu)上給定的一個(gè)任務(wù)，其所有的容器均運(yùn)行在同一臺(tái)主機(jī)中。如果我們打算定位容器的話，那么就使用在同一個(gè)任務(wù)下來(lái)組織它們的方法來(lái)實(shí)現(xiàn)。如果我們打算將服務(wù)運(yùn)行在不同的主機(jī)，我們則僅需定義多個(gè)任務(wù)來(lái)實(shí)現(xiàn)控制即可。初看這似乎是一種約束，但最終它給我們的和Kubernetes pods一樣的對(duì)容器定位在一定程度的控制能力。
為了說(shuō)明上述問(wèn)題，如下面截圖所示，我們可以看到定義了一個(gè)特定的任務(wù)，此任務(wù)擁有一個(gè)容器，容器托管nginx web服務(wù)。
除了任務(wù)之外，服務(wù)是ECS概念中排名第二重要的。一個(gè)服務(wù)是給定一個(gè)任務(wù)所請(qǐng)求運(yùn)行的特定的實(shí)例數(shù)量。舉例來(lái)說(shuō)，如果我們有一個(gè)如上述所定義的運(yùn)行nginx web服務(wù)容器的任務(wù)的話，我們則要定義一個(gè)服務(wù)，來(lái)請(qǐng)求3個(gè)或更多的實(shí)例組成集群，從而完成web服務(wù)的任務(wù)。
服務(wù)是ECS如何提供彈性的保證。當(dāng)一個(gè)服務(wù)啟動(dòng)后，服務(wù)就會(huì)監(jiān)控其中的任務(wù)是否是活動(dòng)的，實(shí)例的數(shù)量是否正確，以及其中容器的數(shù)量是否正常。如果任務(wù)停止運(yùn)行了，或者是無(wú)響應(yīng)了，又或者是出現(xiàn)問(wèn)題了。服務(wù)就會(huì)請(qǐng)求啟動(dòng)更多的任務(wù)，以及必要的話清理任務(wù)。
下面截圖所示，在集群中一個(gè)nginx服務(wù)被定義為3個(gè)運(yùn)行的任務(wù)。這些任務(wù)個(gè)個(gè)都處于運(yùn)行狀態(tài)。
