Condividi tramite

Procedure consigliate di Azure Operator Service Manager per i gruppi di configurazione

Questo articolo fornisce le linee guida di Azure Operator Service Manager per ottimizzare la progettazione degli schemi dei gruppi di configurazione (CGS) e il funzionamento dei valori del gruppo di configurazione (CGV). I fornitori di funzioni di rete (NF), gli operatori telco e i partner devono tenere presenti queste procedure durante l'onboarding e la distribuzione di NFS.

Panoramica dello schema JSON

Json Schema è uno standard IETF (Internet Engineering Task Force) che fornisce un formato per i dati JSON necessari per un'applicazione e come interagire con esso. L'applicazione di questi standard per un documento JSON consente di applicare la coerenza e la validità dei dati tra i dati JSON.

Dove viene usato lo schema JSON?

  • Azure Operator Service Manager usa la notazione dello schema JSON come meta schema all'interno schemaDefinition delle proprietà per l'oggetto CGS ConfigurationGroupSchemaPropertiesFormat .
  • Azure Operator Service Manager consente alla finestra di progettazione e all'editore di specificare lo schema JSON quando l'operatore deve fornire dati (valori JSON) durante la creazione di un'istanza di un servizio di rete del sito (SNS) o NF.
  • Azure Operator Service Manager consente di rendere facoltative o obbligatorie le proprietà del meta schema. Dove una proprietà è contrassegnata come required, deve essere specificata nei valori JSON.

Quali parole chiave JSON sono supportate?

Per il meta schema CGS, Azure Operator Service Manager implementa il supporto per le parole chiave standard JSON in base al tipo:

  • Per i tipi di oggetto, il supporto delle parole chiave è limitato dai criteri di filtro. Vedere l'oggetto nella guida di riferimento allo schema JSON.
  • Per i tipi stringa, il supporto delle parole chiave non è limitato o filtrato. Vedere la stringa nelle informazioni di riferimento sullo schema JSON.
  • Per i tipi numerici, il supporto delle parole chiave non è limitato o filtrato. Vedere Tipi numerici nella guida di riferimento allo schema JSON.

Campi facoltativi e obbligatori

Si dichiara una proprietà come facoltativa includendo una required parola chiave che omette la proprietà facoltativa. Se non si specifica la required parola chiave , tutte le proprietà vengono considerate obbligatorie. Per supportare un tipo di proprietà facoltativo, è necessario almeno un tipo di proprietà obbligatorio.

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

Valori predefiniti nello schema JSON

Per le proprietà facoltative, Azure Operator Service Manager implementa un metodo personalizzato per la gestione dei valori predefiniti. Quando un valore predefinito è definito nel meta schema CGS, Azure Operator Service Manager usa tale valore in cui la proprietà è mancante o non definita nei dati CGV di input. La logica del validator di Azure Operator Service Manager essenzialmente idrata il valore CGV con il valore predefinito quando l'operatore non fornisce un valore.

Come definire le impostazioni predefinite

Le impostazioni predefinite devono essere specificate all'interno di proprietà o all'interno di elementi di una matrice. Nell'esempio seguente vengono illustrate le impostazioni predefinite con tipi di proprietà integer e string:

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

Regole per la definizione delle impostazioni predefinite

Quando si convalida un valore predefinito, vengono applicate le regole seguenti. Prendere in considerazione queste regole quando si usano valori predefiniti per garantire i risultati previsti.

  • Un valore predefinito non deve essere applicato a una proprietà obbligatoria.
  • Un valore predefinito viene valutato nell'ordine dall'alto verso il basso da dove viene visualizzata per prima la parola chiave.
  • Se esiste un valore di proprietà nel CGV di input, vengono valutati solo gli elementi figlio di tali proprietà per le impostazioni predefinite.
  • Se un valore di proprietà non esiste nel CGV di input, viene valutato per un valore predefinito, insieme a qualsiasi elemento figlio.
  • Dove un valore della proprietà è il object tipo e non esiste né la relativa chiave nel CGV di input, non vengono valutate impostazioni predefinite per l'oggetto.

Considerazioni sul CGS

Nel corso del tempo, l'approccio consigliato ai migliori CGS di progettazione è cambiato.

approccio One-CGS

La raccomandazione originale era quella di usare solo un singolo CGS per l'intero NF. Questo approccio ha consolidato parametri specifici del sito, specifici dell'istanza e specifici della sicurezza in un singolo set di oggetti gruppo di configurazione. Questo approccio ha evitato più set di oggetti, ad eccezione dei rari casi in cui un servizio aveva più componenti. Molti partner hanno eseguito correttamente l'onboarding dei servizi usando questo approccio e rimangono supportati.

approccio Three-CGS

È ora consigliabile usare almeno tre CGS per l'intero NF, organizzando i parametri in questi set di gruppi di configurazione:

  • Parametri specifici del sito: esempi includono indirizzi IP e nomi univoci.
  • Parametri specifici dell'istanza: esempi includono timeout e livelli di debug.
  • Parametri specifici della sicurezza: esempi includono password e certificati. Con i parametri specifici della sicurezza, si usa Azure Key Vault per archiviare valori sicuri.

Progettazione di set di oggetti three-CGS

Quando si progettano oggetti three-CGS, prendere in considerazione le linee guida seguenti per il meta schema:

  • Scegliere i parametri da esporre.

    Una regola generale consiste nell'esporre tali parametri usando un'operazione diretta, ad esempio un livello di calcolo o un valore Helm. Usare questo approccio anziché un parametro su cui agisce un altro agente, ad esempio cloudinit i dati utente.

  • Ordinare i parametri in set specifici del sito, specifici dell'istanza e specifici della sicurezza.

  • Definire i parametri obbligatori e facoltativi. Per i parametri facoltativi, definire un valore predefinito ragionevole.

  • Assicurarsi che i parametri non si sovrappongano tra gli oggetti CGS.

Questo esempio mostra un payload CGS di esempio:

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

Questo esempio mostra un payload CGV corrispondente passato dall'operatore:

{
"qwe": 20
}

Questo esempio mostra il payload CGV risultante generato da Azure Operator Service Manager:

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

Considerazioni sul CGV

Prima di inviare la creazione della risorsa CGV, è possibile verificare che lo schema e i valori del file YAML o JSON sottostante corrispondano a quanto previsto dal CGS corrispondente. Per eseguire questa convalida, un'opzione consiste nell'usare l'estensione YAML per Visual Studio Code.

  • Last updated on