设计自己的pass平台nap 10—-统一接口规范
写在前面
继续探讨一些统一接口，列出统一接口的名称，使用方法，和每个接口的功能。并通过大体流程的描述，详细叙述每个接口的功能。并把这篇文章最为web manager管理界面开发的时候参考的主要接口文档。
继续阅读;设计自己的paas平台nap 9—-统一paas平台入口
写在前面
一个好的paas平台，并不只是提供了牛逼的功能，还在于好的交互。我们之前都是追求功能的完整性，在大体框架完成的时候，我们需要的还有较好的编程风格和交互，所以我们花一些时间思考一下关于同意paas平台入口的问题，这样，对于规范之后平台的开发，web manager管理界面的开发，都有很大的帮助。
继续阅读;设计自己的paas平台nap 8—-支持mpi应用
写在前面
之前我们已经实现了Dockerfile应用，maven应用的支持，现在，我们要加入另外一种类型，这种类型和之前的两种都不一样，这种应用和之前的应用的最大区别在于，这种类型的应用，并不是一个容器就可以完成的，需要多个容器配合，mpi和mapreduce应用就是这样，他们需要master slave节点，共同协作完成一件任务。我们这里先介绍mpi应用的设计，后面再介绍mapreduce应用的支持实现。
继续阅读;设计自己的paas平台nap 7—-单应用多实例
写在前面
前面一片文章说了关于配置多个实例的问题，其实我们应该更加深入的理解一下。很容易混淆的一个问题就是单应用多实例和一组类似应用的区别。而且，他们实现起来也是有很大差别的。下面我们对这个两个问题进行分别探讨，并分别实现，完成nap的更多功能。
继续阅读;设计自己的paas平台nap 6—-配置应用设置参数
写在前面
很多时候，我们需要对应用进行一些配置信息。比如，需要的内存是多少，需要几个cpu来运行它，甚至要启动几个实例等。这些也是一个完整的paas平台所需要具备的功能。当然，nap也需要这个功能。
继续阅读;设计自己的paas平台nap 5—-maven规范和自发现服务
写在前面
nap在对应用进行部署时，应该有一个判断机制，如果这个应用已经是最新的了，那么我们就直接返回最新的结果就可以了，不需要重新部署。而且我们的nap到现在为止，都是只完成了对Dockerfile应用的简单支持，简单一些，我们可以实现maven应用的支持。下面，我们就上面两个问题，进行简单介绍。
继续阅读;设计自己的paas平台nap 4—-fleet集群部署
写在前面
我们之后可能会遇到这个问题。部署成功了一个web应用，我们需要给这个应用注册一个web地址，并且返回给用户，那么，如何得到这个应用的ip地址，端口号等信息呢？在fleet的机制中，有个discovery机制，这个机制就很好的完成了这个工作，其主要工作原理就是，运行一个discovery service，通过不断轮询对应的service有没有启动起来，如果启动起来了，就把其端口号和ip地址等信息写入到etcd中去，当需要的时候，再从etcd中取。下面，我们来简单介绍一些这些在nap中的代码实现。
继续阅读;设计自己的paas平台nap 3—-整体流程
写在前面
有了上一篇关于客户端和服务器端的设计介绍，我们就可以简单地把这两者联系起来，构成一个paas平台的小demo。我们这里通过对最简单的应用类型，有dockerfile的应用，做一次完整的，从push到解释为systemd的service，到最终运行在单机服务器上的过程，首先跑通这个流程，然后再在这个基础上，增加新的应用类型，和晚上操作。
继续阅读;设计自己的paas平台nap 2—-分解客户端和服务器端
写在前面
前面一片文章我们主要介绍了我们的paas平台nap所基于的技术基础，这篇文章，我们首先介绍一下nap的整体思路，然后通过从客户端和服务器端的一些设计，一步一步地来了解如何设计一个完整的paas平台。
继续阅读;设计自己的paas平台nap 1—-背景知识
写在前面
在理解了dokku，dokku-alt的基础上，我们设计自己的paas平台。我们的终极目标是在一个集群环境中设计一个paas平台，dokku只是单机环境下，为了我们的终极目标，我们最终选择的paas的底层平台是coreos集群环境。这几篇blog只是我们不断进行尝试的日志，并不是一个完整的教程，等我们最终搭建好了，可能会写一个完整的教程，但那都是后话。
继续阅读;