麦克莱恩发明集装箱的时候，或许不会想到这种运输方式会推动经济的全球化发展。当一批批货物被打包搬上火车、轮船、飞机，集装箱不仅解决了装货慢、载量小的窘境，还将原来数月的运输时间从数月缩短至数天。当然，考虑到货物的多样性，以及具体使用情况，集装箱并非万能药。这就像是容器，将开发者的应用打包发布到Linux平台上不是一本万利，还要涉及部署成本、操作环境、安全性等问题。
2013年3月，PaaS服务商dotCloud（后来的Docker）将应用容器引擎Docker开源，代码托管在Github上。在此之前，容器技术已经在Linux和UNIX领域经历了十多年的变迁。从技术的角度来看，Docker基于沙箱机制可将任何应用集成在一个轻量化、可移植、标准化的容器中，核心问题就是利用Linux容器技术实现类似虚拟机的功能。然而，在一片为容器叫好的声音中，人们也要注意到这种技术的弱点。
用容器有代价
容器不是一刀切的解决方案，意味着使用者要具有相对应的专业知识，并且要确保基础设施的完整性，有了好地基才好盖房子。将容器集成部署到持续交付管道，使其自动化运转起来，需要在每次提交代码时执行一系列步骤，其中包括一次手动迁入代码库的操作。简单来说，管道的作用就是让容器在内部经过功能性测试，合格“上岗”。期间如果有一次执行延误，就会打破持续性，并且会错过发现问题的时机，导致后期投入更多精力来修补。要知道，在代码提交的几分钟内bug报错与数周后再察觉相比，前者的修复成本要小很多。
需要注意的是，Docker并不会重写代码，只是让跨平台部署变得容易了，想具有扩展性还是要由开发者亲自动手。Docker不是横跨所有系统，毕竟系统层的软件泊接不是停船装货那么简单。跨系统的时候，要先保证Docker自身的新版内核，并且底层是通用的，再小的差错率放大到成千上万台服务器上都是大风险。同时，规模化运行容器离不开管理和编排的支持，又是一笔投资开支。
容器不等于虚拟机
切勿以虚拟机的视角看待容器，其不是可以随意编辑或者删除的对象，遇到问题只能丢弃重建出一个新的。或许有开发者遇到这样的问题：容器执行过程中，修改了容器的内容（如配置文件信息），但因为修改出了问题，导致容器关闭后无法启动。为此，开发者只能创建新镜像，或者直接修改文件。
此外，Docker的资源隔离水平也比不上虚拟机，只能对一些资源共享，其他进程需要排队入列。容器在内核层面也是共享的，在某些环境中换取了高效率，但可用性和冗余也会受到影响。与独立内核的虚拟机不同，如果有一个容器内核损坏，其共享机制就会导致所有关联的容器遭殃。
生产环境缺陷
成熟的企业会使用才出现两年的数据库技术吗？更何况Docker只是一个工具，谈不上架构解决方案。前文提到，部署容器需要镜像管理、日志、监控、负载均衡等全流程的支持，并且升级后的向前兼容性较差，这也导致了容器在生产环境中的弱势，更不要说为大型应用程序创建映像。一些自建生产环境的用户会将Docker放在IaaS上，可能引发资源消耗超出容器实例所需的。而在网络层，并非所有容器都能被公网访问，这就要在网络设置时多多留意，为主机打补丁是常事儿。
部署过程中，Docker Compose与其他工具相比在生产环境配置时复杂度更高，volume绑定、端口对接、网络参数都要修改，并且需要调用很多脚本，以及外部数据库等工具。拿数据库管理来说，开发环境完全可以跨容器托管，但在生产环境就要考虑I/O性能等问题，用于确保高可用性和可靠的备份及存储。能力越大，需要注意的点就越多，容器可以将package直接从开发环境搬到生产环境，但在生产环境仍有要完善的地方。
容器离不开安全
围绕容器的安全性争议从未间断，风险是由内向外的，黑客可以通过破解容器来访问底层服务器，进而影响到云服务商的数据中心。另一方面，不同的镜像来源也让威胁变得难以预测。曾有数据显示，Docker Hub的容器镜像有超过30%保护高风险漏洞，而且这些还经常被下载的镜像。此时，容器就像潘多拉的魔盒一样，你永远不会知道里面到底有什么。
从规范性的角度来看，容器应用商店或许是个好办法。事实上，很多服务商甚至不知道自己的容器有问题，直到漏洞爆发才发现。通常，使用者应该选择熟识的服务商、避开那些长期没有更新过的容器。至于提供方，只能把控好代码质量，定期“体检”。
结语
未来，前沿技术、社区生态、企业支持将成为容器发展的三大基础，上云容器化已经成为趋势，但实际应用过程中还要根据自身业务特性做出判断，避开容器初期部署时的不稳定因素，这样才能将商业价值大化。
热门专题
