次の方法で共有

構成グループに関する Azure Operator Service Manager のベスト プラクティス

この記事では、NF ベンダー、電話会社、およびそのパートナーが従って、構成グループ スキームの設計と構成グループ値の操作を最適化できるガイドラインを提供します。 これらのプラクティスは、NF をオンボードしてデプロイする際に念頭に置いておく必要があります。

コンフィギュレーション グループ スキーマに関する考慮事項

NF 全体の CGS は常に 1 つから開始することをお勧めします。 サイト固有またはインスタンス固有のパラメーターがある場合でも、それらを 1 つの CGS に保持することをお勧めします。 複数のコンポーネント (まれに NF、より一般的にはインフラストラクチャ) または複数の NF 間で共有される構成がある場合は、複数の CGS に分割することをお勧めします。 CGS の数によって、CGV の数が定義されます。

シナリオ

  • FluentD、Kibana、Splunk (一般的なサードパーティ コンポーネント) は、NSD 内のすべての NF に対して常にデプロイされます。 これらのコンポーネントを 1 つの NFDG にグループ化することをお勧めします。
  • NSD には複数の NF があり、すべてがいくつかの構成 (展開場所、パブリッシャー名、およびいくつかのグラフ構成) を共有します。

このシナリオでは、1 つのグローバル CGS を使用して、一般的な NF およびサードパーティ コンポーネントの構成を公開することをお勧めします。 NF 固有の CGS は必要に応じて定義できます。

公開するパラメーターを選択する

  • CGS には、NF (day 0/N 構成) または共有コンポーネントによって使用されるパラメーターのみを含める必要があります。
  • めったに構成されないパラメーターには、既定値が定義されている必要があります。
  • 複数の CGS を使用する場合は、パラメーター間の重複をほとんどまたはまったくなくすことをお勧めします。 重複が必要な場合は、パラメーター名が CGS 間で明確に区別できることを確認します。
  • CGS では、API (Azure Operator Nexus、Azure Operator Service Manager) を使用して定義できる内容を考慮する必要があります。 たとえば、CloudInit ファイルを使用してこれらの構成値を定義するのとは対照的です。
  • 不明な場合は、パラメーターを公開し、CGS で適切な既定値を指定することをお勧めします。 次の例は、サンプルの CGS と対応する CGV ペイロードを示しています。
  • 1 つのユーザー割り当てマネージド ID がすべての 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 Operator Service Manager によって生成された CGV ペイロード:

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

コンフィギュレーション グループの値に関する考慮事項

CGV リソースの作成を送信する前に、基になる YAML または JSON ファイルのスキーマと値が、対応する CGS で想定されているものと一致していることを検証できます。 これを実行するには、Visual Studio Code の YAML 拡張機能を使用する方法があります。