# 應用的部署（待完成） 對于應用和應用組的每一次重定義都將執行一次部署，一次部署包括一個動作的集合，這些動作可以是： * 開始或停止一個或多個應用 * 更新一個或多個應用 * 縮放一個或多個應用 部署不會立即生效,過程需要時間。直到部署完成，部署才在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