Partager via

Meilleures pratiques Azure Operator Service Manager pour intégrer et déployer des fonctions réseau

  • Article

Microsoft a développé de nombreuses pratiques éprouvées pour la gestion des fonctions réseau (NFs) en utilisant Azure Operator Service Manager. Cet article fournit des instructions que les fournisseurs de NF, les opérateurs de télécommunications et leurs partenaires peuvent suivre pour optimiser la conception. Gardez ces pratiques à l’esprit lorsque vous intégrez et déployez vos NFs.

Considérations d’ordre général

Nous vous recommandons d’intégrer et de déployer d’abord vos NFs les plus simples (un ou deux graphiques) en utilisant les guides de démarrage rapide pour vous familiariser avec le flux global. Vous pouvez ajouter les détails de configuration nécessaires dans les itérations suivantes. À mesure que vous parcourez les guides de démarrage rapide, tenez compte des points suivants :

  • Structurez vos artefacts pour qu’ils s’alignent sur l’utilisation planifiée. Envisagez de séparer les artefacts globaux des artefacts que vous souhaitez faire varier selon le site ou l’instance.
  • Assurez-vous de la composition de service de plusieurs NFs avec un ensemble de paramètres qui correspond aux besoins de votre réseau. Par exemple, vous pouvez avoir un graphique qui a 1000 valeurs et vous ne personnalisez que 100 d’entre elles. Assurez-vous que, dans la couche Schéma de groupe de configuration (CGS) (couverte plus largement dans les sections qui suivent), vous n’exposez que 100.
  • Réfléchissez rapidement à la façon dont vous souhaitez séparer l’infrastructure (par exemple, en clusters) ou les magasins d’artefacts et l’accès entre les fournisseurs, en particulier au sein d’un seul service. Faites correspondre votre ensemble de ressources de serveur de publication à ce modèle.
  • Le site Azure Operator Service Manager est un concept logique, une représentation d’une destination de déploiement. Il s’agit par exemple d’un cluster Kubernetes pour les fonctions réseau en conteneur (Containerized Network Functions/CNF) ou d’un emplacement personnalisé étendu d’Azure Operator Nexus pour les fonctions réseau virtualisées (Virtualized Network Functions/VNF). Il ne s’agit pas d’une représentation d’un site de périphérie physique. Il existe donc des cas d’usage où plusieurs sites partagent le même emplacement physique.
  • Azure Operator Service Manager fournit différentes API qui facilitent la combinaison avec ADO ou d’autres outils de pipeline.

Considérations relatives au serveur de publication

  • Nous vous recommandons de créer un seul serveur de publication par fournisseur NF. Cette pratique offre une expérience optimale de support, de maintenance et de gouvernance pour tous les fournisseurs et simplifie la conception de votre service réseau lorsqu’elle est composée de plusieurs NFs de plusieurs fournisseurs.

  • Une fois que l’ensemble souhaité de ressources et d’artefacts du serveur de publication Azure Operator Service Manager est testé et approuvé pour une utilisation en production, nous vous recommandons de marquer l’ensemble comme immuable pour empêcher des modifications accidentelles et garantir une expérience de déploiement cohérente. Envisagez de vous appuyer sur des fonctionnalités d’immuabilité pour distinguer les ressources et les artefacts utilisés en production et ceux utilisés à des fins de test et de développement. Vous pouvez interroger l’état des ressources du serveur de publication et les manifestes d’artefact pour déterminer ceux qui sont marqués comme immuables. Pour plus d’informations, consultez Gestion des locataires, des abonnements, des régions et de la gestion en préversion des serveurs de publication.

    Gardez à l’esprit la logique suivante :

    • Si NSDV (Network Service Design Version) est marqué comme immuable, CGS doit également être marqué comme immuable. Sinon, l’appel de déploiement échoue.
    • Si la version de conception de fonction réseau (Network Function Design Version/NFDV) est marquée comme immuable, le manifeste de l’artefact doit également être marqué comme immuable. Sinon, l’appel de déploiement échoue.
    • Si seul le manifeste d’artefact ou le CGS sont marqués comme immuable, l’appel de déploiement réussit, que la NFDV et la NSDV soient marquées comme immuables.
    • Le marquage d’un manifeste d’artefact comme immuable garantit que tous les artefacts répertoriés dans ce manifeste (généralement, les graphiques, les images et les modèles Azure Resource Manager [modèles ARM]) sont également marqués comme immuables en appliquant les autorisations nécessaires sur le magasin d’artefacts.

  • Envisagez d’utiliser des conventions d’affectation de noms et des techniques de gouvernance convenus pour aider à combler toute lacune restante.

Considérations sur la version et le groupe de définition de fonction réseau

Le groupe de définition de fonction réseau (NFDG) représente le plus petit composant que vous prévoyez de réutiliser indépendamment sur plusieurs services. Toutes les parties d’un NFDG sont toujours déployées ensemble. Ces parties sont appelées networkFunctionApplications. Par exemple, il est naturel d’intégrer une seule NF composée de plusieurs graphiques et images Helm sous la forme d’un seul NFDG si vous déployez toujours ces composants ensemble. Dans les cas où plusieurs NFs sont toujours déployées ensemble, il est raisonnable d’avoir un seul NFDG pour toutes ces fonctions. Les NFDG uniques peuvent avoir plusieurs NFDV.

Pour les versions de définition de fonction réseau conteneurisée (CNF NFDV), la liste networkFunctionApplications ne peut contenir que des packages Helm. Il est raisonnable d’inclure plusieurs packages Helm s’ils sont toujours déployés et supprimés ensemble.

Pour les versions de définition de fonction réseau virtualisée (VNF NFDV), la liste networkFunctionApplications doit contenir au moins un VhdImageFile et un modèle ARM. Le modèle ARM doit déployer une seule machine virtuelle (VM). Pour déployer plusieurs VMs pour une VNF unique, veillez à utiliser des modèles ARM distincts pour chaque VM.

Le modèle ARM ne peut déployer des ressources Resource Manager provenant des fournisseurs de ressources suivants :

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

Remarque

Pour les modèles ARM contenant tout élément au-delà de la liste précédente, tous les appels PUT et Re-PUT sur la VNF entraînent une erreur de validation.

Cas d’usage courants qui déclenchent une mise à jour mineure ou majeure de la version de conception de fonction réseau

  • Mise à jour du CGS/des Valeurs de groupe de configuration (Configuration Group Values/CGV) pour une version existante qui déclenche la modification du fichier deployParametersMappingRuleProfile.
  • Mise à jour des valeurs codées en dur dans la NFDV.
  • Marquage des composants inactifs pour les empêcher d’être déployés via applicationEnablement: Disabled.
  • Nouvelle version de NF, comme des graphiques et des images.

Remarque

Nombre minimal de modifications requises chaque fois que la charge utile d’une NF donnée change. Une version mineure ou majeure de NF sans exposer les nouveaux paramètres du CGS ne nécessite que la mise à jour du manifeste d’artefact, l’envoi de nouvelles images et graphiques et le passage à la version NFDV.

Considérations relatives au groupe de conception et aux versions de service réseau

Network Service Design Group (NSDG) est un composite d’un ou plusieurs NFDG et de tous les composants d’infrastructure (comme les clusters et les machines virtuelles Nexus Azure Kubernetes Service [NAKS]/Azure Kubernetes Service [AKS]) déployés en même temps. Un service de réseau de site (SNS) fait référence à une NSDV unique. Cette conception garantit un déploiement homogène et reproductible du service réseau sur un site donné à partir d’un seul SNS PUT.

Voici un exemple de NSDG :

  • NF Fonction de serveur d’authentification (AUSF)
  • NF Gestion des données unifiée (UDM)
  • Machine virtuelle d’administration prenant en charge AUSF/UDM
  • NF Unity Cloud (UC) Session Management Function (SMF)
  • Cluster NAKS, sur lequel AUSF, UDM et SMF sont déployés

Ces cinq composants forment un NSDG unique. Un NSDG unique peut avoir plusieurs NSDV.

Cas d’usage courants qui déclenchent la mise à jour mineure ou majeure de la version de la conception du service réseau

  • Créer ou supprimer les CGS.
  • Modifications apportées à la NF modèle ARM associée à l’une des NFs déployées.
  • Modifications apportées au modèle ARM d’infrastructure, par exemple AKS/NAKS ou machine virtuelle.

Remarque

Les modifications apportées à la NFDV ne doivent pas déclencher de mise à jour de la NSDV. La valeur NFDV doit être exposée en tant que paramètre au sein du CGS, afin que les opérateurs puissent contrôler ce qu’il faut déployer à l’aide des CGV.

Considérations relatives au schéma de groupe de configuration

Nous vous recommandons de commencer toujours avec un seul CGS pour l’ensemble de la NF. S’il existe des paramètres spécifiques au site ou à l’instance, nous vous recommandons toujours de les conserver dans un CGS unique. Nous vous recommandons de fractionner en plusieurs CGS lorsqu’il existe plusieurs composants (rarement des NFs, plus couramment, une infrastructure) ou des configurations partagées entre plusieurs NFs. Le nombre de CGS définit le nombre de CGV.

Scénario

  • FluentD, Kibana et Splunk (composants tiers courants) sont toujours déployés pour toutes les NFs au sein d’une NSD. Nous vous recommandons de regrouper ces composants en un NFDG unique.
  • Une NSD a plusieurs NFs qui partagent toutes quelques configurations (emplacement de déploiement, nom du serveur de publication et quelques configurations de graphique).

Dans ce scénario, nous vous recommandons d’utiliser un CGS global et unique pour exposer les configurations de composants de NF et tiers courants. Vous pouvez définir un CGS spécifique à la NF en fonction des besoins.

Choisir les paramètres à exposer

  • Le CGS ne doit avoir que des paramètres utilisés par des NFs (configuration jour 0/N) ou des composants partagés.
  • Les paramètres rarement configurés doivent avoir des valeurs par défaut définies.
  • Si plusieurs CGS sont utilisés, nous vous recommandons peu ou pas de chevauchement entre les paramètres. Si un chevauchement est nécessaire, assurez-vous que les noms des paramètres sont clairement distinguables entre les CGS.
  • Ce qui peut être défini via API (Azure Operator Nexus, Azure Operator Service Manager) doit être pris en compte pour le CGS. Par opposition à la définition de ces valeurs de configuration par le biais de fichiers CloudInit, par exemple.
  • Lorsque vous n’êtes pas sûr, un bon point de départ consiste à exposer le paramètre et à avoir une valeur par défaut raisonnable spécifiée dans le CGS. L’exemple suivant montre les exemples de charges utiles CGS et CGV correspondantes.
  • Une identité managée affectée par l’utilisateur unique doit être utilisée dans tous les modèles de NF ARM et doit être exposée via le CGS.

Charge utile CGS :

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

Charge utile CGV correspondante transmise par l’opérateur :

{
"qwe": 20
}

Charge utile CGV résultante générée par Azure Operator Service Manager :

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

Considérations relatives aux valeurs de groupe de configuration

Avant d’envoyer la création de la ressource CGV, vous pouvez vérifier que le schéma et les valeurs du fichier YAML ou JSON sous-jacent correspondent à ce que le CGS correspondant attend. Pour ce faire, une option consiste à utiliser l’extension YAML pour Visual Studio Code.

Considérations CLI

L’extension CLI Azure Operator Service Manager vous aide à publier les NFD et les NSD. Utilisez cet outil comme point de départ pour créer de nouvelles NFD et NSD. Envisagez d’utiliser l’interface CLI pour créer les fichiers initiaux. Modifiez-les ensuite pour incorporer des composants d’infrastructure avant de publier.

Considérations relatives au service de réseau de site

Nous vous recommandons d’avoir un SNS unique pour l’ensemble du site, y compris l’infrastructure. Le SNS doit déployer toute infrastructure requise (par exemple, les clusters et les machines virtuelles NAKS/AKS), puis déployer les NFs requises par-dessus. Cette conception garantit un déploiement homogène et reproductible du service réseau sur un site donné à partir d’un seul SNS PUT.

Nous vous recommandons de déployer chaque SNS avec une identité managée affectée par l’utilisateur plutôt qu’avec une identité managée affectée par le système. Cette identité managée affectée par l’utilisateur doit disposer des autorisations nécessaires pour accéder à la NFDV et doit avoir le rôle d’opérateur d’identité managée sur lui-même. Pour plus d’informations, consultez Créer et affecter une identité managée affectée par l’utilisateur.

Mappage des ressources Azure Operator Service Manager par cas d’usage

Les deux scénarios suivants illustrent le mappage des ressources Azure Operator Service Manager.

Scénario : fonction réseau unique

Une NF avec un ou deux composants d’application est déployée sur un cluster NAKS.

Répartition des ressources :

  • NFDG : si les composants peuvent être utilisés indépendamment, deux NFDG, un par composant. Si les composants sont toujours déployés ensemble, un NFDG unique est déployé.
  • NFDV : selon les besoins en fonction des cas d’usage mentionnés dans les sections « Cas d’usage courants » précédentes, qui déclenchent les mises à jour mineures ou principales de la NFDV.
  • NSDG : unique. Combine les NFs et les définitions de cluster Kubernetes.
  • NSDV : si nécessaire en fonction des cas d’usage mentionnés dans les sections précédentes « Cas d’usage courants » qui déclenchent des mises à jour mineures ou majeures de la NSDV.
  • CGS : unique. Nous vous recommandons que le CGS dispose de sous-sections pour chaque composant et infrastructure déployés pour faciliter la gestion, et comprenne les versions des NFD.
  • CGV : unique en fonction du nombre de CGS.
  • SNS : unique par NSDV.

Scénario : plusieurs fonctions réseau

Plusieurs NFs avec certains composants partagés et indépendants sont déployés sur un cluster NAKS.

Répartition des ressources :

  • NFDG :
    • NFDG pour tous les composants partagés.
    • NFDG pour chaque composant indépendant ou NF.
  • NFDV : plusieurs pour chaque NFDG par cas d’usage mentionné dans les sections « Cas d’usage courants » précédentes, qui déclenchent les mises à jour mineures ou principales de la NFDV.
  • NSDG : unique. Combine l’ensemble des NFs, les composants partagés et indépendants et l’infrastructure (cluster Kubernetes ou toutes les VMs le prenant en charge).
  • NSDV : si nécessaire en fonction des cas d’usage mentionnés dans les sections précédentes « Cas d’usage courants » qui déclenchent des mises à jour mineures ou majeures de la NSDV.
  • CGS :
    • Célibataire. Global pour tous les composants qui ont des valeurs de configuration partagées.
    • NF CGS par NF, y compris la version de la NFD.
    • Selon le nombre total de paramètres, envisagez de combiner tous les CGS en un CGS unique.
  • CGV : identique au nombre de CGS.
  • SNS : unique par NSDV.

Considérations relatives à la mise à niveau logicielle

En supposant que les NFs prennent en charge les mises à niveau sur place/en service, pour les CNFs :

  • Si de nouveaux graphiques et images sont ajoutés, Azure Operator Service Manager installe les nouveaux graphiques.
  • Si certains graphiques et images sont supprimés, Azure Operator Service Manager supprime les graphiques qui ne sont plus déclarés dans la NFDV.
  • Azure Operator Service Manager vérifie que la NFDV/NSDV provient du même NFDG/NSDG, et donc du même serveur de publication. Les mises à niveau entre serveurs de publication ne sont pas prises en charge.

Pour les VNF :

  • Les mises à niveau sur place ne sont actuellement pas prises en charge. Vous devez instancier une nouvelle VNF avec une image mise à jour côte à côte. Supprimez ensuite l’ancienne VNF en supprimant le SNS.
  • Si une VNF est déployée en tant que paire de VMs pour la haute disponibilité, vous pouvez concevoir le service réseau de telle sorte que vous puissiez supprimer et mettre à niveau les VMs une par une. Nous vous recommandons la conception suivante pour autoriser la suppression et la mise à niveau de VMs individuelles :
    • Chaque VM est déployée en utilisant un modèle ARM dédié.
    • Depuis le modèle ARM, deux paramètres doivent être exposés via le CGS : nom de la machine virtuelle, pour autoriser l’indication de l’instance principale/secondaire, et la stratégie de déploiement, contrôlant si le déploiement de VM est autorisé ou non.
    • Dans la NFDV, deployParameters et templateParameters doivent être paramétrés de telle sorte que vous puissiez fournir les valeurs uniques à l’aide des CGV pour chacun d’eux.

Considérations relatives à la haute disponibilité et à la récupération d’urgence

Azure Operator Service Manager est un service régional déployé dans des zones de disponibilité dans les régions qui les prennent en charge. Pour savoir dans quelles régions Azure Operator Service Manager est disponible, consultez Produits Azure par région. Pour obtenir la liste des régions Azure qui ont des zones de disponibilité, consultez Choisir la région Azure qui vous convient.

Tenez compte des exigences suivantes en matière de haute disponibilité et de récupération d’urgence :

  • Pour fournir une géoredondance, vérifiez que vous disposez d’un serveur de publication dans chaque région où vous envisagez de déployer des NFs. Envisagez d’utiliser des pipelines pour vous assurer que les artefacts et ressources du serveur de publication sont maintenus synchronisés entre les régions.
  • Le nom du serveur de publication doit être unique par région par locataire Microsoft Entra.

Remarque

Si une région devient indisponible, vous pouvez déployer (mais pas mettre à niveau) une NF à l’aide des ressources de serveur de publication dans une autre région. En supposant que les artefacts et les ressources sont identiques entre les serveurs de publication, vous devez uniquement modifier la valeur networkServiceDesignVersionOfferingLocation dans la charge utile de la ressource 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

Considérations sur la résolution des problèmes

Pendant l’installation et la mise à niveau par défaut, les options atomiques et d’attente sont définies sur true, et le délai d’expiration de l’opération est défini sur 27 minutes. Lors de l’intégration initiale, et uniquement pendant que vous déboguez et développez des artefacts, nous vous recommandons de définir l’indicateur atomique sur false. pour éviter une restauration helm en cas d’échec et de conserver les journaux ou erreurs susceptibles d’être perdus. La meilleure façon de le faire se trouve dans le modèle ARM de la NF.

Dans le modèle ARM, ajoutez la section suivante :

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

Le nom du composant est défini dans la NFDV :

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

Important

Vérifiez que l’atomique et l’attente sont rétablis sur true une fois l’intégration initiale terminée.

Considérations relatives au nettoyage

Ressources de l’opérateur

À la première étape du nettoyage d’un environnement déployé, commencez par supprimer des ressources d’opérateur dans l’ordre suivant :

  • SNS
  • Site
  • CGV

Une seule fois que ces ressources d’opérateur sont correctement supprimées, si un(e) utilisateur(-trice) continue à supprimer d’autres ressources d’environnement, telles que le cluster NAKS.

Important

La suppression des ressources hors ordre peut entraîner l’abandon des ressources orphelines.

Ressources de l’éditeur

La première étape du nettoyage d'un environnement embarqué consiste à supprimer les ressources de l'éditeur dans l'ordre suivant :

  • NSDV
  • NSDG

Important

Vérifiez que SNS est supprimé avant de supprimer la NFDV.

  • NFDV
  • NFDG
  • Manifeste d’Artéfact
  • Magasin d’Artéfacts
  • Éditeur

Important

La suppression des ressources hors ordre peut entraîner l’abandon des ressources orphelines.

Comportement de classement séquentiel NfApp

Vue d’ensemble

Par défaut, les applications de fonction réseau (NfApps) conteneurisées sont installées ou mises à jour en fonction de l’ordre séquentiel dans lequel elles apparaissent dans la version de conception de fonction réseau (NFDV). Pour la suppression, les NfApps sont supprimées dans l’ordre inverse spécifié. Lorsqu’un éditeur doit définir un ordre spécifique des NfApps, différent de l’ordre par défaut, dependsOnProfile est utilisé pour définir une séquence unique pour les opérations d’installation, de mise à jour et de suppression.

Utilisation de dependsOnProfile

Un éditeur peut utiliser dependsOnProfile dans la NFDV pour contrôler la séquence d’exécutions helm pour les NfApps. Dans l’exemple suivant, lors de l’opération d’installation, les NfApps seront déployées dans l’ordre suivant : dummyApplication1, dummyApplication2, puis dummyApplication. Lors de l’opération de mise à jour, les NfApps sont mises à jour dans l’ordre suivant : dummyApplication2, dummyApplication1, puis dummyApplication. Lors de l’opération de suppression, les NfApps sont supprimées dans l’ordre suivant : dummyApplication2, dummyApplication1, puis 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"
    }
}

Erreurs courantes

À ce jour, si dependsOnProfile fourni dans la NFDV n’est pas valide, l’opération NF échoue avec une erreur de validation. Le message d’erreur de validation s’affiche dans la ressource d’état de l’opération et ressemble à l’exemple suivant.

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

Considérations pour injectArtifactStoreDetails

Dans certains cas, les graphiques Helm tiers peuvent ne pas être entièrement conformes aux exigences AOSM pour registryURL. Dans ce cas, la fonctionnalité injectArtifactStoreDetails peut être utilisée pour éviter d’apporter des modifications aux packages Helm.

Comment activer

Pour utiliser injectArtifactStoreDetails, définissez le paramètre installOptions dans la section roleOrverrides de la ressource NF sur true, puis utilisez la valeur registryURL nécessaire pour que l’URL du registre reste valide. Consultez l’exemple suivant où le paramètre injectArtifactStoreDetails est activé.

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