在AWS EMR上进行持续集成

斯坦

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

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

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

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

还有其他建议吗?

德温博斯特

您绝对不希望维护EC2实例来编排这样的CI / CD流程。首先,它带来了许多挑战,因为随后您需要处理整个服务器实例,对其进行维护,处理网络,应用监视和警报以解决可用性问题,即使如此,您也将没有可用性。担保,这可能会导致其他问题。最重要的是,根本不需要为此类目的维护EC2实例。

我建议您调查将Amazon CodePipeline与Lambda Step Function一起使用。步进功能可用于在完全无服务器的环境中协调EMR群集的配置。使用CodePipeline,您可以在Github存储库中设置Web挂钩,以在每次将更改提交到主Github分支(或指定的任何分支)后自动提取代码并自动启动新的部署。您可以使用EMRFS将S3存储桶或文件夹同步到集群的EMR文件系统,然后获得IAM的安全性优势以及EMRFS附带的其他一致性保证。借助Lambda,您还可以无缝集成到其他服务(例如Kinesis,DynamoDB和CloudWatch等)中,从而简化许多管理和开发任务,

有一些很棒的资源和教程可用于将CodePipeline与EMR结合使用,以及一般而言。这里有些例子:

对于使用Lambda Step Function编排应用程序,也有很棒的教程,包括EMR的使用。这里有些例子:

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

在进入研讨会之前,您可能需要观看Amazon re:Invent会议的许多精彩视频,以快速入门。例如:

YouTube上还有更多此类视频。

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

本文收集自互联网,转载请注明来源。

如有侵权,请联系 [email protected] 删除。

编辑于
0

我来说两句

0 条评论
登录 后参与评论

相关文章