提高企业规模

转发的最初的是在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 '传递到存储库，它将负责处理执行身份验证，以及最终基于这些凭证的授权。

图表越多，问题就越多

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

假设你喜欢离线搜索。你下载了最新的索引(它在服务器上不断更新，所以你的本地索引不断地过时)，找到了一个没有互联网的地方(我过去常说“上了飞机”，但现在连这都不管用了)，运行图表搜索，发现了一个很棒的图表。现在怎么办呢?你还是不能下载图表。

另外，我是否提到过您的本地索引可能已经过时，并且您需要在每次想要搜索时更新它?

现在我们来看看Helm索引实现的真正问题:可伸缩性。Helm为整个存储库提供了一个索引文件。它包含所有图表的列表、关于每个图表的元数据、每个图表的所有版本的列表以及关于每个版本的元数据。有很多文本，很多重复。我们进行了一些基准测试，结果并不理想许多图表：

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

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

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

修复#1 -压缩

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

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

修复#2 -停止转换太多

让我们不要在YAML中转换，然后转换为JSON。我们知道JSON比YAML更容易解析，所以也许我们应该先传输一个gzip压缩的JSON。

修复#3 -分而治之

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

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

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

欢迎来到布局

我们刚刚给自己制造了麻烦。这样划分的索引需要存储库布局。在根目录中使用一堆tar.gz和一个YAML索引已经不能解决问题了。现在我们需要这样的东西:

回购|—应用|—ver1 |—ver2

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

解决办法:添加push命令

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

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

社区岩石!

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