提高企业规模

转发的最初的这篇文章发表在AWS开源博客上

TL/DR:包管理器总的来说很糟糕，但是Helm, Kubernetes的包管理器……一点儿也不错。在包管理器的七宗罪中，Helm只犯了两宗，而且这些都很容易修复。我们将在下面解释怎么做。我们还没有完全做到这一点，但你可以期待Helm在未来为企业做好准备。更好的是，你可以帮忙!请继续阅读。

这篇博文不是关于如何开始使用Helm。具体请参见舵的网站，它有很好的文档。相反，让我们谈谈Helm的一些设计和执行决策，哪些是正确的，哪些是缺乏的，以及我们如何修复它。

包管理器和打印机有什么共同之处

你可能从经验中知道(从燕麦片是地狱派来的印刷工，让我们都痛苦不堪。包管理器也是如此。Sam Boyer在一个Go包管理器实现上工作，他在他的文章中总结了编写和使用包管理器的问题。所以您想要编写一个包管理器。”

总的来说，我们在JFrog十多年的经验教训软件包管理器是否每个包管理器都至少有一个(但通常更多)我们称之为包管理器的七宗罪：

1. 至架构
2. 缺乏对企业场景的规划(例如，没有私有存储库，不能扩展，等等)
3. 可下载的指数
4. CSDR(跨站点依赖解析)漏洞
5. 缺少适当的包认证
6. 缺少版本管理
7. 为中央注册中心使用错误的服务(并对其进行硬编码)

头盔非常好!

我们很喜欢赫尔姆。它成功地避免了上述大部分问题。它很简单(#1)，依赖关系是版本化的(#6)，不允许任意url(#4)，作者通过他们的公共身份进行身份验证(#5)，中央存储库使用blob存储实现(#7)。几乎都很好。

没有身份验证?这不是“企业准备好了”!

在您的扩展过程中，当您需要知道谁部署和下载了什么，以及当您希望开始授予某些人和机器执行或不执行某些事情的访问权限时，会有一个点。等到事情破裂的时候，通常已经太晚了。

直到最近，你还不能对赫尔姆这样做。虽然你可以很容易地在你的网络中建立你自己的私有回购，这对于一个小团队来说可以工作一段时间，但对于一个严肃的开发组织来说是不够的，尤其是在跨团队依赖和共享的情况下。为每个团队维护一个单独的安装，以强制某种分离?缺乏跨团队元数据和维护开销是严重的障碍。

解决办法:提供凭证

掌舵接受了我们的拉取请求这就解决了问题。从Helm 2.9开始，您可以将' -username '和' -password '传递给存储库，它将负责执行身份验证，最后是基于这些凭据的授权。

更多的图表，更多的问题

解决了这个问题后，我们现在正在解决可下载索引的问题。首先，为什么这是个问题?能够执行离线搜索不是很好吗?我们认为，可下载索引虽然在发明之初是完全合理的，但现在产生的问题比它解决的问题更多。过去执行集中的并发搜索是很困难的，但是现在(问问Google)现在不是这样了，对吧？

假设你很享受离线搜索。您下载了最新的索引(它在服务器上不断更新，因此您的本地索引不断过时)，找到了一个没有互联网的地方(我过去常说“上了飞机”，但即使这样也不再起作用了)，运行图表搜索，并找到了一个很棒的图表。现在怎么办呢?你仍然不能下载图表。

另外，我有没有提到您的本地索引可能已经过时了，每次要搜索时都需要更新它?

这里我们谈到了Helm索引实现的真正问题:可伸缩性。Helm为整个存储库提供了一个索引文件。它包含所有图表的列表、每个图表的元数据、每个图表的所有版本的列表，以及每个版本的元数据。这是大量的文本，大量的重复。我们运行了一些基准测试，当你许多图表：

正如你所看到的，当你有很多图表时，客户端解析下载索引的内存消耗会飙升，这是由于一些问题:

1. 客户机解析YAML文件，从中创建一个JSON对象，并使用该对象。
2. 所有东西都有一个索引。它太大了。
3. 有大量的重复。每个版本的元数据都是重复的。

让我们来看看可以采取的一些措施来解决这个问题:

修复#1 -压缩

让我们压缩传输中的索引。这对处理时间没有帮助(实际上，解压缩会增加处理时间)，但它会极大地缩小传输中的索引大小(实际上是一个数量级)。但是，嘿，我们不是说过要减少处理负荷吗?我们马上就会讲到这个，但要注意，不管别人怎么说，延迟仍然存在。如果我们可以用这样一个简单的修复方法将有效载荷大小减少十倍，那么就让我们去做吧!

现在回到减少处理时间和负载的问题。

修复#2 -停止转换太多

我们不要先传输YAML，然后再转换为JSON。我们知道JSON比YAML更容易解析，所以也许我们应该从传输压缩后的JSON开始。

修复#3 -分而治之

让我们将索引分解成一个结构，允许下载和解析它，而不是下载和解析一个大文件:

• 主索引:应用程序列表(最新版本)
  • “artifactory: 5.8.3”
• 应用索引:版本列表(和应用级元数据)
  • “描述”
  • 的维护者
  • “关键词”
  • “源”
• 版本索引:版本的详细信息
  • “appVersion”
  • “创建”
  • “消化”
  • “url”

要搜索图表，您只需要下载并解析顶级索引，因为它不包含任何元数据，所以很小。为了描述图表并获得版本列表，除了最新版本，只需要下载和解析应用索引。这很小，因为它只包含关于一个图表的元数据，以及一个版本列表。最后，当我们想要下载图表时，我们将下载并解析关于该图表特定版本的元数据，包括要下载的URL、要验证的摘要等。

欢迎来到版面设计

我们刚刚给自己制造了一个麻烦。这种划分索引需要存储库布局。在根目录中有一堆tar.gz和一个YAML索引将不再有效。现在我们需要这样的东西:

Repo |——app |——ver1 |——ver2

这没什么大不了的执掌库客户端应该封装存储库结构，而搜索、检索和推送命令应该是支持repo的，对吗?然而,赫尔姆从来没有推命令。这不是一个问题，因为没有布局，任何curl上传都可以做正确的事情——你可以通过HTTP将图表发布到repo的根目录。但在引入布局之后，就不再是这样了。

修复方法:添加push命令

有关于添加push命令的讨论很多。它将充分封装传输协议的更改(从YAML切换到压缩JSON)和存储库布局的更改。

这项工作正在作为Helm 3的一部分进行;马特屠夫描述了他们计划在下一个主要版本中进行的许多改进。虽然大部分的变化发生在运行时和Helm的模板部分，但他提到了“面向图表存储库的性能变化”和官方设计方案包括“将包推送到存储库的命令”。

社区岩石!

正如您所看到的，Helm一开始就避免了其他包管理器的大多数缺点。是的，仍然有改进的空间，但是在JFrog和其他社区成员的帮助下，正如这篇博文所描述的，我们即将解决阻碍Helm和大规模企业采用之间的最后一个技术问题。身份验证问题已经解决，并且索引优化、repo布局和push命令添加正在进行中，我们可以期待Helm成为最先进的包管理器之一。还有还有很多事情要做当然了。Helm让你很容易开始贡献。只要查找标有“不错的第一期，并加入一个神奇的社区。