作为程序员,让我们回忆我们每天从事的熟悉得不能再熟悉的软件开发工作:
在本地搭好开发环境,进行开发工作,完了进行单元测试,把开发好的代码部署到测试系统,重复测试,最后部署到生产系统。
我们不可避免地会遇到这种情况:同样的代码,运行环境发生变化之后无法正常运行。
这种运行环境的变化可以分成不同的维度:
比如代码从程序员的笔记本电脑切换到测试服务器,或者从一台物理服务器切换到公有云/私有云上;
代码依赖的运行库版本发生变化,比如开发时用的python2.7, 但生产机上用的python3
也可能是代码运行的操作系统发生了变化,比如开发及用的ubuntu,生产机用的redhat
程序员除了投入时间在应用程序本身开发上之外,还需要花费额外的精力去处理这种环境或者说infrastructure问题,有的时候很头痛。
作为一个应用程序开发人员,我对底层的这些环境问题不感兴趣,有没有一种办法能使的我不去考虑它们呢?有,使用容器技术。
什么是容器?我们可以从现实生活中容器的概念来类比。
简单地说,一个容器包含了完整的运行时环境:除了应用程序本身之外,这个应用所需的全部依赖、类库、其他二进制文件、配置文件等,都统一被打入了一个称为容器镜像的包中。通过将应用程序本身,和其依赖容器化,操作系统发行版本和其他基础环境造成的差异,都被抽象掉了。
为什么我们要使用容器?那得看看它带来的好处。
既然容器封装了所有运行应用程序所必需的相关的细节,比如应用依赖以及操作系统,这就使得镜像从一个环境移植到另外一个环境更加灵活。比如,同一个镜像可以在Windows或Linux,开发、测试或生产环境中运行。
标准化:大多数容器实现技术基于开放标准,可以运行在所有主流 的Linux 发行版、Microsoft等操作系统上。
容器镜像提供版本控制,这样就可以追踪不同版本的容器,监控版本之间的差异。
容器隔离带来的安全性:一台宿主机上可以运行多个容器,但这些容器内的进程是相互隔离的,且无法相互感知。其中一个容器的升级或者出现故障,不会影响其他容器。
相比虚拟机来说更加轻量级:
虚拟机和容器的目的类似,都致力于对应用程序及其关联性进行隔离,从而构建起一套能够不依赖于具体环境而运行的应用单元。
虚拟机是在物理服务器的上层用软件来模拟特定的硬件系统。Hypervisor位于硬件和系统之间,是创建虚拟机必须的一个部分。虚拟机软件必须使用Hypervisor作为一个中间层,是虚拟机技术的核心,当宿主操作系统启动虚拟机时,会通过hypervisor给虚拟机分配内存,CPU,网络和磁盘等资源,并加载虚拟的操作系统,因而需要消耗宿主机大量的物理资源。
一台宿主机上运行的多个容器化应用共享这台宿主机操作系统的内核,因而不需要虚拟机技术的hypervisor中间层,因而同虚拟机技术相比,更加轻量化,启动速度更快。
为什么这几年来容器技术一下子流行了起来?
随着微服务架构应用开发的普及,很多IT公司纷纷推出了基于微服务架构的新产品,就连SAP这种传统的企业管理软件巨头也发布了很多基于微服务的解决方案,比如Engagement center, revenue cloud等等。
起初微服务提供商倾向于把微服务部署在虚拟机里,这也能实现微服务的隔离性,但无法进行快速扩展,因为前面介绍过的虚拟机的实现原理,其启动需要耗费一些时间,无法立即对瞬时突增的负载或者流量做出反应。并且从成本考虑,使用传统的虚拟机技术,为了实现隔离性,每个应用或者说微服务都必须运行在一个虚拟机里,这种重复和浪费的操作系统和资源的分配,可以通过容器技术来避免,从而大大减少了云服务提供商对硬件的投入,节省了云服务中心的成本。
要获取更多Jerry的原创文章,请关注公众号"汪子熙":
————————————————
版权声明:本文为CSDN博主「汪子熙」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/i042416/article/details/85012912