為什么需要PaaS？一句話，現(xiàn)在的應(yīng)用程序從源代碼到運行階段太復雜，沒有標準的，通用的方式。
整個過程及產(chǎn)出如下：
開發(fā)階段：源代碼構(gòu)建階段：發(fā)布包/可執(zhí)行程序部署階段：可運行的鏡像（發(fā)布包+配置）運行階段：進程、集群、日志、監(jiān)控信息、網(wǎng)絡(luò)不論是Deis，Heroku，F(xiàn)lynn或者其他PaaS的目標，都是為了讓2-4這3個階段盡可能的簡單。看了他們所設(shè)計的產(chǎn)品，簡單到了什么程度？通過一個客戶端命令行工具，實現(xiàn)了：
開發(fā)到構(gòu)建：
用戶通過git提交源代碼，由PaaS自動構(gòu)建鏡像，并提供版本的管理——用戶可以創(chuàng)建新版本(提交新代碼或修改部署配置)、回滾老版本等。
部署到運行：
自動選擇運行機器，為每個進程副本部署啟動單獨的容器，解決請求路由和負載均衡，并提供進程的管理——用戶可以做擴縮容、查看日志、監(jiān)控狀態(tài)等、回滾歷史的發(fā)布
為什么是這些功能？為什么這些功能不能分別由各種工具實現(xiàn)？
在我看來，代碼從發(fā)布到運行由兩根軸組成。
縱軸： 源代碼——發(fā)布包——可運行的鏡像——進程
這里的關(guān)系是一步接一步，順序往下，不論你用什么工具什么平臺，這4步都是流水式的向下。
橫軸： 負載均衡、集群部署擴容縮容、健康檢查、日志
線上的應(yīng)用，有以下幾種情況
發(fā)布新功能：全量更新和部署性能壓力：通過健康檢查或手工觸發(fā)，進行擴容和縮容保證業(yè)務(wù)連續(xù)性：在上面的更新中，通過負載均衡，把新請求導入到更新后的容器上，等待舊的處理完后進行更新所以，上面這4項是一環(huán)扣一環(huán)，橫向的互相關(guān)聯(lián)，如果不在一個工具內(nèi)同時提供這4項功能，就需要人工去填平這里面的信息交互，手動的整合這4個工具，從而帶來復雜性。
約束及實現(xiàn)
縱向編譯：buildpack
buildpack填平的是從源代碼到發(fā)布包的坑，就是一組編譯腳本。
PaaS平臺自己提供一些編譯腳本，但也允許用戶按照規(guī)范自己寫編譯腳本。
（腳本需要自己下載合適版本的編譯器！）
如果使用Docker，用戶提供的就是一個DockerFile或者Dockerimage地址，拿了直接就能跑起來的東西。
縱向運行：Procfile
buildpack讓PaaS知道怎么編譯程序，Procfile讓PaaS知道怎么運行程序。
一個典型的Procfile就是像這樣
cat ./Procfile web: bundle exec rails server -p $PORT后面可以通過命令行來動態(tài)擴容程序
deis ps:scale web=4縱向配置：環(huán)境變量
運行的發(fā)布包在不同的環(huán)境下有不一樣的配置，Deis的方式是通過環(huán)境變量。客戶端的命令行工具上設(shè)置環(huán)境變量后，就直接發(fā)送給所有容器，重設(shè)這些環(huán)境變量，然后重啟。
京公網(wǎng)安備 11010502049343號