Mesos 1.2.0 Release 解读
Mesos刚刚发布了最新的1.2.0版本， 新版本解决了社区之前呼声比较多的几个问题，看得出Mesos开发组的推进进度还是非常快速而平稳的。这也是Mesos社区一贯的作风， 核心Feature稳定优先，周边功能积极支持。
根据1.2.0 Release note列出的几个新Feature， 可以看到几个主要的改进都是围绕着容器相关的， 其中既包含对Mesos Containerizer改进， 同时也有对Docker Containerizer功能补充， 这些工作都是围绕之前Mesos社区提出的Unified Containerier目标来进行的。
容器化和Docker技术在开发者中间已经广泛流行，将来的服务标准化，容器化应该会做的越来越好，Mesos作为调度系统的首选， 顺应潮流也是大势所趋。如何更好地支持容器化应用的调度应该是Mesos近期的工作重点。
数人云逐一分析Release Note中的各个部分：
MESOS-5931
Mesos Containerizer实验性支持auto backend， overlayfs优先于aufs，由于bind backend需要事先存在，需要通过agent启动时的image_provisioner_backend参数明确指出。
解读——
相比Docker Containerizer，Volume一直是Mesos Containerier的弱点，由于Layered存储一开始就是Docker的招牌优势，目的是减少运行时容器对存储的过度使用。Docker当前支持Aufs， Overlayfs，DeviceMapper集中CoW形式的Volume， Bind Mounted Volume本质上不是一种CoW存储，目的更多是帮助在Host和主机之间做存储共享。
Docker社区下一步主要推的是OverlayFS和OverlayFS2，而之前生产环境应用比较广泛的DeviceMapper却没有在Mesos支持范围， 看得出Mesos是紧跟Docker脚步的。
Agent启动增加了image_provisioner_backend参数， 目的是指定预先设定的bind backend地址。
MESOS-6402
（实验）支持Mesos containerizer的rlimit。对于使用Mesos containerizer来启动容器， Isolator添加了对设置POSIX资源限制（(rlimits）的支持。POSIX rlimits可以被用来控制一个进程中耗费的资源。细节见http://mesos.apache.org/docum…。
解读——
Mesos之前支持isolator如posix/cpu, posix/mem， 以及cgroup/cpu等， 这次又增加了rlimit isolator, 可以更灵活的配置Executor比如文件句柄数量，connection数量等。
MESOS-6419
（实验）Teardown未注册的Framework。Master现在对待恢复的Framework将和对待已经注册但是当前断开连接的Framework非常类似。举例来说，当通过HTTP请求Framework时，恢复的Framework将通过正常的“Frameworks”部分进行报告。它意味着不再有“孤儿任务”的概念：如果Master知道这个任务，任务就会运行在Framework之下。类似的，在恢复的Framework上的“teardown”操作现在已经正常工作了。
解读——
Teardown unregistered frameworks， 通过这个改进，目测可以TearDown一些超时的Frameworks，可以很好的清理Frameworks下的tasks， 之前困扰Swan【数人云开源Mesos调度器】开发的一个问题就是如何清理Crashed之后的Swan的task问题，通过这个功能可以很好的帮助Swan解决这个问题。
MESOS-6460
（实验）容器的Attach和Exec。这个特性为正在运行的Mesos任务附加一个远程客户端到其stdin, stdout和stderr上提供了新的Agent API，也提供了一个在同一容器内启动新进程作为运行的Mesos任务、并附加到它的stdin, stdout和stderr上的API。在更高的层面，这些API在功能上模仿了Docker attach和Docker exec。这个特性主要是为了让用户能够调试运行中的Mesos任务。
解读——
针对Docker Containerizer的一个改进， 之前由于没有此功能Debug时候都是通过Mesos task找到对应的Docker容器， 接着通过Docker命令进入到容器当中看Docker运行时状态， 还好数人云的产品之前通过Proxy到Docker daemon已经解决了这个问题， 现如今如果Mesos能解决这个问题， 可以考虑通过Mesos attach到容器当中， 不过性能有待考虑， 毕竟运行时日志是个挺可怕的量。
MESOS-6758
（实验性）在Mesos Containerizer支持“Basic” Docker私有镜像仓库验证。直到目前，Mesos Containerizer一直假定Bearer auth，但是现在我们也为私有镜像仓库支持”Basic auth”。请注意AWS ECS采用了Basic authorization但是尚不可用，因为MESOS-5172的重定向问题。
解读——
私有镜像仓库验证的问题一直是困扰我的问题，这次Mesos终于考虑到这个问题了。 之前普遍的做法，包括Marathon都是将私用仓库的用户名密码达成tar通过fetch功能下载到sandbox当中，Docker executor启动之后发现账号后模拟登陆，其实Docker API早有支持，有了Basic HTTP auth就不用绕一大圈解决登录问题。
此外，还有200多个bug修复和改进。对于全部的版本更新说明，请移步https://git-wip-us.apache.org…。
关于更新：
从Mesos1.1.0滚动更新到Mesos1.2.0非常简单。只有一些小的调整，向后兼容的降低。更新过程中的细节请参考http://mesos.apache.org/docum…。
