Framework开发指南 四

转自： http://www.hitdcos.com/read.php?tid=17&fpage=4

自定义安装Framework Executor


创建您的自定义executor之后，您需要将其提供给集群中的所有的slaves。.
 
一种发布 framework executor是当scheduler向slave发布tasks时让 Mesos fetcher 按需求下载 . ExecutorInfo 是一个Protocol Buffer Message类(定义于include/mesos/mesos.proto), 它包含一个 CommandInfo类型的字段. CommandInfo 允许schedulers规定,除其他事项外, 一些资源作为URIs. 在尝试执行ExecutorInfo 命令前这些资源被slave上的sandbox文件夹取回。支持的URI 模式包括HTTP、FTP、 HDFS、和S3 (注，见src/examples/java/TestFramework.java例子).
或者，当你发布他们去规定framework executors在哪安装 (注， 在一个可以提供给所有slaves的NFS挂载)时，你可以通过传递 frameworks_home 到mesos-slave 守护进程配置选项 (默认为:MESOS_HOME/frameworks) , 然后用CommandInfo.uris里的相对路径, slave 将frameworks_home的值前置于相对路径。
一旦你确定所有mesos-slaves都可以获取executors, 你就可以运行scheduler，它向Mesos master注册并开始接接受offers！
 
可以在FrameworkInfo, TaskInfo, DiscoveryInfo和TaskStatus信息中找到标签（Labels）。计算框架和模块的编写者可以在Mesos内使用标签来标记和传递非机构化的信息。标签是以key-value的自由格式提供给计算框架调度器或标签装饰钩子。下面是protobuf的标签定义：
optional Labels labels = 11;
/**
* 标签集合。
*/
message Labels {
    repeated Label labels = 1;
}
/**
* 以Key，value的形式来自由存储用户数据。
*/
message Label {
  required string key = 1;
  optional string value = 2;
}
标签并不是Mesos给它自己进行解释，但作为管理器和节点之间的终点状态。此外，执行器和调度器在TaskInfo和TaskStatus以编程的方式进行标签解析。下面是列举了两个对标签的例子 ("environment": "prod" 和 "bananas": "apples")可以从管理器状态终点进行获取。 
$ curl http://master/state.json
...
{
  "executor_id": "default",
  "framework_id": "20150312-120017-16777343-5050-39028-0000",
  "id": "3",
  "labels": [
    {
      "key": "environment",
      "value": "prod"
    },
    {
      "key": "bananas",
      "value": "apples"
    }
  ],
  "name": "Task 3",
  "slave_id": "20150312-115625-16777343-5050-38751-S0",
  "state": "TASK_FINISHED",
  ...
},

发现服务Service discovery


当你的计算框架注册了执行器，并启动了任务，可以给发现服务提供额外的信息。这些信息存储在Mesos管理器伴随着其他重要信息 例如节点（slave）正在运行的任务。在Mesos集群运行多计算框架多任务时，发现服务系统可以以编程的方式准备号纠正并恢复创建DNS索引、配置代理、或者更新不一致的存储信息。 
DiscoveryInfo选项信息将会传递给TaskInfo和ExecutorInfo，声明如下代码位于：MESOS_HOME/include/mesos/mesos.proto 
message DiscoveryInfo {
  enum Visibility {
    FRAMEWORK = 0;
    CLUSTER = 1;
    EXTERNAL = 2;
  }

  required Visibility visibility = 1;
  optional string name = 2;
  optional string environment = 3;
  optional string location = 4;
  optional string version = 5;
  optional Ports ports = 6;
  optional Labels labels = 7;
}
显而易见的，通知发现服务器系统应当发现已经通知过的Key参数。我们现在列举三个不同的案例： 
任务不除了所属的计算框架以外的不应当被发现。
任务应当在所运行的Mesos集群中的所有计算框架发现，而不是在外部被发现。
任务应当无误的发现。
大量的发现服务系统提供附加的管理可见的字段。（举例来说，系统中基于代理的ACL，DNS的安全扩展，VLAN或者子网选择）不打算使用可见的资源来管理这些功能。服务发现系统重新从管理器获取任务或者执行器信息，这种方式解决没有DiscoveryInfo如何获取任务。举例，任务不会对其他计算框架可见。（等价于 visibility=FRAMEWORK）或者对所有计算框架可见（等价于 visibiility=CLUSTER）。 
名称字段的数据格式是字符串，字符串可以保证服务发现系统通过名字的形式发现任务。典型的名称字段是提供有效的域名。如果名称无法提供，则需要服务发现系统在taskInfo或者其他信息中的名称字段来为任务创建名称。 
环境变量、地址信息、和版本等字段在大型部署中提供了第一类的支持，对象的属性相同但是在不同地方应用的相似服务。环境可以接收如吃产品/质量检查/开发，位置字段可以接收如下值：EAST-US/WEST-US/EUROPE/AMEA, 以及版本字段可以接收如下值v2.0/v0.9。发现系统需要正确的把这些字段提供给服务发现系统。 
端口字段允许计算框架定义任务的监听端口并明确名称的功能，端口字段是可以再次提交并使用网络的第四层通讯协议（TCP，UDP或者其他）。举例，Cassandra的任务定义如下端口"7000,Cluster,TCP", "7001,SSL,TCP", "9160,Thrift,TCP", "9042,Native,TCP", 和 "7199,JMX,TCP"。由服务发现系统以适当形式的协议把潜在的把DiscoveryInfo的名称字段进行绑定。 
标签字段允许计算框架以key/value对的格式传递主观标签给服务发现系统。注意：通过这些字段传递的任何事情，是无法保障执行移动到下一步。虽然如此，字段提供扩展性。这些共同使用的字段允许我们确认需要请求第一类支持的例子。