十个有关Docker让开发人员失去热情的神话

本文讲的是十个有关Docker让开发人员失去热情的神话【编者的话】近年来Docker及其生态系统日益完善，但是尽管如此，围绕着Docker本身还是有一些神话或者说是误解来阻碍开发人员使用Docker的热情的，本文列出了十个有关Docker的神话，并且探讨了各自的解决方案。

最近在一次谈话中发生了一件奇怪的事情。

我在讨论Docker的发展，但是会不停地听到一些不太对劲的信息。
“Docker本质上是更加企业级的” “Docker只能暂时性地工作在OS X中，几乎不能在Windows上工作”
“我不相信我可以在本地运行Docker而不会有一堆的麻烦”
。。。等等更多

这些陈述中有一些细微的真相（例如下文中的#3和#5），但细微的真相往往使人们很容易忽视什么不是真实的，或者不再是真实的。

那些只是抛出各种术语的文章需要过度数量的框架并且讨论如何利用只有30000个容器来管理每秒十万亿次的请求，这些容器是被托管在600个云服务实例上的，自动化5000个微服务。。。

嗯，现在很容易看得出来围绕Docker有一个很大的神话了。

不幸的是，神话和误解仍然存在，虽然它们除了阻止开发人员尝试Docker之外很少做什么。

所以，让我们来看看最常见的神话——有一些是我已经看到的，还有一些是我以前相信的——并试图在其中找到真相以及如果可以的话，找到解决方案。

神话#10：我不会用Docker开发。。。因为我不能编辑Dockerfile

作为一个开发人员，我在工作时需要特定的工具和环境配置。我也被告知（理应如此）我不能编辑生产环境的Dockerfile来添加我需要的内容。
生产环境的Docker镜像应该只为生产目的而配置。

所以，我怎么用Docker来处理开发需求呢？如果我不能编辑Dockerfile来添加我的工具和配置，我到底该如何在Docker里开发应用程序呢？

我可以复制黏贴生产环境Dockerfile到我自己的环境里，然后按照我自己的需求修改这个文件。但是，我们都知道，重复是万恶之源。并且我们都知道，重复是万恶之源。因为副本是万恶之源。

解决方案

更好的解决方案是使用Docker模式从一个基础镜像构建镜像，而不是复制Dockerfile从而可能导致的更多的问题。

我已经从一个形如“node:6”的基础镜像构建了我的生产环境镜像，所以，为什么不创建一个“dev.dockerfile”并且以应用的生产环境镜像作为基础镜像来构建呢？

现在我可以修改dev.dockerfile来适应我的开发需求，并且知道其将从生产环境镜像使用确切的配置。

想要看到一个Dev镜像的实战吗？

在《Docker构建Node.js应用指南》的一部分——“ Creating a Development Container ”里检出WatchMeCode视频片段即可。

神话#9：我看不到容器内的任何东西，因为我根本看不到我的容器！

Docker是应用的虚拟化（容器化），不是一个用于通用计算用途的完整的虚拟机。

但是开发人员常常需要把一个容器当成一个虚拟机来看待。

我需要获得日志（而不是应用的简单的控制台输出），检查调试输出并且确保我放入容器中的文件和系统的变化满足我所有的需求。

如果容器不是虚拟机，我怎么知道是怎么回事？在容器中，我如何查看文件、环境变量和其他需要的东西？

解决方案

虽然Docker在技术上不是一个完整的虚拟机，但它在底层运行的是一个Linux发行版。

这个发行版也许是一个精简的最小的发行版比如Alpine Linux，但它除了别的之外仍然拥有基本的Shell访问功能，并且由于拥有一个Linux发行版作为容器的基础镜像，如此赋予了我们深入容器内部的选择机会。
根据不同的情况，有两种基本的方法。

方法1：Shell进入一个运行中的容器

如果容器已经启动并运行中，我可以使用“docker exec”命令进入容器内部，并拥有完整的shell访问权限。

一旦我这样做了，我就可以深入容器内部，就好像我shell进入任何一个Linux发行版一样。

方法2：以容器命令运行Shell

如果没有一个已经启动并且正运行的容器——并且我不能获得一个运行的容器，我可以从一个镜像运行一个新的容器，这时可以将Linux Shell作为一个命令来启动。

现在我有了一个新的带着shell运行的容器，允许我非常容易地四处看看。

想要看到一个Shell实战吗？

在《Docker构建Node.js应用指南》和《Docker学习指南》里检出下面这两个WatchMeCode视频片段即可。

Docker Exec Commands in a Container
Start an App w/ a Debugger Attached

神话#8：我不得不在Docker容器里编码吗？但是我不能用我最喜欢的编辑器？！

当我第一次使用Docker容器，并且运行了我的Node.js代码，我为这种可能性感到兴奋。

但这种兴奋感很快就消失了，因为我想知道在构建了镜像之后我应该如何将编辑过的代码移动到容器中。

我每次都应该重新构建镜像吗？这是非常痛苦的缓慢过程……着并不是一个好选项。

OK，我应该shell进入容器内部用vim编辑代码吗？

这个也许可以考虑的。

但是，如果我想使用更好的IDE或者编辑器，这就不允许了。我不得不一直使用类似于像vim这样的编辑器（并且或许不是我喜欢的vim版本）。
如果我只有命令行/Shell访问我的容器，我如何可以使用我喜欢的编辑器呢？

解决方案

Docker允许我们使用“volume mount”选项从宿主机系统挂载一个文件夹到一个目标容器。

借助这个选项，容器的“/var/app”文件夹将会指向本地的“/dev/my-app”目录，用我喜欢的编辑器在“/dev/my-app”目录里编辑代码，自然地就会改变容器内部可以看到及使用的代码。

想要看到一个在一个挂载卷里编辑代码的实战吗？

在《Docker构建Node.js应用指南》的一部分“ editing code in a container ”检出WatchMeCode视频片段即可。

神话#7：我不得不使用一个命令行调试器……我非常喜欢我的IDE调试器

有了可以在容器内部编辑代码并将其生效的能力，再加上可以shell进入容器，就离调试代码就只有一步之遥了。

在编辑完有问题的代码之后，我只需要在容器内部运行调试器，对不对？

这当然是真的——我可以在Docker容器内部使用编程语言的命令行调试器——这不是唯一的选项。

然后问题就是怎么可能使用我喜欢的IDE或者编辑器的调试器调试容器里的代码？

解决方案

简短的回答就是“远程调试”。

然而，长一些的答案就是非常依赖于开发使用的语言和运行时环境了。

举例来说，针对Node.js，我们可以通过TCP/IP端口（5858）来进行远程调试。然后，为了通过Docker容器进行远程调试，我只需要从我的Docker镜像（无疑就是“dev.dockerfile”镜像）公开那个端口即可。

借助于那个公开的端口，我可以在附加我喜欢的调试器之前先shell进入容器并使用任何典型的启动Node.js调试服务的方法。

想要看到使用Visual Studio调试一个Node.js容器吗？

在《在Docker里构建Node.js应用指南》的一部分“ debugging in a container with Visual Studio Code ”检出WatchMeCode视频片段即可。

神话#6：我不得不每次运都行“docker run”，但是我记不住“docker run”的所有那些选项……

毫无疑问，Docker有大量的命令行选项。查看Docker的帮助页面就像阅读一个已经灭绝的文明的古老神话巨著那样痛苦晦涩。

当来到“运行”一个容器的时刻，那么并不奇怪，我经常混淆或者沮丧透顶，从来没有在第一次获得正确的选项。

而且，每一次调用“docker run”都会从镜像创建一个新的容器实例。
如果我需要一个新的容器，这是没有问题的。

然而，如果我希望运行一个我以前创建的容器，我不会喜欢“docker run”的运行结果，这是另一个新的容器实例。

解决方案

我不需要在每一次都运行“docker run”。

相反，我可以“stop”和“start”正在谈论的容器。

这么做正如我所期待的会允许关闭和启动我的容器。

这么做也可以持久化容器在运行时的状态，这意味着我可以从容器关闭时的状态重启。如果我修改了容器内部的任何文件，那些改变可以在容器再一次启动的时候完好无损的。

想要看到启动和停止容器的实战吗？

《Docker构建Node.js应用指南》和《Docker学习指南》里边有很多WatchMeCode视频片段使用了这个技术。

然而，如果你有了新的想法，我推荐你观看 basic image and container management 视频片段，该片段包括了停止和重启一个单独容器的实例。

神话#5：Docker几乎不能在MacOS和Windows上工作，并且我用的就是Mac/Windows

直到几个月前，这在很大程度上还是对的。

在过去，Mac和Windows上的Docker需要随着“docker-machine”工具使用一个完整的虚拟机，以及一个额外的软件层来代理进出虚拟机的工作。
它可以工作……但是它引入了大量的开销，同时限制（或者排除）了某些特定功能。

解决方案

幸运的是，Docker明白目前需要的不是仅仅支持将Linux作为宿主机操作系统。

在2016年下半年，Docker发布了官方的Docker for Mac和Docker for Windows软件包。

这样使得用户可以非常简单地在这些操作系统上安装和使用Docker。随着定期更新，功能和特性也可以几乎等同于Linux上的Docker软件包。这样一来就几乎没有什么区别了，我不记得最后一次我需要一个在这些版本中不可用的选项或者功能是什么时候了。

想要安装Docker for Mac或者Windows吗？

WatchMeCode上有一个免费的安装视频片段（以及Ubuntu Linux！）

Installing Docker for Mac
Installing Docker for Windows
Installing Docker on Ubuntu Linux

神话#4：Docker只是命令行而我明显对于使用可视化工具更高效

Docker出身自Linux，所以毫无意外地Docker更喜欢命令行工具。

大量的命令和选项是不可避免的，然而这对于没有在控制台/终端窗口花费了大量学习和工作时间的开发人员来说，这可能是沮丧以及降低工作效率的来源。

解决方案

随着Docker社区的成长，出现了越来越多的适合更多的开发人员偏好的工具，包括可视化工具。

Docker for Mac和Windows包含了Kitematic的基本集成，举例来说，在我的电脑上就有一个GUI工具可以来管理Docker镜像和容器。

有了Kitematic，可以非常容易在Docker仓库上搜索镜像、创建容器以及管理我安装和运行的容器的各种选项。

想要看到一个Kitematic实战吗？

在《Docker学习指南》里检出WatchMeCode视频片段 the Kitematic 。

神话#3：我不能在容器里运行我的数据库。它不能适当地伸缩……并且我会丢失数据！

容器意味着短暂的生命周期——他们应该按需被摧毁和重建，没有片刻的犹豫。但是如果我从容器里的数据库存储数据，删除容器会删除数据。

此外，数据库系统有非常特定的伸缩方法——既有纵向扩展（更大的服务器）也有横向扩展（更多的服务器）。

Docker似乎看起来是专注于横向扩展的——当需要更多处理能力时，可以创建更多的服务实例。而大多数数据库系统，在另一方面需要特定和专门的配置和维护来进行横向扩展。

所以，这是对的，在Docker容器内部运行一个生产环境数据库不是一个好主意。

然而，我的第一个真正成功的Docker实例就是数据库。

具体来说就是Oracle。

为了我的开发需求，我已经试过但是未能在虚拟机上安装Oracle，我花了将近两个星期断断续续地工作，甚至从来没有接近成功。

然而，我在30分钟里学习了Oracle XE的Docker镜像之后，就已经可以在开发环境启动和运行Oracle了。

解决方案

Docker也许不太适合在生产环境运行数据库，但是用于发环境是非常合适的。

我现在已经运行MongoDB、MySQL、Oracle、Redis以及其它数据/持久化系统有一段时间了，不能比这更快乐了。

而且，当涉及到Docker容器的“短暂”属性时，就可以用挂载卷的方式。
类似于代码编辑的神话，卷挂载提供了一种便捷的方式来在本地系统存储数据并且在容器内部使用。

现在我可以根据需要摧毁一个容器并且重建它，并且明白会从上次离开的地方重新捡起正确的东西。

神话#2：我不会在项目中使用Docker，因为Docker要么全有要么全无的

当我第一次看到Docker时，我就想这是真的——要么你可以将开发、调试、部署和“DevOps”都用Docker搞定（还有两百个额外的工具和框架使得这些工作都可以自动化），要么你拿着Docker什么也不做。

作为我在Docker方面的第一个成功案例，我在安装和运行数据库的经验展示了其它方面。

任何要求要么全有要么全无的工具或者技术都应该用极端的显微镜重新评估的。这是真的非常罕见的，当确实如此的时候，可能不是什么时候都应该投入时间和金钱的。

解决方案

Docker像大多数开发工具一样，可以从小开始起步，逐渐添加扩充功能。

比如在容器中运行一个开发环境数据库。

然后在docker容器内部构建一个单独的类库并且了解它是如何工作的。

接着在一个容器中构建下一个只需要数行代码的微服务。

从这里转移到一个更大的有着多个团队成员在积极开发的项目。
没有必要去孤注一掷的。

神话#1：我根本不能从Docker中获益……因为Docker是“企业级的”和“DevOps”的

当我第一次看到Docker时，这是我不得不要移除的最大的心理障碍。

在我心中，引入Docker是一个极其重大的决策，只有那些我还没有见过的有着伸缩性能问题的技术最先进的团队才不得不拿来处理实际问题。

我这样想并不奇怪。

当我环顾在网络博客和会议谈话上所有的关注和炒作时，我看到的只有“大牌公司如何利用Docker、Kubernetes和崭新的Netflix扩展工具集来自动化10,000,000个微服务”。

Docker也许更擅长“企业级”和“DevOps”，但是开发人员——就像你和我——都可以利用Docker提供的功能。

解决方案

给Docker一个尝试机会。

再一次的，从小项目开始。

我运行了一台有12G内存的虚拟机，在上面为一个客户托管着3个Web项目。至少可以这么说，这是一个轻量级的服务器。但我看向Docker，哪怕仅仅只是普通的旧版本的Docker，也就可以更有效地使用服务器了。

我有了第二个客户——总共有5个兼职开发人员（每周共覆盖不到1人的全职时间），他们已经使用Docker来自动化他们的编译和部署流程。
我基于这一点使用Docker来为Node.js应用构建大多数的开源类库。

我正在寻找新的更好的办法来管理那些我需要每天使用Docker安装的软件和服务。

记住……

不要购买炒作或相信神话

围绕在Docker周边的神话之所以存在是有着充分的理由的。

从历史上看，它很难在Linux之外玩转，并且到今天以及往后的日子，对于企业和DevOps工作都有着巨大的益处。

但是这个神话的不幸之处在于，很难帮助对于像你这样的开发人员获得益处。

如果你发现了这些神话、真相和解决方案的清单，还说“是的，但是……”，我要求你花些时间并重新评估对于Docker的想法以及为什么这么想。

如果你仍然有问题或者关心如何可以在开发环境充分利用Docker，请联系我。我很想听到你们的问题，看看有什么我可以帮忙的。

如果你想学习Docker的基本知识或者使用Docker开发应用程序，但是却不知道从哪入手，请在《Docker学习指南》和《Docker构建Node.js应用指南》底部检出WatchMeCode视频片段。

原文链接：10 Myths About Docker That Stop Developers Cold （翻译：胡震）

原文发布时间为：2017-02-26

本文作者：胡震

本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。

原文标题：十个有关Docker让开发人员失去热情的神话