容器时代，难道这就是我们想要的未来?

以下完整的对话记录，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镜像部署上去。

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说，这不是狗屎。

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。

本文作者：周峰

来源：51CTO