安全なアップグレードプラクティスの概要

2025-06-23

この記事では、Azure Operator Service Manager (AOSM) の安全なアップグレードプラクティス (SUP) について説明します。この機能セットにより、Azure Operator Nexus でホストされている複雑なコンテナーネットワーク関数 (CNF) へのアップグレードが可能になります。通常、これらのアップグレードでは、パートナーの In Service Software Upgrade (ISSU) の方法と要件がサポートされます。この記事では基本的な概念を紹介しますが、高度な SUP の機能を拡張するその他の記事を探してください。

安全なアップグレードの概要

AOSM によってサポートされる特定のネットワークサービスは、1 対多の CMF で構成され、時間の経過と伴ってソフトウェアや構成の変更を必要とするコンポーネントを含みます。これらのコンポーネントレベルを変更するには、1 対多の Helm 操作を実行し、各ネットワーク関数アプリケーション (nfApp) を特定の順序でアップグレードし、ネットワークサービスに最も影響を与えない方法で実行する必要があります。 AOSM の安全なアップグレードプラクティスでは、アップグレードプロセスとワークフローの要件を処理するために、次の高度な機能が適用されます。

SNS reput サポート - ネットワーク機能設計バージョン (NFDV) のすべての nfApp で Helm アップグレード操作を実行します。
Nexus プラットフォーム - Nexus プラットフォームターゲットでの SNS reput 操作をサポートします。
操作タイムアウト - nfApp 操作ごとに操作タイムアウトを設定する機能。
同期操作 - 一度に 1 つのシリアル nfApp 操作を実行する機能。
アップグレード順序の制御 - インストールとアップグレードのために異なる nfApp シーケンスを定義します。
失敗時に一時停止 - nfApp 操作の失敗後に既定の動作が一時停止します。
失敗時のロールバック - オプションの動作。失敗した nfApp の前に nfApps でロールバックが完了しました。
単一チャートテスト検証 - 作成または更新後に Helm テスト操作を実行します。
変更がない場合は nfApp をスキップする - 変更の結果がない nfApps の処理をスキップします。
イメージの事前読み込み - エッジリポジトリにイメージを事前に読み込む機能。

安全なアップグレードのアプローチ

既存の AOSM サイトネットワークサービス (SNS) を更新するために、オペレーターは、展開された SNS リソースに対してリプット要求を実行します。 SNS に複数の nfApps を持つ CNF が含まれている場合、要求はネットワーク関数定義バージョン (NFDV) で定義されているすべての nfApps にわたってファンアウトされます。既定では、表示される順序で、またはupdateDependsOn パラメーターによって定義された順序でオプションとして表示されます。

nfApp ごとに、reput 要求では、helm チャートのバージョンの増加、helm 値の追加/削除、nfApps の追加/削除など、さまざまな変更がサポートされます。タイムアウトは、既知の許容されるランタイムに基づいて nfApp ごとに設定できますが、nfApps は順番に 1 つずつしか処理できません。 reput 更新では、次の処理ロジックが実装されます。

nfApps は、 updateDependsOn 順序に従うか、表示される順番で処理されます。
nfApps はパラメーターがapplicationEnabled無効に設定されている場合、スキップされます。
パラメーター skipUpgrade が enabled に設定されている nfApps は、変更が検出されなかった場合はスキップされます。
古い NFDV と新しい NFDV の間で一般的な nfApps は、 helm upgradeを使用してアップグレードされます。
新しい NFDV にのみ存在する nfApps は、 helm installを使用してインストールされます。
展開された nfApps は、新しい NFDV では参照されませんが、 helm deleteを使用して削除されます。

結果を保証するために、nfApp テストは helm メソッド、helm pre または post hook によってトリガーされるテスト、またはスタンドアロンの Helm テストフックを使用してサポートされます。フック前またはフック後の障害の場合は、 atomic パラメーターが使用されます。 atomic/true の場合、失敗したチャートはロールバックされます。 atomic/false の場合、ロールバックは実行されません。スタンドアロンの Helm テストフックエラーの場合、 rollbackOnTestFailure はアトミックと同様のロジックに従って受け入れられます。スタンドアロン Helm テストの詳細については、記事「インストールまたはアップグレード後にテストを実行する」を参照してください

nfApp 操作エラーが発生し、失敗した nfApp が atomic または rollbackOnTestFailure パラメーターによって処理された後、オペレーターは失敗した nfApp の前に変更された nfApp を処理する方法の動作を制御できます。障害時の一時停止では、オペレーターは失敗した nfApp に対処した後に AOSM を強制的に中断し、混在したバージョン環境を維持できます。ロールバックが失敗した場合、オペレーターは AOSM に以前の nfApp を強制的にロールバックし、元の環境スナップショットを復元できます。アップグレード失敗の動作の制御の詳細については、次の記事を参照してください。アップグレードエラーの動作を制御する

サービス内アップグレードに関する考慮事項

Azure Operator Service Manager は通常、サービスのアップグレードをサポートします。これは、実行中のサービスを中断することなく展開バージョンを進行するアップグレード方法です。 ISSU 操作中に AOSM の適切な動作を確保するために、ネットワーク関数の所有者に関するいくつかの考慮事項が必要です。

AOSM が複数の nfApp の順序付きセットに対してアップグレードを実行するとき、AOSM はまず新しい nfApp をすべてアップグレードまたは作成してから、古い nfApp をすべて削除します。この方法により、すべての新しい nfApps の準備が整うまでサービスに影響が及ばないようにしますが、古い nfApp と新しい nfApp の両方の一時的なホスティングに追加のプラットフォーム容量が必要になります。
AOSM が複数のレプリカを持つ nfApp をアップグレードする場合、AOSM では、ローリングオプションまたは再作成オプションのデプロイプロファイル設定が優先されます。ローリングを使用する場合は、値 maxUnavailable と maxSurge を CGS パラメーターとして公開してから、実行時に演算子 CGV を使用して設定できます。

最終的には、特定のサービスを中断せずにアップグレードする機能は、そのサービス自体の機能です。サービスの発行元にさらに問い合わせて、サービス内アップグレード機能を理解し、適切な AOSM 動作オプションと一致していることを確認してください。

安全なアップグレードの前提条件

AOSM を使用してアップグレードを計画する場合は、アップグレードの実行前に次の要件に対処して、アップグレードの試行に費やされた時間を最適化し、アップグレードが成功することを確認します。

発行元やデザイナーのワークフローを使用して、更新された成果物をオンボードします。
- ほとんどの場合、既存の発行元を使用して新しいバージョンの成果物をホストします。
  - 既存のパブリッシャーを使用すると、別のバージョンに SNS を更新する helm upgrade がサポートされます。
  - 新しいパブリッシャーを使用するには、現在のSNS上の helm delete と、新しいSNSバージョンの helm install が必要です。
- アーティファクトストア、ネットワークサービスデザイングループ (NSDG)、およびネットワーク関数設計グループ (NFDG) は不変であり、変更できません。
  - これらのリソースの 1 つを変更するには、新しい SNS をデプロイする必要があります。
- 新しいチャートとイメージを格納するには、新しい成果物マニフェストが必要です。
  - 新しいグラフと画像のアップロードの詳細については、オンボードドキュメントを参照してください。
- 新しい NFDV、および必要に応じてネットワークサービス設計バージョン (NSDV) が必要です。
  - NFDV の変更は複雑な場合があります。この記事では、基本的な変更のみを取り上げません。
  - 新しい NSDV は、新しい構成グループスキーマ (CGS) バージョンが導入される場合にのみ必要です。
- 必要に応じて、新しい CGS。
  - アップグレードで新しい公開構成パラメーターが導入される場合は必須です。

注

メジャーバージョンが異なる NSDV と NFDV は、同じ NSDG と NFDG でサポートできます

オペレーターワークフローを使用して、更新された成果物を作成します。
- 必要に応じて、新しい CGS に基づいて新しい構成グループ値 (CGV) を作成します。
- 既存のサイトおよびサイトネットワークサービスオブジェクトを確認して、ペイロードを再利用して作成します。
テンプレートを更新して、アップグレードパラメーターがアップグレードの信頼性とエラー時の必要な動作に基づいて確実に設定されるようにします。
- 運用環境に使用される設定では、エラーの詳細が抑制される場合があります。一方、デバッグまたはテストに使用される設定では、これらの詳細を公開することを選択できます。

安全なアップグレードの手順

AOSM を使用してアップグレードをトリガーするには、次のプロセスに従います。

新しい NFDV リソースを作成する
- 新しい NFDV バージョンの場合は、有効な SemVer 形式である必要があります。新しいバージョンには、アップグレード (デプロイ済みバージョンと対比してより大きな値)、またはダウングレード (デプロイ済みバージョンと対比してより低い値) を指定できます。新しいバージョンは、メジャー、マイナー、またはパッチの値によって異なる場合があります。
新しい NFDV パラメーターを更新する
- Helm チャートのバージョンを更新することも、必要に応じて Helm 値を更新またはパラメーター化することもできます。新しい nfApps は、展開されたバージョンに存在しなかった場所に追加することもできます。
目的の nfApp 順序の NFDV を更新する
- UpdateDependsOn は、更新操作中に nfApps の順序を指定するために使用される NFDV パラメーターです。 updateDependsOn指定されていない場合は、NFDV に表示される CNF アプリケーションのシリアル順序が使用されます。
必要なアップグレード動作に合わせて ARM テンプレートを更新する
- 必要な CNF アプリケーション timeout、 atomic パラメーター、および rollbackOnTestFailure パラメーターを必ず設定してください。アップグレードに対する信頼性が高まるにつれて、これらのパラメーターを時間の経過とともに変更すると役立つ場合があります。
SNS のリプットを発行する
- オンボードが完了すると、reput 操作が送信されます。 nfApps の数、サイズ、複雑さに応じて、リプット操作が完了するまでに時間がかかる場合があります (数時間)。
信頼できる結果を調べる
- reput で成功の結果が報告されている場合、アップグレードは完了しており、ユーザーはサービスの状態と可用性を検証する必要があります。 reput でエラーが報告されている場合は、アップグレード失敗の回復に関するセクションの手順に従って続行します。

安全なアップグレードの再試行手順

reput 更新が失敗した場合は、次のプロセスに従って操作を再試行できます。

失敗した nfApp の診断
- ログやその他のデバッグ情報を分析して、nfApp エラーの根本原因を解決します。
完了したグラフを手動でスキップする
- 失敗した nfApp を修正した後、アップグレードの再試行を試みる前に、 applicationEnablement パラメーターを変更して再試行動作を高速化することを検討してください。このパラメーターは false に設定できます。nfApp はスキップする必要があります。このパラメーターは、nfApp でアップグレードが必要ない場合に便利です。
SNS のリプット再試行を発行する (成功するまで繰り返す)
- 既定では、reput は、 applicationEnablement フラグを使用してスキップされない限り、宣言された更新順序で nfApps を再試行します。

installOptions と UpgradeOptions を使用してタイムアウトを制御する

SNS 操作が helm install または helm upgradeのいずれかを開始すると、27 分のデフォルト・タイムアウト値が使用されます。この値はグローバルネットワーク関数 (NF) レベルでカスタマイズできますが、NF ペイロードテンプレートの roleOverrideValues を使用して、コンポーネント NF レベルでこの値をカスタマイズすることをお勧めします。 CGS/CGV で roleOverrideValues をさらに公開することで、実行時にオペレーターによる制御が可能になります。次の例は、2 つの nfApp コンポーネントに適用される、サポートされている installOptions パラメーターと upgradeOptions パラメーターを示しています。

{
  "roleOverrideValues": [
    {
      "name": "nfApplication1",
      "deployParametersMappingRuleProfile": {
        "helmMappingRuleProfile": {
          "options": {
            "installOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1"
            },
            "upgradeOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1"
            } } } } },
    {
      "name": "nfApplication2",
      "deployParametersMappingRuleProfile": {
        "helmMappingRuleProfile": {
          "options": {
            "installOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1"
            },
            "upgradeOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1"
            } } } } }
  ]
}

applicationEnablement を使用して nfApp をスキップする

NFDV リソースでは、 deployParametersMappingRuleProfile の下に、Unknown、Enabled、または disabled の値を受け取る列挙型のサポートされるプロパティ applicationEnablement があります。ネットワーク関数のデプロイ中に nfApp 操作を手動で除外するために使用できます。次の例では、プロパティに含まれる値として applicationEnablement をパラメーター化するジェネリックメソッド roleOverrideValues 示します。

NFDV テンプレートの変更

NFDV の変更は必ずしも必要ありませんが、必要に応じて、パブリッシャーは NFDV を使用して、 applicationEnablement プロパティの既定値を設定できます。既定値は、 roleOverrideValuesによって変更されない限り使用されます。 NFDV テンプレートを使用して、 applicationEnablementの既定値を設定します。次の例では、 enabled 状態を networkfunctionApplication の既定値 hellotest 設定します。

      "___location":"<___location>", 
      "properties": {
      "networkFunctionTemplate": {
        "networkFunctionApplications": [
            "deployParametersMappingRuleProfile": {
              "applicationEnablement": "Enabled"
            },
            "name": "hellotest"
        ],
        "nfviType": "AzureArcKubernetes"
        },
      }

applicationEnablement値をより動的に管理するために、オペレーターは NF テンプレート roleOverrideValues プロパティを使用してリアルタイム値を渡すことができます。演算子は NF テンプレートを直接操作できますが、代わりに roleOverrideValuesをパラメーター化して、実行時に CGV テンプレートを介して値を渡すことができます。次の例は、CGS、NF テンプレート、および最後に CGV に必要な変更を示しています。

CGS テンプレートの変更

CGS テンプレートは、 roleOverrideValuesの下でパラメーター化する行ごとに 1 つの変数宣言を含むように更新する必要があります。次の例では、3 つのオーバーライド値を示します。

        "roleOverrideValues0": {
          "type": "string"        
        },    
        "roleOverrideValues1": {
          "type": "string"        
        },        
        "roleOverrideValues2": {
          "type": "string"
        }

NF ペイロードテンプレートの変更

NF テンプレートは、3 つの方法で更新する必要があります。まず、暗黙的な構成パラメーターを型オブジェクトとして定義する必要があります。次に、 roleOverrideValues0、 roleOverrideValues1、および roleOverrideValues2 は、config パラメーターにマップされた変数として宣言する必要があります。第 3 に、 roleOverrideValues0、 roleOverrideValues1、および roleOverrideValues2 は、適切な順序で適切な構文に従って roleOverrideValues 置き換えるために参照する必要があります。

  "parameters": {
    "config": {
      "type": "object",
      "defaultValue": {}
    }
  }
  "variables": {
    "roleOverrideValues0": "[string(parameters('config').roleOverrideValues1)]",
    "roleOverrideValues1": "[string(parameters('config').roleOverrideValues1)]",
    "roleOverrideValues2": "[string(parameters('config').roleOverrideValues2)]"
  },
  "resources": [
  {
<snip>
     "roleOverrideValues": [
          "[variables('roleOverrideValues0')]",
          "[variables('roleOverrideValues1')]",
          "[variables('roleOverrideValues2')]"
        ]
   }

CGV テンプレートの変更

CGV テンプレートを更新して、実行時に roleOverrideValues プロパティに置き換えられる各変数の内容を含めることができます。次の例では、 rollbackEnabled を true に設定し、その後に nfApplications の hellotest と hellotest1 のオーバーライドセットを設定します。

{
    "roleOverrideValues0": "{\"nfConfiguration\":{\"rollbackEnabled\":true}}",
    "roleOverrideValues1": "{\"name\":\"hellotest\",\"deployParametersMappingRuleProfile\":{\"applicationEnablement\":\"Enabled\",\"helmMappingRuleProfile\":{\"releaseName\":\"override-release\",\"releaseNamespace\":\"override-namespace\",\"helmPackageVersion\":\"1.0.0\",\"values\":\"\",\"options\":{\"installOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"30\",\"injectArtifactStoreDetails\":\"true\"},\"upgradeOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"30\",\"injectArtifactStoreDetails\":\"true\"}}}}}",
    "roleOverrideValues2": "{\"name\":\"hellotest1\",\"deployParametersMappingRuleProfile\":{\"applicationEnablement\" : \"Enabled\"}}"
}

このフレームワークを導入することで、オペレーターは、CGV の簡単な更新を介して任意の roleOverrideValues を管理し、その CGV を目的の SNS 操作にアタッチすることができます。

変更のない nfApps をスキップする

skipUpgrade 機能は、CNF アップグレードにかかる時間を最適化するように設計されています。パブリッシャーが roleOverrideValues の upgradeOptions でこのフラグを有効にすると、AOSM サービスレイヤーは特定の事前チェックを実行して、特定の nfApplication のアップグレードをスキップできるかどうかを判断します。すべての事前チェック条件が満たされている場合、そのアプリケーションのアップグレードはスキップされます。それ以外の場合、アップグレードはクラスターレベルで実行されます。

事前確認の条件

次のすべての条件が満たされている場合は、アップグレードをスキップできます:

nfApplication のプロビジョニングの状態は成功です。
Helm チャートの名前またはバージョンに変更はありません。
Helm の値に変更はありません。

skipUpgrade 機能の有効化または無効化

skipUpgrade 機能は、既定では無効になっています。 roleOverrideValuesのupgradeOptionsでこの省略可能なパラメーターが指定されていない場合、CNF アップグレードは従来の方法で続行され、nfApplicationsはクラスターレベルでアップグレードされます。

ネットワーク機能リソースを使用した skipUpgrade の有効化

roleOverrideValues を使用して SkipUpgrade 機能を有効にするには、次の例を参照してください。

{
    "___location": "eastus2euap",
    "properties": {
        "publisherName": "xyAzureArcRunnerPublisher",
        "publisherScope": "Private",
        "networkFunctionDefinitionGroupName": "AzureArcRunnerNFDGroup",
        "networkFunctionDefinitionVersion": "1.0.0",
        "networkFunctionDefinitionOfferingLocation": "eastus2euap",
        "nfviType": "AzureArcKubernetes",
        "nfviId": "/subscriptions/4a0479c0-b795-4d0f-96fd-c7edd2a2928f/resourcegroups/ashutosh_test_rg/providers/microsoft.extendedlocation/customlocations/ashutosh_test_cl",
        "deploymentValues": "",
        "roleOverrideValues": [
            "{\"name\":\"hellotest\",\"deployParametersMappingRuleProfile\":{\"helmMappingRuleProfile\":{\"options\":{\"installOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"1\"},\"upgradeOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"4\",\"skipUpgrade\":\"true\"}}}}}",
            "{\"name\":\"runnerTest\",\"deployParametersMappingRuleProfile\":{\"helmMappingRuleProfile\":{\"options\":{\"installOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"5\"},\"upgradeOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"5\"}}}}}"
        ]
    }
}

例の説明

nfApplication: hellotest
- skipUpgrade フラグが有効になっています。 hellotest のアップグレード要求が事前確認の条件を満たしている場合、アップグレードはスキップされます。
nfApplication: runnerTest
- skipUpgrade フラグが指定されていません。そのため、runnerTest は、事前チェック条件が満たされている場合でも、クラスターレベルで従来の Helm アップグレードを実行します。

完全な roleOverrideValues オプションリファレンス

この記事とその他の記事のすべての例をまとめて、次のリファレンスでは、 roleOverrideValues メカニズムを通じて現在サポートされているすべてのオプションを示します。

{
  "roleOverrideValues": [
    {
      "nfConfiguration": {
        "rollbackEnabled": "true"
      }
    },
    {
      "name": "nfApplication1",
      "deployParametersMappingRuleProfile": {
        "helmMappingRuleProfile": {
          "options": {
            "installOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1",
              "testOptions": {
                "enable": "true",
                "timeout": "true",
                "rollbackOnTestFailure": "true",
                "filter": [
                  "test1",
                  "test2"
                ]
              }
            },
            "upgradeOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1",
              "skipUpgrade": "true",
              "testOptions": {
                "enable": "true",
                "timeout": "true",
                "rollbackOnTestFailure": "true",
                "filter": [
                  "test1",
                  "test2"
                ]
              }
            }
          }
        }
      }
    },
    {
      "name": "nfApplication2",
      "deployParametersMappingRuleProfile": {
        "helmMappingRuleProfile": {
          "options": {
            "installOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1",
              "testOptions": {
                "enable": "true",
                "timeout": "true",
                "rollbackOnTestFailure": "true",
                "filter": [
                  "test1",
                  "test2"
                ]
              }
            },
            "upgradeOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1",
              "skipUpgrade": "true",
              "testOptions": {
                "enable": "true",
                "timeout": "true",
                "rollbackOnTestFailure": "true",
                "filter": [
                  "test1",
                  "test2"
                ]
              }
            }
          }
        }
      }
    }
  ]
}