scrum 工件_一个简单,可扩展的解决方案,用于存储和提供构建工件
scrum 工件
在Pinterest,我们的使命是帮助人们发现自己喜欢的事物,使他们过上更有创造力和充实的生活。 Pinterest工程的发展速度惊人得惊人,其中一些主要服务每天发布两次。 我们努力在主线中构建和集成每个提交,这每天都会转化成大量的构建工件。 可靠地存储它们并以一致的性能有效地为其提供服务对我们的增长速度提出了巨大的挑战。
Pinrepo是我们应对这一挑战的答案。 这是一个简单但可扩展的解决方案,用于在内部存储和提供构建工件,例如Debian软件包,maven jar和pypi软件包。 我们已经在生产中运行Pinrepo超过八个月,并且性能稳定且几乎无需维护。
现在,我们将GitHub上的 Pinrepo 开源 。 在那里,您可以找到所有配置节和说明以自行创建。 它还包括一个pypi发布工具,用于发布和维护pypi软件包。 检查一下,让我们知道您的想法! 并且,随时为您的自定义和改进做出贡献。
Pinrepo功能
- 简单:在AWS S3中发布和存储构建工件,并与Nginx反向代理一起使用
- 可扩展:轻松添加其他格式支持,例如RPM
- 可靠:高可用性的Nginx集群和AWS S3服务
- 可扩展: Nginx层可水平扩展 ,因为AWS S3后端具有高度可扩展性
- 对DevOps友好:在生产中运行了八个月,几乎无需维护
克服扩展挑战
Pinrepo帮助我们解决的最大挑战是可伸缩性,它使我们能够随着时间的推移有效地为大量数据提供服务。 例如,在一天构建50次主要的36MB Python程序包时(每天总共1.8GB,每三个月总共162GB),扩展成为一个问题。 我们之前使用过不同的解决方案,但是随着对象数量的增加,它们的性能通常会随着时间的推移而下降。
除了扩展之外,还存在服务可用性和数据持久性方面的问题。 我们之前使用的解决方案基于单个主机和磁盘,并且它们运行缓慢且经常崩溃。 尽管有备份过程,但它们通常在没有通知的情况下中断。 维护这些服务是一场噩梦,我们需要在持久,高度可扩展的对象存储之上提供可靠的服务。
我们考虑过直接使用Amazon S3,但是我们发现我们无法使用它来存储和提供构建工件,因为如果未将存储桶配置为可公开访问,则存储库客户端将无法与S3进行通信。 这些类型的AWS S3请求首先需要“签名”,包括一个基于请求的某些元素计算和附加HMAC的过程。
只需在AWS S3前面添加Nginx服务器集群即可解决该问题。 从理论上讲,我们可以“修复”所有存储库客户端,以便它们可以直接与S3进行通信,但是这将需要大量工作,并且难以维护并扩展到其他工件格式。 另一方面,Nginx层不仅可以签名并将请求转发到AWS,而且还可以为工件提供本地缓存,从而极大地提高了性能。 Nginx层是无状态的,可以轻松地水平扩展,因此也解决了可用性问题。 另外,不需要额外的备份过程。
我们的答案:Pinrepo,我们的内部工件存储库。
Pinrepo简介
我们在负载均衡器后面创建了Nginx服务器集群,将所有请求代理到后端AWS S3服务,并使用Nginx模块ngx_set_misc创建了AWS服务请求签名。
将工件直接发布到S3
在Amazon S3中有很多上传和维护工件元数据和布局的方法,包括使用deb-s3上传和维护debian软件包,以及使用maven插件maven-s3-wagon来获取maven软件包。 我们找不到任何现有工具将Python软件包上传到S3,因此我们编写了自己的pypi-release以上传和维护pypi软件包。
简单更好
通过将构建工件直接发布和存储到Amazon S3并在Nginx集群中进行前端扩展,我们简化了技术堆栈,同时以最少的维护需求实现了可扩展性和耐用性。
未来的改进
尽管可以使用各种S3工具来查找存储库中可用的内容,但是可以添加具有搜索支持的简单UI。 添加其他功能时请务必小心,不要使它们成为关键路径的一部分,以免损害现有简单解决方案的可靠性和可扩展性。 分段存储库和程序包升级也很不错,但是如果您具有分段部署和预生产测试环境,则不是必需的。 Pinrepo也可以扩展为轻松支持更多软件包格式,例如RPM。
致谢:感谢Raj Patel,他帮助评估了各种现有解决方案并使流程正式化; Jayme Cox,负责审查设计并为实施细节提供建议; 以及Pinterest云工程团队的所有成员,后者可提高站点的可靠性,速度和安全性,并为云基础架构和开发人员构建技术构建块。
本文基于Pinterest博客的公告。
scrum 工件