Compartir a través de

Procedimientos recomendados de Azure Operator Service Manager para grupos de configuración

En este artículo se proporcionan instrucciones de Azure Operator Service Manager para optimizar el diseño de esquemas de grupo de configuración (CGS) y el funcionamiento de los valores del grupo de configuración (CGV). Los proveedores de funciones de red (NF), los operadores de telecomunicaciones y sus asociados deben tener en cuenta estas prácticas al incorporar e implementar NFs.

Información general sobre el esquema JSON

El esquema JSON es un estándar del Grupo de tareas de ingeniería de Internet (IETF) que proporciona un formato para qué datos JSON se requieren para una aplicación y cómo interactuar con él. Aplicar estos estándares para un documento JSON le ayuda a aplicar la coherencia y la validez de los datos en los datos JSON.

¿Dónde se usa el esquema JSON?

  • Azure Operator Service Manager usa la notación de esquema JSON como un metaesquema dentro de schemaDefinition las propiedades del objeto CGS ConfigurationGroupSchemaPropertiesFormat .
  • Azure Operator Service Manager permite al diseñador y al publicador especificar el esquema JSON cuando el operador debe proporcionar datos (valores JSON) durante la creación de instancias de un servicio de red de sitio (SNS) o NF.
  • Azure Operator Service Manager permite que las propiedades del meta esquema sean opcionales o necesarias. Donde una propiedad está marcada requiredcomo , debe especificarse en los valores JSON.

¿Qué palabras clave JSON se admiten?

Para el meta-esquema de CGS, Azure Operator Service Manager implementa compatibilidad con palabras clave estándar JSON de tipo por tipo:

  • En el caso de los tipos de objeto, la compatibilidad con palabras clave está limitada por la directiva de filtro. Consulte el objeto en la referencia de esquema JSON.
  • En el caso de los tipos de cadena, la compatibilidad con palabras clave no está limitada ni filtrada. Consulte string en la referencia de esquema JSON.
  • En el caso de los tipos numéricos, la compatibilidad con palabras clave no está limitada ni filtrada. Consulte Tipos numéricos en la referencia de esquema JSON.

Campos opcionales y obligatorios

Se declara una propiedad como opcional mediante la inclusión de una required palabra clave, que omite la propiedad opcional. Si no especifica la required palabra clave , todas las propiedades se consideran necesarias. Necesita al menos un tipo de propiedad obligatorio para admitir un tipo de propiedad opcional.

{
"type": "object",
"properties": {
  "abc": {
    "type": "integer",
     "default": 30
  },
  "xyz": {
    "type": "string",
    "default": "abc123"
  }
 }
"required":  ["abc"]
}

Valores predeterminados en el esquema JSON

Para las propiedades opcionales, Azure Operator Service Manager implementa un método personalizado de control de valores predeterminados. Cuando se define un valor predeterminado en el meta esquema de CGS, Azure Operator Service Manager usa ese valor donde falta la propiedad o no está definida en los datos de CGV de entrada. La lógica del validador de Azure Operator Service Manager hidrata básicamente el valor de CGV con el valor predeterminado cuando el operador no proporciona un valor.

Definición de valores predeterminados

Los valores predeterminados deben especificarse dentro de propiedades o dentro de elementos de una matriz. En el ejemplo siguiente se muestran los valores predeterminados con tipos de propiedad integer y string:

{
"type": "object",
"properties": {
  "abc": {
    "type": "integer",
     "default": 30
  },
  "xyz": {
    "type": "string",
    "default": "abc123"
  }
 }
}

Reglas para definir valores predeterminados

Las reglas siguientes se aplican al validar un valor predeterminado. Tenga en cuenta estas reglas cuando use valores predeterminados para garantizar los resultados esperados.

  • No se debe aplicar un valor predeterminado a una propiedad necesaria.
  • Un valor predeterminado se evalúa en orden de arriba abajo desde donde aparece la palabra clave en primer lugar.
  • Cuando existe un valor de propiedad en el CGV de entrada, solo se evalúan los elementos secundarios de esas propiedades para los valores predeterminados.
  • Cuando un valor de propiedad no existe en el CGV de entrada, se evalúa para un valor predeterminado, junto con los elementos secundarios.
  • Cuando un valor de propiedad es el object tipo y no existe ni su clave en el CGV de entrada, no se evalúa ningún valor predeterminado para el objeto.

Consideraciones sobre CGS

Con el tiempo, el enfoque recomendado para mejorar el diseño de los CGS ha cambiado.

enfoque de One-CGS

La recomendación original era usar solo un solo CGS para toda la NF. Este enfoque consolida los parámetros específicos del sitio, específicos de instancia y específicos de seguridad en un único conjunto de objetos de grupo de configuración. Este enfoque ha evitado varios conjuntos de objetos, excepto en casos poco frecuentes en los que un servicio tenía varios componentes. Muchos asociados incorporaron correctamente los servicios mediante este enfoque y sigue siendo compatible.

enfoque de Three-CGS

Ahora se recomienda usar al menos tres CGS para todo el NF mediante la organización de parámetros en estos conjuntos de grupos de configuración:

  • Parámetros específicos del sitio: algunos ejemplos incluyen direcciones IP y nombres únicos.
  • Parámetros específicos de la instancia: algunos ejemplos incluyen tiempos de espera y niveles de depuración.
  • Parámetros específicos de la seguridad: algunos ejemplos incluyen contraseñas y certificados. Con parámetros específicos de la seguridad, se usa Azure Key Vault para almacenar valores seguros.

Diseño de conjuntos de objetos de tres CGS

Tenga en cuenta las siguientes directrices de meta-esquema al diseñar objetos de tres CGS:

  • Elija los parámetros que se van a exponer.

    Una regla general consiste en exponer esos parámetros mediante una operación directa, como un nivel de proceso o un valor de Helm. Use este enfoque en lugar de un parámetro en el que actúa otro agente, como cloudinit los datos de usuario.

  • Ordene los parámetros en conjuntos específicos de la instancia y específicos de la seguridad específicos del sitio.

  • Defina los parámetros obligatorios frente a los opcionales. Para los parámetros opcionales, defina un valor predeterminado razonable.

  • Asegúrese de que los parámetros no se superpongan entre objetos CGS.

En este ejemplo se muestra una carga de CGS de ejemplo:

{ 
  "type": "object", 
  "properties": {
    "abc": { 
      "type": "integer", 
      "default": 30
    }, 
    "xyz": { 
      "type": "integer", 
      "default": 40
    },
    "qwe": {
      "type": "integer"
    }
   }
   "required": "qwe"
}

En este ejemplo se muestra una carga de CGV correspondiente que el operador pasa:

{
"qwe": 20
}

En este ejemplo se muestra la carga de CGV resultante que genera Azure Operator Service Manager:

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

Consideraciones sobre CGV

Antes de enviar la creación de recursos del CGV, puede validar que el esquema y los valores del archivo YAML o JSON subyacente coincidan con lo que espera el CGS correspondiente. Para realizar esa validación, una opción es usar la extensión YAML para Visual Studio Code.

  • Last updated on