네트워크 기능을 온보딩하고 배포하는 Azure Operator Service Manager 모범 사례

아티클
11/07/2024

Microsoft는 Azure Operator Service Manager를 사용하여 NF(네트워크 기능)를 관리하기 위한 검증된 많은 사례를 개발했습니다. 이 문서에서는 NF 공급업체, 통신 사업자 및 파트너가 디자인을 최적화하기 위해 따를 수 있는 지침을 제공합니다. NF를 온보딩하고 배포할 때 이러한 사례를 염두에 두어야 합니다.

일반적인 고려 사항

먼저 빠른 시작을 사용하여 전체 흐름을 숙지하여 가장 간단한 NF(하나 또는 두 개의 차트)를 온보딩하고 배포하는 것이 좋습니다. 후속 반복에서 필요한 구성 세부 정보를 추가할 수 있습니다. 빠른 시작을 진행하면서 다음 사항을 고려합니다.

계획된 용도에 맞게 아티팩트 구조화 사이트 또는 인스턴스별로 변경하려는 아티팩트에서 전체 아티팩트 분리를 고려합니다.
네트워크의 요구 사항과 일치하는 매개 변수 집합을 사용하여 여러 NF의 서비스 구성을 확인합니다. 예를 들어 값이 1,000개이고 100개만 사용자 지정하는 차트가 있을 수 있습니다. CGS(구성 그룹 스키마) 계층(다음 섹션에서 더 광범위하게 설명됨)에서 100개만 노출하는지 확인합니다.
인프라(예: 클러스터) 또는 아티팩트 저장소를 분리하고 공급자 간의 액세스, 특히 단일 서비스 내에서 액세스하려는 방법에 대해 초기에 생각해 보세요. 게시자 리소스 집합이 이 모델과 일치하도록 합니다.
Azure Operator Service Manager 사이트는 배포 대상을 나타내는 논리적 개념입니다. 예를 들어 CNF(컨테이너화된 네트워크 기능)에 대한 Kubernetes 클러스터 또는 VNF(가상화된 네트워크 기능)에 대한 Azure Operator Nexus 확장 사용자 지정 위치가 있습니다. 물리적 에지 사이트의 표현이 아니므로 여러 사이트가 동일한 물리적 위치를 공유하는 사용 사례가 있습니다.
Azure Operator Service Manager는 ADO 또는 다른 파이프라인 도구와 간편하게 결합할 수 있는 다양한 API를 제공합니다.

게시자 고려 사항

NF 공급자당 단일 게시자를 만드는 것이 좋습니다. 이 방법은 모든 공급업체에서 최적의 지원, 유지 관리 및 거버넌스 환경을 제공하고 여러 공급업체의 여러 NF로 구성된 경우 네트워크 서비스 디자인을 간소화합니다.
원하는 Azure Operator Service Manager 게시자 리소스 및 아티팩트 집합을 테스트하고 프로덕션 사용을 승인한 후에는 전체 집합을 변경할 수 없는 것으로 표시하여 우발적인 변경을 방지하고 일관된 배포 환경을 보장하는 것이 좋습니다. 불변성 기능을 사용하여 프로덕션에 사용되는 리소스와 아티팩트를 테스트 및 개발 용도로 사용하는 리소스와 아티팩트와 구분하는 것이 좋습니다. 게시자 리소스 및 아티팩트 매니페스트의 상태를 쿼리하여 변경할 수 없는 것으로 표시되는 항목을 확인할 수 있습니다. 자세한 내용은 게시자 테넌트, 구독, 지역 및 미리 보기 관리를 참조하세요.

고려할 사항은 다음과 같습니다.
- NSDV(Network Service Design Version)가 변경할 수 없는 것으로 표시되면 CGS도 변경할 수 없는 것으로 표시되어야 합니다. 그렇지 않으면 배포 호출이 실패합니다.
- NFDV( Network Function Design Version)가 변경할 수 없는 것으로 표시되면 아티팩트 매니페스트도 변경할 수 없는 것으로 표시되어야 합니다. 그렇지 않으면 배포 호출이 실패합니다.
- 아티팩트 매니페스트 또는 CGS만 변경할 수 없는 것으로 표시되면 NFDV 및 NSDV가 변경할 수 없는 것으로 표시되는지 여부에 관계없이 배포 호출이 성공합니다.
- 아티팩트 매니페스트를 변경할 수 없는 것으로 표시하면 해당 매니페스트에 나열된 모든 아티팩트(일반적으로 차트, 이미지 및 Azure Resource Manager 템플릿[ARM 템플릿])도 아티팩트 저장소에 필요한 권한을 적용하여 변경할 수 없는 것으로 표시됩니다.
합의된 명명 규칙 및 거버넌스 기술을 사용하여 나머지 격차를 해결하는 것이 좋습니다.

네트워크 기능 정의 그룹 및 버전 고려 사항

NFDG(Network Function Definition Group)는 여러 서비스에서 독립적으로 다시 사용하려는 가장 작은 구성 요소를 나타냅니다. NFDG의 모든 파트는 항상 함께 배포됩니다. 이러한 파트를 networkFunctionApplications(이)라고 부릅니다. 예를 들어 이러한 구성 요소를 항상 함께 배포하는 경우 여러 Helm 차트 및 이미지로 구성된 단일 NF를 단일 NFDG로 온보딩하는 것은 당연합니다. 여러 NF가 항상 함께 배포되는 경우 모든 경우에 단일 NFDG가 있는 것이 합리적입니다. 단일 NFDG에는 여러 NFDV가 있을 수 있습니다.

CNF NFDV(컨테이너화된 네트워크 기능 정의 버전)의 경우 networkFunctionApplications 목록에는 helm 패키지만 포함될 수 있습니다. 항상 함께 배포 및 삭제되는 경우 여러 Helm 패키지를 포함하는 것이 합리적입니다.

VNF NFDV(가상화된 네트워크 기능 정의 버전)의 경우 networkFunctionApplications 목록에 하나 이상의 VhdImageFile 및 하나의 ARM 템플릿이 포함되어야 합니다. ARM 템플릿은 단일 VM(가상 머신)을 배포해야 합니다. 단일 VNF에 여러 VM을 배포하려면 각 VM에 대해 별도의 ARM 템플릿을 사용해야 합니다.

ARM 템플릿은 다음 리소스 공급자의 Resource Manager 리소스만 배포할 수 있습니다.

Microsoft.Compute
Microsoft.Network
Microsoft.NetworkCloud
Microsoft.Storage
Microsoft.NetworkFabric
Microsoft.Authorization
Microsoft.ManagedIdentity

참고 항목

이전 목록 이외의 항목이 포함된 ARM 템플릿의 경우 VNF에서 모든 PUT 호출 및 Re-PUT을 수행하면 유효성 검사 오류가 발생합니다.

네트워크 기능 디자인 버전 부 버전 또는 주 버전 업데이트를 트리거하는 일반적인 사용 사례

deployParametersMappingRuleProfile 변경을 트리거하는 기존 릴리스에 대한 CGV(CGS/구성 그룹 값) 업데이트
NFDV에서 하드 코딩된 값 업데이트
구성 요소가 applicationEnablement: Disabled을(를) 통해 배포되지 않도록 구성 요소를 비활성 상태로 표시
차트 및 이미지와 같은 새 NF 릴리스입니다.

참고 항목

지정된 NF의 페이로드가 변경 될 때마다 필요한 최소 변경 횟수입니다. 새 CGS 매개 변수를 노출하지 않는 부 또는 주 NF 릴리스는 아티팩트 매니페스트를 업데이트하고, 새 이미지와 차트를 푸시하고, NFDV 버전 범핑만으로 이루어집니다.

네트워크 서비스 디자인 그룹 및 버전 고려 사항

NSDG(네트워크 서비스 디자인 그룹)는 하나 이상의 NFDG 및 인프라 구성 요소(예: NAKS[Nexus Azure Kubernetes Service]/AKS[Azure Kubernetes Service] 클러스터 및 가상 머신)가 동시에 복합 배포됩니다. SNS(사이트 네트워크 서비스)는 단일 NSDV를 참조합니다. 이러한 디자인은 단일 SNS PUT에서 지정된 사이트에 네트워크 서비스의 일관되고 반복 가능한 배포를 보장합니다.

NSDG의 예는 다음과 같습니다.

AUSF(인증 서버 기능) NF
UDM(통합 데이터 관리) NF
AUSF/UDM을 지원하는 관리자 VM
UC(UNITY Cloud) SMF(세션 관리 함수) NF
AUSF, UDM 및 SMF가 배포되는 NAKS 클러스터

이러한 5개의 구성 요소는 단일 NSDG를 형성합니다. 단일 NSDG에는 여러 NSDV가 있을 수 있습니다.

네트워크 서비스 디자인 버전 부 버전 또는 주 버전 업데이트를 트리거하는 일반적인 사용 사례

CGS 만들기 또는 삭제
배포 중인 NF 중 하나와 연결된 NF ARM 템플릿의 변경 내용입니다.
인프라 ARM 템플릿의 변경 내용(예: AKS/NAKS 또는 VM)입니다.

참고 항목

NFDV의 변경은 NSDV 업데이트를 트리거해서는 안 됩니다. 운영자가 CGV를 사용하여 배포할 내용을 제어할 수 있도록 NFDV 값은 CGS 내에서 매개 변수로 노출되어야 합니다.

구성 그룹 스키마 고려 사항

전체 NF에 대해 항상 단일 CGS로 시작하는 것이 좋습니다. 사이트별 또는 인스턴스별 매개 변수가 있는 경우에도 단일 CGS에 유지하는 것이 좋습니다. 여러 NF에서 공유되는 여러 구성 요소(드물게 NF, 더 일반적으로 인프라) 또는 구성이 있는 경우 여러 CGS로 분할하는 것이 좋습니다. CGS 수는 CGV 수를 정의합니다.

시나리오

FluentD, Kibana 및 Splunk(일반적인 타사 구성 요소)는 항상 NSD 내의 모든 NF에 대해 배포됩니다. 이러한 구성 요소를 단일 NFDG로 그룹화하는 것이 좋습니다.
NSD에는 모두 몇 가지 구성(배포 위치, 게시자 이름 및 몇 가지 차트 구성)을 공유하는 여러 NF가 있습니다.

이 시나리오에서는 단일 글로벌 CGS를 사용하여 일반적인 NF 및 타사 구성 요소를 노출하는 것이 좋습니다. 필요에 따라 NF 관련 CGS를 정의할 수 있습니다.

노출할 매개 변수 선택

CGS에는 NF(일 0/N 구성) 또는 공유 구성 요소에서 사용하는 매개 변수만 있어야 합니다.
거의 구성되지 않은 매개 변수에는 기본값이 정의되어 있어야 합니다.
여러 CGS를 사용하는 경우 매개 변수 간에 거의 또는 전혀 겹치지 않는 것이 좋습니다. 겹쳐야 하는 경우 매개 변수 이름이 CGS 간에 명확하게 구별되도록 합니다.
API(Azure Operator Nexus, Azure Operator Service Manager)를 통해 정의할 수 있는 항목은 CGS에 대해 고려해야 합니다. 예를 들어 CloudInit 파일을 통해 이러한 구성 값을 정의하는 것과 반대입니다.
확실하지 않은 경우 매개 변수를 노출하고 CGS에 적절한 기본값을 지정하는 것이 좋은 시작점입니다. 다음 예제에서는 샘플 CGS 및 해당 CGV 페이로드를 보여 줍니다.
단일 사용자가 할당한 관리 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 확장을 사용하는 것입니다.

CLI 고려 사항

Azure Operator Service Manager CLI 확장은 NFD 및 NSD의 게시를 지원합니다. 새 NFD 및 NSD를 만들기 위한 시작점으로 이 도구를 사용합니다. CLI를 사용하여 초기 파일을 만드는 것을 고려합니다. 그런 다음 게시하기 전에 인프라 구성 요소를 통합하도록 편집합니다.

사이트 네트워크 서비스 고려 사항

인프라를 포함하여 전체 사이트에 대해 단일 SNS를 사용하는 것이 좋습니다. SNS는 필요한 인프라(예: NAKS/AKS 클러스터 및 가상 머신)를 배포한 다음, 맨 위에 필요한 NF를 배포해야 합니다. 이러한 디자인은 단일 SNS PUT에서 지정된 사이트에 네트워크 서비스의 일관되고 반복 가능한 배포를 보장합니다.

모든 SNS는 시스템이 할당한 관리 ID가 아닌 사용자가 할당한 관리 ID를 사용하여 배포하는 것이 좋습니다. 이 사용자가 할당한 관리 ID에는 NFDV에 액세스할 수 있는 권한이 있어야 하며 관리 ID 운영자의 역할 자체가 있어야 합니다. 자세한 내용은 사용자가 할당한 관리 ID 만들기를 참조하세요.

사용 사례당 Azure Operator Service Manager 리소스 매핑

다음 두 시나리오에서는 Azure Operator Service Manager 리소스 매핑을 보여 줍니다.

시나리오: 단일 네트워크 기능

하나 또는 두 개의 애플리케이션 구성 요소가 있는 NF는 NAKS 클러스터에 배포됩니다.

리소스 내역:

NFDG: 구성 요소를 독립적으로 사용할 수 있는 경우 구성 요소당 하나씩 두 개의 NFDG를 사용합니다. 구성 요소가 항상 함께 배포되는 경우 단일 NFDG입니다.
NFDV: 필요에 따라 NFDV 부 버전 또는 주 버전 업데이트를 트리거하는 이전 "일반적인 사용 사례" 섹션에 설명된 사용 사례를 기반으로 합니다.
NSDG: 단일. NF 및 Kubernetes 클러스터 정의를 결합합니다.
NSDV: 필요에 따라 NSDV 부 버전 또는 주 버전 업데이트를 트리거하는 이전 "일반적인 사용 사례" 섹션에 설명된 사용 사례를 기반으로 합니다.
CGS: 단일. CGS에는 보다 쉽게 관리할 수 있도록 배포되는 각 구성 요소 및 인프라에 대한 하위 섹션이 있고 NFD용 버전을 포함하는 것이 좋습니다.
CGV: CGS 수에 따라 단일입니다.
SNS: NSDV당 단일입니다.

시나리오: 여러 네트워크 기능

일부 공유 및 독립 구성 요소가 있는 여러 NF가 NAKS 클러스터에 배포됩니다.

리소스 내역:

NFDG:
- 모든 공유 구성 요소에 대한 NFDG입니다.
- 모든 독립적인 구성 요소 또는 NF에 대한 NFDG입니다.
NFDV: NFDV 부 버전 또는 주 버전 업데이트를 트리거하는 이전 "일반적인 사용 사례" 섹션에서 설명된 사용 사례당 각 NFDG당 여러 개입니다.
NSDG: 단일. 모든 NF, 공유 및 독립 구성 요소 및 인프라(Kubernetes 클러스터 또는 모든 지원 VM)를 결합합니다.
NSDV: 필요에 따라 NSDV 부 버전 또는 주 버전 업데이트를 트리거하는 이전 "일반적인 사용 사례" 섹션에 설명된 사용 사례를 기반으로 합니다.
CGS:
- 단일: 공유 구성 값이 있는 모든 구성 요소에 대해 전체로 설정됩니다.
- NFD 버전을 포함하여 NF당 NF CGS입니다.
- 총 매개 변수 수에 따라 모든 CGS를 단일 CGS로 결합하는 것이 좋습니다.
CGV: CGS 수와 같습니다.
SNS: NSDV당 단일입니다.

소프트웨어 업그레이드 고려 사항

NF가 CNF에 대해 현재 위치/서비스 내 업그레이드를 지원한다고 가정합니다.

새 차트와 이미지가 추가되면 Azure Operator Service Manager에서 새 차트를 설치합니다.
일부 차트와 이미지가 제거되면 Azure Operator Service Manager는 NFDV에서 더 이상 선언되지 않은 차트를 삭제합니다.
Azure Operator Service Manager는 NFDV/NSDV가 동일한 NFDG/NSDG에서 시작되었으므로 동일한 게시자에서 유래했는지 확인합니다. 게시자 간 업그레이드는 지원되지 않습니다.

VNF의 경우:

현재 위치 업그레이드는 현재 지원되지 않습니다. 업데이트된 이미지를 함께 사용하여 새 VNF를 인스턴스화해야 합니다. 그런 다음 SNS를 삭제하여 이전 VNF를 삭제합니다.
VNF가 고가용성을 위해 한 쌍의 VM으로 배포된 경우 VM을 하나씩 삭제하고 업그레이드할 수 있는 방식으로 네트워크 서비스를 디자인할 수 있습니다. 개별 VM의 삭제 및 업그레이드를 허용하려면 다음 디자인을 사용하는 것이 좋습니다.
- 각 VM은 전용 ARM 템플릿을 사용하여 배포됩니다.
- ARM 템플릿에서 두 개의 매개 변수를 CGS를 통해 노출해야 합니다. VM 이름으로 기본/보조 인스턴스를 나타낼 수 있도록 하고 배포 정책을 사용하여 VM 배포가 허용되는지 여부를 제어해야 합니다.
- NFDV에서는 각각에 대해 CGV를 사용하여 고유한 값을 제공할 수 있는 방식으로 deployParameters 및 templateParameters을(를) 매개 변수화해야 합니다.

높은 가용성 및 재해 복구 고려 사항

Azure Operator Service Manager는 해당 서비스를 지원하는 지역의 가용성 영역에 배포된 지역 서비스입니다. Azure Operator Service Manager를 사용할 수 있는 모든 지역의 경우 지역별 Azure 제품을 참조하세요. 가용성 영역이 있는 Azure 지역 목록은 적합한 Azure 지역 선택을 참조하세요.

다음과 같은 고가용성 및 재해 복구 요구 사항을 고려합니다.

지역 중복도를 제공하려면 NF를 배포하려는 모든 지역에 게시자가 있는지 확인합니다. 파이프라인을 사용하여 게시자 아티팩트와 리소스가 지역 전체에서 동기화되도록 고려합니다.
게시자 이름은 Microsoft Entra 테넌트당 지역별로 고유해야 합니다.

참고 항목

지역을 사용할 수 없게 되면 다른 지역의 게시자 리소스를 사용하여 NF를 배포(업그레이드는 하지 않음)할 수 있습니다. 아티팩트와 리소스가 게시자 간에 동일하다고 가정하고 SNS 리소스 페이로드의 networkServiceDesignVersionOfferingLocation 값만 변경하면 됩니다.

resource sns 'Microsoft.HybridNetwork/sitenetworkservices@2023-09-01’ = {
 name: snsName
 location: location
 identity: {
  type: 'SystemAssigned'
 }
 properties: {
   publisherName: publisherName
   publisherScope: 'Private'
   networkServiceDesignGroupName: nsdGroup
   networkServiceDesignVersionName: nsdvName
   networkServiceDesignVersionOfferingLocation: location

문제 해결 고려 사항

설치 및 업그레이드하는 동안 기본적으로 원자성 및 대기 옵션이 true(으)로 설정되고 작업 시간 제한이 27 minutes(으)로 설정됩니다. 초기 온보딩 중에 아티팩트를 디버깅하고 개발하는 동안에만 원자 플래그를 설정하여 false. 실패 시 Helm 롤백을 방지하고 손실될 수 있는 로그 또는 오류를 유지하는 것이 좋습니다. 이를 수행하는 최적의 방법은 NF의 ARM 템플릿에 있습니다.

ARM 템플릿에서 다음 섹션을 추가합니다.

"roleOverrideValues": [
    "{\"name\":\"NF_component_name>\",\"deployParametersMappingRuleProfile\":{\"helmMappingRuleProfile\":{\"options\":{\"installOptions\":{\"atomic\":\"false\",\"wait\":\"true\",\"timeout\":\"100\"},\"upgradeOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"4\"}}}}}"
]

구성 요소 이름은 NFDV에 정의됩니다.

     networkFunctionTemplate: {
      nfviType: 'AzureArcKubernetes'
      networkFunctionApplications: [
        {
          artifactType: 'HelmPackage'
          name: 'fed-crds'
          dependsOnProfile: null
          artifactProfile: {
            artifactStore: {
              id: acrArtifactStore.id
            }

Important

초기 온보딩이 완료된 후 원자성 및 대기가 다시 true 설정되었는지 확인합니다.

정리 고려 사항

운영자 리소스

배포된 환경을 정리하는 첫 번째 단계로, 먼저 다음 순서로 운영자 리소스를 삭제합니다.

SNS
Site
CGV

사용자가 NAKS 클러스터와 같은 다른 환경 리소스를 삭제하려면 이러한 연산자 리소스가 성공적으로 삭제된 후에만 가능합니다.

Important

리소스를 순서대로 삭제하면 분리된 리소스가 남을 수 있습니다.

게시자 리소스

온보딩된 환경을 정리하는 첫 번째 단계로, 먼저 다음 순서대로 게시자 리소스를 삭제합니다.

NSDV
NSDG

Important

NFDV를 삭제하기 전에 SNS가 삭제되었는지 확인합니다.

NFDV
NFDG
아티팩트 매니페스트
아티팩트 저장소
게시자

Important

리소스를 순서대로 삭제하면 분리된 리소스가 남을 수 있습니다.

NfApp 순차적 순서 지정 동작

개요

기본적으로 NfApps(컨테이너화된 네트워크 함수 애플리케이션)는 NFDV(네트워크 함수 디자인 버전)에 표시되는 순차적 순서에 따라 설치되거나 업데이트됩니다. 삭제의 경우 NfApps는 역순으로 삭제됩니다. 게시자가 기본값과 다른 NfApps의 특정 순서를 정의해야 하는 경우 dependsOnProfile을 사용하여 설치, 업데이트 및 삭제 작업에 대한 고유한 시퀀스를 정의합니다.

dependsOnProfile 사용 방법

게시자는 NFDV의 dependsOnProfile을 사용하여 NfApps에 대한 helm 실행 시퀀스를 제어할 수 있습니다. 다음 예제를 고려할 때 설치 작업에서 NfApps는 dummyApplication1, dummyApplication2, dummyApplication 순서로 배포됩니다. 업데이트 작업에서 NfApps는 dummyApplication2, dummyApplication1, dummyApplication 순서로 업데이트됩니다. 삭제 작업에서 NfApps는 dummyApplication2, dummyApplication1, dummyApplication 순서로 삭제됩니다.

{
    "location": "eastus",
    "properties": {
        "networkFunctionTemplate": {
            "networkFunctionApplications": [
                {
                  "dependsOnProfile": {
                        "installDependsOn": [
                            "dummyApplication1",
                            "dummyApplication2"
                        ],
                        "uninstallDependsOn": [
                            "dummyApplication1"
                        ],
                        "updateDependsOn": [
                            "dummyApplication1"
                        ]
                    },
                    "name": "dummyApplication"
                },
                {
                  "dependsOnProfile": {
                        "installDependsOn": [
                        ],
                        "uninstallDependsOn": [
                            "dummyApplication2"
                        ],
                        "updateDependsOn": [
                            "dummyApplication2"
                        ]
                    },
                    "name": "dummyApplication1"
                },
                {
                    "dependsOnProfile": null,
                    "name": "dummyApplication2"
                }
            ],
            "nfviType": "AzureArcKubernetes"
        },
        "networkFunctionType": "ContainerizedNetworkFunction"
    }
}

일반적인 오류

현재 NFDV에 제공된 dependsOnProfile이 유효하지 않으면 유효성 검사 오류와 함께 NF 작업이 실패합니다. 유효성 검사 오류 메시지는 작업 상태 리소스에 표시되며 다음 예제와 유사합니다.

 {
  "id": "/providers/Microsoft.HybridNetwork/locations/EASTUS2EUAP/operationStatuses/ca051ddf-c8bc-4cb2-945c-a292bf7b654b*C9B39996CFCD97AB3A121AE136ED47F67BB13946C573EF90628C47628BC5EF5F",
  "name": "ca051ddf-c8bc-4cb2-945c-a292bf7b654b*C9B39996CFCD97AB3A121AE136ED47F67BB13946C573EF90628C47628BC5EF5F",
  "resourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/xinrui-publisher/providers/Microsoft.HybridNetwork/networkfunctions/testnfDependsOn02",
  "status": "Failed",
  "startTime": "2023-07-17T20:48:01.4792943Z",
  "endTime": "2023-07-17T20:48:10.0191285Z",
  "error": {
    "code": "DependenciesValidationFailed",
    "message": "CyclicDependencies: Circular dependencies detected at hellotest."
  }
}

injectArtifactStoreDetails 고려 사항

경우에 따라 타사 helm 차트가 registryURL에 대한 AOSM 요구 사항을 완전히 준수하지 않을 수 있습니다. 이 경우 helm 패키지를 변경하지 않도록 injectArtifactStoreDetails 기능을 사용할 수 있습니다.

사용 방법

injectArtifactStoreDetails를 사용하려면 NF 리소스 roleOrverrides 섹션의 installOptions 매개 변수를 true로 설정한 다음 레지스트리 URL을 유효한 상태로 유지하는 데 필요한 레지스트리 URL 값을 사용합니다. 사용하도록 설정된 injectArtifactStoreDetails 매개 변수의 다음 예제를 참조하세요.

resource networkFunction 'Microsoft.HybridNetwork/networkFunctions@2023-09-01' = {
  name: nfName
  location: location
  properties: {
    nfviType: 'AzureArcKubernetes'
    networkFunctionDefinitionVersionResourceReference: {
      id: nfdvId
      idType: 'Open'
    }
    allowSoftwareUpdate: true
    nfviId: nfviId
    deploymentValues: deploymentValues
    configurationType: 'Open'
    roleOverrideValues: [
      // Use inject artifact store details feature on test app 1
      '{"name":"testapp1", "deployParametersMappingRuleProfile":{"helmMappingRuleProfile":{"options":{"installOptions":{"atomic":"false","wait":"false","timeout":"60","injectArtifactStoreDetails":"true"},"upgradeOptions": {"atomic": "false", "wait": "true", "timeout": "100", "injectArtifactStoreDetails": "true"}}}}}'
    ]
  }
}

다음을 통해 공유

네트워크 기능을 온보딩하고 배포하는 Azure Operator Service Manager 모범 사례

일반적인 고려 사항

게시자 고려 사항

네트워크 기능 정의 그룹 및 버전 고려 사항

네트워크 기능 디자인 버전 부 버전 또는 주 버전 업데이트를 트리거하는 일반적인 사용 사례

네트워크 서비스 디자인 그룹 및 버전 고려 사항

네트워크 서비스 디자인 버전 부 버전 또는 주 버전 업데이트를 트리거하는 일반적인 사용 사례

구성 그룹 스키마 고려 사항

시나리오

노출할 매개 변수 선택

구성 그룹 값 고려 사항

CLI 고려 사항

사이트 네트워크 서비스 고려 사항

사용 사례당 Azure Operator Service Manager 리소스 매핑

시나리오: 단일 네트워크 기능

시나리오: 여러 네트워크 기능

소프트웨어 업그레이드 고려 사항

높은 가용성 및 재해 복구 고려 사항

문제 해결 고려 사항

정리 고려 사항

운영자 리소스

게시자 리소스

NfApp 순차적 순서 지정 동작

개요

dependsOnProfile 사용 방법

일반적인 오류

injectArtifactStoreDetails 고려 사항

사용 방법

피드백

추가 리소스