ruby-on-rails - Kubernetes：Rails 凭证还是 ConfigMap / Secret 方式？

Question

我将我的Rails 6应用程序部署在Kubernetes集群中，并考虑如何实现我的ENVvar。

我经常在主机上使用dotenv常规变量的 Rails 应用程序。ENV但看来，我现在可以省略它们并使用 Rails 凭据。但仅仅因为功能存在并不意味着它必须被使用或必须更好，对吧？

所以我不确定如何解决这个环境/安全难题：

接近 ConfigMap

• 在集群上创建一个ConfigMap以提供ENVvars
• 将所有 ENV 变量放入 ConfigMap
• 省略 Rails 凭据

方法凭证

• 为 KubernetesSecret或 ConfigMap 提供RAILS_MASTER_KEY
• 对我需要的所有变量使用 Rails 凭据
• （某些 ENV 变量是否必须像 ConfigMap 一样保留在 ConfigMap 中RAILS_ENV？）

我担心的缺点是，当我想更改 ENV var（修复拼写错误、缩放工作人员、切换数据库、凭据...）时，我必须通过很多步骤：进行 git push、构建和标记容器并等待部署。使用 ConfigMap 我只需kubectl apply更改即可。

我喜欢 Rails 的“约定优于配置”的方式，因此将 vars 分散到两种或三种不同的类型对 mem 来说似乎不太实用，但恐怕我必须这样做。

• 哪种方法更安全？

• 哪一个更“高效”或“开发人员友好”？

• 那么什么时候使用凭证呢？

• 2021 年的最佳做法是什么？

标签： ruby-on-railskubernetesruby-on-rails-6

Answer 1

您不会（仅）使用 ConfigMap，因为这不安全，但您可以使用 Secret 以与您描述的方式相同的方式保存所有环境变量。真的取决于您喜欢哪种工作流程。不管你怎么做，你在某个地方都有一些 Kubernetes Secrets 对象，只是它的范围问题。所以你 100% 需要有一个工作流程来处理这方面的事情。但是，如果您更喜欢通过 Rails 工作流程进行日常机密编辑，这样您就不需要过多地接触 Kubernetes 方面，那很酷。

就我个人而言，我认为接触秘密数据的系统越少越好，即使这意味着 Rails 开发人员需要学习一种新工具。