容器基础(一): Docker介绍

IaaS

IaaS阶段, 用户租借基础设施,但是还是需要像以前管理服务器那样,用脚本或者手工方式在这些机器上部署应用。这个过程中当然难免会碰到云端机器和本地机器环境不一致的问题。想想每一次同步不同机器环境的过程,就知道这个过程的艰辛!

 

PaaS

2013年,Cloud Foundry开启了以开源PaaS为核心构建平台层服务能力的变革, 通过在容器底层使用Namespace和Cgroups对应用进行隔离,Cloud Foundry通过这个隔离的沙箱让多个应用能在一起互不干涉的运行。

百度百科:
Cloud Foundry支持多种框架、语言、运行时环境、云平台及应用服务,通过一套应用的打包和分发机制,使开发人员能够在几秒钟内进行应用程序的部署和扩展,无需担心任何基础架构的问题。

 

虽然Cloud Foundry提供了一个更好的用户体验,但是还是存在易用性问题:

对于一个"正确的"应用包,Cloud Foundry能实现快速部署,但为了能打包出这个"正确的"应用包, 过程却很繁琐,用户可能需要为不同语言和框架,甚至每个版本打一个包,而打好的包在本地能正常运行,但是在云端却不一定能正常运行。

 

CaaS

这个时候,Docker项目开源了,虽然Docker底层和Cloud Foundry一样,都是使用Namespace和Cgroups技术,但是另外的一小部分功能,却成为了Docker项目后面成功的关键:

通过打包整个根文件系统,把应用的所有依赖(包括操作系统文件)都打包到一起,生成Docker镜像,Docker通过Docker镜像解决了Cloud Foundry打包繁琐和不一致性的问题,提供了一种"build once, run anyway"的优雅解决办法!

 

容器编排(Container Orchestration)

虽然Docker项目发展迅猛,但是对于用户而言,最终要部署的,还是他们的网站、服务甚至云计算等。一个Docker中运行的是一个进程,对于用户的大规模集群而言,只有提供平台层能力的工具才会真正吸引他们。这种情况下,支持大集群容器管理的Docker Swarm和Kubernetes来了。

 

这里不讨论各大公司间狗血的争斗,只简单讨论下为什么Docker Swarm最终落败于Kubernetes:

Docker Swarm通过Docker镜像部署应用,但是实际上一个Docker容器里只管理一个进程。现实环境下,提供一个完整的服务通常需要多容器配合才行,比如容器A和容器B/C配合提供服务,且容器A需要容器B/C先启动, Swarm里面对这种情况的处理就比较麻烦。而Kubernetes却通过Pod轻松的解决了这一点。

 

posted @ 2018-11-29 19:00  子厚。  阅读(287)  评论(0编辑  收藏  举报