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服務,也可部分解決共享文件的需求。