基于Docker開發的PaaS平台 DINP基于Docker開發的PaaS平台 DINP

dinp是又一個基于docker開發的paas平台。

dinp 包含如下元件：

之是以用了“又”字，是因為現在的paas平台着實很多，dinp隻不過是又造了個輪子，下面給大家說說這個輪子與其他輪子的不同點。

<a target="_blank"></a>

paas 平台是個規範性很強的平台，app要用paas托管，必須要滿足1、2、3...n條規範才可以。web應用通常無狀态，邏輯簡單，部署方式統一故而可以 使用paas托管。但對于一些分布式大型軟體、複雜的rpc服務，部署架構複雜，并不适合用paas托管。有所為有所不為，dinp隻接管web應用。

像 tsuru之類的paas，從代碼的push就開始接管了。他們通常要求使用者把代碼push到指定repo的指定分支，以此觸發git receiver，git receiver與後端其他元件協同，拉取使用者最新代碼，下載下傳dependency，編譯，打包等等。但是在國内，因為一些原因，下載下傳 dependency是一個很費勁的過程。如果這個動作放到平台來做，使用者每次要上線了都要等待一個漫長的過程是不可接受的。

是以，dinp不接管代碼的編譯環節，需要使用者自己通過科學上網的方式搞定。比如java，使用者把最終的war包扔給dinp即可，而不能是扔一 堆.java源檔案和pom.xml；比如golang，使用者把編譯好的二進制扔給dinp即可，而不能扔一堆.go源檔案；比如python，使用者最好 提前下載下傳好相關lib庫，然後加入環境變量，而不是提供一個pip_requirements.txt，當然，對于一些特别容易安裝的lib庫，使用者提供 一個pip_requirements.txt也未嘗不可，dinp也支援，但是不推薦。

如果你對 docker比較熟悉，那dinp對你來說會很簡單，我們并沒有做太多事情，你了解起來也會相對輕松。paas中需要一個通用打包規範，我們使用了 dockerfile；paas中需要一個scm存放釋出包，我們使用了docker registry；paas中需要一個container來run app，我們使用了docker。另外paas中需要一個七層router，我們使用了cloudfoundry提供的gorouter。dinp的絕大 部分元件都是golang寫的，靜态編譯的語言部署起來超友善。dashboard和uic是用java寫的，基于jfinal架構，很簡單的，相信我。

使用者把代碼打包為.tar.gz，交給builder打包為一個docker image

拿到builder産出的docker image去dashboard建立一個app，設定好執行個體數、記憶體大小、image位址，o了。dashboard把使用者填寫的這些資訊寫入mysql

server定期從mysql同步使用者期望的資料，姑且稱之為desired state

部署在所有計算節點的agent與server之間有心跳通信，收集本機的剩餘記憶體量和container清單，姑且稱之為real state

server對比desired state和real state，發現某個app的執行個體數少了就去排程新的計算節點建立新執行個體，如果發現某個app執行個體數多了，就幹掉多餘的執行個體

server同時會分析real state，組織出路由資訊寫入redis

router定期從redis中擷取路由資訊

router通常部署多個，前面部署lvs，注冊一個域名，比如apps.io，把*.apps.io這個泛域名解析到lvs vip，整個流程就通了

如 果你玩過cloudfoundry，會很敏感的發現，dinp沒有接管mysql、memcache、redis、mq等等服務。為什麼呢？我們的想法是 這樣的：專業的人做專業的事，在公司裡，mysql、redis之類的服務已經有dba團隊運維管理了很久了。他們是最懂的人，他們已經形成了一整套成熟 的部署規範，運維流程。隻要提供一個連接配接位址，一個賬号讓paas上的app連上去就行了，何必非要把mysql與dinp做很強的關聯整合呢

dinp在公司内部小規模用了幾個月，沒有出什麼問題，大家可以玩一玩了。

原文釋出時間：2015-02-10

本文來自雲栖合作夥伴“linux中國”