add by zhj: 其实我主要是想看看基于docker的PaaS的特性。php
原文:http://developer.baidu.com/wiki/index.php?title=docs/cplat/baejava
百度应用引擎(BAE)提供多语言、弹性的服务端运行环境,能帮助开发者快速开发并部署应用。node
咱们在运营BAE2.0的过程当中,发现困扰开发者的一个主要问题就是应用的“云端运行环境”与开发者的“本地开发环境”不一致,不少功能受到限制。开发者在本地开发调试好的应用,发布到云端就遇到种种问题没法运行,不得不针对云端环境进行修改。python
这个问题的主要缘由在于传统PAAS(例如BAE2.0等)采用“沙盒技术”来实现应用之间的资源隔离,“沙盒技术”须要对运行环境和编程 语言进行功能限制,(例如禁止建立进程和线程,禁止某些系统调用,禁止对某些文件系统路径的读写,禁止加载C语言模块、禁止某些网络功能等),这就大大增 加了开发者的学习成本,也使得应用的开发和迁移难度变大。mysql
图1 linux
【如图1所示: 在同一个执行单元内部,采用“沙盒技术”,对每一个应用的“运行环境和编程语言功能”进行限制,从而实现了应用的隔离。】 web
为了解决这个困扰广大开发者的问题,咱们推出了新版PAAS平台--BAE3.0。BAE3.0在底层采用“轻量虚拟机技术”完美解决了资 源隔离问题,而在运行环境和编程语言层面,则不作任何限制;应用在云端的运行环境与开发者本地的开发环境保持一致,从而使得学习成本、开发和迁移成本降到 最低,开发者的生产力获得最大限度的解放。 redis
图2 sql
【如图2所示,为每一个执行单元建立一个轻量虚拟机,每一个执行单元跑一个BAE部署。在轻量虚拟机之间实现资源隔离;在“运行环境和编程语言”层面无任务限制。】 mongodb
在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服务,也可部分解决共享文件的需求。