0

我们已经构建了一些微服务 (MS)，这些微服务 (MS) 已部署到我们公司的 K8s 集群中。

对于当前的部署，我们的任何一个 MS 都将构建为 Docker 映像，并使用以下步骤手动部署；它工作正常：

  • 创建配置图
  • 安装 Service.yaml
  • 安装 Deployment.yaml
  • 安装 Ingress.yaml

我现在正在研究 Helm v3 以简化和封装这些部署。我已经阅读了很多 Helm v3 文档，但我仍然没有找到一些简单问题的答案，我希望在吸收整个文档以及Go和SPRIG之前在这里得到答案，然后发现它不会t 符合我们的需要。

我们的 Spring MS 有 5 个单独的application.properties文件，它们特定于我们 5 个环境中的每一个。这些属性文件是简单的多行key=value格式，带有一些以#开头的注释。

# environment based values
key1=value1
key2=value2

使用helm create ，我在根目录中安装了一个名为./deploy的图表，它自动创建了./templates和values.yaml。

问题是我需要访问Chart 的./deploy目录之外的application.properties文件。

从 helm 开始，我想在configmap.yaml的 Data: 部分中引用这两个文件。

  • ./src/main/resource/dev/application.properties
  • ./src/main/resources/logback.xml

我想保留这些文件的当前格式，而不是将它们重写为JSON/YAML格式。

Helm v3 允许这样做吗？

在此处输入图像描述

4

1 回答 1

1

将其作为答案，因为评论中没有足够的空间！

检查我上面分享的 12 因素应用程序链接，特别是关于配置的部分......那里的解释不是很好，但背后的想法是构建一个容器并在任何环境中部署该容器而无需修改它加上能够更改配置而无需创建新版本（如果配置在容器中烘焙，则后者无法完成）。例如，这允许在不发布版本（或任何其他配置参数）的情况下更改数据库连接池大小。从安全的角度来看，这也很好，因为您可能不希望容器在具有生产配置（密码、api 密钥等）的较低环境（dev/test/whatnot）中运行。这种方法类似于一次构建，随处部署的持续交付原则。

我假设当您在本地运行应用程序时，您只需要访问一组配置，因此您可以将其保存在单独的文件中（例如 application.dev.properties），并在 helm 环境变量中拥有在环境之间更改的参数. 我知道您提到您不想这样做，但这在当今被认为是一种很好的做法（将来可能会被认为是其他方式......）。

我也认为务实很重要，如果在你的情况下你觉得不需要在容器之外进行配置，那么不要这样做，并且可能使用我给出的将命令行参数更改为的建议选择配置文件效果很好。同时，请记住 12 因素应用程序方法，以防您发现将来确实需要它。

于 2021-12-09T20:23:36.000 回答