容器技术的快速兴起和采用已经导致了一些不可预料且令人困惑的后果，比如监管的缺失，以及流程改变地太快接近崩溃。有计划以及正确的工具生态系统，CTO和开发经理才能够确保容器的引入在其团队里不会造成短视混乱的局面。

本文探讨了为什么和容器技术可能带来的好处比起来可能更容易造成问题。我会尝试在错误发生之前就深入地思考，利用可用的工具来避免错误的发生，而不只是仅仅说“容器对我们而言不适用”。

容器将宿主Linux操作系统的某些部分隔离出来，它们看上去就像拥有独特配置和应用实例。容器基于LXC技术，该技术自2008年开始就包涵了多个流行的Linux发行版。该方案和虚拟机（VM）技术类似。但是，容器能够无损地保持宿主操作系统的性能，并且更小。它们帮助开发人员更加快速地搭建工作所需的整个环境。它们还能够使得应用发布更加快速、更加可预测。

如今使用的主要容器技术是Docker。为了进一步推进容器驱动的流水线，Docker团队已经添加了一系列命令行接口，管理工具，公开和私有库，以及一些配置，比如网络和安全。所有这些都使得容器技术成为整个开发团队更为实用的技术方案。

现状概览

将应用作为整个堆栈（操作系统、系统配置和代码）来划分层次并不是什么新想法。虚拟化技术就是来源于这样的想法。但是，虚拟化的缺点在于VM很大，并且和不可变的hypervisor层紧密耦合。这意味着如果想要给VM做快照，并且像容器一样移动，就需要很大的带宽和强大的服务器能力。但是，这还不是最严重的问题：你还需要丢弃已经习惯的服务器旧式IT维护方式。Hypervisor一直属于IT，IT习惯于将VM当作物理服务器对待，生成一次然后直到出现问题才需要再作处理。这样的方式不适用于软件开发。

达到更好的层次划分的动力来自于应用复杂度的增加：使用更多的组件，更加强调安全性，以及代码和系统级别组件的更紧密的集成。这些全都强化了开发人员和基础架构之间的空白之处，并且尝试调和这两者之间的问题。

这意味着发布只有代码的应用不太理想。然而，如果你能够作为整体堆栈发布应用，那么定位并解决系统到代码的问题会更加容易。在开发领域，全栈部署是未来。对于开发团队而言，容器意味着开发人员、QA和IT能够更加具体地讨论应用，并且更快地定位问题的根本原因。

当优势成为问题

几分钟之内，开发人员就可以从公开库里拉取一个容器镜像，并且在其本地机器上生成一个实例。一个小时内，开发人员就能够完成该实例的改动，将其转换成自己的镜像，并且再次发布到其他10台宿主机器里，或者在同一台机器里创建出10个新实例。如果将这样的能力扩展到单个开发人员之外、拉取、修改和容器生成能够病毒式地传播。并且很快，团队就会拥有之前根本无法想象的容器实例数量。

这也正是优势迅速转化出问题之处：当出现未受管容器的生态系统的时候。先不谈那些不太严重的问题，比如浪费的资源，除此之外，容器技术带来了一些更加严重的问题：

1.治理和审计

2.变更管理

3.IT安全

4.应用集成

5.资源规划

6.管控和审计

这些问题使得新方案面临新的威胁，甚至是一些能够摧毁企业的问题，比如黑客攻击或者低劣的应用质量。容器是为了移动而构建的，它们不是为了监管和管理而生。因此，如今容器的使用还很有限，很少企业真正地实现了容器技术驱动的流水线愿景。

容器的主要用例在于开发人员，以非常随机的方式使用容器。他们为了快速测试，以及能够随时销毁并替换开发环境，而生成容器。但是大部分常见的容器用例有一个独特的元素，这正是容器正好能融入应用程序之处。如今，容器对于应用程序前端而言最为有用，因为其最大的价值之一就是保持小和敏捷。因此在容器里添加数据库是违反这一价值的。

容器非常值得投资

容器技术必须和一系列实践及工具共存，使其能够在团队范围内以可持续的方式工作，这一观念得到越来越多的共识。对于看到优势的企业而言，现实有些遥不可及，这也将其置于更广泛的现代开发实践之后。对于全栈开发，或者持续集成，交付和开发来说，容器并不是不可或缺的，但容器的确能够让这些实践更加容易。

容器能够带给企业的好处使得其非常值得投资，来帮助解决上述问题，以及推进应用交付发展到交付容器，而不是代码的阶段。并且，幸运的是，该领域有用的技术和生态系统战略正在飞速地向前发展。

因此不要放弃希望。容器引入的成熟阶段正在来临，它一定会改变我们看待应用和软件开发的方式。