add by zhj: 其实我主要是想看看基于docker的PaaS的特性。
原文:http://developer.baidu.com/wiki/index.php?title=docs/cplat/bae
百度应用引擎(BAE)提供多语言、弹性的服务端运行环境,能帮助开发者快速开发并部署应用。
我们在运营BAE2.0的过程中,发现困扰开发者的一个主要问题就是应用的“云端运行环境”与开发者的“本地开发环境”不一致,很多功能受到限制。开发者在本地开发调试好的应用,发布到云端就遇到种种问题无法运行,不得不针对云端环境进行修改。
这个问题的主要原因在于传统PAAS(例如BAE2.0等)采用“沙盒技术”来实现应用之间的资源隔离,“沙盒技术”需要对运行环境和编程 语言进行功能限制,(例如禁止创建进程和线程,禁止某些系统调用,禁止对某些文件系统路径的读写,禁止加载C语言模块、禁止某些网络功能等),这就大大增 加了开发者的学习成本,也使得应用的开发和迁移难度变大。
图1
【如图1所示: 在同一个执行单元内部,采用“沙盒技术”,对每个应用的“运行环境和编程语言功能”进行限制,从而实现了应用的隔离。】
为了解决这个困扰广大开发者的问题,我们推出了新版PAAS平台--BAE3.0。BAE3.0在底层采用“轻量虚拟机技术”完美解决了资 源隔离问题,而在运行环境和编程语言层面,则不做任何限制;应用在云端的运行环境与开发者本地的开发环境保持一致,从而使得学习成本、开发和迁移成本降到 最低,开发者的生产力得到最大限度的解放。
图2
【如图2所示,为每个执行单元创建一个轻量虚拟机,每个执行单元跑一个BAE部署。在轻量虚拟机之间实现资源隔离;在“运行环境和编程语言”层面无任务限制。】
在BAE2.0中应用与BAE部署一一对应,不同部署之间若要共享数据或资源必须通过授权管理,复杂且不方便;在BAE3.0中,应用可包含多个BAE部署,同应用下的多个部署之间的资源是共享的。
在BAE3.0中,每一个BAE实例称为一个“部署”。
每个BAE部署对应一种部署类型。除了传统的WEB形式的部署类型外,BAE3.0新增了worker类型的部署。传统的WEB类型,主要用来创建 WEB应用,它的特点是通过HTTP请求来驱动应用逻辑;但有时候我们需要长期在后台跑一些任务,例如爬虫,不停的去爬取各种网络资源,这种就需要 woker类型的部署来实现了。目前BAE3.0平台支持node.js-web,php-web, php-worker, java-web, python-web, python-worker等部署类型,后续会支持更多类型,给开发者更多的选择。
每个BAE部署由一个或多个“执行单元”组成。执行单元是一个抽象的概念,每个执行单元实际是由一组进程组成;例如一组lighttpd + php-fpm 进程组成了 php-web执行单元。对于一个WEB应用来说,随着访问量的上升,一个执行单元很可能扛不住压力。那么可以通过增加执行单元个数进行“水平扩展”,或 者增大执行单元配置如内存进行“垂直扩展”,从而轻松应对压力。
执行单元由一组进程组成,而这组进程实际是运行在一个单独的轻量虚拟机里面的;每个执行单元对应一个轻量虚拟机。对开发者来说,不需要关心轻量虚拟机的存在,而是关心为自己应用服务的“执行单元”; 而对BAE的运维人员来说,才需要关心轻量虚拟机的运行情况。
图3
【如图3所示:在BAE3.0中,BAE部署与执行单元、轻量虚拟机的关系】
假设有一个“BAE部署”,分配了两个“执行单元”,每个“执行单元”对应一个“轻量虚拟机”, “执行单元”是抽象概念,它启动后,对应着“轻量虚拟机”里面的一组进程,包括 lighttpd 和 php-fpm 进程等。
当“轻量虚拟机”出现故障后,BAE平台会自动为它重新分配一个轻量虚拟机,并将“执行单元”部署到新的轻量虚拟机上,这就是“执行单元”的迁移。这种技术保证了应用的高可靠性。
当应用流量上升,两个“执行单元”不够用的时候,可以再增加新的轻量虚拟机,并部署“执行单元”,这就是“执行单元”的扩容。这种技术保证了应用的可扩展性。
比如在BAE2.0里面的限制,包括创建进程、创建线程、系统调用、执行C扩展模块、文件系统访问等等,在BAE3.0都不再进行限制。
除了PHP、Python、Java、Node.js以外,我们还会陆续增加对主流开发语言的支持。此外将来开发者还可以自定义运行环境。
由于编程语言层面没有任何限制,那么各种编程框架的支持也就水到渠成了。不管你是主流的框架,还是小众的框架,只要能在开发者本地的环境中运行起来,那么在云端也可以跑起来。
对于python开发者来说,只要把依赖的模块,例如django, flask等写到 requirements.txt中,BAE会自动帮你把这些模块部署到执行环境中。对于nodejs开发者,可以使用 package.json 达到同样的效果。
BAE2.0里面,我们为开发者提供的很多贴心的服务,在BAE3.0里面继续可以使用,如MySQL、MongoDB、Redis、Cache、Image等等。
许多PaaS,对外的网络访问需要通过HTTP Proxy 或者是Socket Proxy 代理出去;而在BAE3.0里面,对外的网络访问不再需要经过代理层的转发。
很多PaaS只能提供web类型应用的开发;而BAE3.0新增的worker类型应用,可以满足开发者执行长期任务的需求。例如您可以使用worker类型来实现一个自定义的网络爬虫。Worker类型示例
我们提供了接近于“云端运行环境”的本地开发环境工具,帮助开发者在本地进行开发和调试;当您在本地完成开发和调试后,再将应用部署到云端,就可以流畅的运行起来了。
在创建BAE部署的时候,您可以根据实际情况选择执行单元的“套餐类型”;也可以在应用上线后,根据访问量随时调整“套餐类型”,从而提高资源利用率。
BAE3.0 是一种基于Linux Container的资源独享型PaaS:
Ubuntu 12.04 Server
每个轻量虚拟机都具有一定的资源配额,应用如果使用了超过配额的资源,就可能出现不可预期的错误。例如疯狂分配内存,大量占用磁盘空间等等。
应用代码部署在 /home/bae/app 目录下,其权限为 bae 账号所有
应用代码以 bae 账号来运行;因此应用代码对于 /home/bae 目录下具有任意的读写和访问权限,同时对 /tmp 目录也具有读写和访问权限
应用虽然可以在 /home/bae/ 等目录下任意读写,但是我们说轻量虚拟机里面是一个“临时性文件系统”;也就是说,应用在这些目录下动态创建的文件、目录,是随时可能消失的。这是因为当 轻量虚拟机出现故障,或者轻量虚拟机所在物理机器出现故障的情况下,需要将这个轻量虚拟机动态的迁移到别的物理机器上,保证应用的“高可用性”。迁移后, 原来轻量虚拟机里面的文件、目录就都丢失了;这也是PaaS通用的处理逻辑。
对应用开发者来说,应该意识到PaaS的这种特性,并尽量将需要持久化的数据或者是需要被多个轻量虚拟机共享的数据放到mysql, redis, mongodb, bcs 等存储服务器上。或者使用NFS服务,也可部分解决共享文件的需求。