ソフトウェアバージョンと再構築

2 つの Terraform 変数が Customer Edge のソフトウェアを設定します。オペレーティングシステム用の ce_os_version と F5 Distributed Cloud ビルド用の ce_sw_version です。どちらも直感に反する動作をします — フィールドを空にすると何もインストールされないのではなく最新ビルドが取得され、あるノードではインストールできるバージョンが、ディスクが小さい同一のノードでは失敗することがあります。

バージョンフィールドの動作 — 2 つのフェーズ

フェーズを分けて理解することがすべての核心です。混同すると、動作が自己矛盾しているように見えます。

初回起動時、ノードは ce_sw_version で指定されたビルドをインストールします。 terraform/modules/ce-node は version = "latest" でマーケットプレイスイメージをデプロイするため、ノードが最初に持つビルドはそのイメージが現時点で提供しているものであり、これは時間とともに変化します。 ce_sw_version は「インストールするかどうか」ではなく目標バージョンを指定します。空のままにするとサーバーが選択することになり、ノードが現状維持になるわけではありません。ce_os_version についても同様です。

変更の方向が常に上位バージョンへ向かうとは限りません。2026-07-28 に観測した際、イメージには 20260703-e2c462a というスタンプのビルドが含まれており — このフリートが使用する crt-20250613-3382 よりも新しく、テナントが通知していた crt-20260201-0179 よりも新しいものでした。イメージが持つビルドよりも古いビルドを指定すると、ノードは逆方向に移行するよう求められます。これは通常の操作であり、このフリートはその方法で作成され、正常に動作しています。

バージョンフィールドを空にすることは、中立な選択ではなく最もリスクの高い選択です。 作成時、サーバーは空のフィールドをそのままにしません — 最新の通知済みバージョンで埋め、それをインストールします。両フィールドを未設定で作成されたサイトは、テナントが通知していた 2 つのバージョン — crt-20260201-0179 と OS 9.2026.14 — に固定されて戻ってきており、その後インストールが失敗しました。2026-07-29 に観測。

これには 2 つの影響があります。空は「最新を取得」を意味するため、固定されていないデプロイメントは後述のディスク制限に最も遭遇しやすくなります。また、一方のフィールドを空にしてもう一方を分離することはできません。サーバーが空のフィールドを埋めてしまうからです — 両方を意図的に設定するか、それぞれの最新バージョンを受け入れるかのいずれかです。

初回起動後、何も自動的にアップグレードされません。 F5 Distributed Cloud は新しいビルドを通知して待機します。「ノードは最初のインストール状態に留まる」というのは、作成後のフェーズに当てはまる話であり、作成中のフェーズではありません。

両フェーズはサイトオブジェクトで確認できます。2026-07-28 に観測したこのフリートの状態:

volterra_software_status.available_version   crt-20260201-0179
operating_system_status.available_version    9.2026.14

ノードは crt-20250613-3382 と OS 9.2024.6 で動作しており、新しいビルドが提供されているものの適用されていません — これは停滞したアップグレードではなく、定常状態です。

Terraform ではバージョンを変更できません。API では可能です

これらは 2 つの別々の事実であり、混同すると誤った計画につながります。

Terraform では変更できません。 ce_os_version と ce_sw_version は事実上、作成時のみ有効です。どちらかを変更して apply すると、API は [BAD_REQUEST] Invalid request parameters でアップデートを拒否します。2026-07-29 に観測した使い捨てサイトでの検証では、3 つのすべての方向 — より新しいビルドへの前方固定、古いビルドへの後方固定、および両フィールドをクリアする固定解除 — で同様に拒否されました。前方固定は特別なケースではありません。

API では変更できます。 F5 Distributed Cloud はサイトごとに専用のアップグレードアクションを公開しており、再構築や Terraform の関与なしに変更をインプレースで開始します:

# ソフトウェアビルド
curl -X POST -H "Authorization: APIToken $TOKEN" -H 'Content-Type: application/json' \
  --data '{"version": "<software-version>"}' \
  "$API_URL/api/config/namespaces/system/sites/<site-name>/upgrade_sw"

# オペレーティングシステム
curl -X POST -H "Authorization: APIToken $TOKEN" -H 'Content-Type: application/json' \
  --data '{"version": "<os-version>"}' \
  "$API_URL/api/config/namespaces/system/sites/<site-name>/upgrade_os"

2026-07-29 に観測: ソフトウェアの呼び出しは 200 を返し、サイトは deployment_state.phase が UPGRADE_IN_PROGRESS の状態で UPGRADING に移行し、サイトオブジェクトのリクエスト済みバージョンがポストしたバージョンに変更されました。フィールドを省略すると 400 と version empty in the request が返され、これによりフィールド名が確認されました。

数分ではなく数時間を想定し、失敗しても慌てないでください。 デフォルトディスクのノードでは、crt-20260201-0179 へのアップグレードに約 1 時間かかり、途中で UPGRADE_FAILED と result Failed が報告されましたが、その後新しいビルドで正常に完了しました。プラットフォームは自動的に再試行します。

これはアップグレードを監視したり、スクリプトで自動化したりする場合に直接的な影響があります。Failed の結果は最終判定ではなく、待機すべき状態です。最初の Failed を最終結果として扱うと、最終的に成功するアップグレードに対して失敗を報告してしまいます。

パスのグループに注意してください: これらは operate ではなく config 配下にあります。operate 配下の同じパスは 404 API Group could not be determined を返しますが、これはルーティングメッセージであり、アップグレードが存在しないことを示すものではありません — この区別が本プロジェクトで誤った結論を招きました。

このページではかつて、CE を別のバージョンに移行するにはサイトを再作成する必要があること、および拒否されたアップデートが「サーバー上でフィールドをクリアする」ため Terraform が永遠に失敗する変更を提案し続けるという 2 点を記載していました。いずれもテストで否定されました。上記の API アップグレードは再作成なしにインプレースでバージョン変更を開始し、3 回の拒否されたアップデートのそれぞれの後、サイトのスペックは変更されず、サイトは ONLINE のままでした。プロバイダーイシュー xcsh#1387 で説明されている乖離は、すでに固定値を超えて自動アップグレードされたサイトで観測されたものであり、その乖離した起点状態が必要な可能性があります。スペックが固定値と一致するサイトでは再現されませんでした。

アップグレードではなく再構築を行う場合、CE を置き換えることのすべての影響が適用されます。

固定されたビルドがインストールに失敗し、サイトがスタックする場合

固定値を受け入れることとインストールすることは同一ではありません。crt-20260201-0179 に固定された新規作成の単一ノード Azure Secure Mesh v2 Customer Edge では、サイトオブジェクトは固定バージョンを即座に報告しましたが、その後インストールが失敗しました:

site_state        PROVISIONING
phase             UPGRADE_FAILED
result            Failed
last_installed    (empty)
message           stage: 10, app: voucher obj: voucher objKind: DaemonSet failed ...
                  required replicas: 1, current replicas: 0

2026-07-28 に観測し、2026-07-29 に 2 回再現しました。同じ実行でオペレーティングシステムの固定は正常にインストールされました（9.2024.6 から 9.2026.14、UPGRADE_COMPLETED）。失敗したのはソフトウェアのインストールのみです。サイトは ONLINE に到達せず、last_installed_version は空のままであったため、正常なビルドへのロールバックは行われませんでした — ロールバック先となる以前の正常なインストールが存在しなかったからです。

作成時の失敗はアップグレード中の失敗とは異なります。 2 つの動作は異なり、介入するかどうかを判断する際にその違いが重要です:

	作成時	API アップグレード中
再試行して成功するか?	いいえ — 20 分以上 `Failed` のまま、2 回とも	はい — 回復して完了
ノードの最終状態は?	`PROVISIONING`、何もインストールされない	正常なビルドで `ONLINE`
そのまま放置しても安全か?	いいえ、スタックしたまま	はい、回復するか古いビルドを維持

したがって、作成時の失敗はより大きなディスクでの再構築が必要な一方、Failed を報告するアップグレードは結論を出す前にしばらく待機すべきです。

原因はバージョンではなくディスクです。 ソフトウェア × OS × ディスクサイズのマトリクスで、同じマーケットプレイスイメージから 1 組み合わせにつき 1 つの使い捨て単一ノード Azure Secure Mesh v2 サイトを作成して検証しました。2026-07-29 に観測:

ソフトウェア	OS `9.2024.6`（イメージが提供するバージョン）	OS `9.2026.14`
`crt-20250613-3382`	インストール成功	インストール成功
`crt-20260201-0179`	インストール成功	失敗、デフォルトディスクのみ

どちらのバージョンも単独では失敗しません。その組み合わせのみが失敗し、それもイメージのデフォルトディスクでのみ発生します — 同じ組み合わせが 33 GB およびテストしたすべてのより大きいサイズでインストールできます。したがって、新しいビルドも新しいオペレーティングシステムも単独ではサポートされていないわけではなく、組み合わせるとデフォルトノードが持つよりわずかに多くのディスク容量が必要になるということです。

terraform/modules/ce-node は disk_size_gb を設定していないため、すべての Customer Edge はイメージのデフォルトを使用します — この組み合わせが失敗する唯一のサイズです。実行するには、ディスクを拡張してください。

余裕の小ささが驚きであり、これが長期間バージョンの問題に見えていた理由です。デフォルトは 31 GiB（health コマンドは size_gb: 31 を報告し、/var は失敗状態のノードで空き 3.5 G の 29 G）です。33 GB ではクリーンにインストールできます。 つまりデフォルトはわずか約 2 ギガバイト不足しているだけであり、大幅に不足しているわけではありません。

フリートに適用する前に、使い捨てサイトでバージョン変更をテストしてください。この方法で失敗するフリートは PROVISIONING でスタックし、再作成のみが唯一の解決策となります。

このドキュメントが説明するビルド

本サイトのコマンドリファレンスは、このフリートが実行する crt-20250613-3382 について説明しています。新しいビルドにのみ存在するコマンドは sitecli/command-classification.json の not_on_this_build に記録され、新しいビルドのコマンドとして別途ドキュメント化されているため、そちらのコマンドがここで実行可能であるとは読み取れません。オンボックスコマンドも参照してください。