1 前言
新炬DCOS云平台管理采用marathon容器应用编排框架作为底层组件。它搭建了以Docker容器为基础封装各类应用和运行环境，以Mesos、Marathon为核心实现容器资源的分布式调度与协调，并以Marathon-LB实现服务注册和业务的引流。其中，Marathon作为DCOS云平台的核心组件，并结合MESOS的资源调度组件，实现DCOS云平台下任务的动态调度，针对Marathon这一核心组件，新炬DCOS小组进行了长期的研究和生产实践，今天主要为大家分享Marathon简介与实践原理。
2 Marathon简介
Marathon按照官方的说法是个它是基于Mesos框架的私有PaaS，它实现了Mesos的Framework。Marathon实现了服务发现和负载平衡、为部署提供REST API服务、授权和SSL、配置约束等功能。它还支持Shell命令和Docker部署应用。同时也提供Web UI界面、支持CPU，内存，存储和实例个数等参数设置，支持单个应用的Scale，但不支持复杂的集群定义。Marathon本身是通过Scale方式来实现的。
Marathon能够支持运行长服务，比如Web应用等。Marathon能够原样运行任何Linux二进制发布版本，如Tomcat Play等。
Marathon具有容错功能，当容器由于节点崩溃等原因意外停止运行时，Marathon会自动将容器调度到其他mesos slave节点。这一点类似进程管理工具Supervisor，当进程意外退出时，Supervisor会重启进程。然而，自动容错功能并不适合有状态服务，即带有数据卷(volume)的容器，例如Oracle与MySQL,对数据一致性要求很高，而且数据丢失面临很大安全性问题。以至于数据很难跨节点移动，目前的技术还不够成熟。因此，Marathon目前仅适合运行无状态的服务，而数据库等有状态服务应该单独部署。这样做也可以提高数据的安全性。
3 Marathon原理与架构
Marathon组件可以为您的每个应用程序指定所需要的CPU,内存，存储和程序运行的实例个数。它可以使用可用的集群资源对失败的任务自动做出响应。如果某个Mesos Slave节点宕机或应用的某个实例退出、失败，Marathon将会自动在mesos slave节点启动一个新的实例，来替换掉失败的实例。Marathon也允许用户在部署时指定应用程序彼此间的依赖关系，这样就可以保证某个应用程序实例不会在它依赖的数据库实例启动前启动。
4 Marathon特性
l 高可用，支持多主节点(主备模式)自动切换。
l 支持多种容器环境。
l 支持有状态服务，如数据库。
l 使用Web管理界面用于配置操作和监控系统状态。
l 约束规则，比如限制任务分布在特定节点。
l 服务发现、负载均衡。
l 支持健康检查，实现容错。
l 支持事件订阅，用于集成到其它系统。
l 运行指标监控接口。
l 完善易用的REST API,便于集成和编写脚本。
5 Marathon Rest API接口
新炬DCOS云平台调用marathon API接口
|
接口用途 |
方法 |
接口 |
|
获取marathon服务状态 |
GET |
/ping |
|
获取marathon部署应用信息 |
GET |
/v2/apps |
|
获取应用ID应用部署信息 |
GET |
/v2/apps/{id} |
|
获取应用ID任务 |
GET |
/v2/apps/{id}/tasks |
|
重启app_id应用 |
POST |
/v2/apps/{app_id}/restart |
|
获取marathon作业信息 |
GET |
/v2/tasks |
|
创建新的应用 |
POST |
/v2/apps |
|
更新应用 |
PUT |
/v2/apps/{app_id} |
|
强制更新应用 |
PUT |
/v2/apps/{app_id}?force=true |
|
删除应用 |
DELETE |
/v2/apps/{id} |
|
强制删除应用 |
DELETE |
/v2/apps/{id}?force=true |
|
创建一个空应用组 |
POST |
/v2/groups |
|
在应用组内更新应用 |
PUT |
/v2/groups/{id} |
|
在应用组内强制更新应用 |
PUT |
/v2/groups/{id}?force=true |
|
删除应用组内的应用 |
DELETE |
/v2/groups/{id} |
|
强制删除应用组内的应用 |
DELETE |
/v2/groups/{id}?force=true |
|
获取应用信息 |
GET |
/v2/groups/{id} |
|
获取部署信息 |
GET |
/v2/deployments |
|
删除应用部署信息 |
DELETE |
/v2/deployments/{deploymentId} |
|
强制删除应用部署信息 |
DELETE |
/v2/deployments/{deploymentId}?force=true |
|
获取marathon队列信息 |
GET |
/v2/queue |
|
获取marathon信息 |
GET |
/v2/info |
6 Marathon 应用部署测试
下面我们在这里做两个小测试，一种是通过marathon组件调用mesos组件部署个nginx镜像的Docker容器。另一种通过marathon api接口创建nginx容器。
6.1 通过marathon UI创建nginx应用
创建应用
首先准备应用定义文件， 此文件为JSON格式。定义了应用的名称(id)、命令、资源(cpu、内存等)和实例数量等信息。
创建应用定义文件，使用json方式创建nginx容器
|
{ "cmd" : "nginx -g 'daemon off;'", "container" : { "docker" : { "image" : "XX.XX.XX.24/dcos/nginx:new", "network" : "BRIDGE", "portMappings" : [ { "containerPort" : 80, "hostPort" : 0 } ] }, "type" : "DOCKER" }, "cpus" : 0.2, "id" : "nginx", "mem" : 32.0 } |
登录http://maraton_ip:8080在Web页面上，点击创建Create Application按钮。 弹出操作窗中，切换为JSON模式。
将 上一步准备的JSON内容复制到输入框内，点击输入框旁的创建Create Application按钮保存配置。 此时新建应用的信息，将出现在Web页面的应用列表。
查看到marathon UI界面看到已经运行了两个nginx的Docker容器
在后台主机上可以看到marathon创建的nginx容器
现在你就可以通过http://ip:31520来访问到nginx。
6.2 使用Marathon API来创建nginx容器
首先准备应用定义文件， 此文件为JSON格式。定义了应用的名称(id)、命令、资源(cpu、内存等)和实例数量等信息。
创建应用定义文件，使用json方式创建nginx容器，在后台服务器上定义一个nginx.json文件。
|
{ "cmd" : "nginx -g 'daemon off;'", "container" : { "docker" : { "image" : "xx.xx.xx.24/dcos/nginx:new", "network" : "BRIDGE", "portMappings" : [ { "containerPort" : 80, "hostPort" : 0 } ] }, "type" : "DOCKER" }, "cpus" : 0.2, "id" : "nginx-1", "mem" : 32.0, "instances" : 2 } |
通过API在Marathon上创建任务
curl -X POST -H "Content-Type: application/json" http://{marathon_ip}:8080/v2/apps -d@nginx.json
在Marathon页面确认容器已经启动
此时看到marathon UI界面启动了两个nginx容器。
在后台主机节点确认容器已经正常启动
7 参考文档
http://mesosphere.github.io/marathon/api-console/index.html
https://mesosphere.github.io/marathon/docs
8 总结
使用Marathon REST API接口并集成到DCOS云平台，实现自动化运维功能，解决了运维人员的应用部署慢、灰度发布和水平弹性扩缩容等问题。随着越来越多企业开始搭建部署自己的私有云、数据中心化管控以及应用容器化趋势，同时也是为了减轻应用工作负载，节省资源成本，以及更好的提升业务系统运营效率，这种运维能力将变得愈发重要。后续我们的目标是要让上云后的多种类型的业务系统运行在共享资源上面发挥更好、更理想的实际效果。
有需要的朋友可以关注我的公众号，文章每日一更
