Condividi tramite

Procedure consigliate di Azure Operator Service Manager per eseguire l'onboarding e la distribuzione di funzioni di rete

  • Articolo

Microsoft ha sviluppato molte procedure comprovate per la gestione delle funzioni di rete (NF) usando Azure Operator Service Manager. Questo articolo fornisce linee guida che i fornitori NF, gli operatori di telecomunicazioni e i loro partner possono seguire per ottimizzare la progettazione. Tenere presenti queste procedure quando si esegue l'onboarding e si distribuiscono le NF.

Considerazioni generali

È consigliabile eseguire prima l'onboarding e distribuire le NF più semplici (uno o due grafici) usando le guide introduttive per acquisire familiarità con il flusso complessivo. È possibile aggiungere i dettagli di configurazione necessari nelle iterazioni successive. Quando si esaminano le guide introduttive, considerare i punti seguenti:

  • Strutturare gli artefatti per allinearsi all'uso pianificato. Valutare la possibilità di separare gli artefatti globali dagli elementi che si desidera variare in base al sito o all'istanza.
  • Assicurarsi che la composizione del servizio di più NF con un set di parametri che corrisponda alle esigenze della rete. Ad esempio, si potrebbe avere un grafico con 1.000 valori e personalizzare solo 100 di essi. Assicurarsi che nel livello CGS (Configuration Group Schema) (descritto più ampiamente nelle sezioni successive) sia possibile esporre solo 100.
  • Si pensi in anticipo a come separare l'infrastruttura (ad esempio, i cluster) o gli archivi artefatti e l'accesso tra i fornitori, in particolare all'interno di un singolo servizio. Impostare il set di risorse dell'editore in modo che corrisponda a questo modello.
  • Il sito di Azure Operator Service Manager è un concetto logico, una rappresentazione di una destinazione di distribuzione. Alcuni esempi sono un cluster Kubernetes per le funzioni di rete in contenitori o un percorso personalizzato esteso di Nexus operatore di Azure per le funzioni di rete virtualizzate.Examples are a Kubernetes cluster for Containerized Network Functions (CNF) or an Azure Operator Nexus extended location for Virtualized Network Functions (VNFs). Non è una rappresentazione di un sito perimetrale fisico, quindi si hanno casi d'uso in cui più siti condividono la stessa posizione fisica.
  • Azure Operator Service Manager offre varie API che semplificano la combinazione con ADO o altri strumenti di pipeline.

Considerazioni sul server di pubblicazione

  • È consigliabile creare un singolo editore per ogni fornitore NF. Questa procedura offre un supporto ottimale, manutenzione e un'esperienza di governance in tutti i fornitori e semplifica la progettazione del servizio di rete quando sono composte da più NF da più fornitori.

  • Dopo che il set desiderato di risorse e artefatti dell'editore di Azure Operator Service Manager viene testato e approvato per l'uso in produzione, è consigliabile contrassegnare l'intero set come non modificabile per evitare modifiche accidentali e garantire un'esperienza di distribuzione coerente. Prendere in considerazione la possibilità di basarsi sulle funzionalità di immutabilità per distinguere le risorse e gli artefatti usati nell'ambiente di produzione rispetto a quelli usati per scopi di test e sviluppo. È possibile eseguire una query sullo stato delle risorse del server di pubblicazione e dei manifesti dell'artefatto per determinare quali sono contrassegnati come non modificabili. Per altre informazioni, vedere Tenant, sottoscrizioni, aree e gestione dell'anteprima del server di pubblicazione.

    Tenere presente la logica seguente:

    • Se la versione di progettazione del servizio di rete (NSDV) è contrassegnata come non modificabile, anche CGS deve essere contrassegnato come non modificabile. In caso contrario, la chiamata di distribuzione non riesce.
    • Se Network Function Design Version (NFDV) è contrassegnato come non modificabile, anche il manifesto dell'artefatto deve essere contrassegnato come non modificabile. In caso contrario, la chiamata di distribuzione non riesce.
    • Se solo il manifesto dell'artefatto o CGS è contrassegnato come non modificabile, la chiamata di distribuzione ha esito positivo indipendentemente dal fatto che NFDV e NSDV siano contrassegnati come non modificabili.
    • Contrassegnare un manifesto di artefatto come non modificabile garantisce che tutti gli artefatti elencati in tale manifesto (in genere, grafici, immagini e modelli di Azure Resource Manager [modelli ARM]) siano contrassegnati come non modificabili applicando anche le autorizzazioni necessarie per l'archivio artefatti.

  • Prendere in considerazione l'uso di convenzioni di denominazione concordate e tecniche di governance per risolvere eventuali lacune rimanenti.

Considerazioni sulla versione e sul gruppo di definizioni di funzioni di rete

Network Function Definition Group (NFDG) rappresenta il componente più piccolo che si prevede di riutilizzare in modo indipendente tra più servizi. Tutte le parti di un NFDG vengono sempre distribuite insieme. Queste parti sono denominate networkFunctionApplications. Ad esempio, è naturale eseguire l'onboarding di un singolo NF composto da più grafici Helm e immagini come singolo NFDG se si distribuiscono sempre questi componenti insieme. Nei casi in cui più NF vengono sempre distribuite insieme, è ragionevole avere un singolo NFDG per tutti. I singoli NFDG possono avere più NFDV.

Per le versioni delle definizioni di funzione di rete in contenitori (CNF NFDV), l'elenco networkFunctionApplications è in grado di contenere solo pacchetti Helm. È ragionevole includere più pacchetti Helm se vengono sempre distribuiti ed eliminati insieme.

Per le versioni delle definizioni delle funzioni di rete virtualizzate (VNF NFDV), l'elenco networkFunctionApplications deve contenere almeno un VhdImageFile e un modello di ARM. Il modello di ARM deve distribuire una singola macchina virtuale (VM). Per distribuire più macchine virtuali per un singolo VNF, assicurarsi di usare modelli di ARM separati per ogni macchina virtuale.

Il modello di ARM può distribuire solo le risorse di Resource Manager dai provider di risorse seguenti:

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

Nota

Per i modelli ARM contenenti qualsiasi elemento oltre l'elenco precedente, tutte le chiamate PUT e Re-PUT sul VNF generano un errore di convalida.

Casi d'uso comuni che attivano l'aggiornamento della versione secondaria o principale di Network Function Design Version

  • Aggiornamento dei valori del gruppo di configurazione/CGS per una versione esistente che attiva la modifica di deployParametersMappingRuleProfile.
  • Aggiornamento di valori hard-coded in NFDV.
  • Contrassegno dei componenti inattivi per impedire la distribuzione tramite applicationEnablement: Disabled.
  • Nuova versione NF, ad esempio grafici e immagini.

Nota

Numero minimo di modifiche necessarie ogni volta che il payload di un determinato NF cambia. Una versione NF secondaria o principale senza esporre nuovi parametri CGS richiede solo l'aggiornamento del manifesto dell'artefatto, il push di nuove immagini e grafici e l'urto della versione NFDV.

Considerazioni sul gruppo di progettazione e sulla versione dei servizi di rete

Il gruppo di progettazione dei servizi di rete (NSDG) è un composito di uno o più gruppi NFDG e di tutti i componenti dell'infrastruttura (ad esempio, cluster e macchine virtuali Nexus Azure Kubernetes Service [NAKS]/Servizio Azure Kubernetes [AKS]) distribuiti contemporaneamente. Un servizio di rete del sito (SNS) fa riferimento a un singolo NSDV. Tale progettazione garantisce una distribuzione coerente e ripetibile del servizio di rete in un determinato sito da un singolo SNS PUT.

Un esempio di NSDG è:

  • Funzione server di autenticazione (AUSF) NF
  • Gestione dati unificata (UDM) NF
  • Macchina virtuale amministratore che supporta AUSF/UDM
  • Funzione di gestione delle sessioni (SMF) di Unity Cloud (UC) NF
  • Cluster NAKS, in cui vengono distribuiti AUSF, UDM e SMF

Questi cinque componenti formano un singolo NSDG. Un singolo NSDG può avere più NSDV.

Casi d'uso comuni che attivano l'aggiornamento della versione secondaria o principale della versione del servizio di rete

  • Creazione o eliminazione di CGS.
  • Modifiche apportate al modello ARM NF associato a una delle NF distribuite.
  • Modifiche apportate al modello ARM dell'infrastruttura, ad esempio servizio Azure Kubernetes/NAKS o macchina virtuale.

Nota

Le modifiche apportate a NFDV non devono attivare un aggiornamento NSDV. Il valore NFDV deve essere esposto come parametro all'interno del CGS, in modo che gli operatori possano controllare cosa distribuire usando ICGV.

Considerazioni sullo schema del gruppo di configurazione

È consigliabile iniziare sempre con un singolo CGS per l'intero NF. Se sono presenti parametri specifici del sito o specifici dell'istanza, è comunque consigliabile mantenerli in un singolo CGS. È consigliabile suddividere in più CGS quando sono presenti più componenti (raramente NF, più comunemente, infrastruttura) o configurazioni condivise tra più NF. Il numero di CGS definisce il numero di CGV.

Scenario

  • FluentD, Kibana e Splunk (componenti di terze parti comuni) vengono sempre distribuiti per tutte le NF all'interno di un NSD. È consigliabile raggruppare questi componenti in un singolo NFDG.
  • NSD include più NF che condividono tutte alcune configurazioni (percorso di distribuzione, nome editore e alcune configurazioni del grafico).

In questo scenario, è consigliabile usare un singolo CGS globale per esporre le configurazioni comuni dei componenti di terze parti e NF. È possibile definire CGS specifici di NF in base alle esigenze.

Scegliere i parametri da esporre

  • CGS deve avere solo parametri usati da NF (configurazione giorno 0/N) o componenti condivisi.
  • I parametri configurati raramente devono avere valori predefiniti definiti.
  • Se vengono usati più CGS, è consigliabile non sovrapporsi tra i parametri. Se è necessaria la sovrapposizione, assicurarsi che i nomi dei parametri siano chiaramente distinguibili tra i CGS.
  • Ciò che può essere definito tramite API (Azure Operator Nexus, Azure Operator Service Manager) deve essere considerato per CGS. Anziché, ad esempio, definire tali valori di configurazione tramite file CloudInit.
  • In caso di dubbi, un buon punto di partenza consiste nell'esporre il parametro e avere un valore predefinito ragionevole specificato in CGS. L'esempio seguente illustra il CGS di esempio e i payload CGV corrispondenti.
  • Una singola identità gestita assegnata dall'utente deve essere usata in tutti i modelli ARM NF e deve essere esposta tramite CGS.

Payload CGS:

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

Payload CGV corrispondente passato dall'operatore:

{
"qwe": 20
}

Payload CGV risultante generato da Azure Operator Service Manager:

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

Considerazioni relative ai valori dei gruppi di configurazione

Prima di inviare la creazione della risorsa CGV, è possibile verificare che lo schema e i valori del file YAML o JSON sottostante corrispondano a quanto previsto dal CGS corrispondente. A tale scopo, un'opzione consiste nell'usare l'estensione YAML per Visual Studio Code.

Considerazioni sull’interfaccia della riga di comando

L'estensione dell'interfaccia della riga di comando di Azure Operator Service Manager è utile per la pubblicazione di NSD e NFD. Usare questo strumento come punto di partenza per la creazione di nuovi NSD e NFD. Prendere in considerazione l'uso dell'interfaccia della riga di comando per creare i file iniziali. Quindi modificarli per incorporare i componenti dell'infrastruttura prima della pubblicazione.

Considerazioni sul servizio di rete del sito

È consigliabile disporre di un singolo servizio SNS per l'intero sito, inclusa l'infrastruttura. SNS deve distribuire qualsiasi infrastruttura necessaria (ad esempio, cluster NAKS/servizio Azure Kubernetes e macchine virtuali) e quindi distribuire le NF necessarie. Tale progettazione garantisce una distribuzione coerente e ripetibile del servizio di rete in un determinato sito da un singolo SNS PUT.

È consigliabile distribuire ogni servizio SNS con un'identità gestita assegnata dall'utente anziché un'identità gestita assegnata dal sistema. Questa identità gestita assegnata dall'utente deve avere le autorizzazioni per accedere alla NFDV e deve avere il ruolo di Operatore identità gestita su se stesso. Per altre informazioni, vedere Creare e assegnare un'identità gestita assegnata dall'utente.

Mapping delle risorse di Azure Operator Service Manager per caso d'uso

I due scenari seguenti illustrano il mapping delle risorse di Azure Operator Service Manager.

Scenario: singola funzione di rete

Un NF con uno o due componenti dell'applicazione viene distribuito in un cluster NAKS.

Scomposizione delle risorse:

  • NFDG: se i componenti possono essere usati in modo indipendente, due gruppi NFDG, uno per componente. Se i componenti vengono sempre distribuiti insieme, un singolo NFDG.
  • NSDV: come necessario in base ai casi d'uso illustrati nelle sezioni "Casi d'uso comuni" precedenti che attivano gli aggiornamenti della versione secondaria o principale di NFDV.
  • NSDG: singolo. Combina le definizioni delle NF e dei cluster Kubernetes.
  • NSDV: come necessario in base ai casi d'uso illustrati nelle sezioni "Casi d'uso comuni" precedenti che attivano gli aggiornamenti della versione secondaria o principale di NSDV.
  • CGS: singolo. È consigliabile che CGS includa sottosezioni per ogni componente e infrastruttura da distribuire per una gestione più semplice e include le versioni per i dischi NFD.
  • CGV: singolo in base al numero di CGS.
  • SNS: singolo per NSDV.

Scenario: più funzioni di rete

Più NF con alcuni componenti condivisi e indipendenti vengono distribuiti in un cluster NAKS.

Scomposizione delle risorse:

  • NFDG:
    • NFDG per tutti i componenti condivisi.
    • NFDG per ogni componente indipendente o NF.
  • NSDV: diversi per ogni NFDG per caso d’uso illustrato nelle sezioni "Casi d'uso comuni" precedenti che attiva gli aggiornamenti della versione secondaria o principale di NFDV.
  • NSDG: singolo. Combina tutte le NF, i componenti condivisi e indipendenti e l'infrastruttura (cluster Kubernetes o qualsiasi macchina virtuale di supporto).
  • NSDV: come necessario in base ai casi d'uso illustrati nelle sezioni "Casi d'uso comuni" precedenti che attivano gli aggiornamenti della versione secondaria o principale di NSDV.
  • CGS:
    • Single. Globale per tutti i componenti con valori di configurazione condivisi.
    • NF CGS per NF, inclusa la versione del NFD.
    • A seconda del numero totale di parametri, valutare la possibilità di combinare tutti i CGS in un singolo CGS.
  • CGV: uguale al numero di CGS.
  • SNS: singolo per NSDV.

Considerazioni sull'aggiornamento software

Supponendo che le NF supportino gli aggiornamenti sul posto/nel servizio, per le funzioni CNF:

  • Se vengono aggiunti nuovi grafici e immagini, Azure Operator Service Manager installa i nuovi grafici.
  • Se alcuni grafici e immagini vengono rimossi, Azure Operator Service Manager elimina i grafici che non sono più dichiarati nella vista NFDV.
  • Azure Operator Service Manager convalida che il valore NFDV/NSDV proviene dallo stesso NFDG/NSDG e quindi dallo stesso server di pubblicazione. Gli aggiornamenti tra server di pubblicazione non sono supportati.

Per le VNF:

  • Gli aggiornamenti sul posto non sono attualmente supportati. È necessario creare un'istanza di un nuovo VNF con un'immagine aggiornata affiancata. Eliminare quindi il VNF precedente eliminando SNS.
  • Se VNF viene distribuito come coppia di macchine virtuali per la disponibilità elevata, è possibile progettare il servizio di rete in modo da poter eliminare e aggiornare le macchine virtuali una alla volta. È consigliabile usare la progettazione seguente per consentire l'eliminazione e l'aggiornamento di singole macchine virtuali:
    • Ogni macchina virtuale viene distribuita usando un modello di ARM dedicato.
    • Dal modello di ARM, è necessario esporre due parametri tramite CGS: nome macchina virtuale, per consentire l'indicazione dell'istanza primaria/secondaria e dei criteri di distribuzione, controllando se la distribuzione di macchine virtuali è consentita o meno.
    • In NFDV deployParameters e templateParameters devono essere parametrizzati in modo da poter fornire i valori univoci usando ICGV per ognuno.

Considerazioni relative alla disponibilità elevata e al ripristino di emergenza

Azure Operator Service Manager è un servizio a livello di area distribuito tra le zone di disponibilità nelle aree che le supportano. Per tutte le aree in cui è disponibile Azure Operator Service Manager, vedere Prodotti Azure in base a area. Per l'elenco delle aree di Azure con zone di disponibilità, vedere Scegliere l'area di Azure appropriata.

Considerare i requisiti di disponibilità elevata e ripristino di emergenza seguenti:

  • Per garantire la ridondanza geografica, assicurarsi di disporre di un server di pubblicazione in ogni area in cui si prevede di distribuire NF. Prendere in considerazione l'uso delle pipeline per assicurarsi che gli artefatti e le risorse dell'editore vengano mantenuti sincronizzati tra le aree.
  • Il nome dell'editore deve essere univoco per area per ogni tenant di Microsoft Entra.

Nota

Se un'area non è più disponibile, è possibile distribuire (ma non aggiornare) un NF usando le risorse del server di pubblicazione in un'altra area. Supponendo che gli artefatti e le risorse siano identici tra i server di pubblicazione, è sufficiente modificare il valore networkServiceDesignVersionOfferingLocation nel payload della risorsa SNS.

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

Considerazioni relative alla risoluzione dei problemi

Durante l'installazione e l'aggiornamento per impostazione predefinita, le opzioni atomiche e di attesa sono impostate su true e il timeout dell'operazione è impostato su 27 minutes. Durante l'onboarding iniziale, solo durante il debug e lo sviluppo di artefatti, è consigliabile impostare il flag atomico su false. Questo impedisce un rollback helm in caso di errore e mantiene eventuali log o errori che altrimenti andranno persi. Il modo ottimale per eseguire questa operazione si trova nel modello ARM di NF.

Nel modello di ARM aggiungere la sezione seguente:

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

Il nome del componente è definito in NFDV:

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

Importante

Assicurarsi che atomica e attesa siano impostate di nuovo su true dopo il completamento dell'onboarding iniziale.

Considerazioni sulla pulizia

Risorse operatore

Come primo passaggio per la pulizia di un ambiente distribuito, iniziare eliminando le risorse dell'operatore nell'ordine seguente:

  • SNS
  • Site
  • CGV

Una volta eliminate correttamente queste risorse dell'operatore, un utente deve continuare a eliminare altre risorse di ambiente, ad esempio il cluster NAKS.

Importante

L'eliminazione di risorse non in ordine può comportare la rimozione di risorse orfane.

Risorse del server di pubblicazione

Come primo passaggio per pulire un ambiente di cui è stato eseguito l'onboarding, iniziare eliminando le risorse dell'editore nell'ordine seguente:

  • NSDV
  • NSDG

Importante

Assicurarsi che SNS venga eliminato prima di eliminare il valore NFDV.

  • NFDV
  • NFDG
  • Manifesto artefatto
  • Archivio di artefatti
  • Publisher

Importante

L'eliminazione di risorse non in ordine può comportare la rimozione di risorse orfane.

Comportamento di ordinamento sequenziale di NfApp

Panoramica

Per impostazione predefinita, le applicazioni per le funzioni di rete in contenitori (NfApps) vengono installate o aggiornate in base all'ordine sequenziale in cui vengono visualizzate nella versione di progettazione delle funzioni di rete (NFDV). Per l'eliminazione, NfApps vengono eliminati nel sepcified dell'ordine inverso. Quando un editore deve definire un ordinamento specifico di NfApps, diverso dal valore predefinito, viene usato un oggetto dependsOnProfile per definire una sequenza univoca per le operazioni di installazione, aggiornamento ed eliminazione.

Come usare dependsOnProfile

Un server di pubblicazione può usare dependsOnProfile in NFDV per controllare la sequenza di esecuzioni helm per NfApps. Dato l'esempio seguente, nell'operazione di installazione, NfApps verrà distribuito nell'ordine seguente: dummyApplication1, dummyApplication2, quindi dummyApplication. In caso di operazione di aggiornamento, NfApps verrà aggiornato nell'ordine seguente: dummyApplication2, dummyApplication1, quindi dummyApplication. In caso di operazione di eliminazione, NfApps verrà eliminato nell'ordine seguente: dummyApplication2, dummyApplication1, quindi 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"
    }
}

Errori comuni

A partire da oggi, se dependsOnProfile fornito in NFDV non è valido, l'operazione NF avrà esito negativo con un errore di convalida. Il messaggio di errore di convalida viene visualizzato nella risorsa di stato dell'operazione e ha un aspetto simile all'esempio seguente.

 {
  "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."
  }
}

considerazioni su injectArtifactStoreDetails

In alcuni casi, i grafici Helm di terze parti potrebbero non essere completamente conformi ai requisiti di AOSM per RegistryURL. In questo caso, è possibile usare la funzionalità injectArtifactStoreDetails per evitare di apportare modifiche ai pacchetti Helm.

Abilitazione

Per usare injectArtifactStoreDetails, impostare il parametro installOptions nella sezione ruolo risorsa NFOrverrides su true, quindi usare qualsiasi valore registryURL necessario per mantenere valido l'URL del Registro di sistema. Vedere l'esempio seguente del parametro injectArtifactStoreDetails abilitato.

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