标签: blue-green-deployment

我们目前正在Heroku上使用两个dynos运行Ruby on Rails项目(RefineryCMS).

每次我们更新网站时,我们都会遇到大约1到2分钟的停机时间.管理层对此并不满意.

我们真正喜欢的是某种(透明的)蓝绿色部署:http://martinfowler.com/bliki/BlueGreenDeployment.html

这可以在Heroku或其他云平台上实现吗？

我们也使用Unicorn,但如果有必要,我很乐意改变.

我计划从网页中提取（基本上是在获得许可的情况下抓取）一些数据并将其存储在 elasticsearch 中（您知道，用于搜索）。

虽然我有权从网站上抓取数据，

• 此数据没有 API 或其他结构化来源
• 它是直接手动编写成 HTML 的
• 没有唯一标识符可以区分一个条目与另一个条目（我基本上将从 DOM 中提取大约 1,000-5,000 个条目）。

当我将其存储在 es 中时，我计划将其放入一个索引和映射类型中，例如thing.

但是，随着时间的推移，源（HTML 网页）可能会随着它们添加/删除/更改其中一些条目的内容而发生变化。由于源中没有标识符，我无法轻松识别新的（更糟糕的是，已删除或已更改的）。

我想让我的 es 索引保持最新，我在想的是某种蓝绿色机制：

• 我根据源更改的速度按某个计划（每天/每周）运行提取过程
• 每次运行该进程时都会生成另一个索引（或者可能是一个新的集群）。假设当前索引是index-prod，进程构建的新索引是index-rc（候选发布）
• 它index-rc基于一些启发式进行验证（对条目数量的灵活速度检查、我们知道应该工作的示例查询等）
• 如果它是有效的，它要么：
  • A. 慢慢地将查询翻转到新的集群/索引中
  • 或 B. 一次性翻转到新的集群/索引

我计划使用AWS Elastisearch Service托管elasticsearch集群，并且可能会使用Route 53 CNAMEs （也许是 ELB？）来制作一些东西，但我想知道 elasticsearch 本身是否有更隐式的支持来这样做？

本质上，我想将一个索引的数据交换为另一个。

我们使用Terraform为项目设置了基础架构,包括代码部署,ALB和自动扩展组.到目前为止,我们正在进行就地部署.但现在我们正试图切换到Blue/Green部署.由于CodeDeploy Blue/Green部署会在成功部署时替换整个自动缩放组,因此Terraform状态文件中旧的Autoscaling组状态将变得陈旧,并且不会反映由CodeDeploy服务添加的新Autoscaling组.有没有任何已知的方法来克服这个问题？

我们希望能够部署我们的 Spark 作业，以便在部署期间处理数据时不会出现任何停机时间（目前大约有 2-3 分钟的窗口）。在我看来，最简单的方法是模拟“蓝/绿部署”理念，即启动新版本的 Spark 作业，让它预热，然后关闭旧作业。但是，使用结构化流和检查点，我们不能这样做，因为新的 Spark 作业看到最新的检查点文件已经存在（来自旧作业）。我在下面附上了一个示例错误。有没有人对潜在的解决方法有任何想法？

我想过将现有的检查点目录复制到新创建的作业的另一个检查点目录 - 虽然这应该作为一种解决方法（一些数据可能会被重新处理，但我们的数据库应该去重复），这似乎超级hacky，我宁愿不追求。

Caused by: org.apache.hadoop.fs.FileAlreadyExistsException: rename destination /user/checkpoint/job/offsets/3472939 already exists
    at org.apache.hadoop.hdfs.server.namenode.FSDirRenameOp.validateOverwrite(FSDirRenameOp.java:520)
    at org.apache.hadoop.hdfs.server.namenode.FSDirRenameOp.unprotectedRenameTo(FSDirRenameOp.java:364)
    at org.apache.hadoop.hdfs.server.namenode.FSDirRenameOp.renameTo(FSDirRenameOp.java:282)
    at org.apache.hadoop.hdfs.server.namenode.FSDirRenameOp.renameToInt(FSDirRenameOp.java:247)
    at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.renameTo(FSNamesystem.java:3677)
    at org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.rename2(NameNodeRpcServer.java:914)
    at org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolServerSideTranslatorPB.rename2(ClientNamenodeProtocolServerSideTranslatorPB.java:587)
    at org.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos$ClientNamenodeProtocol$2.callBlockingMethod(ClientNamenodeProtocolProtos.java)
    at org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:616)
    at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:982)
    at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2049)
    at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2045)
    at java.security.AccessController.doPrivileged(Native Method)
    at javax.security.auth.Subject.doAs(Subject.java:422)
    at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1698)
    at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2045)

    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
    at org.apache.hadoop.ipc.RemoteException.instantiateException(RemoteException.java:106)
    at org.apache.hadoop.ipc.RemoteException.unwrapRemoteException(RemoteException.java:73)
    at org.apache.hadoop.hdfs.DFSClient.rename(DFSClient.java:1991)
    at org.apache.hadoop.fs.Hdfs.renameInternal(Hdfs.java:335)
    at org.apache.hadoop.fs.AbstractFileSystem.rename(AbstractFileSystem.java:678)
    at org.apache.hadoop.fs.FileContext.rename(FileContext.java:958)
    at org.apache.spark.sql.execution.streaming.HDFSMetadataLog$FileContextManager.rename(HDFSMetadataLog.scala:356)
    at org.apache.spark.sql.execution.streaming.HDFSMetadataLog.org$apache$spark$sql$execution$streaming$HDFSMetadataLog$$writeBatch(HDFSMetadataLog.scala:160)
    ... 20 …

我正在尝试为具有蓝绿色部署支持的 AWS ECS编写云形成模板。AWS 最近在 ECS 中添加了这个蓝绿色功能，在云形成模板中找不到任何更新它的参考。他们提供了关于如何通过 UI 而不是通过云形成来做到这一点的文档。我猜，AWS 可能不会更新他们的云形成文档，因为它是一项新功能。任何找到文档的帮助将不胜感激。提前谢谢你。

我很难为我的 s3 静态网站提供蓝绿色。我在给定的存储桶中发布了该网站的一个版本，并在以下位置公开：

• Cloudfront 发行版
• 然后在 53 号公路上
• 和另一个 CDN（公司，解析 DNS）以访问互联网。

我尝试了一些“计算”解决方案，比如 ALB，但我没有成功。

我遇到的困难的主要问题是，当我使用新地址更新 CloudFront 时，DNS 复制时间很长，这使得将未来版本回滚到旧版本变得困难（考虑为此发布使用不同的存储桶）。

有没有人经历过这个或知道如何解决这个问题？

使用 cloudformation 模板通过网关 API 部署 lambda 函数时，我想将使用不同阶段创建的网关 API 放在 route53 后面，以便可以使用加权流量进行蓝/绿部署。是否可以在不手动登录到控制台进行配置的情况下自动执行整个过程？

我想创建一个 CodePipeline，它从 CodeCommit 源构建一个容器映像，然后以蓝/绿方式将新映像部署到我的 ECS 服务（EC2 启动类型）。

• 源阶段是 CodeCommit，它已经包含 appspec.json
  和 taskdef.json
• 构建阶段正在构建新容器并将其成功推送到 ECR，文件 imagedefinition.json 是在此步骤创建的 BuildArtifact，包含容器和最近创建的镜像，其标签对应于 CodeCommit commit-id。
• 部署阶段由操作“Amazon ECS（蓝/绿）”组成，使用 SourceArtifact 和 BuildArtifact 作为 InputArtifact，从 SourceArtifact 获取 appspec 和 taskdef，从 BuildArtifact 获取图像描述，最终在 Blue/ 中部署新容器绿色方式。

问题出在 BuildArtifact 的图像定义上。管道在部署阶段失败并出现错误：

"" 尝试从工件中读取图像工件文件时出现无效的操作配置异常：BuildArtifact。“”

如何正确配置“Amazon ECS（蓝/绿）”部署阶段，以便它可以使用最近创建的映像并部署它....通过替换 taskdef.json 中的占位符 IMAGE_NAME ？

任何提示高度赞赏：D