容器真的是万能吗?看完你会沉默

麦克莱恩发明集装箱的时候,或许不会想到这种运输方式会推动经济的全球化发展。当一批批货物被打包搬上火车、轮船、飞机,集装箱不仅解决了装货慢、载量小的窘境,还将原来数月的运输时间从数月缩短至数天。当然,考虑到货物的多样性,以及具体使用情况,集装箱并非万能药。这就像是容器,将开发者的应用打包发布到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%保护高风险漏洞,而且这些还经常被下载的镜像。此时,容器就像潘多拉的魔盒一样,你永远不会知道里面到底有什么。