我们有一个在GKE Kubernetes上运行的应用程序,它希望auth url(用户将通过他的浏览器重定向)作为环境变量传递 .
我们在每个环境中使用不同的命名空间
所以我们当前的pod配置看起来像这样:
env:
- name: ENV
valueFrom:
fieldRef:
fieldPath: metadata.namespace
- name: AUTH_URL
value: https://auth.$(ENV).example.org
所有工作都令人惊讶,我们可以拥有任意数量的动态环境,我们只需要应用-f config.yaml,它可以完美地工作而无需更改单个配置文件和任何第三方脚本 .
现在 生产环境 我们想要使用不同的域,所以一般模式 https://auth.$(ENV).example.org
不再起作用了 .
我们有什么选择?
-
由于配置在git repo中,因此为
prod
环境创建一个单独的分支 -
有一个默认的ConfigMap和一个特定的prod环境,并通过一些脚本运行它(如果存在
prod-config.yaml
然后使用它,否则使用config.yaml
) - 但是这种方法我们不能再直接使用kubectl了 -
将此配置移至应用程序级别,并为
prod
env设置单独的配置文件 - 但这种情况与12factor应用程序相反? -
其他......?
2 回答
这似乎是一个使用helm的理想机会!
它很容易上手,只需将分蘖安装到您的群集中即可 .
Helm使您能够创建可以安装到群集中的“图表”(类似于包) . 你可以很容易地模拟这些 . 作为一个例子,你可能有config.yaml看起来像这样:
然后,在掌舵图表中,您有一个包含url默认值的
values.yaml
,例如:您可以将
--values
选项与helm一起使用来指定每个环境values.yaml
文件,甚至可以使用helm上的--set
标志在使用helm install
时覆盖它们 .请查看文档here,了解有关值和模板如何在helm中工作的信息 . 它似乎非常适合您的用例
jaxxstorms的回答很有帮助,我只想添加对你提出的选项意味着什么:
我不建议在GIT中使用单独的分支,因为分支的目的是允许同时编辑相同的数据,但你拥有的是不同的数据(集群的不同配置) .
使用Helm可以更优雅地解决这个问题 . 您可以使用helm为不同的环境生成不同的文件,而不是脚本 . 你可以使用kubectl(使用最终文件,我也会检查GIT顺便说一句 . ) .
这是一个意见问题但我总体上建议按应用程序和技术拆分部署 . 例如,当我部署一个运行3个不同应用程序AB和C的集群,并且每个应用程序需要Nginx,CockroachDB和Go应用程序服务器时,我将拥有9个配置文件,这使我可以单独部署或更新每个技术 . 应用程序上下文 . 这对于允许在诸如Jenkins之类的CI服务器中进行单独的部署操作并且遵循一般的关注点分离非常重要 .
请参阅jaxxstorms关于Helm的回答 .