介绍

当前模块的执行中，直接传递了众多端口（ws、api、rpc、Prometheus）。 这种方法可能很麻烦，并且不符合 Kubernetes 的最佳实践，即 pod 通常只公开一个端口（80 或 443）。 该提案建议过渡到以配置文件为中心的方法，同时仍然保留在需要时直接传递端口的功能。

目标

  1. 简化Kubernetes部署的端口配置。
  2. 作为参数传递的端口值优先于配置文件值。
  3. 为希望使用传统的基于端口或基于环境变量的部署的用户提供灵活性。

建议的解决方案

1.配置文件

不会直接传递多个端口，而是引入一个配置文件。 默认情况下，该文件将包含预定义的端口。 可以使用 Kubernetes 的“ConfigMap”将该配置文件传递给模块。

配置文件示例：

ws_端口：3000
api_端口：3001
rpc_端口：3002
普罗米修斯端口：9090

2. 直接传递端口

虽然 Kubernetes 部署建议使用配置文件方式，但用户仍然可以直接传递端口。 如果端口作为参数传递，这些值将覆盖配置文件中的值。

3.基于环境变量的部署

对于喜欢使用环境变量进行源代码部署的用户，该模块可以设计为读取 Linux 系统上设置为环境变量的端口值。 如果设置了这些环境变量，它们将覆盖配置文件值，但优先级低于直接作为参数传递的端口值。

示例：如果WS_PORT环境变量设置为3005，它将覆盖配置文件中的ws_port值，除非ws_port作为参数传递。

实施步骤

  1. 更新模块以读取配置文件：修改模块以从提供的配置文件中读取端口值。
  2. 基于参数的覆盖：实现逻辑以覆盖配置文件端口值（如果它们作为参数提供）。
  3. 基于环境变量的覆盖：实现逻辑来检查环境变量并使用这些值（如果设置）。 确保直接参数值具有最高优先级。
  4. 文档：更新文档以提供有关设置端口值的三种方法的清晰说明：配置文件、直接参数和环境变量。
  5. 测试：在不同场景下彻底测试模块：
    • 仅使用配置文件。
    • 将端口作为参数传递。
    • 设置环境变量。

结论

采用配置文件方法可以简化部署过程，尤其是在 Kubernetes 环境中。 虽然配置文件优先考虑简单性，但直接传递端口或使用环境变量的灵活性确保了向后兼容性并满足各种用户偏好。