Partager via

Bonnes pratiques d’Azure Operator Service Manager pour les groupes de configuration

Cet article fournit des instructions Azure Operator Service Manager pour optimiser la conception des schémas de groupe de configuration (CGS) et le fonctionnement des valeurs de groupe de configuration (CGV). Les fournisseurs de fonction réseau (NF), les opérateurs de télécommunications et leurs partenaires doivent garder ces pratiques à l’esprit lors de l’intégration et du déploiement des fonctions réseau.

Vue d’ensemble du schéma JSON

Le schéma JSON est une norme IETF (Internet Engineering Task Force) qui fournit un format pour les données JSON requises pour une application et comment interagir avec elle. L’application de ces normes pour un document JSON vous permet d’appliquer la cohérence et la validité des données entre les données JSON.

Où le schéma JSON est-il utilisé ?

  • Azure Operator Service Manager utilise la notation de schéma JSON comme méta-schéma dans les schemaDefinition propriétés de l’objet CGS ConfigurationGroupSchemaPropertiesFormat .
  • Azure Operator Service Manager permet au concepteur et au serveur de publication de spécifier le schéma JSON lorsque l’opérateur doit fournir des données (valeurs JSON) lors de l’instanciation d’un service de réseau de site (SNS) ou de NF.
  • Azure Operator Service Manager permet aux propriétés de méta-schéma d’être facultatives ou requises. Lorsqu’une propriété est marquée required, elle doit être spécifiée dans les valeurs JSON.

Quels mots clés JSON sont pris en charge ?

Pour le méta-schéma CGS, Azure Operator Service Manager implémente la prise en charge des mots clés standard JSON sur une base de type par type :

  • Pour les types d’objets, la prise en charge des mots clés est limitée par la stratégie de filtre. Consultez l’objet dans la référence de schéma JSON.
  • Pour les types de chaînes de caractères, la prise en charge des mots clés n’est pas limitée ou filtrée. Consultez string dans la référence de schéma JSON.
  • Pour les types numériques, la prise en charge des mots clés n’est pas limitée ou filtrée. Consultez les types numériques dans la référence de schéma JSON.

Champs facultatifs et obligatoires

Vous déclarez une propriété comme facultative en incluant un required mot clé, qui omet la propriété facultative. Si vous ne spécifiez pas le required mot clé, toutes les propriétés sont considérées comme obligatoires. Vous avez besoin d’au moins un type de propriété requis pour prendre en charge un type de propriété facultatif.

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

Valeurs par défaut dans le schéma JSON

Pour les propriétés facultatives, Azure Operator Service Manager implémente une méthode personnalisée de gestion des valeurs par défaut. Lorsqu’une valeur par défaut est définie dans le méta-schéma CGS, Azure Operator Service Manager utilise cette valeur où la propriété est manquante ou non définie dans les données CGV d’entrée. La logique de validateur Azure Operator Service Manager hydrate essentiellement la valeur CGV avec la valeur par défaut lorsque l’opérateur ne fournit pas de valeur.

Comment définir les valeurs par défaut

Les valeurs par défaut doivent être spécifiées à l’intérieur des propriétés ou dans les éléments d’un tableau. L’exemple suivant illustre les valeurs par défaut avec des types de propriétés entiers et de chaînes :

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

Règles de définition des valeurs par défaut

Les règles suivantes sont appliquées lorsque vous validez une valeur par défaut. Tenez compte de ces règles lorsque vous utilisez des valeurs par défaut pour garantir les résultats attendus.

  • Une valeur par défaut ne doit pas être appliquée à une propriété requise.
  • Une valeur par défaut est évaluée dans l’ordre supérieur à partir duquel le mot clé apparaît en premier.
  • Quand une valeur de propriété existe dans la CGV d’entrée, seuls les enfants de ces propriétés sont évalués pour des valeurs par défaut.
  • Quand une valeur de propriété n’existe pas dans la CGV d’entrée, elle est évaluée pour une valeur par défaut, ainsi que les éventuels enfants.
  • Lorsqu’une valeur de propriété est le object type, et ni sa clé n’existe dans la CGV d’entrée, aucune valeur par défaut pour l’objet n’est évaluée.

Considérations relatives à CGS

Au fil du temps, l’approche recommandée pour la conception des CGS a changé.

approche "One-CGS"

La recommandation initiale était d’utiliser un seul CGS pour l’ensemble de la NF. Cette approche a consolidé des paramètres spécifiques au site, spécifiques à l’instance et spécifiques à la sécurité dans un ensemble unique d’objets de groupe de configuration. Cette approche a évité plusieurs jeux d’objets, à l’exception des rares cas où un service avait plusieurs composants. De nombreux partenaires ont intégré avec succès des services à l’aide de cette approche, et cette approche reste soutenue.

Approche à trois CGS

Nous vous recommandons maintenant d’utiliser au moins trois CGS pour l’ensemble de la FN, en organisant des paramètres dans ces ensembles de groupes de configuration :

  • Paramètres spécifiques au site : les exemples incluent des adresses IP et des noms uniques.
  • Paramètres spécifiques à l’instance : les exemples incluent des délais d’expiration et des niveaux de débogage.
  • Paramètres spécifiques à la sécurité : des exemples incluent des mots de passe et des certificats. Avec des paramètres spécifiques à la sécurité, vous utilisez Azure Key Vault pour stocker des valeurs sécurisées.

Conception des ensembles d’objets à trois CGS

Tenez compte des instructions de méta-schéma suivantes lorsque vous concevez trois objets CGS :

  • Choisissez les paramètres à exposer.

    Une règle de pouce consiste à exposer ces paramètres à l’aide d’une opération directe, telle qu’un niveau de calcul ou une valeur Helm. Utilisez cette approche plutôt qu’un paramètre sur lequel un autre agent agit, comme cloudinit les données utilisateur.

  • Triez les paramètres en ensembles spécifiques au site, à l’instance et à la sécurité.

  • Définissez les paramètres obligatoires et facultatifs. Pour les paramètres facultatifs, définissez une valeur par défaut raisonnable.

  • Vérifiez que les paramètres ne se chevauchent pas entre les objets CGS.

Cet exemple montre un exemple de charge utile CGS :

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

Cet exemple montre une charge utile CGV correspondante que l’opérateur transmet :

{
"qwe": 20
}

Cet exemple montre la charge utile CGV résultante générée par Azure Operator Service Manager :

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

Considérations relatives à la CGV

Avant d’envoyer la création de la ressource CGV, vous pouvez vérifier que le schéma et les valeurs du fichier YAML ou JSON sous-jacent correspondent à ce que le CGS correspondant attend. Pour effectuer cette validation, une option consiste à utiliser l’extension YAML pour Visual Studio Code.

  • Last updated on