我们所有人都使用某种包装管理器，包括清洁女工Galya姨妈，她的口袋里有一部iPhone，现在已更新。 但是，关于程序包管理器的功能尚未达成共识，标准的rpm和dpkg操作系统以及构建系统称为程序包管理器。 我们提供有关它们功能的主题的思考-它的功能以及为什么在现代世界中需要它们。 然后，我们将深入研究Kubernetes，并在这些功能方面仔细考虑Helm。
我们将理解为什么在此图中仅以绿色突出显示模板功能，以及组装和包装，环境自动化等存在哪些问题。 但请不要担心，本文并不以一切都不好的事实结尾。 社区对此不满意，并提供了替代工具和解决方案-我们将处理它们。
Ivan Glushkov （
gli ）通过发表有关RIT ++的报告为我们提供了帮助，该报告是以下详细介绍的视频和文本版本。
RIT ++上的此DevOps演讲和其他演讲的视频已发布，并可以在我们的YouTube频道上免费观看-寻找您正在解决的问题的答案。
关于演讲者： Ivan Glushkov开发软件已有15年了。 我设法在MZ的Echo平台上发表评论，并参与了MCST中Elbrus处理器的编译器开发。 他目前在Postmates从事基础设施项目。 Ivan是主要的
DevZen播客之一，他们在其中讨论我们的会议：
这里是RIT ++，
这里是HighLoad ++。
包装经理
尽管每个人都使用某种程序包管理器，但是对于它是什么并没有达成一致。 有一个共同的理解，每个都有自己的理解。
让我们回想一下最先想到哪些类型的程序包管理器：
- 所有操作系统的标准软件包管理器： rpm，dpkg，portage ，...
- 包管理器支持不同的编程语言： 货物，阴谋，钢筋3，混合物 ，...
它们的主要功能是执行用于安装软件包，更新软件包，卸载软件包以及管理依赖项的命令。 在编程语言内部的程序包管理器中，事情要复杂一些。 例如，有诸如“启动软件包”或“创建发行版”（构建/运行/发行版）之类的命令。 事实证明，这已经是一个构建系统，尽管我们也称它为包管理器。
所有这一切仅是由于您不能随便拿走……让Haskell爱好者原谅这种比较。 您可以运行二进制文件，但不能在Haskell或C中运行该程序，首先需要以某种方式准备它。 而且准备工作相当复杂，用户希望一切都可以自动完成。
发展历程
与GNU libtool一起工作的人（这是为一个包含大量组件的大型项目而制作的）并不嘲笑马戏团。 这确实非常困难，有些情况原则上不能解决，而只能绕开。
相比之下，像Rust的货物这样的现代包装语言管理器要方便得多-只需按一下按钮，一切就可以正常进行。 尽管实际上，在幕后解决了许多问题。 而且，所有这些新功能都需要附加的内容，尤其是数据库。 尽管可以在包管理器中将其随意命名，但我将其称为数据库，因为 数据存储在此处：有关已安装的软件包，其版本，已连接的存储库以及这些存储库中的版本的信息。 所有这些必须存储在某个地方，因此有一个内部数据库。
使用该编程语言进行开发，对该语言进行测试，启动-所有这些都是内置的并且位于内部，
工作变得非常方便 。 大多数现代语言都支持这种方法。 即使是那些不支持的人也开始支持，因为社区迫切要求并说在现代世界中没有它是不可能的。
但是任何解决方案总是不仅具有优点，而且具有缺点 。 缺点是您需要包装器，其他实用程序和内置的“数据库”。
码头工人
您是否认为Docker是软件包管理器？
无论如何，但本质上是肯定的。 为了将应用程序与所有依赖项完全放在一起并使它在单击按钮时起作用，我不知道更正确的实用程序。 如果不是包管理器，这是什么？ 这是一个很棒的包裹经理！
Maxim Lapshin已经
说过 ，使用Docker变得更加容易，事实就是如此。 Docker有一个内置的构建系统，所有这些数据库，绑定，实用程序。
所有福利的价格是多少？ 那些与Docker合作的人很少考虑工业应用程序。 我有这样的经验，而且价格实际上很高：
- 必须存储在Docker映像中的信息量 （映像大小）。 所有依赖项，实用程序的一部分，库都必须打包在其中，映像很大，您需要能够使用它。
- 范式的转变要复杂得多。
例如，我有一项任务是转移一个程序以使用Docker。 该程序是由一个团队多年来开发的。 我来了，我们做着书上写的所有事情：我们为用户绘制故事，角色，查看他们的工作方式，标准例程。
我说：
-Docker可以解决您的所有问题。 观看如何完成。
-一切都会在按钮上-太好了！ 但是我们希望SSH在Kubernetes容器内进行。
-等待，任何地方都没有SSH。
-是的，是的，一切都很好...但是可以使用SSH吗？
为了将用户的感知转变为新的方向，需要花费大量时间，花费教育工作和大量精力。
另一个价格因素是
Docker注册表是映像的外部存储库，需要以某种方式安装和控制它。 它有其自身的问题，垃圾收集器等，并且如果您不遵循它，它通常会掉下来，但是这一切都已解决。
Kubernetes
终于，我们到达了Kubernetes。 这是一个很酷的OpenSource应用程序管理系统，受到社区的积极支持。 尽管Kubernetes最初是由一家公司创立的，但现在拥有一个庞大的社区，无法跟上它的步伐，实际上没有其他选择。
有趣的是，所有Kubernetes节点本身都通过容器在Kubernetes中工作，所有外部应用程序都通过容器工作-
一切都通过容器工作 ！ 这既是加号也是减号。
Kubernetes具有许多有用的功能和特性：分布，容错，与不同的云服务一起工作的能力以及面向微服务架构的方向。 所有这些都很有趣而且很酷，但是如何在Kubernetes中安装应用程序呢？
如何安装该应用程序？
在Docker注册表中安装Docker映像。
这句话的背后是深渊。 您可以想象-您有一个用Ruby编写的应用程序，并且必须将Docker映像放入Docker注册表中。 这意味着您必须：
- 准备Docker映像
- 了解进展情况，基于哪个版本；
- 能够测试；
- 收集并填写您之前安装的Docker注册表。
实际上，这是一个很大的难题。
另外，您仍然需要用k8的术语（资源）描述应用程序清单。 最简单的选择：
- 描述部署+ pod，服务+入口（可能）；
- 运行kubectl apply -f resources.yaml命令，并将所有资源转移到该命令。
甘地把手放在幻灯片上-好像我在Kubernetes中找到了程序包管理器。 但是kubectl不是软件包管理器。 他只是说我想看到系统的这种最终状态。 这不是在安装程序包，不是在处理依赖项，也没有在构建-只是“我想看到这种最终状态”。
头盔
终于我们来到了赫尔姆。 Helm是一种多功能工具。 现在，我们将考虑Helm的发展领域以及与之合作的领域。
模板引擎
首先，Helm是模板引擎。 我们讨论了需要准备哪些资源，问题是如何用Kubernetes编写（不仅限于yaml）。 最有趣的是，这些是在特定环境中针对特定应用程序的静态文件。
但是，如果您在多个环境中工作，并且不仅具有生产环境，还具有针对不同团队的暂存，测试，开发和不同环境，则需要具有多个相似的清单。 例如，由于其中一个服务器中有多个服务器，并且您需要具有大量副本，而在另一个服务器中-仅一个副本。 没有数据库，无法访问RDS，您需要在其中安装PostgreSQL。 这是旧版本，我们需要重新编写所有内容。
所有这些多样性导致这样一个事实，即您必须将Kubernetes的清单作为清单，在任何地方复制并在任何地方修复：在此替换一位，在此替换另一位。 这变得非常不舒服。
解决方案很简单-您需要
输入模板 。 即，您形成一个清单，在其中定义变量，然后将外部定义的变量作为文件提交。 模板创建最终清单。 事实证明，可以在所有环境中重用同一清单，这更加方便。
例如，Helm的清单。
- Helm中最重要的部分是Chart.yaml ，它描述了清单的种类，版本，工作方式。
- 模板只是Kubernetes资源模板，其内部包含某种变量。 这些变量必须在外部文件或命令行中定义，但始终在外部定义。
- values.yaml是文件的标准名称，其中包含这些模板的变量。
用于安装图表的最简单的启动命令是helm install ./wordpress（文件夹）。 要重新定义一些参数，我们说：“我想精确地重新定义这些参数并设置这样的值。”
Helm可以完成这项任务，因此在图中我们将其标记为绿色。
是的，缺点出现了：
- 细致 。 资源是完全按照Kubernetes定义的，没有引入其他抽象级别的概念：我们只需编写我们想为Kubernetes编写的所有内容，然后在其中替换变量。
- 不要重复自己-不适用。 通常有必要重复同样的事情。 如果您有两个名称不同的类似服务，则需要完全复制整个文件夹（大多数情况下是这样做）并更改必要的文件。
在深入介绍Helm的方向之前，我将为您介绍所有这些，这是一个包管理器，让我们看一下Helm如何与依赖项一起工作。
处理依赖项
头盔很难与依赖项一起使用。 首先，有一个require.yaml文件适合我们所依赖的文件。 在处理需求时，他会执行requirements.lock-这是所有依赖项的当前状态（块）。 之后，他将它们下载到名为/ chart的文件夹中。
有一些工具可以管理：谁，如何连接，在哪里连接-
标签和条件 ，用于确定在哪个环境中（取决于哪些外部参数）连接或不连接某些依赖项。
假设您有用于暂存环境的PostgreSQL（或用于生产的RDS，或用于测试的NoSQL）。 通过在Production中安装此软件包，您将不会安装PostgreSQL，因为在那里不需要PostgreSQL-仅使用标签和条件即可。
这里有趣的是什么？
- Helm混合了所有依赖项和应用程序的所有资源；
- 排序->安装/更新
在/图表中下载了所有依赖项之后（这些依赖项可能是100），Helm将获取并复制其中的所有资源。 渲染模板后，他将所有资源收集到一个位置，并按照自己的顺序进行排序。 您无法影响此顺序。 您必须自己确定程序包所依赖的内容，并且如果程序包具有传递依赖项，则需要将所有它们都包含在requirements.yaml的描述中。 必须牢记这一点。
包装经理
Helm安装应用程序和依赖项，您可以告诉Helm安装-它将安装软件包。 因此，这是一个程序包管理器。
同时，如果您有一个外部资源库，您可以在其中上传软件包，则可以不以本地文件夹的形式访问它，而可以简单地说：“从该资源库中获取此软件包，并使用相同的参数安装它。”
有很多软件包的开放存储库。 例如，您可以运行：helm install -f prod / values.yaml stable / wordpress
在稳定的存储库中，您将使用wordpress并自行安装。 您可以做所有事情：搜索/升级/删除。 事实证明，Helm是一名包裹经理。
但是有缺点：必须将所有
传递依赖项都包含在其中。 当可传递依赖项是独立的应用程序并且您想分别使用它们进行测试和开发时，这是一个大问题。
另一个缺点是
端到端配置 。 当您拥有数据库并且需要将其名称传输到所有软件包时，可以这样做，但是很难做到。
通常，您已经安装了一个小数据包并且可以正常工作。 世界是复杂的：应用程序取决于应用程序，而应用程序又取决于应用程序-您需要以某种方式对其进行巧妙配置。 赫尔姆不知道该如何支持这个问题，或者不知道有什么大的问题来支持它，有时您必须用手鼓跳舞很多才能使它起作用。 这很糟糕，因此图中的“程序包管理器”以红色突出显示。
组装与包装
Kubernetes中的应用程序“您不能只是获取并运行”。 您需要对其进行组装，即制作一个Docker映像，将其写入Docker注册表等。 虽然整个包装在Helm中的定义是。 我们确定程序包是什么，应该包含哪些功能和字段，签名和身份验证（您公司的安全系统将非常高兴）。 因此，一方面，似乎支持组装和打包，另一方面，未配置使用Docker映像的工作。
Helm不允许您在没有Docker映像的情况下运行应用程序。 同时，Helm没有配置用于组装和包装，也就是说，实际上，它不知道如何使用Docker映像。
这与为某些小型库进行升级安装而导致的情况相同，您将被发送到一个远程文件夹以运行编译器。
因此，我们说Helm不知道如何处理图像。
发展历程
下一个头痛是发展。 在开发中，我们希望快速方便地更改我们的代码。 在打孔卡上打孔的时间已经过去，结果是5天后获得的。 每个人都习惯在编辑器中用一个字母替换另一个字母，然后按编译，然后已经修改的程序就可以工作了。
事实证明，更改代码时，还需要执行许多其他操作：准备Docker文件； 运行Docker，以便构建映像； 把它推到某个地方 部署到Kubernetes集群 只有这样，您才能在Production上获得所需的内容，然后可以检查代码。
由于具有
破坏性的更新头盔升级，仍然带来不便。 您查看了一切工作原理，通过kubectl exec查看了容器内部，一切都很好。 此时，您开始更新，下载新映像，启动新资源，删除旧资源-您需要从头开始。
最大的痛苦是
大形象 。 大多数公司不使用小型应用程序。 通常，如果不是超级整体，则至少是一个小的整体。 随着时间的流逝，年轮增长，代码库增加，并且应用程序逐渐变得很大。 我曾多次遇到大于2 GB的Docker映像。 现在想象一下，您要在程序中的一个字节中进行更改，然后按一个按钮，然后将生成一个2 GB的Docker映像。 然后按下一步按钮，开始向服务器传输2 GB。
Docker允许您处理层，即 检查是否存在一层或另一层，并发送丢失的一层。 但是世界是如此，以至于大多数情况下它将是一个大层次。 虽然2 GB将用于服务器，而2 GB将用于具有Docker注册表的Kubernetes，但它们将以各种方式推出，直到您终于开始使用，您才能放心地喝茶。
Helm对大型Docker映像不提供任何帮助。 我认为这不应该，但是Helm开发人员比所有用户都了解更多，Steve Jobs对此很微笑。
发展的障碍也变成了红色。
环境自动化
最后一个方向-环境自动化-是一个有趣的领域。 在Docker（和相关模型）（以及相关的Kubernetes）领域问世之前，不可能说：“我想在此服务器或这些服务器上安装我的应用程序，以便有n个副本，50个依赖项，并且它们全部自动运行！” 也许有人会说，这是什么，但不是！
Kubernetes提供了此功能，并且以某种方式使用它是合乎逻辑的，例如说：“我正在这里部署新环境，我希望所有已经准备好应用程序的开发团队只需单击一个按钮，所有这些应用程序都将自动安装在新环境中” 。 从理论上讲，Helm应该对此有所帮助，以便可以从任何地方从外部数据源（S3，GitHub）进行配置。
建议在Helm中有一个特殊的按钮“终于做好我了！” -它会立即变好。 Kubernetes允许您执行此操作。
这特别方便，因为Kubernetes可以在任何地方运行，并且可以通过API运行。 通过在AWS或Google Cloud Engine中本地启动minikube，您可以立即使用Kubernetes，并在任何地方都可以使用Kubernetes：按下按钮，一切都很好。
似乎Helm自然可以允许您这样做。 因为否则，创建Helm的意义何在？
事实证明，不！
没有环境的自动化。
替代品
当Kubernetes有一个每个人都在使用的应用程序（现在实际上是解决方案的第一号），但是Helm遇到了上面讨论的问题时，社区不得不做出回应。 它开始创建替代工具和解决方案。
模板引擎
作为模板引擎，Helm似乎解决了所有问题，但社区仍然在创造替代方案。 让我提醒您模板引擎的问题：冗长和代码重用。
Ksonnet是一个很好的代表
。 它使用根本不同的数据和概念模型，并且不适用于Kubernetes资源，但具有自己的定义：
原型（参数）->组件->应用程序->环境。
有一些部分构成了原型。 通过外部数据对原型进行参数化，然后出现组件。 几个组件组成了可以运行的应用程序。 它在不同的环境中运行。 这里有一些到Kubernetes资源的明确链接，但可能没有直接的类比。
当然，Ksonnet的主要目标是
重用资源 。 他们希望确保一旦编写了代码，以后就可以在任何地方使用它，从而提高了开发速度。 如果您创建一个大型的外部库，则人们可以不断地将其资源发布到那里，并且整个社区都可以重用它们。
从理论上讲，这很方便。 .
, — , , . Ksonnet . Ksonnet Helm , , .. , , , .
, , , , . . , , , 0.1. , .
, —
KubePack , .
发展历程
:
- Helm;
- Helm;
- , ;
- , .
1. Helm
—
Draft . — , , . Draft — Heroku-style:
- (pack);
- , , Python «Hello, world!»;
- , Docker- ( );
- , , docker-registry, ;
- .
, , .
Helm, Draft Helm-, production ready, , Draft Helm-, . .
, Draft , Helm-. Draft — .
2. Helm
Helm Charts Kubernetes-, Helm Charts. :
Helm, . , , command line interface, Chart , git push .
, docker build, docker push kubectl rollout. , Helm, . .
3.
— . —
Metaparticle . , Python, Python , .
, , , sysconfig .. .
, , , - Kubernetes-.
: , ; , ; ..
, , , - , Python- Kubernetes-. ?
- , . . , , preinstall , - . Kubernetes-, Metaparticle, .
, , Kubernetes- . , , Metaparticle.
Metaparticle, Helm . , .
Telepresence/Ksync — . , , Helm-, . , - , - , , . , Production-, Production - .
Kubernetes , Docker, registry, Kubernetes. . , .
, , , Development . : , , , , — , , , Helm, , .
, .
4. Kubernetes Kubernetes
, Kubernetes Kubernetes. , Helm- , . , . , Docker-compose .
Docker-compose , , , , Docker, Kubernetes, Docker-compose, . , . , Docker. .
minikube , Docker-compose, . , , Docker-compose — 10 . , .
Docker-compose, , .
, — Helm, , , Helm - . CI/CD, , . — Helm, ? , , .
CI/CD, , docker', set-, , — .
CI/CD — , .
总结
5 Helm . , . , , . , , , .
Helm
, , Helm . , Helm , . , , , Helm.
, Road Map.
Kuberneres Helm community , ,
Helm V3 .
Tiller, cli
, . Helm :
- , (cmd ..).
- Tiller — , Kubernetes.
Tiller , Command Line Interface. : « Chart» — Helm , , Tiller', : «, - ! , Kubernetes-» — .
Helm, Tiller , . , , , , Tiller' — namespace . Tiller namespace, , . , .
V3 Tiller .
? , , Command Line Interface, , Kubernetes. , Kubernetes , Tiller. kubectl cli .
Tiller
. , Kubernetes Command Line Interface : , , , pre- post-. .
Lua- Chart
, — ,
lua- . Chart lua-, . . , . , , , .
Lua , , , - , , .
, , . , . Kubernetes, - , , , , . 让我们看看会发生什么。
Release- + secret
, ,
Release- , Release . , Release-, , , CRD, , .
namespace
Release- namespace, , -
Tiller' namespace — , .
CRD: controller
, CRD-controller Helm , push-. .
, .
,
Helm . , , , . , , . Helm — - Kubernetes. - , , .
,
CI/CD , .
Slack，我们有一个bot来报告何时有新版本通过master，并且所有测试均成功。您告诉他：“我想在Staging中安装它”，然后他安装，您说：“我想在那里进行测试！” -他开始了。很舒服对于开发，请使用Docker-compose或Telepresence。一项服务的多个版本
最后，我们将分析存在两个应用程序A和B的情况，这两个应用程序C取决于C，但是C的版本不同。 需要解决这个问题：
- 进行开发，因为实际上我们必须开发相同的东西，但是要开发两个不同的版本；
- 释放
- 对于名称冲突，因为在所有标准软件包管理器中，安装两个不同版本的软件包可能会导致问题。
实际上，Kubernetes可以为我们做出一切决定-您只需要正确使用它即可。
我建议您根据Helm创建3个图表，3个存储库（对于C存储库，这将是两个不同的分支）。 最有趣的是，针对v1和v2的所有安装都应在其内部包含有关版本或所创建的服务的信息。 幻灯片的一种解决方案，附录C； 发行名称表示这是服务A的版本v1； 服务名称还包含版本。 这是最简单的示例，您可以完全不同地进行操作。 但是最重要的是名称是唯一的。
第二个是传递依赖，在这里它更加复杂。
例如，您正在开发一个服务链，并且想要测试A。为此，您必须将A所依赖的所有依赖项（包括可传递的）传递给包的Helm定义。 但是同时，您也想开发B并对其进行测试-如何做到这一点是不可理解的，因为您还需要将所有可传递依赖项都放入其中。
因此，我建议您不要在每个程序包中添加所有依赖项，而应使其独立并不受外部控制。 这很不方便，但这是两个弊端中的较小者。
有用的链接
•
草稿•
GitKube•
头盔•
Ksonnet•电报贴纸：
一 ，
二•
Sig-Apps•
KubePack•
超微粒•
脚手架•
头盔v3•
Docker-compose•
Ksync•
网真•
无人机•
锻造发言人Ivan Glushkov在
GitHub上的个人资料，在
Twitter上 ，在
Habr上 。
好消息
在YouTube频道上，我们打开了RIT ++艺术节上有关DevOps的所有报告的视频 。 这是一个单独的播放列表 ，但是在完整的视频列表中，还有来自其他会议的许多有用信息。
更好的是，订阅该频道和新闻通讯 ，因为在来年我们将有很多发展空间 ：5月，RIT ++框架； 分别在春季，夏季和秋季（作为HighLoad ++的一部分）和单独的秋季DevOpsConf Russia进行 。