标签: blue-green-deployment

我对金丝雀版本的理解是,它是对部分生产节点的部分发布,其中粘性会话已打开.这样,如果您最终发布了错误的错误,您可以控制并最大限度地减少受影响的用户/客户数量.

我对蓝色/绿色版本的理解是你有2个镜像生产环境("蓝色"和"绿色"),你将更改推送到蓝色或绿色的所有节点,然后使用网络魔术来控制用户通过DNS路由到哪些环境.

所以,在我开始之前,如果我到目前为止所说的任何内容都不正确,请先纠正我!

假设我或多或少走上正轨,那么关于这两个策略的几个问题:

• 是否存在金丝雀优于蓝/绿的情况,反之亦然？
• 是否存在部署模型可以同时实施这两种策略的情况？

蓝/绿部署和滚动部署之间有什么区别？我一直认为蓝/绿部署是一种突然从旧版本到新版本的流量切换.

这说说蓝/绿部署在AWS上显示各种不同的策略来实现一个蓝色/绿色的部署,但他们似乎也匹配的定义滚动部署.

蓝/绿部署是滚动部署的子集吗？

在我们使用Spring Cloud开发微服务的过程中,我们开始使用Zuul作为从外部到微服务的任何连接的代理,以及任何需要联系其他微服务的微服务.

一段时间后,我们得出结论,Zuul被设计为边缘服务(仅从外部到微服务的代理流量),不应该用于跨微服务通信.特别是Spring Cloud建议使用eureka与另一个服务建立直接(可能是负载平衡)连接的方式使我们反对在所有事件之间使用Zuul.

当然,一切都按预期工作得很好(就像Spring云一样),但我们对如何使用此设置执行某个用例毫无头绪.

在部署新版本的微服务时,我们希望对旧版本和新版本进行蓝/绿部署.但是,在微服务之间没有Zuul,两个单独服务之间的通信将继续使用旧版本,直到从eureka中删除.

我们正在考虑如何实现这一目标.在下面的图片中,我画了我认为可能是一个选项.

在图片的第一部分,Zuul打电话给eureka来获取注册表来创建路线.服务1还调用eureka以使注册表路由到服务2.由于服务2在eureka注册表中,因此路由成功完成.

在图的第二部分中,部署了服务2(服务2.1)的更新.它也注册了eureka,这使得服务1现在可以路由到服务2和服务2.1.蓝/绿部署不需要这样做.

在第三部分中,展示了针对此问题的另一个eureka实例的潜在解决方案.此实例不支持对等,不会与第一个eureka实例同步.与第一个实例相反,这个唯一的目的是促进蓝色/绿色部署.服务2.1向第二个eureka实例注册,服务1将其配置更改为从第一个尤其是第二个eureka实例获取其注册表.

我们面临的主要问题是这是否是一个可行的解决方案.具有Zuul路由的灵活性是我们在这种情况下没有的一大优点.我们应该回过头来通过Zuul路由每个服务到服务的呼叫,还是有另一个解决方案(可能是某种类型的功能区配置)更合适？或者第二个eureka实例是此类部署的最佳解决方案？

任何反馈将不胜感激.

亲切的问候,安德烈亚斯

我目前正在Azure ServiceFabric上使用ReliableActors框架构建应用程序.随着我们扩大规模,我正在考虑进行蓝/绿部署.我可以看到如何使用无状态系统来做到这一点.有没有办法使用有状态的演员来做到这一点？

我正在尝试一个与图像中详细描述的设置非常相似的设置:https://raw.githubusercontent.com/Oreste-Luci/netflix-oss-example/master/netflix-oss-example.png

在我的设置中,我使用的是客户端应用程序(https://www.joedog.org/siege-home/),代理(Zuul),发现服务(Eureka)和简单的微服务.一切都部署在PWS上.

我想从我的简单微服务的一个版本迁移到下一个版本,没有任何停机时间.最初我开始使用这里描述的技术:https://docs.cloudfoundry.org/devguide/deploy-apps/blue-green.html

在我看来,这种方法与Eureka等发现服务并不"兼容".实际上,我的服务的新版本在Eureka中注册并且甚至在我可以重新映射所有路由(CF路由器)之前接收流量.

这引出了另一种方法,我依赖于Spring Cloud/Netflix中的故障转移机制:

1. 我启动了一个新的(向后兼容)版本的服务.
2. 当这个版本被Zuul/Eureka选中时,它开始获得50%的流量.
3. 一旦我确认新版本正常工作,我就会删除"旧"实例.(我只需点击PWS中的"停止"按钮)

据我所知,Zuul在引擎盖下使用了Ribbon(负载均衡),所以在旧实例仍然在Eureka但实际上关闭的那一瞬间,我期望在新实例上重试而不会对客户端产生任何影响.

但是,我的假设是错误的.我的客户端出现了几个502错误:

Lifting the server siege...      done.

Transactions:               5305 hits
Availability:              99.96 %
Elapsed time:              59.61 secs
Data transferred:          26.06 MB
Response time:              0.17 secs
Transaction rate:          89.00 trans/sec
Throughput:             0.44 MB/sec
Concurrency:               14.96
Successful transactions:        5305
Failed transactions:               2
Longest transaction:            3.17
Shortest transaction:           0.14

我的application.yml的一部分

server:
  port: ${PORT:8765}

info:
  component: proxy

ribbon:
  MaxAutoRetries: 2   # Max number of retries …

我们可以使用“Helm Charts”部署应用程序

helm install --name the-release  helm/the-service-helm --namespace myns

我们使用冷“滚动升级”部署，

helm upgrade --recreate-pods the-release helm/the-service-helm --namespace myns

有没有办法使用“Helm Charts”来实现“蓝/绿”部署？

我已经研究了这篇关于蓝/绿部署的文章,然后一些谷歌搜索引入了我关于Canary Release的这篇文章.我有这种含糊之处:数据库会发生什么？我们应该如何使它们同步？我有两种可能的情况:

• 想象一下
  ,当蓝色处于活动状态时,每个环境(绿色和蓝色)有两个独立的数据库,新记录将被插入到它的数据库中,绿色不知道这些变化,
  除非我们提供类似机制的触发器(或任何其他机制)更新绿色数据库.
• 第二种情况表明我们在两个环境之间共享一个向后兼容的数据库,但
  在处理数据库时,向后兼容性并不那么容易,我们必须
  在发布应用程序之前发布数据库更改.

可能存在第三种情况,对主蓝/绿部署中的数据库实施蓝/绿部署.

您认为更好的解决方案是什么？为什么？你建议任何其他练习或众所周知的模式吗？

谢谢

作为我们的蓝绿色部署策略的一部分,我们正在为prod RDS实例创建快照,然后将此快照恢复到应用db迁移并将新的Green应用程序链接到它的新实例.

我们的RDS实例有100 GB的空间,但我们的数据库目前仅使用10 MB.

拍摄快照大约需要2分钟

从快照恢复需要25分钟!

考虑到用户被迫在所有这段时间内保持只读模式并且我们的数据库大小目前小于10 MB,恢复的25分钟太长.

我想知道这个恢复时间是否是Amazon RDS的正常时间,或者我们是否做错了什么.

• 亚马逊RDS Postgres.
• 多AZ:是的
• 实例类:中等
• 通用(SSD)
• IOPS:已禁用.

昨天我们与团队一起讨论了使用零停机部署来支持我们的单页面应用程序的可能性.

在讨论它时,我们确定了一个边缘案例.用户在浏览器中加载页面后,在重新加载页面之前无法从内存中删除该页面.这意味着如果用户加载页面并开始使用网站(例如开始输入类似我现在正在做的长篇文章),那么在重新加载页面之前,他无法收到它的更新版本.

我们可以忽略用户在浏览器中看到旧应用程序版本的事实,但下面列出了2个点.

1. 如果我们引入用于服务spa的HTTP Api的重大更改,那么用户将无法保存他的文章(数据丢失!),或者在执行其他后端相关操作时可能会收到一些其他错误.
2. 当用户导航到新页面而不重新加载SPA时,他可以接收下一页的模板或与外部旧容器不兼容的某些控件的模板.它可以帮助破坏标记或应用程序逻辑.
3. 我们不能强迫用户重新登录,因为他可能正在打字他的文章,这只是一个糟糕的用户体验.

考虑到所有这些要点,可以提出以下解决方案:

1. 用户1将SPA的v1加载到他的浏览器中.
2. 除了auth令牌之外,版本信息也会发送到浏览器(例如使用JWT).
3. 我们想部署应用程序的v2版本.我们启动v2版本,但不禁用v1.
4. 用户2将SPA的v2加载到他的浏览器中
5. 用户1进入SPA的下一页.负载均衡器检查其令牌中的版本信息,并将用户1的流量路由到v1服务器.
6. 用户2以相同的方式路由到v2.
7. 用户1注销应用程序并关闭浏览器.
8. 用户1登录 - 这次他收到v2.
9. v1应用程序长时间没有收到任何流量后会被处理掉.

然而,在这种方法中,可以使多个版本存活,超过2个(例如,如果用户在一整天或两天内保持在线).这意味着在最后一个用户注销之前我们将无法将数据库迁移到新架构(图像如何对Facebook等网站起作用).拥有多个版本不是问题,但Docker和Rancher等工具可以让我们轻松完成.

同样在步骤7.用户需要重新加载页面或关闭浏览器 - 否则他仍将使用v1,我们不能强迫他进入下一个版本.

我的问题是您使用什么方法来实现单页面应用程序的零停机/蓝绿部署？

当您将流量切换到"绿色"版本时,如何管理应用程序的"蓝色"版本的生命周期,尤其是在现有的"蓝色"客户端应用程序方面.

你有没有解决这些问题,你知道其他任何解决方案吗？

我想运行蓝绿部署；然而，EF 迁移似乎阻止了这一点。如果我将版本 1 部署到蓝色插槽，创建 EF 迁移并将版本 2 部署到绿色插槽，则会发生以下两种情况之一。

场景一：

我将运行迁移，版本 1 将停止工作。这违背了能够在绿色插槽中测试版本 2 同时让我们的用户在蓝色插槽中运行版本 1 的目的。

场景2：

在从蓝色插槽切换到绿色插槽之前，我不会运行迁移。这意味着在允许用户访问版本 2 之前我无法测试绿色插槽（版本 2）。

处理这个问题的标准/最佳实践是什么？