一份Docker的反方辩论——我还是用Heroku好了

这是一篇在国外社区非常火的文章。由CircleCI创始人所写,追逐热点新技术的程序员与只想做个简单web应用的程序员对话,Docker到底能否解决简单小应用的问题吗?Heroku真的歇菜了吗?我们有请反方辩者登场——

PS,小数只是勤劳的搬运工,文章并不代表数人云观点:)

本文为两个程序员之间的对话,一个打算使用Heroku做个简单Web应用的传统程序员,另一个追捧Docker及各种新技术的时髦程序员,前者虚心向后者“请教”的故事……

嗨我老板让我和你聊聊,我听说你很懂Web应用?

是的,我现在更沉迷分布式系统。我刚从ContainerCamp 和 Gluecon大会回来,我正准备去参加下周的Dockercon。我对于行业正在发生的变化感觉十分兴奋——一切都更简单和可靠了,这就是未来呀!

真酷。目前我只搭建了一个简单的Web应用——一个普通的使用Rails的CRUD应用,打算部署到Heroku上去。是不是还是这样的路子?

哦不。那都是老一套了。Heroku已死——已经没有人用了。你需要使用Docker,那才是未来。

哦好吧,那是啥?

Docker是一种容器化的新方式。就像LXC,但是同时也是一种封装形式,一个分布式平台,工具让分布式系统变得非常容易。

容……容器?接下来呢,LXE是啥?

就像steroids上的chroot!

好吧cher——oot又是啥?

好吧,看,Docker,容器化,它是未来,它就像虚拟化但是更快更便宜。

哦就像Vagrant。

不,Vagrant已经死了。现在所有的一切都在容器化,它是未来。

好吧,所以我不再需要了解虚拟化的东西?

不,你仍然需要虚拟化,因为容器并不提供一个完全安全的环境。所以如果你想在多租户的环境下跑东西,你还是需要保证你没有脱离沙盒的。

好吧,这里我有点迷惑。我们来说一下,所以有一个类似虚拟化的东西叫做容器,我可以把它用在Heroku上面吗?

Heroku对Docker是有一些支持,但是我告诉你:Heroku已死,你应该把你的容器跑在CoreOS上。

好吧,那是啥?

它是很酷的Host OS,你可以和Docker一起使用。甚至,你不需要Docker,你可以用rkt。

火箭?

不,是rkt

好吧,火箭。

不,它现在叫rkt。完全不一样,它是一个可选择的容器化形式,并不像Docker那样是捆绑式的,所以它更有编排性。

哦那它好不好吗?

当然非常好,编排性是未来啊。

好的,那你是如何用它的?

我不知道,我不认为现在会有人用它。

哎,那你说说刚才提到的CoreOS?

好的,它是你和Docker搭配使用的一个Host OS。

Host OS又是什么?

Host OS跑你所有的容器。

跑我的容器?

是的,你需要东西来跑你的容器。所以你搭建像EC2的实例,你把Core OS放上面,然后运行Docker daemon,然后可以把Docker镜像部署到里面。

这里的哪一部分是容器?

所有都是,看,你把你的应用写一个Dockerfile,把它转变成本地镜像,然后你可以把它推到任何一个Docker主机。

哦,就像Heroku?

不,不是Heroku。我告诉你了,Heroku已经死了。你用Docker来跑你的云。

啥?

是的,它真的很简单,看gifee。

Gify?

“人人都可拥有Google那样的基础设施”(Google’s infrastructure foreveryone else)。你用一些现成的工具和堆栈,用容器,然后就可以拥有和Google一样强大的基础设施了。

那为啥我不能直接用Google的东西?

你认为六个月之内能搞定吗?

好吧,没有其他人弄这个东西吗?我自己不想弄。

亚马逊有ECS,但是你要写XML或者其他玩意。

那OpenStack上的什么呢?

Ew。

Ew?

Ew。

好吧你看我真的不想自己来弄。

不,它真的很简单,你需要建一个Kubernetes集群就可以了。

我需要一个集群?

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

我只有一个服务。

你的意思是啥?你有一个应用,那么你就该有至少8-12个服务。

什么?不,只有一个应用,服务嘛,也只是其中一个。

不,看看微服务。它才是未来。我们做的都是微服务,你把你的整体式应用分割成12个服务,每一块你做的工作都只是一部分。

这看起来有点多啊。

这是确保它可靠的唯一方式。如果你的认证服务挂了……

认证服务?我正打算用它,就跟我之前用过的几次一样。

棒极了。用gem,把它放到它的项目里,把RESTful API放上去,然后你的其他服务也用那个API,就可以很好地处理失败和其他事情。把它放到容器里,然后持续地交付。

好的,然后我就有了成堆的无法管理的服务,那该怎么办?

是的,我正在说的Kubernetes,会协调你所有的服务的。

协调它们?

是的,你有了这些服务,为了确保它们可靠你需要很多份它们的备份,Kubernetes会确保你有足够的备份,在你的fleet里它们是各个节点分布式的,所以它们总是可用的。

我现在需要一个fleet?

是的,为了稳定性。但是Kubernetes可以为你管理它,你知道Kubernetes很好用因为Google建造了它,它跑在etcd上面。

Etcd是啥?

它是RAFT的一个具体实现。

好吧,Raft是啥?

它就像Paxos。

好吧,这个兔子洞到底有多深?我只是想实现一个应用,哎,好吧,深呼吸,那么Paxos是啥?

Paxos就像一种很古老的70年代的旧分布式协议,没人理解或者使用。

好吧,感谢你告诉我这个。那么Raft是啥。

因为没人理解Paxos,所以这个叫diego的家伙……

哦你知道他?

不,他做的是CoreOS,然而,Diego为他的博士论文创造了Raft,因为Paxos实在太难了。真是邪恶而聪明的家伙。他又写了etcd作为实现,Aphyr说它并不是很糟。

Aphyr是谁?

Aphyr是那个写了“Call Me Maybe”的家伙,你知道,那个分布式系统和BDSM的家伙。

什么?你说BDSM?

是的,在旧金山,每个人都进入了分布式系统和BDSM。

哦,他写了那个Katy Perry的歌?

不,他写了一系列的关于每个数据库如何挂了CAP的博客

CAP是啥?

CAP定理,它表明你只能在一致性,可用性和隔离性中选择两个。

好吧,所有的数据库都完败CAP?这意味着什么?

这意味着它们都是渣渣,就像Mongo。

我猜Mongo是web规模的?

对,没错。

Etcd呢?

Etcd是一个分布式键值存储。

好吧就像Redis。

不,并不像Redis。Edcd是分布式的,如果网络分区了Redis会失去它一半的代码。

好吧,它是分布式键值存储。那为啥它有用?

Kubernetes用etcd建立了一个标准的5节点的集群作为一个消息总线,它包含了Kubernetes一些自己的服务来提供一个有弹性的编排系统。

5个节点?我只有一个应用,那么我需要多少个机子?

好吧,你要有12个服务,你也需要一些多余的备份,一些负载均衡,edcd集群,你的数据库,Kubernetes集群。所以你至少应该跑50个容器。

哦天!

没什么大不了的。容器真的非常效率,所以你应该可以把他们分布在8个机子上,是不是很了不起?

确实是一个方法,通过这个,我是不是可以简单地部署我的应用了?

当然,我是说,存储对于Docker和Kubernetes来说仍然是一个开放的问题,网络会承担一些工作,但是你基本已经可以达到那个未来之地了。

我明白了,好吧,我懂了。

棒极了。

感谢你的这些解释。

没问题。

那我来重复一遍确保我领悟了这些。

好的!

我只需要把我简单的CRUD应用分割成12个微服务,每一个都配有API可以弹性地恢复它们的错误,把它们放进Docker容器,启动8个机器的fleet,均为跑Core OS的Docker主机,用一个小的跑etcd的Kubernetes的集群来协调它们,明确网络和存储的开放问题,然后我就可以持续地给我的fleet交付多个微服务的冗余备份,是这样吗?

是的,它是不是很棒?

我要回去继续Heroku了。

(文章转自:CircleCI blog)

    原文作者:优云数智
    原文地址: https://segmentfault.com/a/1190000006687689
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞