【編者的話】本文作者重點介紹了如何使用docker、coreos、mesos、vulcand、對象存儲來部署一個可擴充的web應用，他首先介紹了 為什麼要選擇這些工具以及與其它工具相比這些工具的優勢。緊接着，他通過實際案例示範了整個部署過程，圖文并茂，推薦閱讀。
<a target="_blank"></a>
讓我們先來讨論一下為什麼我決定使用這些軟體來展示如何建立一個可擴充的web基礎架構。
那問題來了，為啥要選擇linux容器？因為相比于虛拟機，linux容器擁有更低的計算和存儲開銷。
以一個單元的形式自動更新整個系統，而不是一個包接着一個包的更新（如果你的基礎設施沒有spof，甚至要重新開機系統）
包含用于發現服務的etcd，也使用vulcand（甚至設定中需要mesos）
包含了systemd和fleet，一個可以以一個init系統呈現你整個叢集的工具。在這個設定中我不使用fleet，但是在其它方面我有使用它，比如幾秒内啟動elastic search叢集。
我看到有關如何部署容器或虛拟機的很多教程，但我總是驚訝地看到，他們很少涉及基礎設施的負載均衡部分。
在我看來，負載均衡是一個可擴充的web應用架構的重要組成部分。如果使用者不能正常通路你的應用，那還搞什麼自動化？
有三種不同的方式來自動化部署docker容器，具體如下：
kubernetes：這可能是最佳的選擇之一，但現在kuernetes還太年輕。
mesos：mesos目前已經支援docker，它已經是一個相對穩定的平台，并且可以用來部署其它軟體，例如hadoop。
我們可以通過上面介紹的軟體來部署可擴充和高可用的應用。但是，資料怎麼處理？
結構化的内容可能會被存儲到分布式資料庫中，例如mongodb。非結構化的内容一般會存儲在一個本地檔案系統、nas或者對象存儲。
本地檔案系統并不适合現在的場景，因為容器可能會被部署到叢集的任何一個節點上。
然而，對象存儲卻可以在任何容器的任何應用中使用，并且是高可用的，因為我們使用了負載均衡器，它不需要任何配置，這也可以加快應用程式的開發周期。為什麼了？因為開發者不需要考慮資料的存儲方式、目錄結構管理等。
我已經開發了一個web應用程式，它展示了一個應用程式如何不通過資料路徑處理上傳和下載下傳，我會在下面運作這個應用程式。
上圖展示了幾個不同的元件，以及我如何設定3個節點的coreos叢集。
1.png
我使用keepalived來確定公共 ip 10.64.231.84是可用的，不管對應在coreos1還是coreos3節點上。
vulcand會運作再每個節點上，以均衡使用者和web應用程式之間的負載，同僚也可以平衡應用程式和不同的vipr節點。
私有的docker registry在coreos1節點上運作，并使用amazon s3 api在vipr上存儲鏡像。
mesos主節點（master）和marathon運作在coreos2節點上。
這裡是我用來建構docker鏡像的dockerfile：
建構鏡像時我使用了--no-cache參數，以確定最新的源代碼是從github上克隆的。
最後，我推送鏡像到docker registry。
我已經指定了一個tag（2.0），以確定叢集中的每個節點都會從docker registry擷取最新版本。
現在，讓我們使用docker鏡像部署一個mesos應用：
當mesos應用程式啟動後，mesos marathon ui就會顯示應用程式的狀态。
2.png
幾秒鐘之後，應用部署成功，docker主機和端口顯示在ui中。
使用在marathon ui顯示的資訊，我可以通路url為http://coreos1.ad.forest:31000的web應用程式。
4.png
當應用程式運作時頁面左上角會顯示容器名稱，用于上載和下載下傳的圖檔的amazon s3終端（endpoint）會顯示在左下角，并表明vipr用于存儲資料。
我們現在可以上傳圖檔了。
5.png
下面是由web應用程式發送到浏覽器的代碼，以讓浏覽器直接上傳圖檔到對象存儲平台。
圖檔直接上傳到對象存儲平台的事實意味着該web應用程式中并沒有資料路徑。也就是說無需部署數百個執行個體應用程式就可以擴充。
這個web應用程式，也可用于顯示所有存儲在相應的amazon s3的圖檔。
6.png
圖檔下方顯示的url表明圖檔可以直接從對象存儲平台下載下傳，而這又意味着web應用程式不是從資料路徑直接下載下傳。
對象存儲是事實上的标準網絡規模應用。
現在，讓我們看看如何能夠從外界通路該web應用程式。
我使用golang開發了一個小工具，同時使用marathon api和etcd api：
找到那些運作的mesos應用程式但卻沒有相對應的在etcd中的vulcand規則，然後建立缺失的規則。
找到那些存在與etdc的vulcand規則中的不再運作的mesos應用，然後删除。
7.png
8.png
其中mesos之美在于它能夠輕松地擴充目前正在運作的應用程式的執行個體數目。
9.png
幾秒鐘後，20個執行個體正在運作。
10.png
我需要再次運作我的工具來更新vulcand規則。
11.jpg
現在，如果我重新整理我的網頁浏覽器，可以看到，在左上角顯示的容器名稱是基于服務的應用程式執行個體發生變化。
12.png
13.png
使用marathon ui或api時，它也可以按比例縮小的執行個體數并再次運作工具來更新vulcand規則。
原文釋出時間：2015-01-28
本文來自雲栖合作夥伴“linux中國”