Basic application
First we save the following code as shell.json:
{
“id”: "shell",
"cmd": "while [true];do echo 'DCOS shell';sleep 5;done",
"cpus": "0.1",
"mem": "10.0",
"instances": "1"
}
Execute the following command line :
curl 10.134.29.134:5000/v2/apps -d @shell.json -H "Content-type:application/json"
It passes the json file to the scheduler through the marathon api, and requests to create an instance. The resource requirements are 0.1cpu, 10M memory, and the shell command line is executed. cmd will be sent to the underlying Mesos executor for execution, eventually via /bin/bash -c ${cmd}.
Open the DCOS control panel and select the Marathon management interface. As shown in the figure, you can find that the app named shell is running. The app is in a one-to-many relationship in the creation of Marathon, that is, an app can have multiple tasks.
Figure 3-1
As can be seen from the above figure, Marathon provides functions such as manual app scaling, health check, log management, and app life cycle management.
First of all, we introduce Marathon's function of manually scaling the App. Select Scale Application for rapid scaling. As shown in the figure below, fill in 10 to expand the App to 10 Tasks.
Figure 3-2
As shown in the figure below, the shell App expands to 10 Tasks:
Figure 3-3
Since it can be expanded, of course it can be shrunk. Select the Task you want to destroy and click Kill&scale. In addition to creating an App through the curl command above, Marathon provides a Web UI to create an App, click create on the main interface, and fill in the corresponding parameters in the check box, as shown in the following figure.
Figure 3-4
In this section, the basic application of Marathon has been introduced. Next, we will introduce how Marathon applies remote resources.
run remote resource
For complex applications, all operations cannot be passed through simple cmd commands. For such cases, Marathon provides uri parameters, and uses Mesos fetcher to download, decompress, and extract resources before scheduling. Before delving into this topic, let's understand the application scenarios through examples:
{
“id”: "resource",
"cmd": "./shell.sh",
"cpus": "0.1",
"mem": "10.0",
"instances": "1",
"uris": [
"http://10.128.3.75/images/shell.sh"
]
}
Before the above instance executes cmd, it will pass 10.128.3.75/images/shell.sh under Mesos, and then execute the resource in the application sandbox of the selected slave node. You can view the sandbox of the task through the web interface and click to enter page, you can view the shell.sh script downloaded by Mesos.
需要注意的是，Mesos v0.22及以上版本在默认情况下执行cmd的方式，是先设权限后执行，因此，cmd命令类似于chmod u+x shell.sh &&sh shell.sh。
除了上述提及的功能之外，Marathon框架自身清楚框架内的应用资源。当然，Marathon对于下述文件将首先尝试解压并提取资源：
· .tgz
· .tar.gz
· .tbz2
· .tar.bz2
· .txz
· .tar.xz
· .zip
uris对资源进行定位下载，Marathon支持多种协议类型，种类如下所示：
· file:
· http:
· https:
· ftp:
· ftps:
· hdfs:
· s3:
· s3a:
· s3n:
uri的值是数组类型，可以支持同时输入多个资源：
{ ...
"uris": [
"https://github.com/zouyee/repo.zip",
"http://10.128.3.75/images/shell.sh",
"ftp://10.128.3.75/images/my-other-file.css"
]
...
}
容器运行
1、简单应用
Marathon可以使用docker对应用进行高效快捷的部署，在下述应用实例中，使用docker部署一简单web应用：使用Docker的python:3镜像，启动一个容器内部端口8080的服务，网络模式选择bridge，因此有portMapping选项，在其字段中，hostport值设为0，意味着Marathon任意分配映射到外部的端口，json内容如下所示：
{
"id": "web",
"cmd": "python3 -m http.server 8080",
"cpus": 0.5,
"mem": 32.0,
"container":
{
"type": "DOCKER",
"docker":
{
"image": "python:3",
"network": "BRIDGE",
"portMappings":
[
{
"containerPort": 8080,
"hostPort": 0
}
]
}
}
}
通过HTTP API接口启动该应用：
curl -X POST http://10.134.29.134:8080/v2/apps -d web.json -H "Content-type: application/json"
通过dcos client启动该用，dcos marathon app add web.json
通过Marathon web UI界面可以看到名为web的应用已运行。
图 3-5
2、端口分配
Marathon涉及到端口配置或者端口概念的地方有三处，第一部分是在应用配置的container中的portMapping，主要有containerport、hostport、serviceport，如图3-6所示，第二处在应用配置的Optional settings中的Ports，如图3-7所示，第三处在实际App中某一Task分配的port(s)，如下图3-8所示。
图3-6 container中的端口映射
图 3-7 可选项中的端口
图 3-8 Task分配到的端口
通过图3-6可以发现，Port Mappings包括Container Port、Host Port、Service Port、Protocol等字段，图3-7可以发现，Optional settings包含Ports字段。
containerPort：container Port指定在容器内部的端口，它适用于docker的bridge网络做port mapping。
hostPort: host Port specifies the host bound port. When using the BRIDGE network, you need to specify the port mapping from the host port to the container port. When using the HOST network, the request port defaults to the host port.
BRIDGE network: docker applications can use BRIDGE network. In this network environment, the container port (the container internal port) corresponds to the host port (the port on the host).
HOST network: The HOST network can be used for non-docker Marathon applications and docker applications. In this mode, the application directly binds one or more ports of the host.
ports: This port needs to be regarded as a resource and needs to be set when using the HOST network.
protocol: The port specified by the protocol (such as tcp, udp)
servicePort: Marathon does not bind this port, it is used for service discovery.
If containerPort is set to 0 in portMapping, its value will be the same as hostPort, hostPort will be randomly assigned, the default range is between 31000-32000 .
About the Marathon application of DCOS, I will introduce so much first. The next article will introduce application groups and health check related content. Thank you for reading!
http://sanwen8.cn/p/1f0EGer.html