文档章节

应用更新和部署

xueyi28
 xueyi28
发布于 2016/05/22 15:56
字数 1359
阅读 14
收藏 0

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

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

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

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

 

 

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

Starting : 如果dbapp都启动,db先有app启动
Stopping : 如果dbapp都停止,app先于db停止
Upgrade : 看具体的调容场景
Scaling : 如果dbapp一起调容,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

如果你设置你minimumHealthCapacity0.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.
 

本文转载自:http://blog.csdn.net/kangqi7000/article/details/51475398

共有 人打赏支持
xueyi28
粉丝 7
博文 92
码字总数 33680
作品 0
南宁
更新APP-执行滚动更新

目标: 使用kubectl做一次滚动更新 更新一个应用 用户期望应用一直是可用的,而开发者期望一天部署多次新版本。 在k8s里,这是通过滚动更新来实现的。 Rolling updates允许增量更新新的Pods实...

趁你还年轻233
03/12
0
0
如何使用Helm更新使用ConfigMap的应用程序

Helm的小小黑科技,让你简单快速地更新那些使用ConfigMap的应用程序。随时随心更改配置文件内容,而应用程序将实时根据变化而更新~ 文内有逐步的步骤详解,还有打包好的helm chart供你使用哟...

RancherLabs
07/25
0
0
Docker和持续交付、持续部署类型

王杰 译 在本篇博文的姊妹篇《 五步走战略建立良好的持续交付流程》中,我们看到了高性能IT团队如何采用Docker来实现持续交付(CD)的最佳实践。其中,CD可以通过大量的部署方法实现,而Doc...

程序师
02/04
0
0
Docker和持续交付部署类型

在本篇博文的姊妹篇《五步走战略建立良好的持续交付流程》中,我们看到了高性能IT团队如何采用Docker来实现持续交付(CD)的最佳实践。其中,CD可以通过大量的部署方法实现,而Docker只是帮助...

Docker
02/03
0
0
通过Rancher部署并扩容Kubernetes集群基础篇二

接上一篇通过Rancher部署并扩容Kubernetes集群基础篇一 7. 使用ConfigMap配置redis https://github.com/kubernetes/kubernetes.github.io/blob/master/docs/user-guide/configmap/redis/redi......

自由linux
2017/07/12
0
0

没有更多内容

加载失败,请刷新页面

加载更多

下一页

SpringBoot2.0 停机

最近新建了个SpringBoot2.0的项目,因为原来一直使用的是传统的Tomcat部署war包的形式,所以这次SpringBoot内置Tomcat部署jar包的时候遇到了很多问题。其中一个就是因为没有外置的Tomcat容器...

Canaan_
昨天
0
0
Confluence 6 外部参考

一个外部参考的意思是任何站点链接到你 Confluence 的实例。任何时候当 Confluence 的用户单击这个外部链接的时候,Confluence 可以记录这次单击为参考。 在默认的情况下,外部链接的参考链接...

honeymose
昨天
0
0
Android中的设计模式之抽象工厂模式

参考 《设计模式解析》 第十一章 Abstract Factory模式 《设计模式:可复用面向对象软件的基础 》3.1 Abstract Factory 抽象工厂 对象创建型模式 《Android源码设计模式解析与实战》第6章 创...

newtrek
昨天
0
0
Redis | 地理空间(GEO)的一个坑

Redis的地理空间(Geo)是个好东西,轻轻松松的就可以把地图描点的问题处理了, 最近却遇到一个坑...Redis采用的Msater-Slave模式, 运用GEORADIUS在salve读取对应的数据,新增了从节点但是从不返...

云迹
昨天
0
0
日期和时间API - 读《Java 8实战》

日期与时间 LocalDate 创建一个LocalDate对象并读取其值 // 根据年月日创建日期LocalDate date1 = LocalDate.of(2014, 3, 18);// 读取System.out.println(date1.getYear()); // 2014Sys...

yysue
昨天
0
0

没有更多内容

加载失败,请刷新页面

加载更多

下一页

返回顶部
顶部