[[142150]]

以下完整的對話記錄，U 為提問者，P為Paul Biggar(Founder of CircleCI)。

U：Hi，我老板讓我采訪你，我聽說你是個Web專家?

P：是啊，我現在專攻分布式系統。我剛從ContainerCamp和Gluecon回來，打算下周參加DockerCon。真的很興奮，整個行業正朝著 - 讓一切更簡單，更可靠的方式前進。這就是未來!

U：Cool，我現在構建一個簡單的Web應用程序 —— 一個使用Rails的普通CRUD應用程序，將會部署到Heroku的。給我提些建議?

P：Oh，不。這是老方式。Heroku已死 —— 沒有人會再使用它了。你現在需要使用Docker。這才是未來。

U：Oh，好的。Docker是什么?

P：Docker是一種新的容器化的方式。就像LXC，但Docker也是一種打包形式、分發平臺和工具，它可以讓分布式系統的構建變得非常容易。

U：容器化 —— 那是什么?什么是LXE?

P：是LXC。你可以把它想成chroot的升級版。

U：什么是 cher-oot?

P：好，看看。Docker。集裝箱。這就是未來。這就像虛擬化，但速度更快、更廉價。

U：Oh，就像Vagrant。

P：不，Vagrant已死。一切都將會被容器化，這就是未來。

U：好了，所以我不需要知道虛擬化什么嗎?

P：不，你仍然需要虛擬化，因為容器目前沒有提供充分的安全保證。所以，如果你想在多租戶環境中運行應用，你仍然需要沙箱。

U：好吧，我開始有點糊涂了。讓我們一起回顧下。現在有一個像虛擬化一樣的東西，被稱為容器。我可以在Heroku上使用它嗎?

P：嗯，Heroku提供了對Docker的支持，但我告訴你：Heroku已經死了。你需要在CoreOS上運行你的容器。

U：擦，那CoreOS是什么?

P：它是一個可以運行Docker的Host OS。該死的，你甚至都不需要Docker，可以直接使用rkt。

U：Rocket?

P：不，rkt。

U：沒錯，那就是Rocket。

P：不，現在已經叫rkt了。與Docker完全不同。這是另一種集裝箱格式，不像Docker把東西都綁定在一起，所以它更可以隨意組合。

U：那樣很好?

P：當然這是很好的。組合是未來的趨勢。

U：好，你如何使用它?

P：我不知道。估計還沒人能玩轉它。

U：好吧。那你接著剛才繼續說下CoreOS?

P：它是一個可以使用Docker的Host OS。

U：什么是Host OS?

P：一個運行容器的主機操作系統。

U：運行我的容器?

P：是啊，你總得有運行東西的容器。就像你設置一個EC2實例，你把CoreOS放上去就可以了，隨后運行Docker的守護進程，然后你就可以將Docker鏡像部署上去。

#p#

U：其中哪一部分是容器?

P：所有。你可以把應用程序寫為一個Dockerfile，然后在本地把它變成一個鏡像，這樣，鏡像就可以被部署到任何Docker主機了。

U：啊，就像Heroku?

P：不，不是Heroku。我告訴過你了。Heroku死了。你現在使用的是Docker。

U：什么?

P：是啊，這真的很簡單。查一查#gifee。

U：Gify?

P：“谷歌的基礎設施”。你可以基于一些現有的工具，并通過使用容器，就可以擁有和谷歌相同的基礎設施了。

U：我為什么不只使用谷歌的東西呢?

P：你認為這將是大約6個月可以完成的?

U：OK，沒有云服務商提供類似的服務嗎?我真的不想自己搞一套

P：嗯，亞馬遜有ECS，但你得寫煩人的XML。

U：OpenStack又是什么東西?

P：Ew。

U：Ew?

P：Ew。

U：我真的不想自建。

P：不，它真的很容易。您只需設置一個Kubernetes集群。

U：我需要一個集群?

P：Kubernetes集群。它會管理所有服務的部署。

U：我只有一個服務。

P：什么意思?你確實有一個應用程序，所以你必須至少有8-12個服務?

U：什么?沒有，我只是一個應用程序。為什么有那么多服務?

P：不，看看微服務。這是未來。這就是現在我們所做的一切。你把你的整體應用程序分解成12個服務。每一個服務只做一件事情。

U：這似乎代價過高。

P：這是確保應用可靠的唯一途徑。你可以想象下如果你的驗證服務宕機了...

U：認證服務?我之前用的是Gem。

P：對的。使用gem。把它轉變為一個項目，再封裝一個RESTful API就可以了。當你的其它服務使用這個API的時候，它就會變得非常容器。***你可以把這個項目放在容器中。

U：好了，現在我已經得到了幾十個難以管理的服務，現在該怎么辦?

P：Yeah，我提到的Kubernetes。它可以讓你協調所有的服務。

U：交給Kubernetes進行調度?

P：是啊，你的這些服務并不是每時每刻都是可靠的，所以你需要有多個『副本』。Kubernetes就是讓這些服務分布在你的集群的多臺主機上，以保證服務的可靠性。

U：我需要一個集群呢?

P：是啊，為了可靠性。Kubernetes會幫你管理。Kubernetes是谷歌的一個開源項目，它有使用到etcd。

U：什么是etcd?

P：它是Raft的實現。

U：好了，什么是Raft?

P：它就像Paxos。

U：好，什么是Paxos?

P：Paxos就是沒有人理解或使用的上世紀70年代老的分布式共識協議。

U：太好了，謝謝你告訴我。Raft是什么?

P：由于沒有人理解Paxos，所以Diego....

U：哦，你認識他嗎?

P：不，他在CoreOS工作。換句話說，因為Paxos太難了，Diego就在他的博士論文中發布了Raft。聰明的家伙。之后他寫了etcd作為實現，Aphyr說，這不是狗屎。

#p#

U：什么是Aphyr?

P：Aphyr是那家伙昵稱，“就叫我這個名字吧。” 你要知道，關于分布式系統和BDSM的人?

U：什么?你說BDSM?

P：是啊，BDSM。那在舊金山。每個人都向往分布式系統和BDSM。

U：嗯，OK。他寫過Katy Perry的歌曲?

P：不，他寫了一組博客文章有關如何在每個數據庫發生故障時CAP。

U：什么是CAP?

P：CAP定理。CAP 理論說在一個系統中對某個數據不存在一個算法同時滿足一致性，可用性和分區容忍性。

U：OK，所有數據庫發生故障時CAP?這是什么意思?

P：就像Mongo。

U：我以為Mongo was web scale?(此處有梗http://www.mongodb-is-web-scale.com/是個Mongo網站)

P：沒有其他人會這么做。

U：好了，那 etcd?

P：是啊， etcd是一個分布式key-value存儲。

U：哦，就像Redis。

P：不，一點都不像Redis。etcd是分布式的。

U：好的，這是一個分布式 key-value存儲。

P：Kubernetes設置一個使用etcd作為消息總線標準的5個節點集群。它結合了Kubernetes自己的服務，并提供一個非常彈性的業務流程體系。

U：5個節點?我有一個應用程序。我做這些該需要多少臺機器啊?

P： 嗯，你將有大約12個服務，當然，你需要冗余副本，幾個負載均衡的集群etcd，你的數據庫和kubernetes集群。因此，需要運行50個容器。

U：擦!

P：沒什么大不了!容器是非常高效的，所以你應該能夠分發這些跨越在8臺服務器上!是不是很神奇呢?

U：這就是把它的一種方式。而完成這一切，我就可以簡單地部署我的應用程序?

P：當然。我的意思是，存儲仍然是Docker和Kubernetes一個未解決的問題，并且網絡也會有不少問題，但你基本上還沒到那步!

U：我明白。好吧，我想我會努力得到他。

P：非常好!

U：感謝解釋它。

P：沒問題。

U：請允許讓我再說復述一遍，看看是否我的理解是否正確的。

P：當然可以。

U：我只需要將我簡單的CRUD應用程序分割成12個微服務，每個都有自己的API，每個微服務調用其中其他的API，而且彈性處理失敗，并把它們放到Docker容器中。Docker容器又運行于CoreOS之上，并分布在集群的8臺機器上，同時使用運行etcd的Kubernetes集群來調度他們，再解決『網絡和存儲』難題，然后我不斷地提供每個微服務的多個冗余副本到我的集群。是不是這樣?

P：是!是不是很炫酷?

U：我要用回Heroku。

原文鏈接：http://www.dockone.io/article/529