摘要】Marathon是一个成熟的,轻量级的,扩展性很强的Apache Mesos的容器编排框架,它主要用来调度和运行常驻服务(long-running service),提供了友好的界面和Rest API来创建和管理应用。Mesosphere在最近刚刚发布的开源的DC/OS中把Marathon作为其默认的内置应用,可见它的重要性。为了能让大家快速的了解Marathon的主要的核心功能,作者将根据自己在Mesos和Marathon社区的的开发和实践经验,将提供一系列文章来介绍Marathon的主要的核心功能。本文是第一篇。
在介绍Marathon的核心功能之前,为了读者可以快速的体验Marathon的主要的功能,本章节将带领大家在Docker中快速的搭建一个Marathon的集群。
安装环境,作者准备了三台Ubuntu 14.04的虚拟机:
wangyongqiao1.eng.platformlab.ibm.com / 9.111.255.10 - Master
wangyongqiao2.eng.platformlab.ibm.com / 9.111.254.41 - Agent
wangyongqiao3.eng.platformlab.ibm.com / 9.111.255.50 - Agent
Step 1 安装Docker
由于下文我们将介绍如何在Marathon中运行Docker容器,因此必须先在计算节点上安装Docker,因为我们要把Marathon,ZK,Mesos服务运行在Docker中,所以我们也必须在Master节点上安装docker,因此需要在以上三个机器上执行如下命令,来安装docker:
apt-get update
apt-get install wget
wget -qO- https://get.docker.com/ | sh
service docker start
docker info
Containers: 0
Running: 0
Paused: 0
Stopped: 0
Images: 10
Server Version: 1.11.1
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 83
Dirperm1 Supported: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: null host bridge
Kernel Version: 3.13.0-32-generic
Operating System: Ubuntu 14.04.1 LTS
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 3.852 GiB
Name: wangyongqiao1.eng.platformlab.ibm.com
ID: RJNG:KRN6:OUXI:Z6ND:MRN6:VC4A:3JRQ:F5XZ:4YIX:GEDZ:K5IF:PVHM
Docker Root Dir: /var/lib/docker
Debug mode (client): false
Debug mode (server): false
Http Proxy: http://9.21.61.175:3128/
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Step 2 安装Zookeeper集群
因为Marathon会将运行时的一些状态state存储在Zookeeper中,同时在Marathon高可用模式下,Marathon Leader的选举也依赖于Zookeeper,所以首先我们必须先运行一个Zookeeper集群来为多个Marathon服务之间共享状态和Leader的选举。执行以下命令,在以上三个机器上安装ZK集群:
登陆wangyongqiao1.eng.platformlab.ibm.com执行以下命令:
# docker run -d \
-e MYID=1 \
-e SERVERS=9.111.255.10,9.111.254.41,9.111.255.50 \
--name=zookeeper \
--net=host \
--restart=always \
mesoscloud/zookeeper
# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
07bf2d5b3796 mesoscloud/zookeeper "/entrypoint.sh zkSer" 2 seconds ago Up 2 seconds zookeeper
登陆wangyongqiao2.eng.platformlab.ibm.com执行以下命令:
# docker run -d \
-e MYID=2 \
-e SERVERS=9.111.255.10,9.111.254.41,9.111.255.50 \
--name=zookeeper \
--net=host \
--restart=always \
mesoscloud/zookeeper
# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
03bf7c58ad53 mesoscloud/zookeeper "/usr/local/bin/dumb-" 2 seconds ago Up 1 seconds zookeeper
登陆wangyongqiao3.eng.platformlab.ibm.com执行以下命令:
# docker run -d \
-e MYID=3 \
-e SERVERS=9.111.255.10,9.111.254.41,9.111.255.50 \
--name=zookeeper \
--net=host \
--restart=always \
mesoscloud/zookeeper
# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
ac459eb2adaa mesoscloud/zookeeper "/usr/local/bin/dumb-" 2 seconds ago Up 1 seconds zookeeper
Step 3 安装Mesos集群
因为Marathon是构建于Apache Mesos之上的一个框架,因此我们必须首先搭建Mesos集群。执行以下命令,在以上三个机器上安装Apache Mesos集群:
登陆wangyongqiao1.eng.platformlab.ibm.com执行以下命令运行Mesos master:
# docker run -d \
--name mesos-master \
--net host mesosphere/mesos-master:0.28.1-2.0.20.ubuntu1404 \
--quorum=1 \
--work_dir=/var/log/mesos \
--zk=zk:// wangyongqiao1.eng.platformlab.ibm.com:2181, wangyongqiao2.eng.platformlab.ibm.com:2181, wangyongqiao3.eng.platformlab.ibm.com:2181/mesos
分别登陆
wangyongqiao2.eng.platformlab.ibm.com 和wangyongqiao3.eng.platformlab.ibm.com 执行以下命令运行Mesos agent:
docker run -d \
--privileged \
-v /var/run/docker.sock:/var/run/docker.sock \
--name mesos-agent \
--net host gradywang/mesos-agent \
--work_dir=/var/log/mesos \
--containerizers=mesos,docker \
--master= zk:// wangyongqiao1.eng.platformlab.ibm.com:2181, wangyongqiao2.eng.platformlab.ibm.com:2181, wangyongqiao3.eng.platformlab.ibm.com:2181/mesos
注意:Mesosphere官方所提供的Mesos Agent镜像mesosphere/mesos-agent不支持Docker的容器化,所以作者在官方镜像的基础至上创建了一个新的镜像gradywang/mesos-agent来同时支持Mesos和Docker的虚拟化技术。
gradywang/mesos-agent的Dockerfile如下:
#cat Dockerfile
FROM mesosphere/mesos:0.28.0-2.0.16.ubuntu1404
MAINTAINER Yongqiao Wang <yqwyq@cn.ibm.com>```
RUN apt-get update \
&& apt-get -y install curl```
#Install docker client.
RUN curl -o /usr/bin/docker https://get.docker.com/builds/Linux/x86_64/docker-1.10.2 \
&& chmod +x /usr/bin/docker
ENTRYPOINT ["mesos-slave"]
这时后你可以通过 http://wangyongqiao1.eng.platformlab.ibm.com:5050 访问Mesos的Portal。
Step 4 安装Marathon
登陆wangyongqiao1.eng.platformlab.ibm.com执行以下命令运行Marathon:
# docker run -d \
--privileged \
--net=host mesosphere/marathon \
--master zk:// wangyongqiao1.eng.platformlab.ibm.com:2181, wangyongqiao2.eng.platformlab.ibm.com:2181, wangyongqiao3.eng.platformlab.ibm.com:2181/mesos \
--zk zk:// wangyongqiao1.eng.platformlab.ibm.com:2181, wangyongqiao2.eng.platformlab.ibm.com:2181, wangyongqiao3.eng.platformlab.ibm.com:2181/marathon
# curl -L http:// wangyongqiao1.eng.platformlab.ibm.com:8080/v2/info | python -m json.tool | jq '. | .version'
"1.1.1"
这时你可以通过 http://wangyongqiao1.eng.platformlab.ibm.com:8080 访问Marathon的Portal。
Application是Marathon中一个重要的核心概念,它代表了一个长服务。
Application definition表示一个长服务的定义,规定了一个Application启动和运行时的所有行为。Marathon提供了两种方式让你来定义你的长服务,第一种通过Portal来定义,它方便终端用户的理解和使用,另一种是通过JSON格式的文件来定义,并通过RestAPI的方式来创建和管理这个Application,这种方式方便和第三方的系统进行集成,提供了再次的可编程接口。
Application instance表示一个Application的实例,也称作Mesos的一个task。Marathon可以为一个Application创建和管理多个实例,并可以动态的增大和减小某个Application实例的个数,并且通过Marathon-lb实现服务发现和负载均衡。
Application Group:Marathon可以把多个Application组织成一棵树的结构,Group称为这个树的树枝,Application称为这个树的叶子。同一个Group中的Application可以被Marathon统一管理。
Deployments:对Application或者Group的definition的一次修改的提交称为一次deployment。它包括创建,销毁,扩容缩容Application或者Group等。多个deployments可以同时进行,但是对于一个应用的deployments必须是串行的,如果前一个deployment没有结束就执行下一个deployment,那么它将会被拒绝。
定义和部署常驻服务(long-running service)
Marathon用一个JSON文本来定义描述一个常驻服务,一个简单的Application定义如下所示:
# cat test1.json
{
"id": "/test1",
"cmd": "while [ true ] ; do echo 'Hello Marathon' ; sleep 5 ; done",
"cpus": 1,
"mem": 128,
"disk": 0,
"instances": 1
}
id表示一个Application的唯一标识,我们上边说过,Marathon以一个树的形式组织Application,所以Application /test1标识根下的一个应用。
cmd表示应用执行的内容。凡是能用shell执行的任务,理论上都可以通过Marathon在Mesos上简单的运行和管理。默认情况下将通过Mesos的Command executor来执行,它将被包装为:/bin/sh –c ${cmd}
cpus,mem,disk表示执行这个应用需要耗费的资源,Mesos主要通过namespace的机制来控制和隔离资源。
instances 表示这个应用第一次启动使创建的实例的数量。
当然你可以在Marathon的Portal利用图形界面的方式上定义Application,或者在界面上开启JSON Mode来直接编写JSON文本来定义。目前Marathon的Portal没有完全实现Marathon的所有的功能,一次在用图形界面定义之后,如果你要为Application添加其他额外的功能,你可以打开JSON Mode,在界面定义的基础之上继续添加Application的其他属性,在保存的时候,界面会帮助你检查JSON的格式是否合法等。
在Marathon Poratl定义完应用之后,你可以直接提交创建这个应用。
如果用JSON文件的方式,可以用如下的REST API来提交:
#curl -X POST http:// wangyongqiao1.eng.platformlab.ibm.com:8080/v2/apps -d @test1.json -H "Content-type: application/json"
在这个应用提交运行之后,Marathon会监控这个服务的健康状况,如果由于某个原因,这个服务意外终止,Marathon会快速的重新启动这个应用,由于应用是运行在轻量级的容器中的,因此它的恢复速度是非常快的,保证这个应用的长时间不间断运行。但是要注意的一点是,Marathon不是把原来的服务在原来的机器上重启,而是会用Mesos发送过来的任意的Offer把这个服务启动到集群中的任意一个机器上,所以需要两个问题需要解决:
1.如果这个服务是有状态的,那么它再次在另外的机器上启动之后,怎么恢复它的状态?Marathon支持本地的持久化卷来解决这个问题,请见下文的分析。
2.如果这个服务之前作为其他服务的后端,或者有外部的客户端和它进行通信,那么当他启动到别的机器上之后,IP地址发生了变化,那么其他服务和外部的客户端改怎么和新的服务进行通信?Marathon支持Service Discovery的方式来解决这个问题,请见下文分析。
长驻服务提供生命周期的管理
在创建了应用实例之后,可以通过Marathon的Portal或者Rest API来管理应用实例的生命周期:
Suspend: 把这个应用的所有正在运行的实例杀掉,并把这个应用定义的实例的数量减为0,这时这个应用只保留了定义,并没有正在运行的实例。
Destroy:把这个应用的实例和定义全部删除,它不可恢复。
Kill:选择某个应用的某几个实例杀掉,但是Marathon立即会重新创建等同数量的实例。
Kill&Scale:选择某个应用的某几个实例杀掉,并从这个应用定义的实例的数量中减去等同的数量,这时Marathon不会再创建这几个实例。
Scale Up/Down:为某个应用增加或者减少指定数量的实例。
Restart:这可以称为Rolling upgrade,它某人先创建一个新的实例,然后把老的实例杀掉。再后边的章节单独详细讲解。
提供了沙箱机制来管理每个应用的实例
Mesos在执行任务时,会在对应的Agent节点上为每一个任务创建一个沙箱目录,用来表示这个任务的执行环境和存放相关的日志文件。Marathon作为Mesos的framework,对于它提交运行的任务也不例外。用户可以在Marathon的Portal或者Mesos的Portal上从那个沙箱中下载到对应任务的stderr和stdout的日志。这个沙箱目录存在于每个Mesos Agent运行时所设置的work_dir中。
当然了,对于一个复杂的应用程序,不可能用几行简单的shell命令来描述并运行它,它一般会依赖于很多的资源文件(例如多个shell脚本,图片等),针对这种情况,Marathon提供了URLs的概念来管理这些资源文件的位置。Mesos的Fetcher将会通过这些URLs在这个应用执行之前把这些资源文件下载到这个任务的沙箱之中,例如下列应用的定义:
{
"id": "basic-1",
"cmd": "`chmod u+x cool-script.sh && ./cool-script.sh`",
"cpus": 0.1,
"mem": 10.0,
"instances": 1,
"uris": [
"https://example.com/app/cool-script.sh"
]
}
在执行cmd之前,Mesos的fetcher会首先把cool-script.sh脚本下载到任务的沙箱之中,cmd中shell脚本的位置是以每个任务的沙箱目录为根目录的。当有多个资源文件时,urls是个数组类型,可以写多个URL,之间以逗号分割。在Mesos 0.22之后,Mesos的fetcher会自动把下载的文件设置为可执行。Mesos Fetcher现在支持的URL schemes 有file/http/https/ftp/ftps/hdfs/s3/s3a/s3n等。
当然了,为了提高fetcher的下载效率,这些资源文件可以事先被压缩为tgz/tar.gz/tbz2/tar.bz2/txz/tar.xz/zip等格式,fetcher会在下载之后将这些压缩包自动解压缩。
支持应用部署时之间的依赖
Marathon提供了应用组的概念,使Marathon可以一次性对一组应用进行批量deployment。并且在对应用组进行deployment时支持这些应用之间的依赖关系。
例如,一个Web应用分为前端应用和后端数据库,我们可以用一个应用组来管理这个Web应用,并且设置依赖关系,定义如下所示:
# cat webapp.json
{
"id": "webapp",
"apps": [
{
"id": "db",
"cmd": "while [ true ] ; do echo `date +%s` ; sleep 5 ; done",
"cpus": 0.1,
"mem": 10,
"disk": 0,
"instances": 1
},
{
"id": "web",
"cmd": "while [ true ] ; do echo `date +%s` ; sleep 5 ; done",
"cpus": 0.1,
"mem": 10,
"disk": 0,
"instances": 1,
"dependencies": [
"/wepapp/db"
]
}
]
}
如果设置了依赖关系,则在创建这个应用组的时候,Marathon会保证这个应用组中的应用按照依赖顺序进行创建。比如上例中会先创建/webapp/db应用,然后再创建/webapp/web应用。
同时Dependencies也可以设置在Group的级别上,如果一个应用依赖于一个应用组,那么这个应用组中的应用得全部创建之后,这个应用才可以被创建。
另外Marathon还可以对应用组做如下的deployments:
Scale:对Group进行扩容或者缩容,如果组中的应用有依赖关系,那么先扩容被依赖的应用,再扩容依赖的应用,如果是缩容的化则相反。
Destroy:删除这个应用组,如果组中的应用有依赖关系,先删除被依赖应用的实例,然后删除依赖应用的实例。
Suspend:把应用组中的所有应用实例删除,如果组中的应用有依赖关系,先删除被依赖应用的实例,然后删除依赖应用的实例。
注意:Marathon对应用所定义的依赖关系,只有在对一个应用组的一次deployment时才有效。意思是,比如你对某个应用做deployment时,如果它依赖其他的应用,并且依赖的应用没有被提前创建,那么它仍然可以创建成功,它所定义的dependencies将会被忽略。
Rolling Upgrade的支持
开发者和Marathon的终端用户面临的最常见的问题之一是如何推出新版本的应用程序。当应用通过Marathon创建之后,用户可能会要求不要中断服务而将应用升级到最新的版本。一般的做法是,先创建一组新版本的应用实例,然后停止老版本的应用实例。这可以通过几种方式来实现,Marathon在应用配置的层面上提供了minimumHealthCapacity参数来定义rolling upgrade的策略,它表示应用实例数量的百分比:
默认情况下minimumHealthCapacity的值为1,它表示先创建等同数量的新版本的应用的数量,在创建成功之后,再把所有老版本的应用实例删除掉。在原来老版本的应用实例比较多的情况下,这种策略要求集群中要有足够多的资源先来创建新版本的实例。
当minimumHealthCapacity的值为0的时候,它表示先把这个应用程序下的所有实例删除掉,然后在创建等同数量的新版本的应用实例。这种策略一般在生产环境是不推荐的,应为它会导致服务的短时间中断。
当minimumHealthCapacity的值大于0小于1的时候,它表示先把部分的老版本的实例删除掉,然后再创建等同数量的新版本的实例,当所有新版本的应用实例启动成功之后,再把剩余的所有老版本的实例删除掉,再启动其余的新版的实例。例如,原来应用有7个实例,应用的minimumHealthCapacity参数的值为0.4,则在这个应用upgrade的时候,Marathon会先删除3个(0.4*7=2.8四舍五入)老版本的实例,然后启动3个新版的实例,当这3个新版本的实例启动成功之后,然后把剩余四个老版本的实例删除,再创建四个新版本的实例。
注意:当你为某个应用设置的minimumHealthCapacity大于0.5的时候,在对这个应用做upgrade的时候你必须保证你的的集群中有足够的资源,否则新版本的实例将无法创建。
Marathon做upgrade的操作步骤如下:
首先得先修改要升级的应用的definition来发布这个应用的新版本并保存,或者把这个应用需要的resource替换(比如升级你的软件包的版本)。如果你修改了definition,Marathon会自动为你保存历史版本。
将这个应用restart,在restart的时候,Marathon会根据你为这个应用设置的策略minimumHealthCapacity来升级你的应用。
支持不同的应用部署策略
Marathon通过为应用设置约束来决定应用实例的部署策略,比如把某个应用的实例分散创建到不同的机器或者机架上来提供高容错性,或者把应用的所有实例集中部署到同一类型的机器上。
Marathon的约束的定义分为三个部分:约束名,操作符和一个可选的约束的值:
约束名可以是hostname(表示Mesos Agent的机器名)或者Mesos Agent的一个属性(Mesos Agent的属性通过–attributes在启动Mesos Agent的时候指定)的名称。
o hostname约束将匹配每一个offer所对应的的Mesos Agent的机器名。
o hostname的约束名支持下面的所有操作符。
o 如果这个约束名不是hostname,它将匹配Mesos Agent的属性。
o 如果指定的约束名既不是hostname,也匹配不到任何的属性,除了UNLIKE操作符,下面所有的操作符将会匹配不到任何的offer。
o Mesos Agent属性的约束支持所有下列的操作符。
o 注意:目前Marathon仅仅支持约束的字符串值,不支持数字。
操作符:
oUNIQUE:告诉Marathon把这个应用的每一个实例部署到属性值不同的机器上,也就是说属性的值相同的机器上只能运行一个这个应用的实例。比如为某个应用定义如下约束的时候,表示每一个机器上只能运行一个这个应用的实例。”constraints”: [[“hostname”, “UNIQUE”]]
oCLUSTER 告诉Marathon把这个应用的所有实例部署到一组具有相同属性的机器上。比如某个应用的实例只能跑到某些硬件平台上或者把这些应用实例部署到同一个机架或者地域。比如把某个应用的所有实例部署到rack-1上:
"constraints": [["rack_id", "CLUSTER", "rack-1"]]
再比如把某个应用的实例部署到机器名为wangyongqiao.abc.com的机器上:
"constraints": [["hostname", "CLUSTER", "wangyongqiao.abc.com"]]
oGROUP_BY:告诉Marathon把某个应用的实例均匀的创建到属性值不同的机器上。比如为了应用的高可用,你可以通过这个操作符把应用的实例均匀的分散部署到不同的机架或者数据中心。比如把应用的实例均匀分散部署到不同的机架上:
"constraints": [["rack_id", "GROUP_BY"]]
如果你想把你的应用均匀的分散的部署到至少三个机架上,可以把约束定义为:
"constraints": [["rack_id", "GROUP_BY",“3”]]
注:由于Marathon不能在某一个时刻获取到集群所有的资源,因此对于应用实例的在集群的均匀创建还有很多的争论,具体可以参见https://github.com/mesosphere/marathon/issues/3220 Issue。后续Marathon可能会对这个约束有所改进。
oLIKE:接收一个正则表达式,告诉Marathon,这个应用的实例只能创建在匹配这个正则表达式的机器上。比如这个应用实例只能创建在机架rack-1和rack-2上:
"constraints": [["rack_id", "LIKE", "rack-[1-2]"]]
oUNLIKE:这个操作符和LIKE正好是相反的。
支持高可用
Marathon默认支持高可用的模式,在高可用的模式下,如果某一个Marathon服务中断,依然可以继续保持正在运行的常驻服务不间断运行。
Marathon的高可用模式部署非常简单,只需要启动多个Marathon的服务并且指定一个相同的Zookeeper路径,Zookeeper会提供多个Marathon服务之间的Leader选举。例如基于上文的安装步骤,可以登陆wangyongqiao2.eng.platformlab.ibm.com和wangyongqiao2.eng.platformlab.ibm.com执行以下命令启动第二个和第三个Marathon服务:
docker run -d \
--privileged \
--net=host mesosphere/marathon \
--master zk://gradyhost1.eng.platformlab.ibm.com:2181,gradyhost2.eng.platformlab.ibm.com:2181,gradyhost3.eng.platformlab.ibm.com:2181/mesos \
--zk zk://gradyhost1.eng.platformlab.ibm.com:2181,gradyhost2.eng.platformlab.ibm.com:2181,gradyhost3.eng.platformlab.ibm.com:2181/marathon
和Mesos的Web Portal不同的是,Marathon在高可用模式下,所有Marathon实例所提供的Web Portal都可以工作,它们不会像Mesos一样,如果你登陆的不是Leader节点,会跳转到当前的Leader节点。也就是说用户仍然可以在Marathon的非Leader节点的Portal上做操作。Rest API也支持相同的行为。
用户身份认证和权限控制的支持
单独的Marathon目前不支持用户认证和权限控制,但是在Mesosphere发布的开源DC/OS中,这个功能已经被支持。
支持运行Docker容器
通过Marathon的Portal和Rest API,用户可以把它们自己的应用的实例很容易的运行到Docker容器中。
例如我们通过Marathon在Docker中运行一个Web server:
# cat docker-web-server.json
{
"id": "/docker-web-app",
"cmd": "python3 -m http.server 8080",
"cpus": 1,
"mem": 128,
"disk": 0,
"instances": 1,
"container": {
"type": "DOCKER",
"volumes": [],
"docker": {
"image": "python:3",
"network": "BRIDGE",
"portMappings": [
{
"containerPort": 8080,
"hostPort": 0,
"protocol": "tcp",
"name": "webserverport"
}
],
"privileged": false,
"parameters": [],
"forcePullImage": false
}
}
}
# curl -X POST http://wangyongqiao1.eng.platformlab.ibm.com:8080/v2/apps -d @docker-web-server.json -H "Content-type: application/json"
在这个实例成功之后,你可以查询这个应用的实例,通过Marathon分配的随机端口来访问这个WEB服务。
Marathon在运行Docker容器的时候,仅仅支持Docker的HOST和BRIDGE的网络模式。它们最大的区别是,如果容器中运行的应用程序需要消费端口资源,在Host模式下, Marathon不支持用户为这个应用程序自定义使用的端口,它会从Mesos发送的Offer的端口资源中为应用程序动态的选择使用的端口。在BRIDGE模式下,Marathon不但支持动态的端口映射,还支持静态的端口映射。如果是动态的端口分配,在应用的实例创建成功之后,用户可以通过Marathon的Portal或者Rest API获取到分配的这些端口,来访问容器中运行的服务。
注:由于Marathon对端口资源的管理比较复杂,将在下文中单独剖析。
在Marathon中运行Docker 容器,在环境部署的时候需要注意一下几点:
必须在所有的Mesos Agent事先安装Docker(>1.0.0);
启动每一个Mesos Agent服务的时候要指定Docker的容器化方式:–containerizers=mesos,docker;
应为创建Docker container之前需要先pull Docker image,因此需要把Mesos Agent的–executor_registration_timeout参数改大一点,防止应用实例启动超时报错。这个时间默认是1分钟;
同理,也需要把Marathon的–task_launch_timeout参数改大一点。
同时Marathon支持使用一个私有的需要认证的Docker镜像仓库。在Docker 1.6之前,为了从一个私有的需要认证的镜像仓库拉去镜像,Marathon需要在定义应用时通过urls指定.dockercfg文件的位置,在应用的实例创建的时候,这个文件会被fetch到它的沙箱中,并且沙箱的目录$MESOS_SANDBOX会设置成执行任务的 HOME目录,然后Docker在PULL的时候就可以使用这个配置文件。在Docker 1.6之后,需要把docker.tar.gz文件通过urls指定到应用的定义文件中,这个文件包含如下内容:
$ tar -tvf ~/docker.tar.gz
drwx------ root/root 0 2015-07-28 02:54 .docker/
-rw------- root/root 114 2015-07-28 01:31 .docker/config.json
本文到此结束,下篇文章中我们将继续分析Marathon的服务发现,负载均衡,监控机制等功能。