Marathon（2）：Application 部署

浅浅的花香味﹌ 2022-07-15 00:23 120阅读 0赞

# **Application 部署** #

在Marathon中，对应用程序或组定义的每一个修改都会作为部署操作进行。部署是一组操作，会做以下操作：

*  开始/停止一个或多个应用
 *  升级的一个或多个应用
 *  缩放一个或多个应用

部署不马上生效 - 需要一定时间。直到部署成功完成，这个部署才会在Marathon中激活。

多个部署可以在同一时间进行，只要一个应用程序仅通过一个部署更改。如果一个部署被请求，它会尝试修改由之前已经通过部署激活并已经完成的修改，新的部署请求将被拒绝。

# **依赖** #

没有依赖的应用程序可以没有任何限制的，以任何顺序进行部署。如果应用程序之间有依赖关系，那么部署操作将按照一个特定的顺序执行。

![这里写图片描述][20161026170018068]

在应用上面的例子中，*app*依赖于应用*db*。

*  **Starting**：如果*db*和*app*被添加到系统中，*db*先启动，然后再启动*app*
 *  **Stoping**：如果*db*和*app*从系统中删除，*app*先被删除，然后再删除*db*
 *  **Upgrade**：请参见滚动重启章节。
 *  **Scaling**：如果*db*和*app*得到规模，*db*缩放，然后再应用

# **滚动重启** #

开发人员和运维人员面对的最常见的问题是如何推出的应用程序的新版本。这个过程包括两个阶段：启动新版本的一组进程和停止旧版本的一组进程。有很多种模式进行这一过程。

在Marathon中，有一个在应用级别中定义的升级策略属性minimumHealthCapacity。minimumHealthCapacity的值是一个百分比，当应用到实例计数的时候，用来定义某一个应用程序的特定版本在更新期间任何时候都必须保有的健康实例数量。

*  **minimumHealthCapacity == 0**：在新版本部署之前，所有旧的实例可以被停掉。
 *  **minimumHealthCapacity == 1**：在旧版本被停止前，新版本的所有实例都被并行部署
 *  **0和1之间minimumHealthCapacity**：根据minimumHealthCapacity的值scale旧版本，同事启动与minimumHealthCapacity的值相同数量的新版本。如果这成功完成，则新版本被调整为100％，旧版本被停止。

如果有依赖关系这种操作就变得有点复杂。当上面依赖例子中的应用程序被更新时，以下操作将被执行：

1.  升级应用程序的db，直到所有实例都替换，准备和健康（考虑设置upgradeStartegy）
2.  升级应用程序的app，直到所有实例都替换，准备和健康（考虑设置upgradeStrategy）

如果你选择一个大于0.5的minimumHealthCapacity 的值，在更新过程中，集群环境需要预留更多的可用容量。在这种情况下，一半以上的相同的应用程序的实例是并行的。如果应用有依赖性，就要总结这些容量限制在我们的例子中，我们定义了db为0.6，app为0.8。这意味着，在更新的情况下，我们有12个db实例（6个老版本和6个新版本），32个应用实例（16个老版本和16新新版本）并行运行。

> 注：这里的数量，咋一看有点不知所以，要对照上图上的数字看。

# **强制部署** #

一个应用程序在同一时间只能被一个部署修改。其他对应用程序的修改必须等待上一个部署完成。运行带有强制标志部署可以打破了这一规则。REST接口允许为所有的更改状态操作添加强制标志。

> **注意**：强制标志；只应在部署失败的情况下使用！

如果强制标志被设置，则受此影响的所有部署都被取消。这可能会使系统处于不一致的状态。具体而言，当一个应用程序在滚动升级过程中时部署被取消，它可能会处在一些应用是老的版本，一些应用是新版本的情况。如果新的部署不更新应用程序，它会留在状态，直到未来的部署应用在程序。

相反，唯一的安全强制更新的一种部署方式就是只影响单一的应用程序。

因此，使用强制更新的情况，就是用于修复之前失败的部署。

# **一个失败的部署** #

一个部署有几个步骤。部署步骤被一步一步执行。如果先前步骤已成功完成，下一个步骤才会执行，。

有些情况下，某一步永远不会成功完成。例如：

*  新的应用程序不能正常启动
 *  新的应用程序出在不健康状态
 *  新应用程序的依赖没有声明同时不可用
 *  群集的容量耗尽
 *  应用程序使用Docker容器，修改被列在\[Running Docker Containers on Marathon\]没有执行。（[https://mesosphere.github.io/marathon/docs/native-docker.html][https_mesosphere.github.io_marathon_docs_native-docker.html]）
 *  …

在这种情况下，将会一直执行部署。为了修复系统，一个新的部署必须应用被应用到当前出问题的部署上以解决问题。

# **在/V2/deployments端点** #

可被访问运行部署的列表经由在/V2/deployments端点。几个项目适用于所有部署的建议：

*  affectedApps：哪些应用程序受此部署
 *  step：此部署执行的步骤
 *  currentStep：这实际上执行的步骤

每一步都可以有几个动作。一个步骤内的操作是同时进行的。可能的操作是：

*  **ResolveArtifacts**解决应用程序的所有构建和将其保存在构建仓库中
 *  **StartApplication**启动指定的应用程序
 *  **StopApplication**停止指定的应用程序
 *  **ScaleApplication**缩放指定的应用程序
 *  **RestartApplication**重新启动指定的应用程序的minimumHealthStrategy
 *  **KillAllOldTasksOf**停止指定应用程序任务的其余部分

--------------------

参考资料：

**\[1\]: [http://mesosphere.github.io/marathon/docs/deployments.html][http_mesosphere.github.io_marathon_docs_deployments.html]**

[20161026170018068]: /images/20220715/6d10709a2b044cd1b5d17d132d28743e.png
[https_mesosphere.github.io_marathon_docs_native-docker.html]: https://mesosphere.github.io/marathon/docs/native-docker.html
[http_mesosphere.github.io_marathon_docs_deployments.html]: http://mesosphere.github.io/marathon/docs/deployments.html