本文中，我将研讨利用强有力的策略和工具，如何帮助你确保容器技术采用的可持续和在开发组织中的延伸——而不是分裂成不同的部分。我会指出其中的功能差异，及处理的方式。此外，我还会建议把容器应用到测试与开发环境（test/dev）以外以及进入应用发布流程的方式。

在对开发伙伴进行了30次访谈之后，我意识到很显然有一些大的拦路石需要搬走才能让容器技术步入正轨。这30人里面，只有4人提过有可能是产品级的用例，剩下的只是在test/dev环境下玩玩而已。在被问到为什么不做生产中使用容器时，典型的回答往往不是技术本身，而是与它如何稳定地融入到范围更广的交付链当中有关。

在没有明确战略的情况下采用容器技术会引起应用质量的下降以及治理风险的增高。产品质量下降是因为非法容器引入的隐藏变量最终会以bug或中断的形式浮出水面。治理也受到威胁，因为对容器缺乏清晰的监视，你不知道哪些遵循了策略，哪些没有遵循。还有变更管理的问题，对于任何开发团队来说这都是一个可怕的词，在专家离开团队之后会成为一个问题。

以下是目前容器技术需要帮助以便缓和风险的关键差距：

网络限制：容器网络（Docker Network ）让你可以方便地在同一主机下对容器进行网络连接。加上一些其他的工作，你就可以跨主机使用叠加网络功能。然而，也就到此为止了。网络配置操作是受限的，而且到目前为止可以说这些手段都是人工的。尽管容器脚本化可以规模化，因为你必须给网络定义增加预分配实例，每次提供容器时还需要额外步骤，这容易引起错误。

库控制受限：库已经成为任何容器会话的中心议题。公共库是最有价值的，因为他贡献了大量的预置容器，节省了许多的配置时间。然而，在沙盒里使用它是有风险的。在不知道谁以及如何创建镜像的情况下，可能会存在任意数量的有意或无意的稳定性和安全性风险。对于企业来说，有必要建立和维护一个私有库，这个库的建立挑战不大，但管理是个问题。Docker为大型库的镜像管理提供了一个有限的元数据模型，确保未来实例如预期的能力受限，也没有叠加功能。

没有清晰的审计跟踪：提供容器是很简单的，但知道提供容器的时间、原因、方式以及提供方却不容易。因此，在提供之后，你并不掌握多少出于审计目的的历史。

运行实例的低可见性：如果没有经过深思熟虑的行动，实例提供后很难接触到运行容器的对象，也很难知道哪些应该出现在那里，哪些不应该出现在那里。这个就是我所谓的容器蔓生问题—这个问题严重起来会导致：

• 非法VM
• 旧版本与配置
• 资源浪费
• 无法进行资源规划

这些挑战并非不可克服的。同时，尽管Docker并未将其列入开发路线图，该公司现在还在积极地处理着。比方说，在DockerCon15发布的Notary可以让组织设置策略，策略可以针对所有新的容器进行检查。而第三方市场甚至还有更强的产品。

以下是应对这些挑战的关键办法：

• 规划：有时候很难接受的一点是，你不仅要对应用进行架构设计，还得对管道做一样的事情。组织不会放弃冲刺（sprint）和产品功能相关的活动，正如他们不会放弃对管道和和发布流程所做的事情一样。应该事先进行审慎的工作来确保容器系统定义好，能够在很长一段时间内运行正常。这个的石蕊试验可以挑选可能产生的问题例子，然后测试一下团队，看看他们能否及如何回答这个问题。
• 服务开通：数量少的情况下，容器的开通使用是简单的。但团队加入的话，就会多了很多的变数。比方说，确保大家不会踩到别人的脚；在团队范围内确保开通匹配预期的配置，如预期的组件；确保容器的移除服务或替换不是临时的或者没有指导等。
• 日志分析：从宿主机器进行日志时，每个容器都是无需额外工作建立全面可视性的唯一途径。只有这样才能容易地整个容器集合范围内进行查询了解进展。
• 容器世界将会发生快速演变，焦点会集中在更成熟应对企业需求上。一旦这一点实现，未来就会采纳更多像微服务这样的概念，而容器管道则会变得更加抽象—甚至你都不需要知道它们在哪里，容器库也会更加健壮。

最大的抑制因素也许是新的工具和功能来得太快。组织往往会按下暂停键等等看有一个关键功能能够一揽子解决。或者进一步限制容器的使用，直到能确保更新不会导致大规模的中断。

总有一天我们会把应用比作容器而不是代码，要为这一天做好准备。同时，什么地方围绕着基础设施的考虑最小，要找到这个点，并且应该在应用生命周期的早期去考虑。未来几年容器技术的面目将会焕然一新，也因此会改变应用的本质。