Aracılığıyla paylaş

Ağ işlevlerini ekleme ve dağıtmaya yönelik en iyi Azure Operatör Hizmeti Yöneticisi yöntemleri

  • Makale

Microsoft, Azure Operatör Hizmeti Yöneticisi kullanarak ağ işlevlerini (NF) yönetmek için kanıtlanmış birçok uygulama geliştirmiştir. Bu makalede NF satıcılarının, telco operatörlerinin ve iş ortaklarının tasarımı iyileştirmek için izleyebilecekleri yönergeler sağlanmaktadır. NF'lerinizi eklerken ve dağıtırken bu uygulamaları göz önünde bulundurun.

Dikkat edilmesi gereken temel noktalar

Genel akışı tanımak için hızlı başlangıçları kullanarak ilk olarak en basit NF'lerinizi (bir veya iki grafik) eklemenizi ve dağıtmanızı öneririz. Sonraki yinelemelerde gerekli yapılandırma ayrıntılarını ekleyebilirsiniz. Hızlı başlangıçlar boyunca aşağıdaki noktaları göz önünde bulundurun:

  • Yapıtlarınızı planlı kullanımla uyumlu olacak şekilde yapılandırma. Genel yapıtları siteye veya örneğe göre değiştirmek istediğiniz yapıtlardan ayırmayı göz önünde bulundurun.
  • Ağınızın gereksinimleriyle eşleşen bir dizi parametreyle birden çok NF'nin hizmet bileşiminden emin olun. Örneğin, 1.000 değer içeren bir grafiğiniz olabilir ve bunlardan yalnızca 100 tanesini özelleştirebilirsiniz. Yapılandırma Grubu Şeması (CGS) katmanında (izleyen bölümlerde daha kapsamlı olarak ele alınmıştır) yalnızca 100'ün kullanıma sunmadığından emin olun.
  • Altyapıyı (örneğin, kümeler) veya yapıt depolarını ayırmayı ve özellikle tek bir hizmet içinde sağlayıcılar arasında erişim sağlamayı nasıl istediğinizi erkenden düşünün. Yayımcı kaynak kümenizin bu modelle eşleşmesini sağlayın.
  • Azure Operatör Hizmeti Yöneticisi sitesi, dağıtım hedefinin bir gösterimi olan mantıksal bir kavramdır. Örnek olarak Kapsayıcılı Ağ İşlevleri (CNF) için bir Kubernetes kümesi veya Sanallaştırılmış Ağ İşlevleri (VNF) için Genişletilmiş Azure Operatör Nexus özel konumu verilebilir. Fiziksel uç sitenin bir gösterimi olmadığından, birden çok sitenin aynı fiziksel konumu paylaştığı kullanım örnekleriniz vardır.
  • Azure Operatör Hizmeti Yöneticisi, ADO veya diğer işlem hattı araçlarıyla birleştirmeyi basitleştiren çeşitli API'ler sağlar.

Yayımcı ile ilgili dikkat edilmesi gerekenler

  • NF sağlayıcısı başına tek bir yayımcı oluşturmanızı öneririz. Bu uygulama, tüm tedarikçiler genelinde en iyi destek, bakım ve idare deneyimini sağlar ve birden çok satıcının birden çok NF'sinden oluştuğunda ağ hizmeti tasarımınızı basitleştirir.

  • İstenen Azure Operatör Hizmeti Yöneticisi yayımcı kaynakları ve yapıtları üretim kullanımı için test edilip onaylandıktan sonra, yanlışlıkla yapılan değişiklikleri önlemek ve tutarlı bir dağıtım deneyimi sağlamak için kümenin tamamını sabit olarak işaretlemenizi öneririz. Üretimde kullanılan kaynaklar ve yapıtlar ile test ve geliştirme amacıyla kullanılanlar arasında ayrım yapmak için değişmezlik özelliklerine güvenmeyi göz önünde bulundurun. Hangilerinin sabit olarak işaretleneceğini belirlemek için yayımcı kaynaklarının ve yapıt bildirimlerinin durumunu sorgulayabilirsiniz. Daha fazla bilgi için bkz . Yayımcı kiracıları, abonelikler, bölgeler ve önizleme yönetimi.

    Aşağıdaki mantığı aklınızda bulundurun:

    • Ağ Hizmeti Tasarım Sürümü (NSDV) sabit olarak işaretlenmişse, CGS'nin de sabit olarak işaretlenmesi gerekir. Aksi takdirde dağıtım çağrısı başarısız olur.
    • Ağ İşlevi Tasarım Sürümü (NFDV) sabit olarak işaretlenmişse yapıt bildirimi de sabit olarak işaretlenmelidir. Aksi takdirde dağıtım çağrısı başarısız olur.
    • Yalnızca yapıt bildirimi veya CGS sabit olarak işaretlenirse, NFDV ve NSDV'nin sabit olarak işaretlenip işaretlenmediğine bakılmaksızın dağıtım çağrısı başarılı olur.
    • Yapıt bildiriminin sabit olarak işaretlenmesi, bu bildirimde listelenen tüm yapıtların (genellikle grafikler, görüntüler ve Azure Resource Manager şablonları [ARM şablonları]) yapıt deposunda gerekli izinler zorunlu kılınarak sabit olarak işaretlenmesini sağlar.

  • Kalan boşlukları gidermeye yardımcı olmak için üzerinde anlaşmaya varılan adlandırma kurallarını ve idare tekniklerini kullanmayı göz önünde bulundurun.

Ağ İşlevi Tanım Grubu ve Sürüm ile ilgili dikkat edilmesi gerekenler

Ağ İşlevi Tanım Grubu (NFDG), birden çok hizmette bağımsız olarak yeniden kullanılmasını planladığınız en küçük bileşeni temsil eder. NFDG'nin tüm bölümleri her zaman birlikte dağıtılır. Bu bölümler olarak adlandırılır networkFunctionApplications. Örneğin, her zaman bu bileşenleri birlikte dağıtırsanız, birden çok Helm grafiğinden ve görüntüsünden oluşan tek bir NF'yi tek bir NFDG olarak eklemek doğaldır. Birden çok NF'nin her zaman birlikte dağıtıldığı durumlarda, hepsi için tek bir NFDG'nin olması mantıklıdır. Tek NFDG'ler birden çok NFDV'ye sahip olabilir.

Kapsayıcılı Ağ İşlevi Tanım Sürümleri (CNF NFDV'ler) networkFunctionApplications için liste yalnızca helm paketlerini içerebilir. Her zaman birlikte dağıtılır ve silinirse birden çok helm paketi eklemek mantıklıdır.

Sanallaştırılmış Ağ İşlevi Tanım Sürümleri (VNF NFDV'ler) networkFunctionApplications için listede en az bir VhdImageFile ve bir ARM şablonu bulunmalıdır. ARM şablonu tek bir sanal makine (VM) dağıtmalıdır. Tek bir VNF için birden çok VM dağıtmak için her VM için ayrı ARM şablonları kullandığınızdan emin olun.

ARM şablonu yalnızca aşağıdaki kaynak sağlayıcılarından Resource Manager kaynaklarını dağıtabilir:

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

Not

Önceki listenin ötesinde herhangi bir şey içeren ARM şablonları için, VNF'deki tüm PUT çağrıları ve Yeniden PUT bir doğrulama hatasına neden olur.

Ağ İşlevi Tasarım Sürümü ikincil veya ana sürüm güncelleştirmesini tetikleyen yaygın kullanım örnekleri

  • CGS/Yapılandırma Grubu Değerlerinin (CGV) değiştirilmesini tetikleyen mevcut bir sürüm için güncelleştirilmesi deployParametersMappingRuleProfile.
  • NFDV'de sabit kodlanmış değerleri güncelleştirme.
  • bileşenlerinin aracılığıyla applicationEnablement: Disableddağıtılmasını önlemek için etkin olmayan bileşenleri işaretleme.
  • Grafikler ve görüntüler gibi yeni NF sürümü.

Not

Belirli bir NF'nin yükü her değiştiğinde gereken en az değişiklik sayısı. Yeni CGS parametrelerini göstermeden ikincil veya önemli bir NF sürümü yalnızca yapıt bildiriminin güncelleştirilmesini, yeni görüntülerin ve grafiklerin gönderilip NFDV sürümünün çarpmasını gerektirir.

Ağ Hizmeti Tasarım Grubu ve Sürüm ile ilgili dikkat edilmesi gerekenler

Ağ Hizmeti Tasarım Grubu (NSDG), aynı anda dağıtılan bir veya daha fazla NFDG'nin ve tüm altyapı bileşenlerinin (Nexus Azure Kubernetes Service [NAKS]/Azure Kubernetes Service [AKS] kümeleri ve sanal makineler gibi) bileşimidir. Site ağ hizmeti (SNS), tek bir NSDV'ye başvurur. Bu tür tasarım, ağ hizmetinin tek bir SNS PUT'dan belirli bir siteye tutarlı ve yinelenebilir dağıtımını garanti eder.

NSDG örneği:

  • Kimlik Doğrulama Sunucusu İşlevi (AUSF) NF
  • Birleşik Veri Yönetimi (UDM) NF
  • AUSF/UDM'yi destekleyen yönetici VM
  • Unity Cloud (UC) Oturum Yönetimi İşlevi (SMF) NF
  • AUSF, UDM ve SMF'nin dağıtıldığı NAKS kümesi

Bu beş bileşen tek bir NSDG oluşturur. Tek bir NSDG'de birden çok NSDV olabilir.

Ağ Hizmeti Tasarım Sürümü ikincil veya ana sürüm güncelleştirmesini tetikleyen yaygın kullanım örnekleri

  • CGS'leri oluşturma veya silme.
  • Dağıtılan NF'lerden biriyle ilişkili NF ARM şablonundaki değişiklikler.
  • Aks/NAKS veya VM gibi altyapı ARM şablonundaki değişiklikler.

Not

NFDV'deki değişiklikler NSDV güncelleştirmesini tetiklememelidir. NFDV değeri CGS içinde bir parametre olarak gösterilmelidir, böylece işleçler CGV'leri kullanarak ne dağıtacaklarını denetleyebilmelidir.

Yapılandırma Grubu Şemasında dikkat edilmesi gerekenler

NF'nin tamamı için her zaman tek bir CGS ile başlamanızı öneririz. Siteye veya örneğe özgü parametreler varsa, yine de bunları tek bir CGS'de tutmanızı öneririz. Birden çok NF arasında paylaşılan birden çok bileşen (nadiren NF'ler, daha yaygın olarak altyapı) veya yapılandırmalar olduğunda birden çok CGS'ye bölmenizi öneririz. CGS sayısı, CGV sayısını tanımlar.

Senaryo

  • FluentD, Kibana ve Splunk (ortak üçüncü taraf bileşenleri) her zaman bir NSD içindeki tüm NF'ler için dağıtılır. Bu bileşenleri tek bir NFDG olarak gruplandırmanızı öneririz.
  • NSD'de birkaç yapılandırmayı (dağıtım konumu, yayımcı adı ve birkaç grafik yapılandırması) paylaşan birden çok NF vardır.

Bu senaryoda, ortak NF ve üçüncü taraf bileşen yapılandırmalarını kullanıma açmak için tek bir genel CGS kullanmanızı öneririz. NF'ye özgü CGS'yi gerektiği gibi tanımlayabilirsiniz.

Kullanıma açık parametreleri seçme

  • CGS yalnızca NF'ler (gün 0/N yapılandırması) veya paylaşılan bileşenler tarafından kullanılan parametrelere sahip olmalıdır.
  • Nadiren yapılandırılan parametrelerin varsayılan değerleri tanımlanmış olmalıdır.
  • Birden çok CGS kullanılıyorsa, parametreler arasında çok az çakışma olmaması önerilir. Çakışma gerekiyorsa, parametre adlarının CGS'ler arasında açıkça ayırt edilebilir olduğundan emin olun.
  • CGS için API (Azure Operatör Nexus, Azure Operatör Hizmet Yöneticisi) aracılığıyla tanımlanabilecekler dikkate alınmalıdır. Örneğin, CloudInit dosyaları aracılığıyla bu yapılandırma değerlerini tanımlamanın aksine.
  • Emin değilseniz, iyi bir başlangıç noktası parametresini kullanıma sunma ve CGS'de makul bir varsayılan değer belirtmektir. Aşağıdaki örnekte örnek CGS ve karşılık gelen CGV yükleri gösterilmektedir.
  • Tüm NF ARM şablonlarında tek bir kullanıcı tarafından atanan yönetilen kimlik kullanılmalıdır ve CGS aracılığıyla kullanıma sunulmalıdır.

CGS yükü:

{ 
  "type": "object", 
  "properties": { 
    "abc": { 
    "type": "integer", 
    "default": 30
    }, 
    "xyz": { 
    "type": "integer", 
    "default": 40
    },
    "qwe": {
    "type": "integer" //doesn't have defaults
    }
  }
  "required": "qwe"
}

İşleç tarafından geçirilen ilgili CGV yükü:

{
"qwe": 20
}

Azure Operatör Hizmet Yöneticisi tarafından oluşturulan sonuçta elde edilen CGV yükü:

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

Yapılandırma Grubu Değerlerinde dikkat edilmesi gerekenler

CGV kaynak oluşturma işlemini göndermeden önce, temel alınan YAML veya JSON dosyasının şemasının ve değerlerinin ilgili CGS'nin beklediğiyle eşleşip eşleşmediğini doğrulayabilirsiniz. Bunu başarmak için visual studio code için YAML uzantısını kullanmak bir seçenektir.

CLI ile ilgili dikkat edilmesi gerekenler

Azure Operatör Hizmeti Yöneticisi CLI uzantısı, ND'lerin ve NSD'lerin yayımlanması konusunda yardımcı olabilir. Yeni ND'ler ve NSD'ler oluşturmak için başlangıç noktası olarak bu aracı kullanın. İlk dosyaları oluşturmak için CLI kullanmayı göz önünde bulundurun. Ardından, yayımlamadan önce altyapı bileşenlerini dahil etmek için bunları düzenleyin.

Site ağ hizmetiyle ilgili dikkat edilmesi gerekenler

Altyapı dahil olmak üzere sitenin tamamı için tek bir SNS'niz olması önerilir. SNS gerekli altyapıları (örneğin, NAKS/AKS kümeleri ve sanal makineler) dağıtmalı ve ardından en üstte gerekli NF'leri dağıtmalıdır. Bu tür tasarım, ağ hizmetinin tek bir SNS PUT'dan belirli bir siteye tutarlı ve yinelenebilir dağıtımını garanti eder.

Her SNS'nin sistem tarafından atanan yönetilen kimlik yerine kullanıcı tarafından atanan yönetilen kimlikle dağıtılmalarını öneririz. Kullanıcı tarafından atanan bu yönetilen kimliğin NFDV'ye erişim izinleri olmalıdır ve Yönetilen Kimlik İşleci rolüne sahip olması gerekir. Daha fazla bilgi için bkz . Kullanıcı tarafından atanan yönetilen kimlik oluşturma ve atama.

Kullanım örneği başına Azure Operatör Service Manager kaynak eşlemesi

Aşağıdaki iki senaryoda Azure Operatör Hizmet Yöneticisi kaynak eşlemesi gösterilmektedir.

Senaryo: Tek ağ işlevi

Bir veya iki uygulama bileşenine sahip bir NF, BIR NAKS kümesine dağıtılır.

Kaynak dökümü:

  • NFDG: Bileşenler bağımsız olarak kullanılabiliyorsa, her bileşen için bir tane olmak üzere iki NFDG. Bileşenler her zaman birlikte dağıtılırsa tek bir NFDG.
  • NFDV: NFDV ikincil veya ana sürüm güncelleştirmelerini tetikleyen önceki "Yaygın kullanım örnekleri" bölümlerinde belirtilen kullanım örneklerine bağlı olarak gerektiğinde.
  • NSDG: Tek. NF'leri ve Kubernetes küme tanımlarını birleştirir.
  • NSDV: NSDV ikincil veya ana sürüm güncelleştirmelerini tetikleyen önceki "Yaygın kullanım örnekleri" bölümlerinde belirtilen kullanım örneklerine bağlı olarak gerektiğinde.
  • CGS: Tek. CGS'nin daha kolay yönetim için dağıtılan her bileşen ve altyapı için alt bölümlere sahip olması ve NFD sürümlerini içermesini öneririz.
  • CGV: CGS sayısına göre tek.
  • SNS: NSDV başına tek.

Senaryo: Birden çok ağ işlevi

Bazı paylaşılan ve bağımsız bileşenlere sahip birden çok NF bir NAKS kümesine dağıtılır.

Kaynak dökümü:

  • NFDG:
    • Tüm paylaşılan bileşenler için NFDG.
    • Her bağımsız bileşen veya NF için NFDG.
  • NFDV: NFDV ikincil veya ana sürüm güncelleştirmelerini tetikleyen önceki "Yaygın kullanım örnekleri" bölümlerinde belirtilen kullanım örneği başına her NFDG başına birden çok.
  • NSDG: Tek. Tüm NF'leri, paylaşılan ve bağımsız bileşenleri ve altyapıyı (Kubernetes kümesi veya destekleyen VM'ler) birleştirir.
  • NSDV: NSDV ikincil veya ana sürüm güncelleştirmelerini tetikleyen önceki "Yaygın kullanım örnekleri" bölümlerinde belirtilen kullanım örneklerine bağlı olarak gerektiğinde.
  • CGS:
    • Bekar. Paylaşılan yapılandırma değerlerine sahip tüm bileşenler için genel.
    • NFD sürümü de dahil olmak üzere NF başına NF CGS.
    • Toplam parametre sayısına bağlı olarak, tüm CGS'leri tek bir CGS'de birleştirmeyi göz önünde bulundurun.
  • CGV: CGS sayısına eşittir.
  • SNS: NSDV başına tek.

Yazılım yükseltmesi ile ilgili dikkat edilmesi gerekenler

NF'lerin CNF'ler için yerinde/hizmet içi yükseltmeleri desteklediği varsayılırsa:

  • Yeni grafikler ve görüntüler eklenirse, Azure Operatör Hizmet Yöneticisi yeni grafikleri yükler.
  • Bazı grafikler ve görüntüler kaldırılırsa, Azure Operatör Hizmet Yöneticisi artık NFDV'de bildirilmeyen grafikleri siler.
  • Azure Operatör Hizmet Yöneticisi, NFDV/NSDV'nin aynı NFDG/NSDG'den ve dolayısıyla aynı yayımcıdan kaynaklandığını doğrular. Yayımcılar arası yükseltmeler desteklenmez.

VNF'ler için:

  • Yerinde yükseltmeler şu anda desteklenmiyor. Güncelleştirilmiş bir görüntüyle yeni bir VNF'yi yan yana örneklemeniz gerekir. Ardından SNS'yi silerek eski VNF'yi silin.
  • VNF, yüksek kullanılabilirlik için bir vm çifti olarak dağıtılırsa, ağ hizmetini VM'leri tek tek silip yükseltebileceğiniz şekilde tasarlayabilirsiniz. Tek tek VM'lerin silinmesine ve yükseltebilmesi için aşağıdaki tasarımı öneririz:
    • Her VM, ayrılmış bir ARM şablonu kullanılarak dağıtılır.
    • ARM şablonundan, hangi örneğin birincil/ikincil olduğunu belirtmek için vm adı ve VM dağıtımına izin verilip verilmediğini denetleyen dağıtım ilkesi olmak üzere CGS aracılığıyla iki parametrenin kullanıma sunması gerekir.
    • NFDV'de ve templateParameters her birinin CGV'lerini deployParameters kullanarak benzersiz değerleri sağlayabilmeniz için parametriz edilmesi gerekir.

Yüksek kullanılabilirlik ve olağanüstü durum kurtarma konuları

Azure Operatör Hizmeti Yöneticisi, bunları destekleyen bölgelerdeki kullanılabilirlik alanları arasında dağıtılan bölgesel bir hizmettir. Azure Operatör Hizmeti Yöneticisi'nin kullanılabildiği tüm bölgeler için bkz . Bölgeye göre Azure ürünleri. Kullanılabilirlik alanları olan Azure bölgelerinin listesi için bkz . Sizin için doğru Azure bölgesini seçme.

Aşağıdaki yüksek kullanılabilirlik ve olağanüstü durum kurtarma gereksinimlerini göz önünde bulundurun:

  • Coğrafi olarak yedeklilik sağlamak için, NF'leri dağıtmayı planladığınız her bölgede bir yayımcınız olduğundan emin olun. Yayımcı yapıtlarının ve kaynaklarının bölgeler arasında eşitlenmiş durumda tutulduğundan emin olmak için işlem hatlarını kullanmayı göz önünde bulundurun.
  • Yayımcı adı, Microsoft Entra kiracısı başına bölge başına benzersiz olmalıdır.

Not

Bir bölge kullanılamaz duruma gelirse, başka bir bölgedeki yayımcı kaynaklarını kullanarak NF'yi dağıtabilirsiniz (ancak yükseltemezsiniz). Yapıtların ve kaynakların yayımcılar arasında aynı olduğunu varsayarsak, yalnızca SNS kaynak yükündeki değeri değiştirmeniz networkServiceDesignVersionOfferingLocation gerekir.

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

Sorun gidermede dikkat edilecek noktalar

Varsayılan olarak yükleme ve yükseltme sırasında atomik ve bekleme seçenekleri olarak true, işlem zaman aşımı ise olarak 27 minutesayarlanır. İlk ekleme sırasında, yalnızca hata ayıklamaya ve yapıt geliştirmeye devam ederken, atomik bayrağını false. Bu, hata durumunda helm geri almayı önler ve aksi takdirde kaybolabilecek günlükleri veya hataları korur olarak ayarlamanızı öneririz. Bunu başarmak için en uygun yol, NF'nin ARM şablonudur.

ARM şablonuna aşağıdaki bölümü ekleyin:

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

Bileşen adı NFDV'de tanımlanır:

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

Önemli

İlk ekleme tamamlandıktan sonra atomik ve beklemenin geri true ayarlandığından emin olun.

Temizleme konusunda dikkat edilmesi gerekenler

İşleç Kaynakları

Dağıtılan ortamı temizlemenin ilk adımı olarak, işleç kaynaklarını aşağıdaki sırayla silerek başlayın:

  • SNS
  • Site
  • CGV

Yalnızca bu işleç kaynakları başarılı bir şekilde silindiğinde, kullanıcı NAKS kümesi gibi diğer ortam kaynaklarını silmeye devam etmesi gerekir.

Önemli

Kaynakların sıra dışı silinmesi, yalnız bırakılmış kaynakların geride bırakılmasına neden olabilir.

Yayımcı Kaynakları

Eklenen ortamı temizlemenin ilk adımı olarak, yayımcı kaynaklarını aşağıdaki sırayla silerek başlayın:

  • NSDV
  • NSDG

Önemli

NFDV'yi silmeden önce SNS'nin silindiğinden emin olun.

  • NFDV
  • NFDG
  • Yapıt Bildirimi
  • Yapı Deposu
  • Publisher

Önemli

Kaynakların sıra dışı silinmesi, yalnız bırakılmış kaynakların geride bırakılmasına neden olabilir.

NfApp Sıralı Sıralama Davranışı

Genel bakış

Varsayılan olarak, kapsayıcılı ağ işlevi uygulamaları (NfApps) ağ işlevi tasarım sürümünde (NFDV) göründükleri sıralı sıraya göre yüklenir veya güncelleştirilir. Silme işlemi için NfApps ters sırada silinir. Bir yayımcının NfApps'in varsayılandan farklı belirli sıralamasını tanımlaması gerektiğinde, yükleme, güncelleştirme ve silme işlemleri için benzersiz bir sıra tanımlamak için dependsOnProfile kullanılır.

dependsOnProfile'ı kullanma

Bir yayımcı, NfApps için helm yürütme sırasını denetlemek için NFDV'deki dependsOnProfile dosyasını kullanabilir. Aşağıdaki örnekte, yükleme işleminde NfApps şu sırayla dağıtılır: dummyApplication1, dummyApplication2, sonra da dummyApplication. Güncelleştirme işleminde NfApps şu sırayla güncelleştirilir: dummyApplication2, dummyApplication1, sonra da dummyApplication. Silme işleminde NfApps şu sırayla silinir: dummyApplication2, dummyApplication1, ardından 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"
    }
}

Sık Karşılaşılan Hatalar

Bugünden itibaren, NFDV'de sağlanan dependsOnProfile geçersizse, NF işlemi bir doğrulama hatasıyla başarısız olur. Doğrulama hata iletisi işlem durumu kaynağında gösterilir ve aşağıdaki örneğe benzer.

 {
  "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 ile ilgili dikkat edilmesi gerekenler

Bazı durumlarda, üçüncü taraf helm grafikleri registryURL için AOSM gereksinimleriyle tam olarak uyumlu olmayabilir. Bu durumda, helm paketlerinde değişiklik yapmaktan kaçınmak için injectArtifactStoreDetails özelliği kullanılabilir.

Etkinleştirme

injectArtifactStoreDetails kullanmak için NF kaynak rolüOrverrides bölümündeki installOptions parametresini true olarak ayarlayın, ardından kayıt defteri URL'sini geçerli tutmak için gereken kayıt defteriURL değerini kullanın. Aşağıdaki injectArtifactStoreDetails parametresinin etkinleştirildiği örne bakın.

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"}}}}}'
    ]
  }
}