如何使用Docker精简开发过程

我们的策略之一是将Moio的核心应用程序分割成更小的，单任务的微服务，它用来解决编码复杂和保持灵活选择技术的问题。然而，这种基于微服务的方法引来了其他的挑战，比如确保正确配置应用程序的环境。为了支持这种情况，我们推荐使用Docker作为我们基础设施的核心部分。

Docker允许你使用完整的操作系统环境打包应用，然后在软件容器里运行应用程序。软件容器类似于虚拟机，但更接近于机器。举个例子，容器不会被预分配到内存，但在运行时向主机动态请求内存分配。

使用容器意味着像库依赖这样的事情可以独立于主机系统被预安装。其他的依赖诸如配置文件也能通过明智的默认文件被预设，并且被放置在应用程序预期的位置上。最终的结果是：使用Docker我们可以提供给每一个应用程序标准化的环境，即以同样的方式运行在任何系统上。你已经安装在宿主系统上的任何库和包并不重要，因为应用程序并不会与它产生相互作用。

对于开发团队来说，这显然是便利：

应用程序被预见运行在不同的操作系统上

举个例子，OS X系统和各种各样的Linux系统，很令人痛苦的区别是：Apache的安装位置和配置方式（或者如果默认的web服务器就是Apache!）运行Apache在容器内，意味着每个人都能依赖于相同的配置。

在你需要自定义配置的情况里，Docker允许你在启动容器时设置环境变量，这时你可以改变容器的操作方式。Docker具有让你安装宿主系统的目录和文件到容器里的功能。这里我们找到了一个好的做法，很有可能，去更好的使用放置彼此独立的配置文件的文件夹，并且包含这些配置文件进入一个主配置文件中。这两种技术允许容器的微调到达一个很精确的层次。

另外，你也许发现你自己处于这种情况下，你想安装一个目录以便通过容器内的进程创建的数据能在容器的生命周期外存在。一个符合种种情况的用例是当你有一个数据库时，你也许想保持数据持久即使容器已经停止，异常或者奔溃了。安装应用程序的数据目录到主机上是实现这个目的的快捷方式，因为它将存储所有的数据在主机上。

组件间集成相当轻松

如果你有一个微服务需要与另一个团队维护的微服务集成，所有你需要做的事情就是用Docker去拉取微服务，并且运行在你的本地坏境上，无须担心其他依赖关系。

一个主要的好处是，这一过程忠诚的重复了这些服务在生产过程中如何进行相互作用，到如何进行沟通交流。这给了我们极大地自信，我们可以说我们在本地环境上的测试结果将精准的反应什么将在线上环境发生。

Docker镜像是可组合的

这允许我们重复利用我们已经完成的东西。我们已经收藏了一批来自于我们构建的核心镜像， 这意味着我们所有的镜像可获得同样的基础设施。这使团队使用其他团队准备的镜像文件变得容易。

在内部，Docker处理这些通过将镜像的每一部分作为不同的层次来存储，并且组合他们去生产出最终的镜像。这种方法的一个好处是，通过共享基础的镜像，我们Docker库的总规模大大降低了。这也意味着拉取新的镜像将花费更少的时间，因为你拉取的镜像中只有独特的层会被检索。

使用Docker鼓励开发者、测试者和操作者更紧密的合作

开发者需要自觉思考在开发环境之外运行的应用需要什么。这降低了由于墙外世界（开发环境外的世界）引起的问题。 “完成的”产品能如预期一般便捷使用，那他们就可以在线上“让它运行”。

使用镜像也意味着测试者的环境是标准的与线上产品统一的，这一切都只需要他们安装Docker。他们不需要忍受糟糕的文档，关于如何使应用程序运行他们，也能简单容易的拉取准备好的镜像文件并且立即使用他们。

Docker引来了一系列新挑战

严重依赖于Docker的组件机制意味着我们的一些镜像有一长链的基础镜像依赖。举个例子，我们有一个微服务被写在Clojure里。这个服务将被建立在Clojure镜像的顶部。然而，我们的Clojure镜像创建于Java镜像，反过来说，它依赖于我们的共有基础镜像。如果我们对基础镜像做了一个改动，每一个中间镜像需要重新编译以便我们的微服务能利用改动即使中间镜像没有做任何改变，这也添加了大量的开销。

因为Docker依赖于Linux内核功能，使用它在OS X上确实需要一个虚拟机运行一个基于Linux的系统。官方的依赖工具是VirtualBox。这创建了一种独特的情况，文件和文件夹需要先被安装在虚拟机上，然后再放入Docker的容器内。虽然已经有工具为你处理了，某些操作如chown和chmod仍无法工作。

一个关联的问题是用例对文件系统敏感。OS X的默认文件系统是用例不敏感，但是典型的linux系统是用例敏感。如果主机运行了OS X系统然后容器基于Linux，当文件在安装目录里时不正确的命名文件不会被注意到。一旦你尝试运行容器在主机上，主机是一个用例敏感的文件系统时，将不会找到那个文件。

我们在一个权威的基于linux的机器上构建和测试我们的Docker镜像，以此来解决这些问题。这能让我们捕捉到在开发时可能被忽视的错误。

总结

当使用Docker时， 无疑是缓慢的，这是一个正常的初始学习曲线，但是把每一件事都考虑进去，我们发现Docker增长了我们的开发效率，对加入小组的新成员进行入职培训，通常需要花费数天时间，让他们去建立本地环境，而这一过程伴随着繁多的环境故障待排除。使用Docker，很少需要依赖本地环境，并且在大多数用例里，我们能在Docker引入我们应用的当天运行它。（责编/魏伟）