Partager via

Comment utiliser Commit Workflow v2 dans Azure Operator Nexus

Cet article explique comment utiliser Commit Workflow Version 2 (Commit V2) dans Azure Operator Nexus. Cela vous permet d’effectuer des modifications en toute sécurité, de les examiner, de valider les modifications souhaitées ou d’ignorer celles dont vous n’avez pas besoin, entre les ressources prises en charge.

Prerequisites

  • Version du runtime : 5.0.1 ou une version ultérieure est requise pour le workflow de validation v2.

  • Version 8.0.0b3 ou version ultérieure est installée

  • Votre infrastructure réseau doit être dans Provisioned l’état et l’état de configuration doit être Succeeded.

  • L’infrastructure et toutes les ressources affectées doivent avoir l’état administrateur défini sur Enabled.

  • ByOS (Bring Your Own Storage) doit être configuré sur l’infrastructure pour utiliser l’étape de validation facultative.

Vue d’ensemble du workflow de validation v2

Commit V2 vous permet de mettre à jour les ressources prises en charge dans un état brouillon, de valider les modifications de configuration, d’afficher les différences de configuration et de valider ou d’ignorer explicitement les modifications. Il garantit l’atomicité, le contrôle opérationnel et l’expérience utilisateur améliorée pour les opérations complexes de structure réseau.

Avantages du commit V2

  • Opérations de validation plus rapides : réduit le temps d’application des modifications de configuration.

  • Passez en revue la configuration en attente : affichez et validez les différences de configuration avant la validation.

  • Annuler le lot de commit : rétablir les modifications en attente si nécessaire.

  • Configuration du verrou : empêchez les modifications en conflit pendant la mise en scène et la révision.

  • Base pour les scénarios avancés : active la stratégie de commits A/B et les sessions multi-utilisateurs dans les versions ultérieures.

Résumé du flux de travail

Le flux de travail Commit V2 comprend les étapes suivantes :

  • Mettez à jour les ressources prises en charge en mode brouillon à l’aide des opérations PATCH.

  • Verrouillez la configuration de la toile pour examiner ou rejeter les modifications préparées.

  • Si vous le souhaitez, affichez les différences de configuration pour chaque appareil.

  • Validez ou ignorez les modifications.

  • Après validation/abandon, l’infrastructure et toutes les ressources associées retournent à un état provisionné.

Étape 1 : Mettre à jour les ressources en mode brouillon

Les ressources peuvent être mises à jour à l’aide d’opérations PATCH qui conservent la ressource dans un brouillon (ConfigurationState : Accepted) jusqu’à ce qu’elle soit validée explicitement. Ces modifications ne sont pas appliquées au plan de données tant qu’elles ne sont pas validées.

Exemple de scénario

  • Créer une stratégie de routage et l’attacher au réseau interne 1

  • Créer un autre réseau interne 2

Toutes ces modifications sont traitées par lots, mais elles ne sont pas encore appliquées aux appareils.

Étape 2 : Verrouiller la configuration de l’architecture réseau

Avant de pouvoir afficher la différence de configuration ou rejeter la validation, l’infrastructure doit être verrouillée en le mode de configuration.

Verrouillez la configuration pour signaler que toutes les mises à jour prévues sont terminées. Après ce verrou, aucune autre mise à jour ne peut être apportée à toutes les ressources liées à l’infrastructure tant que vous n’avez pas déverrouillé.

Commande Azure CLI

az networkfabric fabric lock-fabric \
    --action Lock \
    --lock-type Configuration \
    --network-fabric-name "example-fabric" \
    --resource-group "example-rg"

Note

Vérifiez que l’état de configuration de l’infrastructure est Accepté.
Fabric n’est pas en maintenance à cause d’opérations non liées (non-commit).
La version de Network Fabric est >= 5.0.1.
Fabric est dans ProvisioningState : réussi.

Une autre fonctionnalité clé de validation V2 fournit consiste à afficher la configuration de validation en attente et la dernière configuration validée pour chaque appareil (à l’exception des appareils NPB (Network Packet Broker) afin que les utilisateurs puissent les comparer pour valider la configuration prévue. En cas d’incohérence, les utilisateurs peuvent déverrouiller l’infrastructure, apporter des modifications nécessaires, verrouiller l’infrastructure, passer en revue la validation en attente suivie de l’opération de validation.

Validez la configuration à l’aide de la view-device-configuration post-action. Cette étape fournit des insights sur les résultats de configuration attendus.

Important

L’infrastructure doit être verrouillée en mode de configuration.
BYOS doit être configuré sur Network Fabric.

Commande Azure CLI


az networkfabric fabric view-device-configuration \
    --network-fabric-name "example-fabric"\
    --resource-group "example-rg"

Emplacement de différences de configuration

Les fichiers de différences de configuration sont stockés dans le compte de stockage fourni par le client au format suivant :

https://<storageAccountName>.blob.core.windows.net/<NF_name>/CommitOperations/DeviceConfigDiff/<CommitBatchId>

Vous pouvez récupérer le CommitBatchId actuel en effectuant une requête GET sur la ressource fabric avec la version 2024-06-15-preview de l’API ou une version ultérieure.

Étape 3a : Annuler le lot de validation (facultatif)

Commit Discard est une action POST sur NetworkFabric, autorisée avant l’exécution d’une validation. Cette opération permet à un utilisateur de rétablir les modifications apportées aux ressources via des opérations PATCH pour une session de validation spécifique. Les utilisateurs peuvent choisir d’ignorer les mises à jour de configuration en attente si des problèmes sont détectés lors de la validation à l’aide de ViewDeviceConfiguration. Cette opération restaure l'état de ressource ARM à sa dernière configuration connue valide et réinitialise l'état de la structure de Accepté & Verrouillé à Réussi.

Note

Vous pouvez récupérer le CommitBatchId en effectuant une requête GET sur la ressource fabric avec la version de l’API 2024-06-15-preview ou une version ultérieure.

Note

Il est recommandé de ne pas déclencher une opération d’abandon après une validation ayant échoué, car cela peut entraîner des configurations incohérentes entre Azure Resource Manager (ARM) et l’appareil. Dans certains cas, une actualisation de l’appareil peut être nécessaire pour rapprocher l’état de configuration entre ARM et l’appareil.

Important

Si votre ressource Network Fabric est associée à une identité managée affectée par l’utilisateur (UAMI), par exemple lors de l’utilisation d’un compte de stockage géré par le client, vous devez vous assurer que le fournisseur de ressources Microsoft.ManagedNetworkFabric a le rôle d’opérateur d’identité managée (MIO) sur l’UAMI. Sans cette autorisation, l'opération d'annulation de commit échoue. Cette exigence s’applique uniquement lorsque Network Fabric est lié à un UAMI. Les structures réseau qui ne sont pas associées à un UAMI n’ont pas besoin d’autorisation supplémentaire pour l’abandon de validation.

az networkfabric fabric discard-commit-batch \
  --resource-group "example-rg" \
  --network-fabric-name "example-fabric"
  --commit-batch-id "example-commit-batch-id"

Note

Les ressources réseau internes/externes passent à l’état administrateur : Désactivé et État de configuration : Rejeté.
Les ressources ne sont pas supprimées, l’utilisateur doit les supprimer manuellement si nécessaire.
La gestion du moniteur réseau inclut des contraintes supplémentaires (les moniteurs désactivés rétablissaient l’état rejeté).

Vous devez effectuer d’autres mises à jour ?

Déverrouillez la configuration pour apporter d’autres modifications, puis répétez les étapes de verrouillage/validation/validation finale.

Exemple de déverrouillage

az networkfabric fabric lock-fabric \
    --action Unlock \
    --lock-type Configuration \
    --network-fabric-name "example-fabric" \
    --resource-group "example-rg"

Étape 4 : Valider la configuration (obligatoire)

Validez la configuration pour appliquer les modifications par lot à tous les appareils de l'infrastructure appropriée.

Commande Azure CLI

az networkfabric fabric commit-configuration \
  --resource-group "example-rg" \
  --resource-name "example-fabric"

  • L’opération retourne un état : Succeeded, InProgressou Failed

  • Utiliser l’interrogation CLI ou les journaux d’activité Azure pour surveiller la progression

Important

  • Ce flux de travail s’applique uniquement lorsque l’infrastructure est à l’état provisionné et que l’étatadministrateur est activé.
  • Le verrouillage est obligatoire avant la validation ; la validation ne peut pas continuer sans verrouiller en premier.
  • La restauration n’est pas prise en charge : toute configuration incorrecte doit être mise à jour et soumise à nouveau.
  • Les mises à jour en dehors de ce flux de travail (par exemple, pour les étiquettes ou les ressources déconnectées) ne nécessitent pas de validation.
  • Last updated on