本篇内容是根据2017年5月份#47 Docker, Moby, Containers音频录制内容的整理与翻译
Solomon Hykes 参加了节目，谈论了 Docker、Moby 项目以及 Go 非常适合容器管理的全部内容。
过程中为符合中文惯用表达有得当删改, 版权归原作者全部.
Erik St. Martin: 好的，各人好，欢迎回到 GoTime 的另一期节目。今天是第 47 期，我们的赞助商是 Toptal。今天的高朋包括我自己，Erik St. Martin，还有 Carlisia Pinto --- 打个招呼吧，Carlisia。
Carlisia Thompson: 各人好。
Erik St. Martin: 今天代替 Brian 出场的是 Adam Stacoviak。
Adam Stacoviak: 各人好！
Erik St. Martin: 能让你从幕后走出来，真的太好了。对于没听过 Adam 另一期节目的朋友来说，Adam 是我们的制作人之一，他总是躲在幕后；我们终于让他走出来了。
Adam Stacoviak: 没错……就像一个把戏师，等候着合适的时机偶尔露面……而 Solomon！我必须为 Solomon 出场，这就是原因。
Erik St. Martin: 说到这里……今天我们非常荣幸地邀请到了特别高朋，Docker 的 CTO 和创始人 Solomon Hykes。
Solomon Hykes: 各人好！感谢邀请我。
Adam Stacoviak: Solomon，非常感谢你抽出时间参加节目；虽然安排上有些波折，但我们不停在期待这次节目。 Docker 是一个巨大的项目，显然每个人都在深入了解它并不停探索。
我们在 Changelog 的节目中早在第 89 期就采访过你。当时用你自己的话来说，那似乎是 20 年前的事了，感觉像是很久从前了……你怎么看？
Solomon Hykes: 是啊，感觉确实很久从前了，我对那次对话有很优美的影象；那次节目非常风趣。
Adam Stacoviak: 给正在收听直播的听众，我会在聊天中放上 链接，各人可以标记一下。链接也会出现在节目笔记中，记得去看看……听听我从前（他们说的）年轻的声音，那时的 Adam，哈哈……
Erik St. Martin: 他今天在我们管理频道里分享了那期节目，我开始听……哇，你的声音真的听起来很年轻。 [笑声]
Adam Stacoviak: 或许是因为当时的音效调治不敷？我也不知道……实在我也不确定。但总之……Docker！它是从 DotCloud 开始的，对吧？
Solomon Hykes: 是的。
Adam Stacoviak: 当时的 DotCloud 是什么？或许人们不须要太多你的介绍，但至少须要了解你今天的身份---你是 Docker 的 CTO 和创始人……带我们回到 DotCloud 的期间吧。给我们一些怀旧的回忆，有什么只有你知道的可以在节目里分享的？
Solomon Hykes: 好的……我不知道是否只有我知道，但当我们做那期 Changelog（第 89 期）的时候，我是一个名叫 DotCloud 的公司的创始人兼 CEO，后来这家公司成为了 Docker。当时我们刚刚发布了 Docker 项目，但还没有完全转型为只支持 Docker 的公司，虽然我以为那已经很快就要发生了。但在 Docker 之前，还有六年的 DotCloud 韶光。以是总的来说，我已经在这个公司工作了九年多了，DotCloud 是一个平台即服务（PaaS）的产物。假如你认识 Heroku 或 Google App Engine，类似的产物……它是一个托管服务，开发者可以用它来部署和扩展他们的应用。
根本上，你写代码，把代码交给我们，然后其他一切我们来处理。我们负责扩展、运行等等。我们在底层利用容器来进步效率。很多人问我们，“哇，这个技能真酷。你是怎么做到的？我不想付费利用你们的服务，但我想自己实现这个技能。”
Erik St. Martin: 人们想要免费用东西？[笑声]
Solomon Hykes: 是啊，真不可思议（笑）。实在，我们并没有发明这种技能；我们是基于底层的系统构建的。当时 Linux 正在渐渐改进对容器的支持，但这仍旧是一个非常小众的技能。当我们在 2008 年开始时，你必须对内核进行大量修改，以是只能用于非常小众的场景。然后在 2012 到 2013 年左右，你可以在未修改的 Linux 内核上自己运行容器，这让很多事情成为了大概。
总之，我们听到了富足多的需求，终极决定开源底层技能，这就成了 Docker。固然，为什么它会盛行起来，这仍旧是一个联合了神秘、运气和（从我的角度看）努力工作的结果。后来我们卖掉了 PaaS 业务，只专注于 Docker。
Erik St. Martin: 你提到有点惊讶它会云云受欢迎……但该给的功劳还是要给，对吧？是的，Linux 内核里有容器功能，但我以为 Docker 让它变得更轻易接近了，对吗？大多数为 Linux 开发软件的人并不了解大概不认识 cgroups 和 namespaces。我以为 Docker 真的让这些变得更轻易接触，而且还有这种便携的镜像格式……
Solomon Hykes: 是的，实际上……风趣的是，Linux 容器自己就已经存在而且为人所知，尽管它只被一小部门专业人士知道，比如系统工程师和运维人员---他们会基于这些构建平台。但你说得对，这是一种非常艰涩的技能，诚实说，当时它还不敷成熟。Linux 容器在那时并没有稳固到高质量的程度……但实际上，我们利用了“容器”这个词的双重含义。Linux 容器是一个非常详细的技能概念，用来沙盒化你的运行应用……但我们将这个术语扩展到了类似“运输集装箱”的含义，后者完全是另一回事。它更多的是关于如何移动东西、如何使它们可重复利用以及如何标准化移动的格式。
直到今天，我以为不同的人对“容器”这个词的理解是不同的。第一个界说是一个非常专业和小众的界说，而运输集装箱是一个全部人都能理解的主流术语，这实际上也是 Docker 专注的范畴。
对于 Docker 来说，Linux 容器只是我们用来交付更广泛功能的一个特性，而这个更广泛的功能是为你的代码提供“运输集装箱”。
Erik St. Martin: 我这里有一个风趣的题目，想听听你的看法……我发现虚拟机（VM）和容器之间的区别在于，Docker 因为很好地抽象了概念，以是人们经常会肴杂它们很相似。很多人会把 tcpdump 和其他随机工具放进容器里，然后加载它们，因为他们没有真正理解容器更接近于一个高度配置的进程，而不是一个真正的虚拟机。你以为人们也有类似的狐疑吗？
Solomon Hykes: 是的，对于我们来说，有一个普遍的主题，那就是不同的人对 Docker 或容器有着不同的理解或体验，他们有着不同的看法。Docker 社区不停以来都非常多元化。换句话说，不同的人对容器和 Docker 有着不同的盼望，有时候乃至会对什么才是精确的答案产生激烈的分歧。
对我们来说，管理这种情况不停是一个挑战。但诚实说，这从一开始就是我们的计划初志：我们说，“你知道吗？并不是每个人都须要对全部事情达成一致才气从同样的工具中受益。” 或许让人们在不同的界说中找到共同点会让事情变得更风趣，那种建立性的分歧会推动我们进步……而且我以为大部门情况下，这是有用的。
举个例子，Docker 社区中有很多开发者和运维人员。我们都知道，开发者和运维人员在事情上的优先级和看法是非常不同的，而这种差异反而带来了利益。一方面，有 Linux 专家、系统工程师等专业人士，他们以一种方式看待容器；另一方面，现在有很多前端开发者刚刚开始接触后端，Docker 对他们来说是一种非常简单的方式行止理后端事务。如今，还有一些完全初学编程的人，Docker 为他们提供了一个安全、风趣的起点，让他们不会感到被评判，并且身边有一群乐于帮助他们的人。
这些是两个非常极度的群体，但挑战在于：“我们如何让全部人都参与到同一个社区中，一起讨论容器？” 这并不总是轻易的。
Erik St. Martin: 这是一个非常风趣的观点，我之前从未思量过。
Carlisia Thompson: Solomon，我想请你回首一下从平台即服务（PaaS）转型为开源项目的谁人阶段……因为我在想---毫无疑问，你们现在是一个乐成的案例，这让一切变得更加引人入胜……以是我在想，你有一个按利用付费的服务，人们也在利用你的服务，但他们却说“我们不想为此付费”。我从一个商业视角来问这个题目，特别是对于那些想创业或正在创业的人……我自己也会有这个题目，我想各人也会很好奇，以是我们来聊聊这个吧。
当时你们处于如许一个阶段：人们在利用你的服务，但他们不想为此付费。那么，你们是如何做出如许的决定，而不是说，“我们调整一下定价模式”大概“我们提供更好的服务，让人们以为他们的耗费物有所值，从而乐意付费”？对我来说，这似乎是一个非常反直觉的决定---“不如把它提取出来，作为一个开源项目提供。” 这种转变是怎么发生的？你们当时有一个明确的计划吗？这个过程是怎样的？
Solomon Hykes: 这是个好题目。并不是说人们不想为我们的服务付费，我们就放弃了这个服务……实际上，DotCloud 这个产物还是挺乐成的；我们有客户，我们在稳步增长，也确实有一部门客户从中得到了代价。而且我们并没有碰到紧急危急。当时我们账户里有富足的钱……我记得我们还有两年的资金储备，以是这不是一个资金题目，也不是“没人想要这个产物，他们不想付费”的题目。但我们确实有两个题目：一是潜伏客户的市场规模太小，我们看到其他同样面对这个市场的公司都不太乐成。根本上，每一家平台即服务的初创公司都失败了。
有些公司通过并入更大的公司而制止了失败，这对它们来说是很好的选择。但显然，没有一家非常乐成的大型平台即服务公司可以让你指着它说：“我想和他们竞争。” 以是我们普遍以为，我们所在的市场没有未来。同时，我们看到了一个更大的人群，他们来找我们说：“我们想从你们这里得到一些东西，可以给我们吗？” 他们并不想要免费利用我们的服务，而是想要别的东西；他们想要的是构建自己服务的根本模块，关键在于定制化。
当你为客户提供一切时，题目在于这是一个一刀切的解决方案；你有一个单一的、整体的平台，它为你做了全部事情，要么担当，要么放弃。这确实很方便，但假如你想要定制化，就做不到；你只能离开，大概等候 DotCloud 添加这种定制化功能。而有了容器，你就像有了一个乐高积木套装。你可以混搭，可以改变很多东西，只须要有这些基础模块可用。
我经常举的一个例子是普通玩具和乐高的对比。我们当时有一个特定的玩具，一些人喜欢，但更多的人说：“嘿，我能不能改一下这个大概谁人？你能不能让我自己造一个玩具？只要给我乐高就行了。” 以是我们开始在旁边做一些实验。我们做了一个副项目---也就是后来成为 Docker 的项目---来看看假如我们给人们提供“乐高”会是什么样子。结果是立竿见影的。从我们第一次在内部做私下演示开始，约莫是在推出 Docker 的前四个月，人们就已经非常兴奋了。各人表现出了巨大的爱好，以是我们只是顺应了这种爱好。
终极，各人对新事物的爱好凌驾了对往事物的爱好，于是我们做出了决定。在你的题目中提到的“跃进”，发生在我们有两个都可行的选择时，这也是为什么这个决定很难。假如 DotCloud 显着失败了，这反而会是一个更轻易做出的决定，因为那时候根本没有选择。但因为 DotCloud 并没有显着失败，我们不得不做出决定。实际上，我一开始说：“我们两个都做。DotCloud 是我们的第一阶段，这个令人兴奋的新东西是第二阶段。” 我们还画了一个图表，第一条增长曲线终极会被第二条增长曲线代替……理论上很棒，但实际操作中，很快我们就发现必须专注。虽然是个艰难的决定，但我们选择了新事物。
Adam Stacoviak: 我本以为你会说，Docker 显然是一个更大的发展方向，我以为你会这么说。
Solomon Hykes: 嗯，这确实是我们终极得出的结论……
Adam Stacoviak: 嗯……
Solomon Hykes: ……以是我们才迈出了这一步，但在当时，这一点完全不显着。
Adam Stacoviak: 那时候很难看清。
Solomon Hykes: 我们是在……你知道 PyCon 上的谁人 lightning talk 两周后转型的。
Adam Stacoviak: 2013 年。
Solomon Hykes: 是的，2013 年，Docker 被介绍出来……
Adam Stacoviak: 那是你第一次谈论关于 Linux 容器未来的演讲，对吧？那就是 Docker。
Solomon Hykes: 是的。
Adam Stacoviak: 然后它就火了。
Solomon Hykes: 那成了我们“意外的发布会”，因为我们并没有计划把那作为我们的发布会。这里还有一个风趣的故事，但重点是，我想我们发布后几周内转型了。以是这一切都发生在……
Adam Stacoviak: 很快，因为当时你上 Changelog 的时候，你还在讨论 DotCloud……实际上，那场演讲---我们会把它的链接放在节目笔记里供听众参考。我会把链接发到 Slack 频道里。那场演讲，当时 Andrew Thorp（当时是 Changelog 的联合主持人）和我看了之后，我们以为：“这个东西超酷。这正在获得关注。” 到今天为止，这场演讲已经有快要 7 万次观看量了，而在开发者范畴，这已经是很高的观看量了。也许在整个 YouTube 世界，百万或几百万才算大，但在开发者范畴，这个数字已经很大了。
Solomon Hykes: 嗯，假如我想成为 YouTube 明星的话，我还有很多工作要做。
Adam Stacoviak: 没错……我们正在努力。
Erik St. Martin: 我记得第一次看到 Docker 的时候，它还是 DotCloud。Brian 和我当时在玩这个东西，我们就有一种感觉：这东西会成大事。它改变了一切。我记得---大概是在 Changelog 的那期节目里---Solomon 提到了虚拟机以及人们对它的期待，但它并没有真正实现。虽然有一些工具让虚拟机在开发中变得有用，比如 Vagrant，但它们的结果远远没达到 Docker 在可复现性和启动速率上的水平。
Adam Stacoviak: 那么 Go 在这其中饰演了什么角色呢？毕竟这是 GoTime，对吧？Go 在 Docker 中的作用是什么？
Carlisia Thompson: 我能问一个关于 Docker 故事之前的题目吗？你们在 DotCloud 用过 Go 吗？
Solomon Hykes: 这是个好题目。答案是没有，我们当时没有用 Go。我们是一个 Python 的团队，以是我们才会在 PyCon 上做展示。
Adam Stacoviak: 这就说得通了。
Solomon Hykes: DotCloud 是用 Python 写的，尽管它可以运行各种类型、用各种语言编写的应用步伐---顺便说一下，这是我们的差异化上风---因为我们利用了容器，以是我们为全部语言的应用步伐提供了一个通用的打包和部署系统。现在这听起来像是理所固然的，但在当时，这是一个大事，没有人这么做……当我们开始开发后来成为 Docker 的这个原型项目时，最初的版本也是用 Python 写的。
后来，我们迭代了频频……但产物始终不是很对路。与此同时，我对这个项目的计划有非常剧烈的意见，结果就是，我把团队里的核心工程师逼得受不了，他离开了……我们不得不从头开始。也就是在那时，我们做出了一个紧张的决定：转向利用 Go。
这个决定更多是出于直觉，而不是深思熟虑的。诚实说，当时这个决定在 DotCloud 内部并不受欢迎……但主要基于几个原因：起首，我直觉上以为 Go 很棒，我也想实验一下，说实话就是如许……固然，也有一些理性的考量。
第一，我们希望优化项目的贡献度。我们希望这个开源项目非常乐成，希望有很多人来参与贡献。以是我们须要一个轻易上手、对更多人来说认识的语言，同时又不能太极度或有太强的主观倾向。我对技能宗教战役没什么爱好，我以为很无聊，我只管远离这些东西。我喜欢 Go 的原因是：假如你是一个 C 步伐员，你会以为“好吧，我能看懂”；假如你是一个 Python 步伐员---也是一样。这种认识感富足吸引更多人，让我们能够快速建立一个主流的贡献者群体，这是一个很大的动力。
另一个原因是，在运维和 DevOps 工具范畴，最大的题目恒久以来是部落分裂。你有 Python 的 DevOps 工具，也有 Ruby 的 DevOps 工具，还有 Java 的 DevOps 工具。当时，这三大阵营是主流。而无论你为你的工具选择了哪种语言，只有你所在的阵营会利用它。其他阵营会直接复制一个类似的工具，导致每件事情都有完全冗余的工具。比如 Fabric 和……你知道吗？我乃至不记得这些工具的名字了……Capistrano。
Erik St. Martin: 哦，我记得 Capistrano。 (译者注: 很古老的一个Ruby写的服务部署工具)
Solomon Hykes: Java 当时也有自己的工具……全部东西都是重复造轮子。而我们希望打造一个全部人都能利用的工具，以是我们须要一种可以编译成二进制文件的语言。就像早期 UNIX 保卫进程（daemon）那样，比如 SSHD……谁会关心它是用哪种语言写的？它是一个二进制文件，你放在那里，它就能运行，对吧？以是这跟易用性有关，我们不想让用户必须额外安装运行时情况。
全部这些因素加在一起，我们终极努力投入了 Go。Docker 是我第一个用 Go 写的项目，显然这个选择很精确。我们确实搭上了 Go 普及的海潮，同时也为它做出了贡献。这就是我们选择 Go 的原因。
Adam Stacoviak: 说到这儿，Erik，你提到你近来参加了一个聚会会议，你们讨论过这个话题……Solomon 提到的这些题目，比如 Ruby 大概因为 Ruby on Rails 很盛行---Matz 自己也这么说过。你以为 Go 的盛行是因为像 Docker 或其他超等盛行的项目，比如 Kubernetes 如许的东西吗？我猜 Kubernetes 可以算是 Docker 的进化版，但你懂我的意思。那次聚会会议里是怎么说的？
Erik St. Martin: 我们主要讨论了 Go 的普及曲线。Solomon，你刚刚提到你选择 Go 是因为想要更多贡献者……但当时，Go 1.0 刚发布大概还不到一年。我以为 2014 到 2015 年是 Go 语言开始“曲线爆发”的时期。我以为 Docker 对此起了很大的作用。比如，“这是一个能彻底改变开发和运维方式的东西。这真的会改变一切。” 人们对它的实现方式很感爱好，他们想构建它，想为它贡献代码，我以为这吸引了更多人去了解 Go 语言。
以是我以为那一年是一场“完善风暴”。各种会议开始涌现，你有 Docker，还有……
Solomon Hykes: 是的，我们决定用 Go 的时间是在 2012 年底。
Adam Stacoviak: 那很早。
Erik St. Martin: 也就是说，1.0 发布后一个月左右。
Solomon Hykes: 当时，这个选择并不是显而易见的---它并没有被炒作，我们没有听到什么“哦，我们必须赶快参加这个潮水”的声音。更多的是，“嘿，我对这个很感爱好，我内心的黑客精神驱使着我……” 有时候，你会被某个工具或语言吸引，然后在之后才找出一些理性的理由来为你的选择辩护…… 这就是我对 Go 的感觉。而作为创业者，我想，“假如我有如许的感觉，那么我的目标用户---那些和我一样的黑客们、我希望他们利用我的工具的人---大概也会有同样的感觉，以是不如跟着这种直觉走，顺势而为。” 结果证明我是对的。
Adam Stacoviak: 离我们第一个中场苏息---大概说是这次节目中唯一的苏息---还有约莫六分钟。带我们回到你做出这个选择内部争论的场景吧。明确一点，这是你为 Docker 的未来选择 Go 而非 Python 的决定，对吗？
Solomon Hykes: 是的。
Adam Stacoviak: 那么，在这个过程中，你是如何向团队倾销这个决定的？特别是因为你们在转型，而且赌注很高…… 乐成的压力很大。你是怎么让各人担当这个决定的？
Solomon Hykes: 起首，到 2012 年底，我们还没有真正开始转型，对吧？要说明的是，当时我们公司大概有 20 人，其中 18 个人都在做 DotCloud。然后是我和别的一个工程师在做这个副项目。以是在内部，这个项目有一段时间被看作是“Solomon 的宠物项目”。各人以为，“他想继续写代码，那就让他写吧……”
Adam Stacoviak: “…让他搞他的东西。”
Solomon Hykes: “…让他搞他的事情，就如许。” 以是当我说，“嘿，我们用 Go 来做这个吧”，最大的反对意见（[音频不清晰 00:23:11.08]）是以为它太新了，而且没须要为了新而改变。以是有点像那种“滚开，别搞这些花哨的新潮玩意儿！”的反应。而这里我想澄清一点，这对很多人来说大概很意外，因为现在 Docker 有点成为了“新潮开发者工具”的代名词，这让我以为很搞笑。实在 DotCloud 是一家运维驱动的公司。我想我们曾经运行着世界上最大的公开部署的 Linux 容器集群；固然，Google 有他们自己的东西，但假如你想部署容器，我们运行着最大的生产情况的 Linux 容器集群。以是我们是一个运维团队，我们在容器中运行数据库、各种语言栈……
Docker 是从实际的运维履历中诞生的。固然后来，它被一个非常兴奋的开发者社区所担当，我们不得不管理社区中多样化的意见和需求（我们之条件到过）。但重点是，在 2012 年，我们绝对是一个对任何新东西都充满怀疑的“老派”运维团队，因为新东西会坏掉，新东西有时只是为了追逐潮水。以是最大的反对声音是“又来玩新玩具了”…… 但终极各人还是以为，“嘿，反正这是 Solomon 的玩具项目，就让他玩吧。”
Adam Stacoviak: 哇…… 以是根本上你是靠自己是“老板”这个身份来推动这件事的，用“他喜欢折腾，就让他折腾吧”如许的方式。
Solomon Hykes: 事情是如许的，实在我不须要去说服谁，因为谁人被借调来帮我做这个副项目的工程师辞职了……
Adam Stacoviak: ……以是根本没人反对。
Solomon Hykes: 就只剩下我一个人…… [笑声] 后来我找了另一个工程师---Andrea，他现在仍旧是 Docker 的明星工程师。他负责写硬件系统接口…… 他写了 LXC 的接口，而我则负责写 UI，也就是前端部门。
Adam Stacoviak: 一开始 Go 的哪些特性吸引了你？实在我想问的是，有什么详细原因让你选择 Go？你提到过编译为二进制文件可以镌汰麻烦之类的，但还有什么？
Solomon Hykes: 这些是外部原因，详细来说是为什么 Go 适合这个项目（Docker）。但从一个黑客的角度来说，吸引我本能地选择 Go 的原因是---我受过 C 系统工程师的练习，后来转用 Python，因为有段时间用 C 做全部事情着实太浪费时间了。从 Python 开始，我们用上了一个非常酷的框架，我乃至不记得它叫什么了……似乎叫 gevent？对，就是轻量级线程，也叫绿线程。以是用 Python 加上 gevent 大概 greenlet（我忘记详细名字了），你可以用一种类似 Go 和 goroutines 的范式写代码。你可以用过程化的风格写代码，同时获得类似回调的利益，但又不会陷入回调地狱和代码杂乱的困境，而当时 Python 的另一种方式就是 twisted。
在 DotCloud，我们全部事情都用 Python 加 gevent 来做，但有时候我们会痛恨没有更简单的方法来利用 C。然后 Go 出现了。从一个用 Python 的 C 黑客的角度来看，Go 是两者的完善联合。它拥有 C 的全部优点---编译型语言、轻量级、对内存的细粒度控制等等，同时也有像 Python 那样方便的高级语法，还有一个优秀的标准库。Python 开发者已经风俗了依赖高质量的标准库，而 Go 也提供了同样的东西。这和 Ruby 不一样，我的履历是 Ruby 就像一个巨大的实验性集合，你永远不知道它什么时候会崩溃。
我以为 Go 早期就带来了那种对高质量、可靠的标准库的专注，这真的戳中了我的全部点。
Erik St. Martin: 我知道我们已经凌驾 Adam 之条件到的苏息时间了，他总是很注意时间的。以是我们现在进入本期节目的赞助商苏息时间。今天的赞助商是 Toptal。
苏息时间：
Erik St. Martin: 好的，我们返来了，继续和 Solomon Hykes 聊天。Carlisia，我记得在苏息前你对 Adam 的题目有一个后续题目……你现在想继续问吗？
Carlisia Thompson: 是的，Adam 提了一个很好的题目，但我以为我们还没有得到答案。他问的是：“Docker 对 Go 的盛行有什么影响？”这个题目有被答复吗？
Adam Stacoviak: 我不确定，我想他当时讲到了一些 [音频不清晰 00:28:43.01] 和 Go 的特性，虽然我很想听听这个题目的答案。比如我们常听到像 Matz（Ruby 的创造者）谈论 Ruby on Rails 对 Ruby 的影响……而你，Solomon，作为 2012 年早期选择 Go 来做 Docker 的人，你以为 Docker 对 Go 语言有什么影响？
Solomon Hykes: 我偶尔会问自己这个题目，但说实话，我并不完全清楚。我的感觉是，Docker 早期利用 Go 简直起到了验证 Go 的作用，在 Go 显着开始盛行但仍须要一些大型项目来证明实在用性的阶段，这种验证尤其紧张。我以为在某些时候，我们大概是当时最大的 Go 项目，尽管我不确定今天是否还云云……但现在的重点是，Go 已经不再须要如许的证明确。
我以为现在我们只是 Go 生态中的一员，我们以这种方式做出贡献，但 Go 已经不再处于须要通过特定项目来证明自己代价的阶段。我以为它现在是一门主流语言了，这真是太棒了。
Erik St. Martin: 这很风趣，因为在差不多同一时间，Brian 和我在筹办第一届 GopherCon 时也有类似的想法。我们不想把会议安排在旧金山，这也是为了证明这不仅仅是 Google 的语言，而是一个超越 Google 的东西。以是那一年我们根本上都在为语言辩护，像是“不是的，不只是 Google 在用 Go 写东西。”
Solomon Hykes: 是的，我记得我们实在也经历了类似的过程……我们做了一点尽职调查。就像我说的，我是发自内心地决定利用 Go，然后假装自己是在通过正式的理智决议过程。我记得我们当时探求了一些证明点，但确实找不到什么高知名度的、在 Google 外部利用 Go 的成熟且大型项目。不过我记得有一点让我下定刻意，那就是在 Google 内部---当时还不清楚 Google 其着实生产情况中用了多少 Go，但我记得有一次 Google 的博客上发了一篇文章，提到……我忘了谁人服务的名字，但它是 Google 的一个定制 MySQL 前端……
Erik St. Martin: Vitesse。 (译者注: 实际是 vitess)
Solomon Hykes: 是的，没错……我想他们后来开源了，但当时还没有开源。不过他们在博客中提到这个服务是用 Go 写的，而且说整个 YouTube.com 前端的 MySQL 查询关键路径都通过了这个服务。我当时简单地在脑海里算了一下，以为“好吧，我可以用这门语言。”
Adam Stacoviak: 很棒。
Solomon Hykes: 以是那是当时让我信服的点。
Erik St. Martin: 是的，我记得实验运行 Vitesse……真的非常酷。我们现在有点在聊过去的回忆，我想渐渐转到 Docker 的成长以及它现在的状态。但我有一个题目是，既然你们这么早就开始采用 Go，乃至到现在，当时 Go 的标准库和周边工具并不多，而采用新语言的一部门本钱就是不得不自己写很多东西……在这个决议过程中，你们碰到了哪些绊脚石？
Solomon Hykes: 没有什么特别大的题目。我们碰到过很多战术上的题目，尤其是在第二年，当我们开始真正深入到系统层面的时候。Docker 的特点是，在早期，它是一个基于现有命令行工具 LXC 的封装工具。实际上，开发 Docker 的一个动机就是因为 LXC 的命令行工具完全不可靠，在运维中会出现各种可怕的不一致性。比如，同一个命令有时会失败然后返回，有时会直接挂起且永远不返回……根本无法猜测结果。因此我们须要在其上构建一个稳固可靠的层……顺便说一句，现在我们常听到一些“古板的人”（姑且这么称呼吧）说：“哦，Docker，只是个潮水工具……LXC 才是真正的‘硬核工具’。” [笑] 但我可以告诉你们，作为运行了几百万个基于 LXC 容器的生产情况的人，与那些“古板的人”不同，用 LXC 并不风趣。
重点是，因为我们做的是封装，以是早期并不须要太复杂的系统交互。我们根本上是调用 LXC 的命令行工具，然后剖析它的输出，类似这种方式。以是我们并没有真正触及标准库的极限……固然，我们也碰到过 bug、不稳固和性能题目，但没有什么特别值得记着的。
到了第二年，当我们替换掉 LXC 并实现了一个直接调用 Linux 内核功能的库，叫 LibContainer……在那时我们碰到了一些题目，但诚实说，没有什么特别值得记着的实例。实际上，思量到 Go 的采用率和成熟度，我不停对它的标准库的质量和广度印象深刻，尤其是相对于语言的成熟阶段。假如你理解我的意思的话，这真的是一个运行得非常好的项目，质量非常高。
我们不停在为 Docker 的最新版本采用 Go 的最新版本，从未落后过。我们从来没有想过“哦，让别人先经历痛苦，我们再升级。” Go 项目让我们学会了信任他们的最新稳固版本……顺便说一下，我希望我能说 Docker 从一开始就达到了同样的水平，但这花了一些时间。
Carlisia Thompson: 那现在呢？你们有没有一个明确的点，比如“现在利用标准库以外的现有库是合理的”？大概 Docker 或 Moby 有没有一个哲学，比如“我们不利用外部库，只用标准库，一切都自己写”？你们有如许的规则吗？假如没有，你们如何决定“现在值得利用一个外部库”？大概说你们是否有一些类别会思量利用外部库，但其他类别不会？
Solomon Hykes: 起首，我听到你提到了“Moby”，那么稍后我可以针对这个题目做个说明吗？
Adam Stacoviak: 是的，我们很快会聊到这个话题。
Solomon Hykes: 答复你的题目，起首，我现在不太直接订定这些规则了……我们已经把这种决议权下放给了很多维护者，但我以为我们不停遵照的是常识性的规则。假如标准库能实现，就用标准库；假如有外部库能实现，就查抄它的更新情况、维护者的响应速率、利用的人数，假如感觉靠谱，那就用。
假如以上都不满足，那就自己写，但要小心别浪费太多时间。假如后来发现有很多人须要这个功能并终极利用了你的实现，那就尽早把它分离出来，酿成一个独立的库，如许它就不会和你的项目绑定得太紧。
我以为我们就是遵照了这些原则，但我以为我刚才说的这些实在适用于任何 [音频不清晰 00:36:18.05] 软件项目。我们并没有做什么特别不同的事情。
Carlisia Thompson: 听起来很合理，是的。
Adam Stacoviak: 我们今天来到这里……现在已经差不多是四年以后了。Docker 很酷，各人都在用它……我们进入了一个全新的世界，在这个世界里，Docker 根本上就是容器范畴的代名词。你们已经拥有了这个名称。假如你谈到容器，你根本上就会说 Docker，对吧？这就是我们现在所处的情况，乃至在命名事物时也是云云。Solomon，你提到了 GoTime FM 聊天室，以是假如你是在之后（不是直播时）收听这个节目，我们是每周四直播的，你可以在 GopherSlack 的 GoTime FM 频道和我们一起交换；我鼓励你参加，但假如你没参加，也不要紧。不过在聊天中，我们讨论了 Docker 过渡到新名称 Moby 的事情。
新闻出来了---我猜大概是三周前，也许一个月前……我这段时间有点忙于自己的事情，不太确定详细时间线，但你们已经进入了一个新阶段，并且改变了这个非常知名的品牌名称 Docker/容器，而且……你怎么敢如许做？为什么会发生这种事情？[笑声] 我以为这是各人的反应，至少在我看来是如许的……就像，“你为什么要这么做？” 你们内部的看法也是一样的吗？
Solomon Hykes: 是的……这确实是一个很大的改变，就像任何大的改变一样，它须要一段时间才气灰尘落定。这是一个真正渐进的改变；是一个持续的变革。只是某个时候你须要启动它，而 DockerCon 上个月就是我们启动它的时间点。
Adam Stacoviak: 好吧，那就是约莫一个月前了。
Solomon Hykes: 是的，没错。以是在谁人时间点之前我们进行了很多工作和渐渐的改变，而在谁人时间点之后也会有很多渐渐的改变和工作，但我想对于很多人来说，这个公告固然是他们第一次听说这件事。关键是，这是一个根天性的转变，我们为此已经努力了很长时间，诚实说，我以为我们本可以在公告的一些战术方面处理得更好……但起首，我想先谈谈“各人”这个词，因为 Docker 的一个非常风趣的地方是---这要追溯到我们讨论的最初话题，“谁是 Docker 社区的一员？这个社区有多大？有多统一？有多样化？” 答案是：“它非常非常大，也非常非常多样化”，我以为你可以从这次改变的反应和认知中看到这一点。
Docker 现在，一方面是一个开发者用来开发应用步伐的平台，运维人员用来部署和管理应用步伐的平台，我们可以在小型项目（业余爱好者）、小型企业中看到这一点，现在也可以在企业中看到。现在有一些非常大的构造，他们的开发者整天都在利用 Docker，运维人员也整天都在利用 Docker 来运行各种应用步伐。这是 Docker 的一个方面，也是 Docker 社区的一个维度。
然后还有另一个方面，这是一个开源项目，专注且充满热情的黑客们一起在代码中协作，利用这些技能来做与容器相干的事情，对吧？容器运行时、容器网络、容器存储等等。我们有一个由系统黑客构成的开源社区。这个社区要小得多，也更加专业化。对我们来说，这个比例约莫是 1 比 1000。
以是须要意识到的关键是，向 Moby 的切换对第二个群体，也就是开源贡献者社区，有积极的影响；这是目标。目标是改善开源社区的情况。
这对我们的用户社区或客户完全没有影响。大概说，假如有影响，也是间接的。换句话说，假如你从更大的范围来看这个社区---任何曾经访问过 github.com/docker/docker 的人都属于这一组群体，较小的群体，更专业、更了解内部工作原理的群体，他们实际上在参与创建它。
但对其他全部利用 Docker 的人来说，什么都没有改变。Docker 还是 Docker，仍旧以同样的方式更新，它拥有雷同的功能，雷同的接口，雷同的免费版本和付费版本……以是，为了给出配景，这是一个须要记着的紧张维度。
Erik St. Martin: 以是我想这是一个关于认知的题目，也有点狐疑……是的，我以为很多人以为“哦，现在是 Moby 容器了，现在我要运行 Moby 命令了”，但你根本上是在说，假如你没有接触 Docker 的代码，你永远不会知道。假如你是一个 Node.js 开发者，你只是用 Docker 部署应用步伐，你仍旧在利用 Docker，你仍旧会去 Docker.com 下载 RPM 文件或其他东西来安装它。
Solomon Hykes: 完全精确。我以为造成这种狐疑的部门原因是我们没有很好地解释清楚。
Adam Stacoviak: 假如你不介意我这么说的话，这看起来像是---我不会说是太早发布，但看起来你们没有充分思量到它的影响，也许……我不知道，这似乎有点像是被随意抛出来的。你以为这是如许执行的吗？还是你以为它没有被富足用心地处理？我没有负面的意思；只是以为你们似乎没有把它当成一件很紧张的事。
Erik St. Martin: 我以为当你离题目太近时，你不肯定能看到外界人们的看法。以是，当你在这个项目上工作时，你会以为，“哦，这完全说得通，我们在做 Moby；它根本上是 Docker 的上游。人们用 Docker，一切都很好……”
Adam Stacoviak: 这也是为什么我开场时提到 Docker 和 Xerox 的类比，因为在我看来---我相信在很多开发者看来也是云云---当你想到容器时，你就会想到 Docker。以是，当你对容器的品牌名称或这一运动（可以这么说）进行改动时，实际上是在搞乱容器的名字，这会让很多人不满。
Solomon Hykes: 是的，我以为这是一个完全合理的题目。确实，我们在整个过程中投入了很多精力；我们中有很多人已经为这个改变努力了一年半时间……
Adam Stacoviak: 对。这看起来不像是你们会盲目去做的事情，思量到你分享给我们的内容，这也是为什么我们从最初的怀旧情绪开始聊起。你们在最初过渡到 Docker 时投入了很多心血，以是显然，在转向 Moby 时也会同样慎重。
Solomon Hykes: 我们确实很慎重，但我以为我们在过程中犯了一些战术上的错误。整个过程本可以更顺畅一些。我不会深入讲整个配景故事，但我以为我们确实做出了一些错误的判定。从大局来看，这只是第一天，紧张的是接下来会有多少贡献继续流入，项目的健康状况如何，Docker 产物的未来发展如何，有多少人会继续利用它，以及他们会有多满意，等等。
诚实说，我以为再过六个月转头看，这会像是雷达上的一个小点。关键是接下来的六个月里，我们执行得如何……我做过很多产物发布；没有任何一次发布是完全顺利的，总会有一些题目出现。就这次来说，我以为出题目的地方---举几个细节或例子---是我们在沟通上尽力优化了两个完全相反的群体。
我们花了很多时间与项目维护者沟通。这是一个非常小的群体---实际上只有不到 50 人拥有项目或其某个组件的提交权限。
我在公告发布前两个月就开始了一封电子邮件讨论，讨论 Docker 作为一个开源产物和 Docker 作为一个开源项目之间的抵牾……还有围绕这两个（产物和项目）的社区不同，它们有不同的盼望，有不同的需求，而我们已经达到了一个规模，这种肴杂变得成了题目。这封邮件中我们还讨论了 Red Hat 在 Fedora 和 Red Hat Enterprise Linux 分离上的做法……以是我们在这个讨论线上投入了很多精力，持续了两个月。
另一方面，我们也努力确保不会对我们的用户和客户造成干扰。任何利用 Docker 的人，我们都想确保他们不会受到影响，同时他们也能理解 Moby 的变革。以是我们花了很多时间为主流人群（我指的是我们的主流人群）计划一个可以理解的故事。你仍旧须要是开发者，大概是了解并关心 Docker 的人，但你不须要是容器引擎的开源贡献者。我们花了很多时间思考如何以最佳方式解释这件事，因为这是一个复杂的话题。实际上，我们切换到 Moby 的根本是改变了我们的生产模式……
从利用 Docker 的人的角度来说，我们是在说，“嘿，我们正在改变 Docker 在底层的生产方式，假如你感爱好，这里有一个高层次的解释，告诉你这对你意味着什么以及为什么这是件功德。” 我们为此进行了优化，这也是我们在 DockerCon 大会主旨演讲中讲述的故事。我以为假如你对这个话题感爱好，可以去看看谁人 主旨演讲（我想我们已经把它放到网上了）。这是第一天的主旨演讲，内里有很多图解……以是，这也是我们关注的另一个方向---向我们的主流用户社区很好地解释这件事。
我们做了这两件事，但我以为我们犯的错误是低估了中间人群的反应。这个中间人群是很多访问我们 GitHub 仓库的人，他们在开源项目中有一些参与，但很浅层；他们不是活跃的提交者，也不是项目的管理者，但他们也不是那些从来没有看过 Docker 源代码的应用开发者。他们介于两者之间。诚实说，我以为对于这个中间社区，我们并没有准备好一份解释。
我们的计划是“让我们公布我们的意图，把代码库搬到一个新地方，然后邀请社区一起来帮助我们执行这次更开放的变更，看看会发生什么。” 结果就是一段时间里，这个变革引起了极大的狐疑和愤怒。
Adam Stacoviak: 这感觉就像是硬生生地撕掉了一个创可贴。
Solomon Hykes: 是的，我以为是如许，但我们当时的希望是---再给一些配景……抱歉，我有点跑题了……
Adam Stacoviak: 不要紧，不要紧。
Solomon Hykes: 来自开源贡献者社区的很多批评---其中的一部门---是我们在某个时候开始的行为更像是一个产物……Docker开始变得更像是一个公司驱动的产物，而不是一个社区驱动的项目。我谈到了这个冲突，即Docker作为项目和Docker作为产物之间的抵牾；这个话题我们与维护者进行了深入讨论，但之后却忘记与其他人讨论。
我们讨论的范例例子是Docker 1.12的发布，谁人时候我们推出了内置的编排功能。这让很多贡献者非常生气，主要有两个原因。第一，我们没有提前告诫他们；我们在Docker内部秘密开发了这个功能，然后才推出，这对于一个产物来说是范例的做法，但对于一个项目来说却并不常见。因此，这真的突显了项目和产物之间的差异。
人们生气的另一个原因是我们没有利用Kubernetes来实现这个功能。有一部门贡献者同时也在为Kubernetes贡献，他们是这个项目的忠实粉丝，他们对我们没有利用他们的项目感到非常愤怒……我们怎么敢？顺便说一下，我以为Kubernetes是一个很棒的项目。我们确实思量过利用它，但终极决定不利用；这只是一个工程上的决定。
无论如何，我想说的是，因为我们受到云云多的批评，因在封闭的情况中办事情并在发布之前将其打磨得非常完善，我们想“嘿，关于Moby，我们就做相反的事。让我们做最小可行的改变”---就是将代码库从一个构造迁移到另一个构造---然后不做其他更改，再解释计划，然后与社区一起公开进行每个变更。这就是我们所做的，但却引发了相反的反响，即“这是什么？这很半成品。不清楚，发生了什么？”
我们以为通过将事情完全公开并让每个人参与来表现得非常友爱，但实际上我以为我们让很多人感到狐疑。以是……
Adam Stacoviak: 但这也许是毕竟……我们的生产交付因为名称更改而中断了几天……我想聊天中有一个题目：“为什么那么多人[听不清 00:49:59.06]”我以为这大概只是docker/docker与moby/moby之间的区别……本质上是一个改变，这大概让很多人感到狐疑。这个突如其来的变革就是我所说的……
Solomon Hykes: 实际上，真正出题目的事情非常少。我以为我们在重定向时出现了一个小故障，但根本上，全部出题目的东西都是轻微堕落，并在当天修复。其他的主要是因为我们移动了代码库---从docker/docker到moby/moby。这让人看起来我们是将Docker产物更名为Moby产物。
Adam Stacoviak: 因此，才有Docker/Xerox的比较，因为“为什么要改变这个？”说实话，我们想和你在这个节目中进行对话的原因就是希望你能分享这些细节。我以为现在从你这里听到这些，与通过博客文章（黑白文字）相比……你无法看到面貌或听到语调，也无法理解或人的真诚，因此很难了解一个构造做出如许的选择的真正原因，而现在从你这里听到的这些是有道理的。你确实是试图在公开的情况中做这件事，试图拥抱社区，这对我来说非常酷。我很感谢你有如许的感觉，因为这表明你关心并拥抱黑客社区，而你固然是其中的一部门。你不再只是Docker，你依然是谁人老旧的Solomon，但我以为你采取的这种方式很酷。只可惜终极却适得其反。
Solomon Hykes: 是的。谢谢，我很感激。说实话，过去四年我们处理的事情中，这次的反响算是相对暖和的。现在我们只专注于改进它，并关注Moby带来的酷炫功能。
关于Moby，除了名称分离之外，最酷的是现在有了开放源代码项目和开放源代码产物的地方……真正令人兴奋的是，它使我们能够进一步将平台拆分成组件，而这正是其紧张之处，因为Moby并不是一个代码库，而是一个组件的集合。它险些像一个发行版。它并不是Docker的全部组件的家，Docker有很多组件---比如Containerd、SwarmKit、Libnetwork、Notary……还有很多其他的，每一个都作为独立项目推出。
假如你喜欢Containerd---Containerd是核心容器运行时，做全部这些事情，但没有承载Docker平台的额外负担和看法；它只是运行Linux容器，提供低级API来实现这一点，正在成为执行这一操作的毕竟标准。因此，即使你不利用整个Docker，假如你在利用容器，很大概会利用Containerd。我们把这个项目捐赠给了一个独立的基金会---我们把它捐赠给了CNCF……以是它不是Moby的一部门，但Moby将其集成到我们称之为“组件组合”的内容中。
我们将对每一个组件做同样的事情，终极你会看到三个阶段，我在你之前粘贴的聊天中画的谁人小铅笔画；我们在供应链中有三个阶段。最上游是各个组件，然后将它们集成到Moby中，但关键是因为它在社区项目中集成，Moby中的不同参与者可以以不同的方式集成这些组件。
可以把它想象成一个乐高俱乐部。你去乐高俱乐部，有一个巨大的箱子，内里装满了你梦寐以求的全部零件，然后各人都聚在这个大桌子上，每个人都在做自己的城堡、雷神或其他东西，假如你想参加一群孩子一起玩，你可以参加，但重点是你可以做自己的……而且，没有强制性的乐高建立你必须参与。这就是我希望在接下来的几个月中强调的Moby方面，而不是名称更改。它在这方面真的很酷，大概一旦我们完善工具，它会变得更酷。你的容器平台会有无数种变革，而Docker只是其中之一。
在这种情况下，Docker就像一个专业的乐高艺术家，有很多人喜欢我们的乐高创作，但我们会和其他人一起待在同一个俱乐部，在同一张桌子上构建我们的乐高作品，与其他人互助，假如有人喜欢，他们可以像从前一样参加，因为这是开源的……但假如他们不喜欢，大概他们只喜欢其中的一部门，想用同样的乐高砖做不同的事情，他们也可以做到。在这个比喻中，Moby就是俱乐部---就是桌子，就是装满全部砖块的箱子。这才是Moby的真正目标。
Adam Stacoviak: 或许我们可以请你再次回到Changelog来深入讨论这个部门。很遗憾我们花了很多时间讨论名称变更，因为我以为这必须谈论，但在没有讨论名称变更的情况下，无法谈论你提到的接下来六个月的事情，这确实让很多人狐疑。
你花了好几年时间为Docker和这个开放容器规范辩护，试图做不同的事情，这种转变似乎是对多年来你提到的各种批评的回应。
Solomon Hykes: 是的。大概我们叫它建立性的反馈。[笑声]
Adam Stacoviak: 没错，建立性的反馈。批评是我的词……我不以为你直接这么说，以是我不是在给你下界说。
Solomon Hykes: 须要记着的是，当我们开始Docker时，我们在DotCloud开源过东西，但从未达到过谁人规模，对吧？而且，这还是公司开源；没有真正努力去创造一个各人同等参与的社区。但从第一天起，Docker就是如许的模式；我们把它隔离了。我们在这个过程中学到了很多东西。我们观察其他项目的做法，进行了模拟……我们还实验了很多人告诉我们是好主意的规模化做法，然后因为在我们这个规模下，这些做法并不好而破坏了。人们经常忘记，能够在Docker规模下运作的项目非常少。
确实有项目，我们不是唯一的，也不是最大的，我们绝对在前0.1%之内。就像系统在大规模下的行为会有所不同，有时候规则也会改变---在小规模下看似显而易见的事情，在大规模下大概会神秘地破裂；对于项目来说也是一样的道理。
以是部门原因是我们必须向那些做开源的人解释，他们为自己做开源而感到自大，并且自信地以为他们了解开源---他们确实了解，但他们不了解我们这个规模的开源。现在我听自己说，这听起来有点自大，但我们也必须面对这个现实。有时候，现实是我们更了解，但这不是一个受欢迎的说法。
我们只是去实验，然后努力回应。假如有人指出某些东西坏了，我们总是谛听，并积极工作去修复它。在内部，我们团队有一种文化，总是讨论破坏的东西，总是谈论题目，我以为我们也许应该做得更好，去展示这一点……但我们真的在做。
不过，我们面对的题目是，因为我们是云云大的目标，每天我们都收到数百条反馈；我们受到一百多条批评，我们必须从那巨量的批评中提取出最紧张和可行的内容。为了做到这一点，我们须要从那些情绪不佳的人、那些只有特定小众用例的人、那些在谈论意见而非毕竟的人中筛选出来……这须要时间，确实很困难，我们总是畏惧，“我们是否遗漏了被噪音沉没的紧张反馈？”顺便说一下，假如你知道哪些工具或技能可以帮助做到这一点，我们不停在探求。
Erik St. Martin: 我知道我们还有几分钟的时间……我很好奇，现在我们有了Moby和分离，你提到过接下来的六个月……你对Docker未来一年的愿景是什么？五年的愿景又是什么？假如你有无穷的时间来自己对Docker进行开发，你会驱动什么？你希望看到什么样的功能？
Solomon Hykes: 很好的题目。[笑声]
Adam Stacoviak: 你把他打败了。
Solomon Hykes: 抱歉，我刚刚在想我整入夜客编程的事情……[笑]
Adam Stacoviak: 不错，Solomon。
Solomon Hykes: 你知道，现在有两组用户对Docker非常兴奋，迫切希望得到更多的东西：开发者和运维人员。我以为运维人员面对着一个巨大的题目，他们须要---他们须要一种新的操作系统，因为现在不再是单独的服务器了，而是像我们所知道的那样，大量的集群，多个集群，机器随时大概消失或在其他地方重新出现，基础办法变得极其复杂、快速变革且规模庞大，而现有的工具和操作系统显然跟不上。
以是，大型科技公司构建了自己的定制分布式操作系统，但其他全部人只能拼集工具和组件，然后用大量的胶带把它们联合在一起，试图创建一个运行它们的操作系统……而我们想要构建的就是这个。
我们从DotCloud的履历中学到一件事：你不能以单体的方式构建这个系统；你必须以模块化的方式来构建。因此，我们要么构建缺失的部门，要么与其他正在构建缺失部门的团队互助，然后学习如何将这些组件整合到一个合理、可在大规模下可靠运行的系统中。诚实说，我们还有很多工作要做。这是我想要专注的事情，也是我们正在积极开发的方向。
另一个方面是开发。外面有很多人有很酷的想法，他们想用代码构建一些东西，但这仍旧太难了。诚实说，我以为我们已经退步了，乃至比Basic或Excel公式的期间还要糟糕。那些都是让更多人能够利用编程来解决题目的巨大进步。
Erik St. Martin: 或SQL。
Solomon Hykes: SQL确实很酷，但你仍旧须要毗连到其他东西，对吧？但我想你说得对，它确实能表达与数据的交互。实际上，SQL也在这个列表之中。
Erik St. Martin: 是的，在那之前，你必须自己编写存储层以及如何检索和处理这些东西，这真的让它在更高的层次上变得更轻易接触。
Solomon Hykes: 对我们来说，因为Docker现在真的成了很多开发者的灯塔，他们想要构建一些东西，但面对很多题目，他们须要工具来解决这些题目，于是他们来找我们，告诉我们：“嘿，我想做这个……你能帮我吗？”诚实说，今天即使我们开发了很多工具，90%的时候我们的答复都是：“不，我们真的帮不了你。没有如许的工具。”但这让我们更想去构建这些工具。
以是我只想让开发者的工作变得更简单。诚实说，我以为我们才刚刚开始……而我不仅仅是指Docker。我是说，作为一个为他人制作工具的社区，我们还有很多工作要做。我以为我们须要进步标准；我们做得还不敷好。
Erik St. Martin: 我想我们差不多到尾声了；大概会超出几分钟……但还有几个题目，我们看看有多少时间。有人问，我记得是Marwin，在GoTime频道里提到，他读到了从REST API转向gRPC的变革，以及这背后的原因和细节。
Solomon Hykes: 哦，是的。这是Moby的一部门令人兴奋的内容---我们现在有了Moby项目，一个很好的框架，可以将Docker平台拆分成不同的组件，每个组件更具专业性，比如Containerd，Containerd就是一个很好的例子。每个组件险些就像一个小的微服务，对吧？从某种意义上说，我们在说：“假如每个应用步伐都朝着微服务模子发展，那为什么运行这些应用步伐的平台自己也不采用微服务模子呢？”这似乎是精确的做法。
曾多少时，我们试图为此编写自己的RPC层……我们早期在DotCloud有一个项目叫ZeroRPC，然后我们进行了很多与HTTP/2和SPDY扩展的实验。在HTTP/2出现之前，以是我不停是探求合适的RPC层的忠实粉丝，但我们从来没有时间真正推动谁人项目。后来gRPC出现了，并得到了广泛的关注，我看到Docker的很多工程师都在利用它。
Containerd是一个gRPC接口……它正在渐渐盛行，因此选择一个RPC层作为低级接口是一个务实的选择。你可以天生全部客户端和SDK等，这真的很不错。
现有的Docker API是一个更高层的API，现在是HTTP REST API。现在我们正在订定这个API的门路图。绝对的优先事项是确保不打破现有用户。因此，HTTP REST API将继续存在，因为我们当前的用户和生态系统在利用它，我们不想打破他们。
以是这更多的是针对全部新API的进步方向。我们起首利用gRPC，因为这是我们特定社区中人们利用的默认选项，但就是如许。假如你有爱好讨论这些，顺便说一下，你应该参加Moby论坛---forums.mobyproject.org。
Adam Stacoviak: 这是另一个很好的题目，任何结束的想法？我们快到尾声了，但这是一个很好的推广……假如你有讨论想要进行，那是个很好的地方，但在我们结束节目之前，Solomon，你还有什么想分享的吗？有什么结束的想法，大概是给Go社区采用Docker/Moby的一些发起？
Erik St. Martin: …为Docker做贡献？
Adam Stacoviak: 是的。
Solomon Hykes: 我以为Moby的整体目的就是将这个项目或一系列项目提升到一个新的水平。假如你对参与有爱好，大概还在犹豫是否贡献，我以为现在实际上是一个很好的时机，因为Moby表明我们在开源方面投入了更多精力；我们希望更多人参与进来，并且乐意提供帮助。
尤其是假如你是开源的新手，我们发现即使是有履历的步伐员也大概对第一次贡献感到犹豫；这是一种巨大的信任飞跃，感觉很陌生……有时你大概会以为这里像是一个俱乐部，而你大概不受欢迎，也许有些私人笑话你无法理解。随着我们社区的发展，这一点是我们必须时候牢记的。
在Docker初期，我们付出了很多努力，使其成为一个非常棒的地方，适合进行第一次开源贡献。我希望Moby也能做到这一点。以是假如你有爱好，请来参与，我们可以一起讨论。
Erik St. Martin: 我还想补充一点关于贡献的事情---假如你的拉取请求等候了很长时间，不要感到沮丧。Docker上有很多拉取请求，大概须要一个月才气处理完。我自己也有过请求等候的经历。项目着实太活跃了。
Solomon Hykes: 是的，假如你查看Docker的文档，会有一个专门的部门讲述如何贡献，我们将继续维护这个部门。我们还构造运动，特别的Docker聚会会议，你可以参加，在那里有导师帮助你选择适合的贡献项目，然后帮助你完成这个贡献。
以是这些运动对于开始开源贡献来说是一个很好的方式。
Adam Stacoviak: 我真的很遗憾我们没有讨论为什么叫Moby，以及这个名字的由来，但我们可以留到下次再谈……我只是想提一下，因为命名真的是一件很难的事情，对吧？
Solomon Hykes: 是的，这是祥瑞物的名字。约莫两年前，我们进行了投票，征求社区对祥瑞物、鲸鱼的名字的选择，社区选择了MobyDoc。现在，两年后，我们在创建一个项目，我们希望与Docker的联系明确，但也希望它有自己的身份，与Docker分开。我们鉴戒了红帽对Fedora的做法---它是一个帽子，有点像参考，我们也做了同样的事情。假如你看标记的话，它是鲸鱼的尾巴。就是如许。
Adam Stacoviak: 说得很好……不错。
Erik St. Martin: 我们已经超时了，但很高兴你能参加这个节目，Solomon。我真的很高兴你有机会来和我们谈谈Docker。
Solomon Hykes: 我很高兴。谢谢你们邀请我，我喜欢谈论这些话题。
Erik St. Martin: 希望我们能继续请你来，随着Docker的不停发展和在运维、开发范畴的扩展。
Solomon Hykes: 我很乐意。随时都可以！
Erik St. Martin: 感谢其他参与节目的朋友---Carlisia和Adam，谢谢你们从幕后走出来和我们聊天。
Adam Stacoviak: 随时欢迎！
Erik St. Martin: 感谢我们的赞助商Toptal对节目的赞助。肯定要把节目分享给其他Go步伐员。你可以在GoTime.fm找到我们，那里可以订阅我们的周刊……我们在Twitter，假如你想参加节目，大概有题目想问我们的高朋，请联系我们……那么，再见，各人！下周见。
Adam Stacoviak: 再见！
Carlisia Thompson: 这真是太好了！谢谢你，Solomon。
Solomon Hykes: 谢谢你。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
