AWS EMR 上的持续集成答案

【问题标题】：Continuous Integration on AWS EMRAWS EMR 上的持续集成
【发布时间】：2017-12-28 12:07:58
【问题描述】：

我们有一个长期运行的 EMR 集群，该集群上使用引导操作安装了多个库。其中一些库正在持续开发中，它们的代码库位于 GitHub 上。

我一直希望以与 Travis 和 CodeDeploy 类似的方式将 Travis CI 插入 AWS EMR。这个想法是让 GitHub 上的代码测试并自动部署到 EMR，同时使用引导操作在所有 EMR 节点上安装更新的库。

我想出的一个解决方案是在中间使用一个 EC2 实例，可以先使用 Travis 和 CodeDeploy 在实例上部署代码。之后触发实例上的午餐脚本以使用更新的库创建新的 EMR 集群。

但是，上述解决方案意味着我们每次部署新版本的系统时都需要创建一个新的 EMR 集群

还有其他建议吗？

【问题讨论】：

好问题，我们遇到了类似的问题，我们最终做了与您提出的解决方案非常相似的事情。我们的 CI 系统将代码部署到单个主机，然后每天 cron 每天创建一个新集群。这将我们的部署率限制为每天一次。但简化了集群之间的切换。我也很好奇是否有更好的方法
我们同时使用长期运行的和临时的 EMR 集群——我们最终可能会启动 20 个集群。一个用于生产，其余用于开发和质量检查。在维护这一点的过程中，我们已经看到了能够启动集群的不可思议的价值。如果您的新架构强制执行此操作，我打赌您会发现这是一件好事：在某种程度上，您定义的实际上是“蓝绿”部署，这是一个非常好的模式，IMO
@TomHarrisonJr 有趣！ - 谢谢。您如何处理在长期运行的集群上引导新版本/库的问题？您是否终止旧集群并创建新集群？干杯
每个版本，即使对于长期运行的集群，都会启动一个新的集群并终止旧的集群。我们支持多种流数据输入机制，因此我们围绕它们构建了一个小框架来处理部署期间的瞬时切换，但除此之外，我们每次发布都会获得一组全新的实例（因此，每周几次）。

标签： amazon-web-services travis-ci amazon-emr aws-code-deploy

【解决方案1】：

您绝对不想维护一个 EC2 实例来编排这样的 CI/CD 流程。首先，它引入了许多挑战，因为你需要处理整个服务器实例，保持它的维护，处理网络，应用监控和警报来处理可用性问题，即使那样，你也不会有可用性保证，这可能会导致其他问题。最重要的是，为了这样的目的维护一个 EC2 实例是没有必要的。

我建议您使用带有 Lambda Step Function 的 Amazon CodePipeline 进行调查。 Step Function 可用于在完全无服务器的环境中编排 EMR 集群的配置。使用 CodePipeline，您可以在您的 Github 存储库中设置一个 Web 挂钩，以在您将更改提交到您的 Github 主分支（或您指定的任何分支）时自动拉取您的代码并启动新的部署。您可以使用 EMRFS 将 S3 存储桶或文件夹同步到集群的 EMR 文件系统，然后获得 IAM 的安全优势，以及 EMRFS 附带的额外一致性保证。借助 Lambda，您还可以无缝集成到其他服务，例如 Kinesis、DynamoDB 和 CloudWatch 等，这将简化许多管理和开发任务，并使您能够以最少的工作实现更复杂的自动化。

有一些很棒的资源和教程可用于将 CodePipeline 与 EMR 结合使用，以及一般情况下。以下是一些示例：

还有关于使用 Lambda Step Functions 编排应用程序的精彩教程，包括 EMR 的使用。以下是一些示例：

在最坏的情况下，如果所有这些选项都失败了，例如，如果您需要在 EMR 集群完成其引导后对 EMR 集群上的启动过程进行非常严格的控制，您始终可以创建一个已加载的 Java JAR作为最后一步，然后使用它来执行 shell 脚本或使用各种 Amazon Java 库来运行您的配置命令。即使在这种情况下，您仍然不需要出于编排目的维护自己的 EC2 实例（在我看来，即使它在 Kubernetes 的 Docker 容器中运行也很难证明其合理性），因为您可以轻松地维护它部署过程以及完全无服务器的方法。

Amazon re:Invent 会议中有许多精彩的视频，您可能想先观看这些视频，以便在您进入研讨会之前快速入门。例如：

YouTube 上还有更多此类视频。

Travis CI 还支持 Lambda 部署，如下所述：https://docs.travis-ci.com/user/deployment/lambda/

【讨论】：