容器是未来吗？

这是一篇有点质疑基于Docker容器分布式系统是否在针对小型应用时过于复杂，有大炮打蚊子的嫌疑?当然，也可以从侧面了解一下Docker分布式生态圈的建设。

下面是采取对话形式：

你好啊，我的老板已经和你谈过话，听说你了解很多关于Web应用的新技术?
-是的, 我现在更是一个分布式系统的粉丝，我刚刚从ContainerCamp 和 Gluecon回来，下周我准备去参加Dockercon. 对业界当前的发展道路非常激动，这使得一切都变得简单和更可靠，它代表未来，It’s the future!

Cool. 我正在使用Rails建立一个简单的CRUD应用，我准备部署到Heroku. 这种方式怎么样?
-噢不. 这是老的方式了，Heroku已经死了，不会再有用户使用它了，你现在需要使用Docker，它代表未来？

噢，好明白，那它是什么东东？
-Docker是一个实现容器化新的方式，它类似LXC, 但是是一种包装格式，一种分布式平台，是一种让分布式系统更容易的工具。

容器..化？ — 这是什么？LXE又是什么?
-它类似LXC. 类似steroids上的chroot !

cheroot又是什么？
-好吧，简单和你说，Docker容器化代表未来，类似虚拟化，但是更快更便宜。

噢，它像Vagrant.
-不, Vagrant已经死了. 现在每件事都将容器化，这是未来趋势。

好吧, 现在我就不需要了解任何关于虚拟化的东西？
-不, 你还是需要虚拟化，因为容器并没有提供完整的安全方案，如果你要以多租户方式运行应用，你还得保证不能脱离沙盒。

好吧，我有点糊涂了，让我梳理一下，有一个东西像虚拟化，称为容器，那么我能在Heroku上用它吗?
-是l, Heroku已经支持docker, 但是我告诉你: Heroku已经死了. 你可以在CoreOS上运行你的容器.

那那又是什么东东?
-它是一个非常酷的主机OS(Host OS)，你能在其上使用Docker，甚至你都不需要Docker, 直接使用rkt.

Rocket?
-不, 是rkt.

好吧, 应该还是Rocket.
-不, 它现在叫rkt. 完全不同了，它是一个容器格式的候选者，再也不会绑定到Docker上，而且更加易于组合。

有那么好吗?
-当然很好. 组合是未来.

好吧，你是怎么用的?
-我不知道. 我不会认为有人会用它

唉，你在谈论CoreOS?
-是的, 它是和Docker一起使用的Host OS

什么是Host OS?
-Host OS能运行你所有容器

运行我的容器?
-是的, 你必须有能运行你容器的东西，这样你可以在亚马逊EC2实例中设置，你将CoreOS放于其中，然后运行Docker后台, 然后你就能部署Docker image到其中了.

这（部署）属于容器哪个部分?
-这就是你所有做的，你将你的应用写成一个Dockerfile, 将它们转换成本地image, 然后你能将它推送到任何Docker主机.

嗯，很像Heroku?
-不, 不是Heroku. 我告诉过你. Heroku已经死了. 使用Docker你运行你自己的云。

什么?
-对，这真的很容易，查查gifee.

Gifee什么意思？
-它是“Google’s infrastructure for everyone else”意思. 通过现成的工具和技术栈，使用容器，你能有Google一样的基础设施。

那么为什么不就直接使用Google东西?
-你认为这会要6个月吗？

好吧，那么难道没有其他地方提供这些吗？我真的不想为自己做主机之类的技术。
-嗯, Amazon有ECS, 但是你得编写XML之类麻烦的玩意。

OpenStack怎么样?
-Ew.

Ew?
-Ew.

看，我真得不要给自己做主机之类的技术
-不, 那很容易. 你只需要设置一个Kubernetes集群.

我需要集群cluster?
-Kubernetes cluster.它会管理所有你的服务部署。

可是我只有一个服务
-你到底什么意思? 你有一个应用app，这样你至少有8-12个服务?

什么? 不，只是一个应用app. 服务什么的是它们中一个
-不，看看微服务microservices. 它是未来. 它是我们正在做的每件事，你将你的整体应用划分为12个服务，每个服务做每件任务。

那好像有点过分吧
-那是你获得可靠的唯一办法，如果你的授权服务当机。。

授权服务? 我只是使用以前多次使用的Ruby的gem。
-好吧. 使用gem. 把它放入自己的项目. 放入一个RESTful API在其上. 这样你的其他服务可以使用这个API, 并优雅地处理失败等事情，把它放入容器，然后持续递交。

OK, 现在我已经有一打没有受管理的服务，怎么办?
-Yeah,我讲的就是Kubernetes. 它能让你指挥路由你的服务.

指挥编排（Orchestrate）服务?
-Yeah, 你有这些服务，它们得可靠运行，这样你就需要冗余复制它们，这样Kubernetes肯定能帮你做到，它们能分布跨多个主机部署，总是可用的。

有了Docker这个集装箱，我还需要一个船队吗?
-Yeah, 为了可靠性. 但是Kubernetes会替你管理. 你知道谷歌就是使用Kubernetes，它运行在etcd上面

什么是etcd?
-是分布式协议RAFT的实现.

什么是Raft?
-它类似Paxos.

上帝, 有必要给我下这么深的套路吗？像兔子洞一样深？我只是要启动一个应用，好吧，深呼吸，告诉我什么是Paxos?
-Paxos像一个真正老的分布式一致性协议，那是70年代还没有人理解并使用它。

好吧，感谢你告诉我这个事实，那么什么是Raft?
-因为没有人理解Paxos, 这个家伙Diego…

Oh, 你认识他?
-No, 他工作在CoreOS. 这么说吧，Diego因为Paxos太难了，因此构建Raft，邪恶的聪明的家伙。然后他写了etcd作为一种实现，Aphyr说那不是狗屎。。

Aphyr是谁?
-Aphyr是那个写‘Call Me Maybe.’家伙，分布式系统和BDSM大牛，你不认识吗?

什么? 你说BDSM?
-Yeah, BDSM. 在San Francisco. 每个人都知道了分布式系统和BDSM.

Uh, OK. 那么他写过凯蒂派瑞的歌之类东东?
-No, 他发表了有关每个数据库如何不能完成CAP系列博文。

什么是CAP?
-就是CAP理论 它说你在一致性 可用性和分区容错性三者中只能取两个。

OK, 所有数据库都在CAP面前失败了? 那是什么意思？
-意思是这些数据库都是狗屎，如Mongo.

我认为Mongo可以实现Web规模扩展?
-没有其他人做到过.

OK, 那么etcd?
-Yeah, etcd 是分布式key-value存储.

Oh, 像 Redis.
-No, 没有一点像Redis. etcd是分布式的. Redis在进行网络分区会丢失一半它写入的数据。

OK, 那么它是分布式key-value存储. 为什么有用?
-Kubernetes设置一个标准的5节点集群，使用etcd作为消息总线. 它结合了一些Kubernetes的自己服务提供完美弹性的业务编排系统.

5个节点? 我只有一个应用. 难道我需要这么多机器吗？
-好吧, 你已经有12个服务，当然你需要这些服务的复制冗余，一个负载平衡器，etcd集群，你的数据库，和kubernetes cluster. 也许50个运行容器吧

WTF!
-没有什么大不了，容器非常有效率，这样你能发布这些容器跨8台机器，是不是很惊奇？

这些都是一种方式，我能简单地部署我的应用吗？
-当然. 存储还是Docker和Kubernetes开放问题，网络会花费一点工作，但是就只有这些工作了。

我明白，我会考虑采用它的
-Great!

谢谢解释
-No problem.

让我重复一下我刚才理解的
-Sure!

我需要将我的简单CRUD应用划分为12个微服务, 它们每个都有自己的APIs 能够够彼此调用，可以弹性处理失败，将这些服务放入Docker容器, 加载一个带有8台机器的船队，Docker运行在CoreOS上，使用小型Kubernetes集群通过etcd管理编排它们, 识别出网络和存储这些开放未解决的问题，那么我就能持续递交多个微服务的复制冗余到这些机器上。就这样吗？
-Yes! 你不感到辉煌吗？

我还是要回到 Heroku.

原文：
It’s The Future - CircleCI
[该贴被banq于2016-08-19 17:13修改过]