如何使用 Kustomize 创建带有 .env 的 configMap

Question

我有一个 NextJS 应用程序，需要安装 .env 文件。我通常通过提供 configMap 来做到这一点：

kind: ConfigMap
apiVersion: v1
metadata:
  name: frontend-configmap
  namespace: default
data:
  .env: |-
    NEXT_PUBLIC_API_URL=http://my.domain.com
    API_URL=http://my.domain.com

但如何使用 Kustomize 做到这一点呢？

我尝试使用envs，但如何获取里面的值？

configMapGenerator:
  - name: frontend-configmap
    envs:
      - .env

先感谢您

Answer 1

您需要.env先创建文件。理想情况下，即使创建配置映射也应该基于现有文件（下面是kustomize和 的示例）kubectl --from-file的示例）。

\n

然后有两个选项如何创建配置映射：

\n

\n
• 创造.env包含环境变量的文件（这是您的示例配置映射）
\n
• 使用环境变量创建一个配置映射.env（每个变量都是一个单独的键）
\n

\n

测试结构：

\n

$ tree -a\n.\n\xe2\x94\x9c\xe2\x94\x80\xe2\x94\x80 .env\n\xe2\x94\x94\xe2\x94\x80\xe2\x94\x80 kustomization.yaml\n\n\n$ cat .env # same as your test data\n\nNEXT_PUBLIC_API_URL=http://my.domain.com\nAPI_URL=http://my.domain.com\n

\n\n

配置映射与.env其中包含包含 envvars 的文件：

\n

kustomization.yaml还有一个附加选项：

\n

$ cat kustomization.yaml \n\nconfigMapGenerator:\n  - name: frontend-configmap\n    files: # using files here as we want to create a whole file\n      - .env\ngeneratorOptions:\n  disableNameSuffixHash: true # use a static name\n

\n

disableNameSuffixHash- 禁止将内容哈希后缀附加到生成的资源的名称中，请参阅生成器选项。

\n

剩下的就是运行它：

\n

$ kustomize build .\n\napiVersion: v1\ndata:\n  .env: | # you can see it\'s a file with context within\n    NEXT_PUBLIC_API_URL=http://my.domain.com\n    API_URL=http://my.domain.com\nkind: ConfigMap\nmetadata:\n  name: frontend-configmap\n

\n

通过使用选项运行可以达到相同的结果--from-file：

\n

$ kubectl create cm test-configmap --from-file=.env --dry-run=client -o yaml\n\napiVersion: v1\ndata:\n  .env: |\n    NEXT_PUBLIC_API_URL=http://my.domain.com\n    API_URL=http://my.domain.com\nkind: ConfigMap\nmetadata:\n  creationTimestamp: null\n  name: test-configmap\n

\n\n

configmap 以 envvars 作为键：

\n

$ cat kustomization.yaml \n\nconfigMapGenerator:\n  - name: frontend-configmap\n    envs: # now using envs to create a configmap with envvars as keys inside\n      - .env\ngeneratorOptions:\n  disableNameSuffixHash: true # use a static name\n

\n

运行它来查看输出：

\n

$ kustomize build .\n\napiVersion: v1\ndata: # you can see there\'s no file and keys are created directly\n  API_URL: http://my.domain.com\n  NEXT_PUBLIC_API_URL: http://my.domain.com\nkind: ConfigMap\nmetadata:\n  name: frontend-configmap\n

\n

kubectl与和选项相同--from-env-file：

\n

$ kubectl create cm test-configmap --from-env-file=.env --dry-run=client -o yaml\n\napiVersion: v1\ndata:\n  API_URL: http://my.domain.com\n  NEXT_PUBLIC_API_URL: http://my.domain.com\nkind: ConfigMap\nmetadata:\n  creationTimestamp: null\n  name: test-configmap\n

\n\n

更多细节：

\n

\n
• 配置映射生成器
\n

\n\n

编辑 - 使用已经存在的 configmap.yaml

\n

如果configmap已经存在，那么可以从kustomization.yaml（如评论中提到的，kustomize是一个模板引擎）引用它，并且仅将其与直接引用一起使用而不进行任何转换并没有真正意义。这是示例之一为什么你需要使用kustomize）。

\n

$ tree\n.\n\xe2\x94\x9c\xe2\x94\x80\xe2\x94\x80 cm.yaml\n\xe2\x94\x94\xe2\x94\x80\xe2\x94\x80 kustomization.yaml\n

\n

cm.yaml具有与问题完全相同的配置。

\n

$ cat kustomization.yaml\n \nresources:\n- cm.yaml\nnamePrefix: test- # used namePrefix for demo purpose (you can omit it as well)\n

\n

configmap构建这个并与.env里面的文件相同：

\n

$ kustomize build .\n\napiVersion: v1\ndata:\n  .env: |-\n    NEXT_PUBLIC_API_URL=http://my.domain.com\n    API_URL=http://my.domain.com\nkind: ConfigMap\nmetadata:\n  name: test-frontend-configmap # name with prefix as it was setup for demo\n  namespace: default\n

\n