应用的部署

# 应用的部署（待完成） 对于应用和应用组的每一次重定义都将执行一次部署，一次部署包括一个动作的集合，这些动作可以是： * 开始或停止一个或多个应用 * 更新一个或多个应用 * 缩放一个或多个应用 部署不会立即生效,过程需要时间。直到部署完成，部署才在Marathon中生效。 只要一个应用由一个部署来改变，多个部署可以在同一时间执行 。如果一次部署请求，试图更改一个已被另一个部署改变的应用程序，这个部署请求将被拒绝。 ## 依赖关系 没有依赖关系的应用可以按任何顺序进行部署，没有约束。如果应用之间存在以来关系，部署动作应该有一个指定的顺序。  这个例子应用app依赖于应用db. * 启动：把db和app加入到系统中，先启动db然后是app * 停止：从系统中移除db和app，是先移除app，再移除db * 更新：看 章节部分滚动重启 * 缩放：如果是db和app缩放，先缩放db后缩放app ## 滚动重启 开发者和使用者经常需要面对的问题之一是如何推出新版本的应用。从根上说，这个过程包含二重语义：启动一组新版本程序，停止一组旧版本程序。在这个过程中可能执行多个可能的模型。 Marathon有一个minimumHealthCapacity更新策略，定义在应用层面。minimumHealthCapacity是一个百分比，涉及到实例的数量，决定了一个特定的应用版本在更新过程中必须有那么几个健康的实例一直存在。 * minimumHealthCapacity == 0 : 在新版本部署之前，所有的实例都将被killed * minimumHealthCapacity == 1 : 在旧版本停止之前，所有的新版本应用都会被一起部署 * minimumHealthCapacity 在0-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. 如果应用存在依赖关系，这可能稍有点复杂。当上面的例子应用更新的时候，下面的动作将被执行（译者注：注意看上图中的instance和minimumHealthCapacity）： 1.缩减旧版本db应用到6个实例 2.启动新版本db应用到6个实例 3.缩减旧版本app应用到16个实例 4.启动新版本app应用到16个实例 5.停止所有的旧版本app 6.停止所有的旧版本db 7.增加新版本db实例到10个 8.增加新版本app实例到20个 Please take into account that your cluster needs to have more capacity available for the update process if you choose a minimumHealthCapacity greater 0.5. In this case more than half of the instances of the same application are run side by side. These capacity constraints are summed up if there are dependencies. In our example, we defined 0.6 for db and 0.8 for app. This means that in the update case, we have 12 instances of db (6 old and 6 new) and 32 instances of app (16 old and 16 new) running side by side. ## 强制部署 一个应用同时只可以被一次部署修改。其他的修改必须等待第一个部署完成。通过加上一个强制标志是可以打破这种规则的。REST允许使用强制标志，对于任何转发台的修改操作。 **注意: The force flag should be used only in the case of a failed deployment!** If a force flag is set, then all deployments that are affected by this deployment are cancelled. This may leave the system in an inconsistent state. Specifically, when an app is in the middle of a rolling upgrade and the deployment is cancelled, it may end up in a state where some old and some new tasks are running. If the new deployment does not update that app, it will stay in that state until a future deployment is being made for that app. By contrast, the only kind of deployments that can be force-updated safely are those which affect single apps only. Consequently, the only good reason to force a deployment affecting multiple apps is to correct a failed deployment. ## A failed Deployment A deployment consists of steps. The steps are executed one after the other. The next step is only executed, if the previous step has finished successfully. There are circumstances where a step will never finish successfully. For example: the new application does not start correctly the new application does not become healthy a dependency of the new application was not declared and is not available the capacity of the cluster is exhausted the app uses a Docker container and the changes listed at Running Docker Containers on Marathon were not followed ... The deployment in this case would take forever. To heal the system, a new deployment must be applied to correct the problem with the current deployment. ## The /v2/deployments endpoint The list of running deployments can be accessed via the /v2/deployments endpoint. There are several items of information available for every deployment: affectedApps: which applications are affected by this deployment steps: the steps to perform for this deployment currentStep: which step is actually performed Every step can have several actions. The actions inside a step are performed concurrently. Possible actions are: ResolveArtifacts Resolve all artifacts of the application and persist it in the artifact store StartApplication Start the specified application StopApplication Stop the specified application ScaleApplication Scale the specified application RestartApplication Restart the specified application to the minimumHealthStrategy KillAllOldTasksOf Kill the rest of tasks of the specified application