소프트웨어 버전 및 재빌드

두 개의 Terraform 변수가 Customer Edge의 소프트웨어를 설정합니다: 운영 체제용 ce_os_version과 F5 Distributed Cloud 빌드용 ce_sw_version. 두 변수 모두 직관적인 이해와는 반대로 동작합니다 — 빈 필드는 없음이 아닌 최신 빌드를 제공하며, 한 노드에 설치되는 버전이 디스크가 더 작은 동일한 노드에서는 실패할 수 있습니다.

버전 필드가 하는 일, 두 단계로

단계를 분리하는 것이 핵심입니다. 혼동하면 동작이 자기모순처럼 읽힙니다.

첫 번째 부팅 시, 노드는 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보다도 새로운 것이었습니다. 이미지가 탑재한 것보다 오래된 빌드를 명시하면 노드가 뒤로 이동하도록 요청하는 것이며, 이는 일반적인 동작입니다: 이 플리트는 그렇게 생성되었으며 실행 중입니다.

버전 필드를 비워두는 것은 중립적인 선택이 아닌 가장 위험한 선택입니다. 생성 시 서버는 빈 필드를 그대로 두지 않습니다 — 가장 최신에 광고된 버전으로 채우고 설치합니다. 두 필드 모두 설정하지 않고 생성된 사이트는 crt-20260201-0179와 OS 9.2026.14로 고정되어 돌아왔고, 이 두 버전은 테넌트가 광고하던 것이었으며, 이후 설치가 실패했습니다. 2026-07-29 확인.

두 가지 결과가 있습니다. 비워두는 것은 “최신 버전을 주세요”를 의미하므로, 고정되지 않은 배포가 아래에 설명된 디스크 한계에 가장 먼저 직면할 가능성이 높습니다. 그리고 한 필드를 비워두어 다른 필드를 격리할 수 없습니다. 서버가 채우기 때문입니다 — 두 필드 모두 의도적으로 설정하거나, 각각의 최신 버전을 받아들이십시오.

첫 번째 부팅 이후에는 자동으로 업그레이드되지 않습니다. 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는 가능합니다

이것은 두 가지 별개의 사실이며, 혼동하면 잘못된 계획을 세우게 됩니다.

Terraform은 불가능합니다. ce_os_version과 ce_sw_version은 사실상 생성 시에만 적용됩니다. 둘 중 하나를 변경하고 적용하면 API가 [BAD_REQUEST] Invalid request parameters와 함께 업데이트를 거부합니다. 2026-07-29 확인 — 일회용 사이트에서 세 가지 방향 모두 — 더 새로운 빌드로 앞으로 고정, 더 오래된 빌드로 뒤로 고정, 두 필드 모두 지워 고정 해제. 앞으로가 특별한 경우는 아닙니다.

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 상태로 이동했으며, 사이트 객체의 요청된 버전이 게시된 버전으로 변경되었습니다. 필드를 생략하면 version empty in the request와 함께 400을 반환하며, 이것으로 필드 이름이 확인되었습니다.

시간을 분이 아닌 시간 단위로 예상하고, 실패에 당황하지 마십시오. 기본 디스크 노드에서 crt-20260201-0179로의 업그레이드는 약 한 시간 동안 실행되었고, 도중에 result가 Failed인 UPGRADE_FAILED를 보고했지만, 그 후 새 빌드에서 성공적으로 완료되었습니다. 플랫폼이 재시도합니다.

이것은 업그레이드를 지켜보거나 스크립팅하는 사람에게 직접적인 영향을 미칩니다: Failed 결과는 기다려야 할 상태이지, 최종 판정이 아닙니다. 첫 번째를 최종으로 처리하면 성공할 업그레이드를 실패로 보고하게 됩니다.

해당 경로의 그룹에 주의하십시오: 이것들은 operate가 아닌 config 아래에 있습니다. operate 아래의 동일한 경로는 404 API Group could not be determined를 반환하는데, 이는 라우팅 메시지이며 업그레이드가 존재하지 않는다는 것이 아닙니다 — 이 프로젝트가 잘못된 결론을 내리는 데 비용을 치른 구분입니다.

이 페이지는 이전에 CE를 다른 버전으로 이동하려면 사이트를 재생성해야 한다고 했으며, 거부된 업데이트가 “여전히 서버의 필드를 지워” Terraform이 영원히 실패하는 변경을 제안하게 만든다고 했습니다. 둘 다 테스트에서 살아남지 못했습니다: 위의 API 업그레이드는 아무것도 재생성하지 않고 버전 변경을 시작하며, 세 가지 거부된 업데이트 각각 이후 사이트의 사양은 변경되지 않았고 사이트는 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에 두 번 재현. 운영 체제 고정은 동일한 실행에서 정상적으로 설치되었습니다 (9.2024.6에서 9.2026.14로, UPGRADE_COMPLETED); 소프트웨어 설치만 실패했습니다. 사이트는 ONLINE에 도달하지 못했고 last_installed_version은 비어 있었으므로, 작동하는 빌드로 롤백되지 않았습니다 — 롤백할 이전 성공적인 설치가 없었습니다.

생성 시 실패는 업그레이드 중 실패와 다릅니다. 두 가지는 다르게 동작하며, 개입 여부를 결정할 때 그 차이가 중요합니다:

	생성 시	API 업그레이드 중
성공으로 재시도하는가?	아니오 — 20분 이상 `Failed` 유지, 두 번	예 — 복구되어 완료됨
노드는 어디에서 끝나는가?	`PROVISIONING`, 아무것도 설치되지 않음	작동하는 빌드에서 `ONLINE`
그대로 두어도 안전한가?	아니오, 멈춰 있음	예, 복구되거나 이전 빌드를 유지함

따라서 생성 시 실패는 더 큰 디스크로 재빌드가 필요하고, Failed를 보고하는 업그레이드는 결론을 내리기 전에 잠시 기다려야 합니다.

원인은 버전이 아닌 디스크입니다. 소프트웨어 × OS × 디스크 크기 매트릭스로, 조합당 일회용 단일 노드 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에 기록되고 더 새로운 빌드의 명령으로 별도로 문서화되므로, 거기에서 여기서 실행 가능한 것으로 읽히는 내용은 없습니다. 온박스 명령도 참조하십시오.