基于Docker开发的PaaS平台 DINP

DINP是又一个基于[Docker](/p/docker)开发的PaaS平台。 DINP 包含如下组件： * [dinp-server](http://git.oschina.net/cnperl/dinp-server) master组件，控制集群中所有计算节点 * [dinp-agent](http://git.oschina.net/cnperl/dinp-agent) Agent，部署在所有计算节点，收集各个节点运行状态和container列表 * [dinp-builder](http://git.oschina.net/cnperl/dinp-builder) 编配平台，负责把用户代码打包为Docker image * [dinp-dash](http://git.oschina.net/cnperl/dinp-dash) Dashboard，用户操作的入口 * [dinp-router](http://git.oschina.net/cnperl/dinp-router) 负责请求的路由等功能 * [dinp-hm](http://git.oschina.net/cnperl/dinp-hm) Health Monitor，对APP的rs进行7层健康检查 * [dinp-common](http://git.oschina.net/cnperl/dinp-common) 公共函数、数据结构 之所以用了“又”字，是因为现在的PaaS平台着实很多，DINP只不过是又造了个轮子，下面给大家说说这个轮子与其他轮子的不同点。 1. DINP只接管web应用 PaaS平台是个规范性很强的平台，app要用PaaS托管，必须要满足1、2、3...n条规范才可以。web应用通常无状态，逻辑简单，部署方式统一故而可以使用PaaS托管。但对于一些分布式大型软件、复杂的rpc服务，部署架构复杂，并不适合用PaaS托管。有所为有所不为，DINP只接管web应用。 2. DINP不接管代码的编译环节 像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也支持，但是不推荐。 3. DINP够简单 如果你对Docker比较熟悉，那DINP对你来说会很简单，我们并没有做太多事情，你理解起来也会相对轻松。PaaS中需要一个通用打包规范，我们使用了Dockerfile；PaaS中需要一个SCM存放发布包，我们使用了Docker Registry；PaaS中需要一个container来run app，我们使用了Docker。另外PaaS中需要一个七层router，我们使用了CloudFoundry提供的gorouter。DINP的绝大部分组件都是Golang写的，静态编译的语言部署起来超方便。Dashboard和UIC是用Java写的，基于JFinal框架，很简单的，相信我 4. DINP的架构  a. 用户把代码打包为.tar.gz，交给Builder打包为一个Docker image b. 拿到Builder产出的Docker image去Dashboard创建一个App，设置好实例数、内存大小、image地址，O了。Dashboard把用户填写的这些信息写入MySQL c. Server定期从MySQL同步用户期望的数据，姑且称之为desired state d. 部署在所有计算节点的Agent与Server之间有心跳通信，收集本机的剩余内存量和container列表，姑且称之为real state e. Server对比desired state和real state，发现某个App的实例数少了就去调度新的计算节点创建新实例，如果发现某个App实例数多了，就干掉多余的实例 f. Server同时会分析real state，组织出路由信息写入redis g. Router定期从redis中获取路由信息 h. Router通常部署多个，前面部署LVS，注册一个域名，比如apps.io，把*.apps.io这个泛域名解析到LVS VIP，整个流程就通了 5. 服务接入 如果你玩过CloudFoundry，会很敏感的发现，DINP没有接管MySQL、Memcache、Redis、MQ等等服务。为什么呢？我们的想法是这样的：专业的人做专业的事，在公司里，MySQL、Redis之类的服务已经有DBA团队运维管理了很久了。他们是最懂的人，他们已经形成了一整套成熟的部署规范，运维流程。只要提供一个连接地址，一个账号让PaaS上的App连上去就行了，何必非要把MySQL与DINP做很强的关联整合呢 补充 DINP在公司内部小规模用了几个月，没有出什么问题，大家可以玩一玩了。