提高企业规模

转发的最初的是在AWS开源博客上发布的吗

TL/DR:包管理器通常都很糟糕，但是赫尔姆，Kubernetes的包装经理……一点都不坏。在打包经理的七宗致命罪行中，赫尔姆只犯了两宗，而且这两宗很容易改正。我们将在下面解释。我们还没有完全做到这一点，但你可以期待Helm在未来成为企业准备。更好的是，你可以帮忙!继续往下读。

这篇博文并不是关于开始使用Helm的。有关详情，请参阅舵的网站，它有很好的文档。相反，让我们来谈谈Helm的一些设计和实现决策，哪些是正确的，哪些是不足的，以及我们如何修复它们。

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

你可能从经验(和燕麦片)认为打印机是从地狱送来的，是为了让我们所有人都痛苦。包管理器也是如此。Sam Boyer曾致力于一个Go包管理器实现，并在他的帖子中完美地总结了编写和使用包管理器的问题。因此，您需要编写一个包管理器．”

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

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

Helm不仅仅是OK!

我们很喜欢赫尔姆。它成功地避免了上述大多数问题。它很简单(#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索引已经不能解决问题了。现在我们需要这样的东西:

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

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

修复方案:添加push命令

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

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

社区岩石!

正如您所看到的，Helm一开始就避免了其他包管理器的大部分缺点。是的，还有改进的空间，但是在JFrog和其他社区成员的帮助下，正如这篇博客文章所描述的，我们即将解决阻碍Helm和大规模企业采用的最后一个技术问题。认证问题已经解决了，而且正在进行的索引优化、回购布局和push命令的添加，我们可以期待Helm成为最先进的包管理器之一。仍有还有很多事情要做,当然。Helm让开始贡献变得非常容易。只需要查找带有“良好的第一问题，加入一个很棒的社区。