已考虑的替代方案

本段描述了一些可能的替代方案，以及它们与当前方法的不同之处。

Docker Compose

  • 此设置将更加简洁，因为它不需要虚拟机进行设置。

  • Docker Compose 在运行真正的 Docker 时支持 CPU 限制，但不支持 Podman。

  • Docker Compose 不支持模板，因此使用不同 CPU 限制来定制不同的设置很困难，而 Helm 在 minikube 中可以使用这种模板。对于 Grafana 堆栈，有一个很好的可定制 Helm 模板，而 Docker Compose 则没有这种方法。

决定：使用 minikube，同时保留 Docker Compose 作为临时的测试设置，并为社区提供一个简单的解决方案。(由 Alexander Schwartz 在 2022 年 5 月提出)

范围：Docker Compose 将仅包含 Keycloak 和数据库，不包含监控堆栈，也不强制执行任何 CPU 限制。

OpenShift Local（以前称为 CodeReady Containers）

  • 它将拥有与 Minishift 相同的功能，并且已经安装了操作员支持。如果开发人员注册了 Red Hat 帐户，它可以自动设置，并且会获得拉取密钥。

  • OpenShift 风格的监控可以通过标准监控功能/操作员安装，也可以通过额外的扩展安装。另一方面，helm 图表似乎比 OpenShift 操作员更具可配置性。

  • Keycloak Java 操作员团队正在使用 minikube 进行测试，并且操作员中心功能可以通过 shell 脚本在几分钟内安装。这将允许在 Minishift 上运行 Keycloak 操作员，以用于此设置。

  • OpenShift Local 将始终使用 VM，并且在 CPU 和 RAM 使用方面将更加重量级。为社区贡献者安装 OpenShift 是一个更大的步骤。从长远来看，维护 OpenShift 和 minikube 的设置可能会有更高的维护成本。从头开始安装 OpenShift Local 比安装 Minishift 花费的时间更长，因为 OpenShift 附带了更多需要下载和启动其容器的操作员，并且将等待依赖项。

  • minikube 有一种机制，可以以轻量级的方式在本地构建容器，并将它们提供给运行的 minikube 实例。OpenShift 的替代方案是 二进制构建。

决定：目前使用 minikube。稍后在需要时向 Helm 脚本添加额外的参数化，以便在 OpenShift 上部署（无论是 Local 还是常规）。在进行第一次 OpenShift 部署之后，重新评估此决定。(由 Alexander Schwartz 在 2022 年 5 月提出)