Azure 运营商服务管理器中的配置组最佳实践

本文提供了 NF 供应商、电信运营商及其合作伙伴可以遵循的准则来优化配置组方案和配置组值的运行。 加入和部署 NF 时，请记住这些做法。

配置组架构注意事项

建议始终从整个 NF 的单个 CGS 开始。 如果存在特定于站点的参数或特定于实例的参数，我们仍建议将它们保留在单个 CGS 中。 当有多个组件（很少是 NF，更常见的是基础结构）或跨多个 NF 共享的配置时，我们建议拆分为多个 CGS。 CGS 的数量定义了 CGV 的数量。

情景

• FluentD、Kibana 和 Splunk（常见的第三方组件）始终会为 NSD 中的所有 NF 部署。 建议将这些组件分组到单个 NFDG 中。
• NSD 有多个 NF，这些 NF 共享几个配置（部署位置、发布者名称和几个图表配置）。

在此方案中，我们建议使用单个全局 CGS 公开常见的 NF 和第三方组件配置。 可以根据需要定义特定于 NF 的 CGS。

选择要公开的参数

• CGS 应仅具有 NF（第 0 天/N 配置）或共享组件使用的参数。
• 很少配置的参数应定义默认值。
• 如果使用多个 CGS，建议在参数之间设置很少的重叠或零重叠。 如果需要重叠，请确保参数名称可以清楚地区分 CGS。
• 可通过 API 定义的内容（Azure 运营商关系、Azure 运营商服务管理器）应考虑用于 CGS。 而不是，例如，通过 CloudInit 文件定义这些配置值。
• 不确定时，一个好的起点是公开参数，并在 CGS 中指定合理的默认值。 以下示例演示了示例 CGS 和相应的 CGV 有效负载。
• 应在所有 NF ARM 模板中使用单个用户分配的托管标识，并且应通过 CGS 公开它。

CGS 有效负载：

{ 
  "type": "object", 
  "properties": { 
    "abc": { 
    "type": "integer", 
    "default": 30
    }, 
    "xyz": { 
    "type": "integer", 
    "default": 40
    },
    "qwe": {
    "type": "integer" //doesn't have defaults
    }
  }
  "required": "qwe"
}

运营商传递的相应 CGV 有效负载：

{
"qwe": 20
}

Azure 运营商服务管理器生成的 CGV 有效负载：

{
"abc": 30,
"xyz": 40,
"qwe": 20
}

配置组值注意事项

在提交 CGV 资源创建之前，可以验证基础 YAML 或 JSON 文件的架构和值是否符合相应的 CGS 预期。 为此，一个选项是使用适用于 Visual Studio Code 的 YAML 扩展。