Docker果真是未来？

作者简介：Paul Biggar是CircleCI的创始人。

嗨，我的上司让我来采访你，听说你对Web应用程序颇为了解？

－是的，我现在主攻分布式系统。我刚参加完ContainerCamp和Gluecon回来，下周要去参加Dockercon大会。确实为行业前进的方向感到激动――让一切变得更简单、变得更可靠。这就是未来！

很棒。我眼下就在构建一个简单的Web应用程序――使用Rails的一个平常的CRUD应用程序，将部署到Heroku。那仍是出路吗？

－哦，不。那是老方法。Heroku过气了，没有人再使用它。现在你需要使用Docker。它是未来。

好的。Docker是啥东东？  

－Docker是实现容器化的一种方法。它就像LXC，但它又是一种包装格式、一种分发平台，以及让分布式系统非常容易的工具。

容器。那么，LXE又是什么？

－不是LXE，是LXC。它好比是增强版的chroot！

cher-oot又是啥东西？

－得了。Docker，容器化，它就是未来。它就像虚拟化，不过速度更快，成本更低。

哦，如此说来就像Vagrant。

－不。Vagrant过气了。现在一切都会容器化，容器是未来。

好吧，那么我就不需要对虚拟化有所了解了？

－不，你仍需要虚拟化，因为容器还根本无法提供一种全面的安全机制。所以，如果你想在多租户环境下运行任何东西，就需要确保你没有跑出沙盒。

好吧，我开始有点糊涂了。让我冷静一下。这么说，有一种技术类似虚拟化，名叫容器。我可以在Heroku上使用这种技术吗？

－嗯，Heroku对Docker提供一定的支持，但是我告诉你：Heroku过气了。你应该在CoreOS上运行容器。

好吧，CoreOS又是什么？

－CoreOS是一种很酷的主机操作系统，可与Docker结合使用。你甚至不需要Docker，就可以使用rkt。

Rocket？

――不是，是rkt。

没划，就叫Rocket。

－不，它现在叫rkt。完全不一样。它是一种替代的容器化格式，不像Docker那样完全捆绑起来，所以它更容易组合起来。

那很好吗？

－当然很好。可组合性是未来趋势。

好吧，你如何使用它？

－我不知道。恐怕没人能使用它。

唉。你可以继续说说CoreOS吗？

－好的，它是一种主机操作系统，可以与Docker结合使用。

主机操作系统又是啥？

－主机操作系统运行你的所有容器。

运行我的容器？

－是的，你要有东西来运行你的容器。所以，你构建了EC2实例之类的系统，把CoreOS放在上面，然后运行Docker守护程序，之后你就可以将Docker镜像部署到上面。

其中哪个部分是容器？

－全部。瞧，你拿来应用程序后，编写一个Dockerfile，在本地转换成镜像，然后可以把那个推送到任何Docker主机。

啊，就像Heroku那样？

－不，不是Heroku。我跟你说过了，Heroku过气了。现在你使用Docker来运行自己的云。

什么？

－没错，这确实很容易。查查#gifee。

Gify？

－“面向其他每个人的谷歌基础设施”。你可以拿来一些现成工具和堆栈，使用容器，就能拥有与谷歌一样的基础设施。

为什么我干脆不用谷歌的东西？

－你认为6个月后这会存在吗？

好吧，别人不托管这东西吗？我其实不想托管自己的东西。

－嗯，亚马逊有ECS，但是你得编写XML或一些内容。

放在OpenStack上如何？

－Ew。

Ew？

－Ew。

瞧，我其实不想托管自己的东西。

－不，它其实很容易。你只要搭建一个Kubernetes集群。

我需要一个集群？

－Kubernetes集群。它将管理你所有服务的部署。

我只有一个服务。

－你啥意思？你有一个应用程序，所以你至少要有8至12个服务？

什么？不，只有一个应用程序。为什么要那么多的服务？

－不，瞧瞧微服务。它是未来。它是我们现在开展一切的方式。你拿来整体式应用程序，把它分成比如12个服务。每个服务对应于你所做的每项任务。

这似乎太多了。

－这是确保它可靠的唯一方式。所以，如果你的验证服务出现了故障……

验证服务？我会使用之前用过几次的这个gem。

－很好。使用gem。把它放入到它自己的项目。在上面放一个充分利用REST的API。然后，你的其他服务就可以使用该API，可从容地处理故障之类的问题。把它放在容器中，不断提供该服务。

OK，那么现在我有了几十个无法管理的服务，现在该怎么办？

－是的，我提到了Kubernetes。它让你可以编排你的所有服务。

编排服务？

－没错，所以你拥有这些服务，它们必须很可靠，所以你需要多个副本。所以，Kubernetes确保你拥有足够的服务，确保它们分布在你集群（fleet）中的多个主机上，那样始终确保可用性。

现在我需要集群？

－是的，为了确保可靠性。但是Kubernetes可以为你管理它。你要知道Kubernetes切实可行，因为谷歌开发了它，它在etcd上运行。

etcd是什么东西？

－它是RAFT的实现。

OK，那么Raft又是什么？

――它就像Paxos。

Christ，我们谈论的话题怎么越来越绕啊？我就想启动一个应用程序。唉。真见鬼。好吧，Paxos又是什么鬼东西？

－Paxos好比是上世纪70年代的老式分布式共识协议，没有人懂得或使用这种协议。

很好，谢谢你告诉我这一点。那么，Raft是什么呢？

－因为没人懂得Paxos，于是名为Diego的家伙…

哦，你认识他？

－不认识，他在CoreOS工作。不管怎样，Diego在撰写博士论文时编写了Raft，因为Paxos太难了。这是个聪明绝顶的家伙。然后，他编写了etcd作为一种实现，Aphyr说这不是狗屎。

Aphyr又是谁啊？

－Aphyr就是写《Call Me Maybe》的那个人。你知道，分布式系统和BDSM家伙吗？

什么？你说BDSM？

－是的，BDSM。在旧金山，大家都在搞分布式系统和BDSM。

OK，他写过Katy Perry唱的那首歌曲吗？

－不，他写过关于每个数据库未通过CAP的一系列博文。

CAP是什么？

－CAP定理（CAP theorem）。该定理表示，在一致性（Consistency）、可用性（Availability）和分区容忍（Partition tolerance）这三个当中只能做到两个，不可能三者兼顾。

OK，所有数据库都未通过CAP？这到底意味着什么？

－这意味着它们都是狗屎。就像Mongo。

我以为Mongo是大规模级别呢？

－别人可不这么认为。

OK，那么etcd呢？

－哦，etcd是一种分布式键值存储系统。

哦，就像Redis。

－不，根本不像Redis。etcd是分布式。如果网络分区，Redis就会丢失一半的写入。

OK，它就是一种分布式键值存储系统。为什么这个很有用？

－Kubernetes使用etcd作为消息总线，构建了一个标准的5节点集群。它结合几个Kubernetes的自有服务，提供一种弹性相当强的编排系统。

5个节点？我有一个应用程序。如果使用这种配置，我到底需要多少个机器啊？

－嗯，你会有大约12个服务，当然每个服务你需要几个冗余副本，几个负载均衡系统，etcd集群、你的数据库还有kubernetes集群。所以那就像是50个运行中的容器。

什么玩意儿!

－没什么大不了！容器其实很高效，所以你应该能够在8台机器上分布这些容器！这不是很出色吗？

别的不多说了，我能够简单地部署我的应用程序吗？

－当然，我的意思是，存储仍是Docker和Kubernetes方面一个悬而未决的问题，网络方面需要一番工作，但是你基本上已大功告成了！

我明白了。OK，我认为我心里有点数了。

－很好！

谢谢解释。

－别客气。

让我重复一下，看看我是否搞明白了没有。

－当然可以！

所以，我就只要把那个简单的CRUD应用程序分成12个微服务，每个微服务都有各自的API，它们调用对方的API，但是处理故障具有弹性，把它们放入到Docker容器，启动8台机器组成的集群，它们其实是运行CoreOS的Docker主机，使用运行etcd的小小的Kubernetes集群对它们进行“编排”，搞清楚网络和存储方面“悬而未决的”问题，然后我可以不断向我的集群交付每个微服务的多个冗余副本。是不是这样？

－没错，是不是很酷？

我还是使用原来的Heroku。

相关阅读：