通用舵图-带有应用程序名称的故障 [英] Generic Helm Chart - Troubles with the application name

问题描述

我需要将许多服务部署到Kubernetes.尽管这些值有所不同，但其中的85％的安装结构相同.我想为这85％使用通用舵图.

I have many services that I will need to deploy to Kubernetes. While the values vary, the installation structure is the same for 85% of them. I would like to use a generic helm chart for that 85%.

起初这看起来非常可行，我可以为每个图表传递一个自定义的 values.yaml 文件.

At first this looked to be very doable, I can just pass in a custom values.yaml file for each chart.

但是后来我意识到chart.yaml的内容不能被覆盖.具体来说，每次部署都需要覆盖 appVersion 和 name 属性.

But then I realized that the contents of chart.yaml cannot be overridden. Specifically, the appVersion and name properties need to be overridden for each deploy.

我真的需要为所有这些cookie切刀微服务维护一个单独的图表吗?或者是否可以制作通用图表并覆盖chart.yaml文件中的 appVersion 和 name 属性?

Do I really need to maintain a separate chart for all these cookie cutter microservices? Or is there a way to make a generic chart and override the appVersion and name properties in the chart.yaml file?

推荐答案

您可能确实需要创建图表"；每个服务都有一个单独的 Chart.yaml 文件，但是您可以将实际实现移到共享库图表中.

You probably do need to "create a chart" with a separate Chart.yaml file for each service, but you can move the actual implementation out to a shared library chart.

编写一个普通Helm图表，其中包含85％的常见部分.您可以根据需要测试部署，但是它可能会将大多数有趣的部分作为值.确保可以在某处访问此文件；这两个最简单的选项将在图表存储库中或作为monorepo的一部分.

Write a normal Helm chart that has the 85%-common parts. You can test deploying it if you'd like, but it will probably take most of the interesting parts as values. Make sure this is accessible somewhere; the two easiest options will be in a chart repository or as part of a monorepo.

现在，您的服务图表只需包含共享图表即可.使用Helm 3语法，看起来可能像这样:

Now your service chart just needs to include to include the shared chart. Using Helm 3 syntax, this could look like:

apiVersion: 2           # Helm 3 syntax with inline requirements
name: some-service
version: 0.0.1
appVersion: 20210317
dependencies:
  - name: application   # the shared chart
    version: '^1.0'
    repository: 'http://helm.example.com/charts'

在服务图表的 values.yaml 文件中，您需要确保在与 name:匹配的键下包括共享图设置(或者，如果共享图表已配置为 global:):

In the service chart's values.yaml file, you need to make sure to include to shared-chart settings under a key matching the name: (or, if the shared chart is so configured, global:):

application:
  redis:
    enabled: false

如果您依赖于 Chart.yaml 文件中的设置，则共享库图表将其自己的 Chart.yaml 视为 .Chart，这可能会影响生成的名称(如果您将内容命名为 {{.Release.Name}}-{{.Chart.Name}}-后缀，他们将看到库的.Chart.Name ，而不是服务的名称.

If you're depending on the settings in the Chart.yaml file, the shared-library chart will see its own Chart.yaml as .Chart, which can affect generated names (if you name things {{ .Release.Name }}-{{ .Chart.Name }}-suffix they will see the library's .Chart.Name, not the service's).

服务图表实际上并不需要它自己的 templates ，并且我相信如果 templates 目录不存在，该图表将正确安装.如果需要，可以在 templates 中添加更多的YAML.最困难的部分是抑制或修改库图中的内容，并且大多数情况下，这将需要支持服务可能需要的所有可能选项.(您可以将整个YAML文件包装在 {{if}} ... {{end}} 中，或在同一文件中包含多个YAML对象，并以 --- ，它们都可以帮助提供这种选择.)

The service chart doesn't actually need its own templates, and I believe the chart will install correctly if the templates directory isn't there. You can add more YAML in templates if you need to. The harder part is suppressing or modifying what's in the library chart, and mostly that will need to support every possible option a service might need. (You can wrap an entire YAML file in {{ if }}...{{ end }}, or include multiple YAML objects in the same file separated by ---, which can both help provide this kind of option.)

这篇关于通用舵图-带有应用程序名称的故障的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！