设计自己的paas平台nap 9—-统一paas平台入口

写在前面

一个好的paas平台，并不只是提供了牛逼的功能，还在于好的交互。我们之前都是追求功能的完整性，在大体框架完成的时候，我们需要的还有较好的编程风格和交互，所以我们花一些时间思考一下关于同意paas平台入口的问题，这样，对于规范之后平台的开发，web manager管理界面的开发，都有很大的帮助。

统一paas平台入口

在我们之前设计的nap（导师帮我起得paas平台的名字，寓意NJU Application Platform, Not Another Platform, take a nap we will do the rest等），平台一共有两个入口，分别是git push的时候，上传应用的入口，另一个就是在web manager管理界面的时候，用fleet的远程控制方法，endpoint来做的。在最初的设计过程中，这两个程序入口已经基本满足了我们的需求，但是在后面的设计过程中，我们发现，我们需要的不只是这两个入口，我们需要一些别的操作，需要新的入口作为支持。同时，这样两个入口，也是非常不美观不安全的。所以，为了进一步完成nap的设计，进一步完善nap的设计，我们准备统一nap的接口。

ssh forced command

继续我们之前只是简单介绍了一下的这个话题。在我们之前的设计中我们只是用command="/home/nap/nap $SSH_ORIGINAL_COMMAND" ssh-rsa ~这条命令改变了程序进入服务器的入口，但是，其实，这个东西可以做的东西，更多。我们之前的设计中，就是直接在/home/nap/nap中，执行了我们希望的流程，不过，这里面可以做一些判定语句，这些语句的作用有两个。一是，丰富nap的接口类型，数量。而是，限制nap用户可以使用的命令的范围，这也是为了平台的安全着想。比如，在/home/nap/nap中，我们用一个case语句。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

args=$*
case $1 in
  
  #something i did before
  git-receive-pack)
      ./git_push_treat $args
  ;;

  #git push and only submit
  submit)
      ./submit_treat $args
  ;;

  #be aware of mpi maven and other projects
  start)
      ./start_treat $args
  ;;

  #just stop it
  stop)
      fleetctl stop $2
  ;;

  #list all submit services in cluster
  list-services)
      fleetctl list-units
  ;;

  #list all instances named like ${app}*
  list-instances)
      ./list_instances_treat $2
  ;;

  #list all machines
  list-machines)
      fleetctl list-machines
  ;;  

  #status of an instance
  status)
      fleetctl status $2 -l
  ;;

  #destroy an instance
  destroy)
      fleetctl destroy $2
  ;;

  *)
      echo "no this command, try git push, submit, start and so on"
esac

这个case语句的作用就非常明显了，不在case语句中的命令，都会告诉用户，所需要的操作没有权限执行。其次，当执行到允许的操作的时候，有相应的操作对其进行配对。比较简单的，像status，destroy等都比较简单。但是有一些比较麻烦的，也是需要特殊处理一下的，比如。 - git-receive-pack 这个命令其实就是我们之前设计的paas平台的第一个接口，其实这里应该用不到了，但是，我还是保留了下来，这个主要是给我自己测试用的。当然，也可以给一些终端用户，而不是web管理界面用户使用。但是我们以后还会设计一个命令行工具，那个命令行工具支持终端用户使用这些命令，但是我们这里还没有设计，以后再论述。 - start 这条命令之所以单独提出来，也是因为这条命令有一些比较难以处理的情况，因为我们希望我们设计的程序支持多种类型，所以，在start的时候，是start了一个应用的多个实例，还是start了一个mpi应用，这些都是不可预知的，所以，我们可能希望通过不同的start命令，来实现这个功能。 - submit 这条命令的目的是，允许用户只是上传应用，并不是上传加部署，是git-receive-pack的简化版本。 - list-instance 这条命令，需求并不是列出所有的跑起来的应用，而是只列出和某个应用相关的应用。比如list-instance $APP，那么，就列出和这个APP相关的，比如这个APP的不同实例啊，如果是mpi应用，仅仅列出这个APP的slave和master之类的啊。

Jun 15th, 2015
nap平台