openshift中的部署策略

部署策略就是改变或者升级应用的一个方法。

目的是升级或者其他改变的整个过程downtime最小以及对终端用户影响最小。

openshift提高了许多的部署策略。总的来说，有2种不同的方法去管理部署策略。一个方法是用deployment configration实现，另一个用openshift router的一些特性去route traffic的方式去实现。前者影响该应用的所有routes. 而后者只会影响到独立的routes。 

滚动部署(Rolling)

openshift默认机制。如果一个应用的deployment configuration中没有配置部署策略，则默认为该策略。

这个策略逐渐用新版应用的instances代替老版本的instance。这个策略会运行readiness probes去检测新pod是否ready. 如果ready则会scale down老版本，否则，部署取消。

openshift中的滚动部署也就是金丝雀部署。新版本这里就是金丝雀。在old instance被取代之前，金丝雀要经过验证。如果readiness一直不成功，金丝雀instance会被删除，deployment configuration也会自动回退到上一个版本。

当你有如下情况时，建议你选用该策略：

1. 你希望你的应用更新没有downtime

2. 你的应用支持老版本和新版本并存。

重建策略(Recreate)

在这个策略种，openshift会先停止正在运行的所有的pod, 然后之启动该应用的新pods。这个策略会导致downtime一段时间。

当你有如下情况时，建议你选用该策略：

1. 你的应用不支持新版本和老版本同时存在

2. 你的应用用的是一个RWO（ReadWriteOnce）模式的可持续存储。这个模式不允许同时有多个pod读写。

定制化策略（Custom）

如果滚动策略和重建策略都不满足你的需求，则你可以使用custom策略去部署应用。你可以提供自己定制化的container image并在该image种定义部署行为。这个定制的image可在应用的deployment configuration中通过spec.strategy.customParams指定。

通过openshift router features实现的策略如下：

蓝绿部署（blue-green）

在蓝绿部署种，你有两个相同的环境，一个运行的老版本，一个运行的是新版本。openshift router用于将当前生产的traffic定向至新的更新的版本。在这个部署中，老版本为green, 新版本为blue。通常如果你有两个特定版本的服务和一个路由时，则你可以使用该部署。

这个路由在任意时刻都指向一个服务，也可以切换至转向另一个服务。作为一个开发人员，你可以在你的新版本的服务充分测试后，再将生产路由切过去。

A/B部署(A/B)

A/B部署允许你在生产环境部署为特定一些用户部署新的版本。你可以配置openshift使大多数请求都routes向当前的生产版本，少数请求routes向新版本。由于时你控制流向不同版本的请求的比例，则随着测试的进展，你可以慢慢的增加routes向新版本的请求数，直到最后停止老版本的routes。当你调整不同version的请求负载时，每个服务的数目也需要调整，使得，服务性能满足预期。

N-1 并存部署(N-1 Compatibility)

许多部署策略都需要两个版本的应用同在提供服务，但是这种情况要求新版本产生的新的数据必须能被老版本的应用处理。应用程序管理的数据可能有许多格式：存储在disk上的数据，存储在数据库中的数据，还有临时的cache。许多设计的很好的无状态的web应用都支持滚动部署，但是我们认为测试和部署的应用去支持N-1并存部署也很有意义。

优雅终止（Graceful Termination）

Openshift在将应用的路由遗除出负载均衡管理列表之前就终止应用instance。 应用必须保证其被终止之前连接的用户都退出了。

当openshift要shutdown一个container时，会发一个container中的进程发一个TERM的信号。程序代码在受到该信号后，就应该停止接受新的连接，这就保证router可以将route转向其他正在运行的instances。程序代码应该等到所有的连接都关闭后在退出，然后shutdown. 

程序代码会等待多久，这段时间我们称之为优雅终止时期（graceful termination period）。等这个优雅终止时期失效，openshift会发送KILL信号给还未退出的进程，进程会立即结束。pod和pod template中terminationGracePeriodSeconds参数决定了时常，默认时30s。

生命周期中的hooks(life-cycle hooks)

重建和翻滚策略支持life-cycle hooks.你可以用这些hooks在部署过程中定点执行定义好的操作。openshift部署包含3种life-cycle的hooks.

前（Pre）

这个前置的life-cycle hook在任何新pod的部署开始之前执行，也会在任何老pod在shutdown之前执行。

中（Mid）

这个中间的life-cycle hook在老pod被shutdown和新pod启动之前执行。

后（Post）

这个后的life-cycle hook在所有新的pod的部署开始之后和在所有老pod shutdown之后执行。

life-cycle hooks在独立的container执行，生命周期短暂。执行完后，自动清除。

自动化的database initialization和migrations就是利用life-cycle很好的例子。

任意一个hook都有一个失败策略（failurePolicy）, 其定义了当一个hook failure发生的时候，该做些什么。可以采取以下这些行为：

中止（abort）： hook失败，则整个deployment失败

再次尝试（retry）: 再次执行hook直到执行成功

忽略（ignore）: 忽略hook失败，继续部署