应用更新和部署 转

先来看我蹩脚的翻译：https://mesosphere.github.io/marathon/docs/deployments.html 应用部署

每一次应用的变动其实都是一次部署操作，部署可以有以下几个操作： 开始、停止一个或者多个应用 更新一个或者多个应用 更新一个或者多个应用 调容一个或者多个应用

部署不是立即生效的，它会花费一点时间，部署会直到所有的部署都结束才会停止 大多数的部署都是一样的，一般都是一个部署改变一个应用。如果即将部署的这个应用已经被另外一个存活的部署操作，那么这个部署操作将会被拒绝。

依赖 没有依赖的应用部署操作没有限制。如果应用之间互相依赖，那么这样的部署操作就需要执行执行的部署命令。

在上面的例子中，app依赖db

Starting : 如果db和app都启动，db先有app启动 Stopping : 如果db和app都停止，app先于db停止 Upgrade : 看具体的调容场景 Scaling : 如果db和app一起调容，db先于app调容

滚动重启 有一个共性问题是，怎么样更新一个应用的版本。作为root，这里要分两步操作：开始新版本的应用，停止老的版本。这是大多数应用跟新的方式。 在marathon中有一个更新的策略参数：minimumHealthCapacity,这个参数默认为开启状态。minimumHealthCapacity是一个标识应用副本数的百分比，标识了在应用整个更新期间必须要保存的健康副本数目。 minimumHealthCapacity == 0 ：在新版本部署之前，所有的老版本都必须杀死。 minimumHealthCapacity == 1 ：再老版本被干掉之前，所有新的版本实例会部署实施。 minimumHealthCapacity between 0 and 1 ：老版本和新版本成比例的启动和停止，如果成功完成，新版本比例为100% ,老版本停止。

如果考虑依赖，稍微会有一点复杂，如果发生了一个更新操作，大体的步骤是这样的： Scale old application db to instance count 6 Start new application of db to instance count 6 Scale old application app to instance count 16 Start new application of app to instance count 16 Stop all instances of old app Stop all instances of old db Scale new db to instance count to 10 Scale new application of app to instance count 20

如果你设置你minimumHealthCapacity为0.5,你要注意开大你执行app的帐号权限。

强制部署

一个应用每次只能进行一个修改。其他的修改只能在第一个部署完成之后进行。你可以强制运行一个部署，打破上述规则。REST接口可以强制进行任何部署操作。

注意，强制操作一般用于防止部署失败。

如果进行了强制操作，这个应用所有的部署都将收到影响。这样可能会给系统留下一个互相矛盾的状态。特别是，当应用正在回滚更新时，应用可能会在有新老任务一块伴随的情况下结束。新的部署如果没有更新应用，它依然会保持在这个状态，直到显现的部署被实施。

对比一下，只有单独的应用可以安全的强制更新。 所以说，强制类操作最好用在部署出错的时候进行。

"upgradeStrategy":{"minimumHealthCapacity":0.5,"maximumOverCapacity":0.5},

minimumHealthCapacity == 0 : all old instances can be killed, before the new version is deployed. minimumHealthCapacity == 1 : all instances of the new version is deployed side by side, before the old version is stopped minimumHealthCapacity between 0 and 1 : scale old version to minimumHealthCapacity and start the new version to minimumHealthCapacity side by side. If this is completed successfully then the new version is scaled to 100% and the old version is stopped.

部署时最少要保留的实例数,防止所有的实例 minimumHealthCapacity (Optional. Default: 1.0) - a number between 0and 1 that is multiplied with the instance count. This is the minimum number of healthy nodes that do not sacrifice overall application purpose. Marathon will make sure, during the upgrade process, that at any point of time this number of healthy instances are up.

部署时最大能启动的实例数量 maximumOverCapacity (Optional. Default: 1.0) - a number between 0 and 1 which is multiplied with the instance count. This is the maximum number of additional instances launched at any point of time during the upgrade process.

maximumOverCapacity如果是1,那在应用部署的时候，新实例和老实例是等量共存的。 如果是0,只能是老实例已经确定停止了，新实例才部署.

minimumHealthCapacity=1且maximumOverCapacity=0，在部署中会至少新增一个实例，不会说就不执行部署了。

The default maximumOverCapacity is 1, which means that all old and new instances can co-exist during the upgrade process. A value of 0.1 means that during the upgrade process 10% more capacity than usual may be used for old and new instances. A value of 0.0 means that even during the upgrade process no more capacity may be used for the new instances than usual. Only when an old version is stopped, a new instance can be deployed.

If minimumHealthCapacity is 1 and maximumOverCapacity is 0, at least one additional new instance is launched in the beginning of the upgrade process. When it is healthy, one of the old instances is stopped. After it is stopped, another new instance is started, and so on.

A combination of minimumHealthCapacity equal to 0.9 and maximumOverCapacity equal to 0 results in a rolling update, replacing 10% of the instances at a time, keeping at least 90% of the app online at any point of time during the upgrade.

A combination of minimumHealthCapacity equal to 1.0 and maximumOverCapacity equal to 0.1 results in a rolling update, replacing 10% of the instances at a time and keeping at least 100% of the app online at any point of time during the upgrade with 10% of additional capacity.