【编者按】Role是Mesos中的一个非常重要的概念，Mesos围绕它来定义资源在多个framework之间分配的策略。在Mesos 0.26之前，Mesos集群的操作员可以通过指定–roles这个参数来指定Mesos所支持的Roles，一个framework只能通过Mesos支持的role来加入到Mesos的集群进而接收Mesos所发送的Resource Offer。如果后来有一个新的framework需要加入，集群操作员需要为它新增一个新的role的时候，他就必须重启所有的Mesos Master节点来修改–roles这个参数,这在实际的生产环境上实际上是不可取的，为了解决这一问题，Mesos在0.27版本中引入了Implicit Roles这个新的特性来解决这一问题。
Mesos Roles
在介绍Implicit Roles之前，我们先来大概的了解一下Role在Mesos中的作用。在Mesos中，role主要是用来在各个framework组之间进行资源的配置，也就是说role提供了多个租户之间的资源隔离，使用同一个role来注册的frameworks属于一个租户。在Mesos中和role相关的case主要有以下几种：
1.资源的静态分配。它是在Mesos agent启动的时候你可以把部分资源分配给某些role，或者一次性把所有的资源分配给某一个role。然后Mesos Allocator将会把这个agent上的资源根据DRF算法分配给这个role下注册的所有frameworks。
2.资源的动态分配。在Mesos运行期，集群的操作员可以通过HTTP endpoint为某些role分配一些资源。
3.Quota配置。比如集群操作员可以通过为某个role配置quota来限制这个role下注册的所有framework使用资源的数量，也可以通过配置quota来保证注册在某个role下的所有framework至少有多少资源可以使用。
4.Weight的配置。可以为不同的role来设置不同的weight来修改它们之间资源分配的优先级。
5.配置磁盘组。可以为某个role创建一个persistent volumes，这样就可以隔离不属于这个role的framework来使用这块存储资源。
Implicit Roles前世今生
在介绍Implicit Roles之前，我们先来了解以下它的背景。为了支持在Mesos数据中心运行期间动态配置role这一问题，社区开始的想法是引入一个新的endpoint来支撑dynamic roles，让集群操作员可以在运行时动态的配置roles。本文的作者作为这个proposal owner来简单介绍一下大概的设计：
这个endpoint是这样的：
$ curl -d JsonMessageBody –X POST http://<master-ip>:<port>/roles例如，如果我们要为新加入的framework新增一个role，则我们可以使用如下的
JsonMessageBody：
{
"name" : "sales",
"weight" : 2.0
}weight参数是可选的，它表示role1的资源分配的优先级，如果在以上的HTTP请求中不指定的话，系统将采用默认值（1.0）.在后续的章节中我们将会对weight相关的特性进行介绍，这里不多说明。
后来社区没有采用这个设计的一个主要的原因，是它引入的一个新的endpoint，对集群操作员来说操作过于繁琐，没有Implicit Roles的设计简洁。如果哪位读者对Dynamic Roles有兴趣的话，你可以参考这个proposal的详细设计：
https://docs.google.com/document/d/1OIgceqpsjV3-_LGF83IMAFnrh1Ea3Zc16w9kWWPpUj4/edit#
Implicit Role从字面意思上来看，就是隐含的role，它主要的思想就是Mesos集群操作员将不需要为Mesos集群配置一个合法的role list，所有可能的role(在role所支持的字符集，长度的范围内)都是容许的。因此一个新的framework能不能使用这个role（例如sales）来注册，将主要取决与Mesos ACLs的配置，Mesos将不会额外验证这个role是不是合法的。也就是说如果一个Mesos 集群没有配置任何的ACLs，那么framework可以使用任意的（注：但必须是role所支持的字符集，以及长度）role来注册。
Implicit Roles实践问题归纳
从上边的简介，我想大家已经对Implicit Roles有一个大致的了解，但也会有不少的问题，从我个人的理解，如果你要在实际中使用这个新的特性，你需要注意一下问题：
兼容性问题
作为一个不断快速演进中的开源产品，虽然Mesos到现在仍然没有达到一个比较稳定的版本（V1.0），但它已经应用与很多企业的生产环境（比如国外的twitter，airbnb，苹果的siri等，国内的爱奇艺，豆瓣等），因此在对一个重要特性做大的改进的时候，我们需要考虑兼容性问题。
上边介绍过，在Implicit Roles实现之前，Mesos集群的操作员是通过–roles这个参数来在Mesos Master启动时配置所支持的role list，上层的framework只能使用这些role来注册Mesos。Implicit Roles的设计为了兼顾向后的兼容性问题，它时分了两个阶段来实施的：
1.第一阶段，也就是在Mesos 0.27版本，Implicit Roles只有在Mesos集群操作员在启动Mesos Master时没有指定–roles时生效。也就是说，这个新的特性在0.27版本中，它仅仅改变了–roles这个参数没有指定时的Mesos的行为，如果一个静态的role list在Mesos Master启动时被指定，那么Mesos集群仍然维持原有的行为。为了进一步理解举个例子：
如果你现在安装了0.27版本，但你在启动Mesos Master时指定了–roles:
\# ./bin/mesos-master.sh --ip=127.0.0.1 --work_dir=/var/lib/mesos --roles="sales,enginers"那么Implicit Roles就被disabled，上层的framework仍然只能使用sales，enginers或者默认的role（＊）来注册到Mesos集群，这时和role相关的行为和0.26之前的行为一致，比如集群操作员仍然不能为Mesos中不支持的role（也就是sales和enginers之外的role）reserve资源，配置quota等。
2.第二阶段：也就是大概在一个贬值周期之后，Mesos的贬值周期一般大概为6个月，按照Mesos release的周期来算，大概在Mesos 0.33版本，–roles这个参数将会被废弃掉，如果那时在启动Mesos master时指定了这个参数，Mesos master将会启动失败，告诉你不支持这个参数。
综上所述：也就是在Mesos 0.27版本之后，Mesos不再推荐在启动Mesos master的时候使用–roles参数，建议使用Implicit roles这个新特性。
资源分配的公平性问题
在看了上边对Implicit Roles的详细解释后， 我想大家一个直接的问题就是如果允许framework用任意的role来注册Mesos，那会不会影响Mesos对资源分配的公平性？会不会出现一个不良公民通过注册多个role来恶意使用更多的资源？了解Mesos资源分配的人可能知道，Mesos默认采用的是DRF allocator，它以一个相对公平的原则在各个role之间分配资源，如果有新的role加入，那它势必会影响已有的资源分配格局。Implicit Roles的这个问题它是通过Mesos 的Authentication和Authorization来解决的。
Mesos集群的操作员可以通过配置Authentication，来保证只有信任的framework可以访问Mesos集群。现在的Authentication主要用在以下三个方面：
1.要求farmeworks注册时进行认证。
2.要求计算节点slaves在注册时进行认证。
3.要求集群操作员在使用某些HTTP endpoints访问Mesos集群时进行认证。
Authentication默认情况下是不被激活的，操作员可以在启动Mesos Master的时候通过指定–authenticate，–authenticate_http 和–credentials参数来激活Authentication。这样Mesos集群就可以避免非法的framework来注册Mesos集群。–credentials指定的是一个JSON格式的文件，例如：
{
"credentials": [
{
"principals": "swarm",
"secret": "passw0rd"
}
]
}另外Mesos集群操作员可以通过配置Authorization来阻止framework以一个非法的role来注册。Mesos Authorization是通过ACLs（Access Control List）来实现的，每一个ACL通过指定一个主题（Subject）来表示它可以对某些对象（Object）做哪些操作（Action）。它是一个JSON格式的配置文件，例如：
{
"register_frameworks": [
{
"principals": {
"values": ["swarm"]
},
"roles": {
"values": ["docker-compose", "docker-client"]
}
}
]
} 上文的配置表示只有principal为swarm这个framework才可以注册Mesos集群，并且它只能使用docker-compose和docker-client作为它的role。这样就可以杜绝上层的framework使用非法的role来注册。
综上所述，其实在实际的生产环境，Implicit Roles这个特性必须要和Mesos的Authentication和Authorization结合来使用。
Implicit Roles对其他endpoints的影响
按照对传统设计的理解，既然role作为Mesos的一个重要的实体，Mesos
围绕它来定义各个framework之间共享resource的规则，因此作为Mesos集群的操作员，他／她应该首先在Mesos集群中创建这个role，然后为这个role配置weight，static／dynamic reservation, quota, create persist volume等，然后framework可以使用这个role以及按照对它所定义的规则来使用集群的resources。
Implicit Roles的设计它打破了这一个传统，也就是它不强调上边的操作顺序。也就是说集群的操作员可以为一个不存在的role设置weight，reserve资源，设置quota等。在Mesos 0.26之前，如果你要操作一个不存的role， 则会失败。这种行为的改变影响的endpoints有：
•/master/create-volumes //为Role创建persistent volume.
•/master/quota //为Role配置quota
•/master/reserve //为Role reserve资源
•/master/weights //为一个Role配置weight，这个feature将在Mesos 0.28 release。
未来展望
Mesos到现在的0.27版本，其实对很多的配置都是不支持在运行时进行修改的，比如：Authentication，Authorization，Framework的Meta信息，Agent的配置信息等。从长期来看，作为下一代的数据中心的操作系统，Mesos必须要对Master和Agent节点同时支持在运行时的动态配置，如：可以在Master/Agent运行时，动态的修改Master/Agent的命令行参数; 可以在Framework运行时，修改它的Meta信息等。请大家关注今年的Mesos Conference，将会有专门的topic来介绍Mesos的动态配置。
IBM Platform DCOS Team作为Mesos社区的主要贡献组织，结合自身在资源调度方面丰富的实践应验，通过将自己的资源调度组件EGO与Mesos集成，为Mesos上层framework提供了更多的调度策略，以及一个集中式的资源调度策略配置界面，Mesos集群的操作员可以通过这个界面配置Global Resource Plan.提升了终端用户使用Mesos的体验。
http://geek.csdn.net/news/detail/59734