中国IDC圈1月3日报道，2013年4月Docker被正式发布开源，所以在软件行业中Docker还很年轻。像我这样的网虫(nerds)，对于这么明星耀眼的软件，首先看到的是它的潜质，并思考如何开始在各种场景下的使用它。

现在很多博主仍在聚焦Docker的优势，而我们感觉到已经是时候认真的询问在什么场景下、为什么这是我们最佳的选择方案。而且更重要的是，当你可能在两者之间做出最好抉择的时候。在慎重思考以下几点后，我们最终没有将Docker用于生产环境。但是，如果你已经将Docker用于生产，我们也愿意听一下你的原因。

我将在这篇文章中分享一下我们的一些发现和一些关键问题的概括，如果你也有计划实施使用Docker，这些问题你应该会遇到的。

我们也希望从你们那里听到：你认为是什么驱动你采用Docker的?你怎么看待未来工具的变化?你期望它们能做到什么地步?

1-你到底需要做多少?

Docker提供功能广泛，这里有几个的例子：

Images(镜像)：Docker可以通过Pull和Push命令构建对象到服务中心

Containers(容器)：Docker可以通过Start/Stop命令管理容器的生命周期

Logging(日志)：Docker可以通过stdout，stderro捕获输出所有的容器内部信息

Volumes(存储)：Docker可以创建和管理容器的相关文件存储

Networking(网络)：Docker可以创建管理虚拟的接口和内部所有容器之间的网络桥接

RPC：Docker服务器提供允许外部程序去控制所有容器的行为的API

提供的功能越多必然会增加一定程度的复杂度，据使用sloccount 统计，仅仅在main repo中就有97100行代码。它们在Docker中全有或者全部没有关系。所有的特性被打包到一个二进制的文件中，没有方法可以实现只打进去一半。所以，如果你准备开始使用Docker，就应该考虑是否需要它提供的这些功能。

2-搞这么复杂值得吗?

一年前，我们为了寻找方法简化构建运行时的管理，开始了Docker跟Jenkins结合使用。开始这个想法后我们不得不开始担忧构建依赖或同时构建造成的环境污染等问题。每一次在新容器的构建，Docker将被隔离。这个做法(指隔离Docker的操作,译者注)在我们仅仅需要Java和Docker而不必处理其它的冲突依赖时简化了我们的设置。

做了这些工作良好的运行了一段时间后，也引入了不少的问题。管理运行时容器并非是不重要的，我们要清理掉旧的容器会留下的文件目录，否则可能最终引起机器故障。

为了解决这些问题，我们不得不构建了一个包装工作(参考cide)来管理Docker容器的每次构建。

当cide构建时，我们也会和Dockerfile构建者关注一些灵活性问题，它不能较好的使用Gemfiles来适应私有库的依赖管理。仅仅是获取运行时和清理工作至少要花费三次的不同迭代。

最终新的解决方案要比先前的好。但是我们觉到这些可以更加简单 ，可以跟工具集更紧密的结合。像所有优秀的开发者一样，你可以在一个在抽象层寻找一个解决方案，但是它并不是那么完美。

3–你能处理故障吗?

Pusher的例子略微小众化，因为我们有长期运行的客户端连接，这些连接有偿提供给我们的客户以便可靠快速的使用。我们必须先限制分发用户的数量。实际上，当我们部署时就已经采取额外的步骤去限制故障了(参考crank的实例)。

Docker是按一个月或者两个月的频次发布新的版本，你很可能像通过二进制更新到最新版。但是，由于Docker是结构化层次的，要想升级就必须关闭宿主机上的所有的容器。这就必然会增加引入新的故障挑战。

目前，这是我们放弃在主生产环境使用Docker最大的原因。我们计划通过替换整个机器环境，通过重定向转换DNS流量，但是直到现在我们也没有解决这个问题。依据你应用程序的架构，这些经验也可以为提供一些建议。

如果你在此处不太注意，就会发现自己重建整个应用程序只是为了适应这种模式而已。这也是我们决定放弃使用Docker的另一个原因。我们怀疑它能添加延迟和一些额外的开销。

4–你有技术支持吗?

最终还是想想看吧，你需要扪心自问你具有操作知识吗?我们发现找到详细的实例Docker部署信息非常困难。我们遇到的都是一些操作的问题以及如何处理它们。

一旦你深入发掘Docker的更多操作，你就发现网上的一点点文档完全不够的。所以有两种方式获得问题的解答：要么多花费时间思考问题，多去论坛交流刷刷问题，或者你总是能搜索到Docker提供的专门支持问题。

本质上，能搜索的是有很多的基础入门信息，但是很少量的信息是在最优解和可操作性上是可用的。超过现在的水平去理解它是一个长期的实用解决方案这个问题是很难做到的。我们想给正在做出决定的人提供一点力所能及的帮助，这也是我们分享这篇文章其中原因之一。

那么我们应该部署Docker吗?

最后这是一个你自己能回答的问题。根据你的使用情况，Docker中无所不包的方法是完美的。 如果说万丈高楼平地起，它确实是一个不错的开端。

但是如果你已经有一个已经发布架构，你就应该问一下自己到底是否真的合适了。我们建议先规划好你的应用程序蓝图，确认你应该需要什么功能，然后检测这些功能Docker是否提供。如果你在构建一些很简单的应用，它可能不是你的理想工具。如果上线的时间是一个障碍，它可能也不是你的理想工具。

对于那些已经运行在Docker生产环境的，我们很乐意想听你们对于工具的发现和怎么在社区交流中得到一个真实的交流从而改善社区的经验。