共计 3008 个字符，预计需要花费 8 分钟才能阅读完成。
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 生产环境的，我们很乐意想听你们对于工具的发现和怎么在社区交流中得到一个真实的交流从而改善社区的经验。
你们在生产环境开始使用 Docker 了吗? 如果你觉得哪个领域有用？我们错过了什么？请在下面的评论让我们知道。
更多 Docker 相关教程见以下内容：
Docker 安装应用(CentOS 6.5_x64) http://www.linuxidc.com/Linux/2014-07/104595.htm
Ubuntu 14.04 安装 Docker http://www.linuxidc.com/linux/2014-08/105656.htm
Ubuntu 使用 VNC 运行基于 Docker 的桌面系统 http://www.linuxidc.com/Linux/2015-08/121170.htm
阿里云 CentOS 6.5 模板上安装 Docker http://www.linuxidc.com/Linux/2014-11/109107.htm
Ubuntu 15.04 下安装 Docker http://www.linuxidc.com/Linux/2015-07/120444.htm
在 Ubuntu Trusty 14.04 (LTS) (64-bit)安装 Docker http://www.linuxidc.com/Linux/2014-10/108184.htm
在 Ubuntu 15.04 上如何安装 Docker 及基本用法 http://www.linuxidc.com/Linux/2015-09/122885.htm
Docker 的详细介绍：请点这里
Docker 的下载地址：请点这里
原文链接：4 questions you need to ask before deploying Docker（翻译：ylzhang）
本文永久更新链接地址：http://www.linuxidc.com/Linux/2015-12/126504.htm
