Jak używać Przepływ Pracy Commit w wersji 2 w ramach Azure Operator Nexus

W tym artykule wyjaśniono, jak używać Commit Workflow w wersji 2 (Commit V2) w Azure Operator Nexus. Ułatwia to bezpieczne przygotowywanie zmian, przeglądanie ich, zatwierdzanie żądanych zmian lub odrzucanie tych, których nie potrzebujesz — między obsługiwanymi zasobami.

Wymagania wstępne

• Wersja środowiska uruchomieniowego: 5.0.1 lub nowsza jest wymagana w przypadku zatwierdzania przepływu pracy w wersji 2.

• Wersja interfejsu wiersza polecenia platformy8.0.0b3 Azure lub nowszy jest zainstalowany

• Sieć szkieletowa musi być w Provisioned stanie, a stan konfiguracji musi być Succeeded.

• System i wszystkie zasoby, których to dotyczy, muszą mieć stan administracyjny ustawiony na Enabled.

• Aby można było użyć opcjonalnego kroku weryfikacji, musisz skonfigurować usługę BYOS (Bring Your Own Storage) w sieci szkieletowej.

Omówienie przepływu pracy w wersji 2

Commit w wersji 2 umożliwia aktualizację obsługiwanych zasobów w stanie roboczym, weryfikację zmian konfiguracji, przeglądanie różnic w konfiguracji oraz wyraźne zatwierdzanie lub odrzucanie zmian. Zapewnia niepodzielność, kontrolę operacyjną i ulepszone doświadczenie użytkownika dla złożonych operacji w sieci szkieletowej.

Korzyści z Commit V2

• Szybsze operacje zatwierdzania: skraca czas stosowania zmian konfiguracji.

• Przejrzyj oczekujące ustawienia: wyświetl i zweryfikuj różnice w konfiguracji przed zatwierdzeniem.

• Odrzuć partię zatwierdzeń: w razie potrzeby przywróć zmiany etapowe.

• Konfiguracja blokady: zapobiegaj zmianom powodującym konflikt podczas przemieszczania i przeglądania.

• Podstawy zaawansowanych scenariuszy: Umożliwia strategię commitów A/B i sesje wielu użytkowników w przyszłych wersjach.

Podsumowanie przepływu pracy

Przepływ pracy Commit V2 zawiera następujące kroki:

• Aktualizowanie obsługiwanych zasobów w trybie roboczym przy użyciu operacji PATCH.

• Zablokuj konfigurację systemu, aby przejrzeć lub odrzucić przygotowane zmiany.

• Opcjonalnie można wyświetlić różnice konfiguracji dla każdego urządzenia.

• Zatwierdź lub odrzuć zmiany.

• Po zatwierdzeniu/odrzuceniu infrastruktura i wszystkie powiązane zasoby powrócą do stanu zaopatrzonego.

Krok 1. Aktualizowanie zasobów w trybie roboczym

Zasoby można aktualizować przy użyciu operacji PATCH, które pozostawiają zasób w wersji roboczej (ConfigurationState: Accepted) do momentu ich jawnego zatwierdzenia. Te zmiany nie są stosowane do płaszczyzny danych do momentu zatwierdzenia.

Przykładowy scenariusz

• Utwórz nowe zasady tras i dołącz je do sieci wewnętrznej 1

• Tworzenie innej sieci wewnętrznej 2

Wszystkie te zmiany są przechowywane w partiach, ale nie są jeszcze wdrażane na urządzenia.

Krok 2. Blokowanie konfiguracji sieci szkieletowej

Aby można było wyświetlić różnicę konfiguracji lub odrzucić zatwierdzenie, sieć szkieletowa musi być zablokowana w trybie konfiguracji.

Zablokuj konfigurację, aby zasygnalizować ukończenie wszystkich zamierzonych aktualizacji. Po zablokowaniu nie można wprowadzać dalszych aktualizacji do dowolnych zasobów związanych z infrastrukturą do momentu odblokowania.

Polecenie Azure CLI

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

Krok 3. Weryfikowanie aktualizacji (opcjonalne, ale zalecane)

Kluczową funkcjonalnością wersji 2 jest możliwość wyświetlania konfiguracji oczekujących na zatwierdzenie i ostatniej zatwierdzonej konfiguracji dla każdego urządzenia (z wyjątkiem urządzeń brokera pakietów sieciowych (NPB)), aby umożliwić użytkownikom porównanie ich, aby potwierdzić zamierzoną konfigurację. Jeśli wystąpi niezgodność, użytkownicy mogą odblokować moduł, wprowadzić niezbędne zmiany, zablokować moduł, przejrzeć oczekujący na zatwierdzenie commit, a następnie wykonać operację zatwierdzania.

Zweryfikuj konfigurację za pomocą akcji po wykonaniu view-device-configuration. Ten krok zapewnia wgląd w oczekiwane wyniki konfiguracji.

Polecenie Azure CLI

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

Lokalizacja różnic w konfiguracji

Pliki różnic konfiguracji są przechowywane na koncie magazynowym dostarczonym przez klienta w następującym formacie:

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

Bieżący identyfikator CommitBatchId można pobrać, wykonując żądanie GET w zasobie sieci szkieletowej z wersją 2024-06-15-preview interfejsu API lub nowszą wersją.

Krok 3a. Odrzucenie partii zatwierdzeń (opcjonalnie)

Akcja POST "Commit Discard" w NetworkFabric jest możliwa do wykonania przed zatwierdzeniem. Ta operacja umożliwia użytkownikowi przywrócenie zmian wprowadzonych w zasobach za pośrednictwem operacji PATCH dla określonej sesji zatwierdzenia. Użytkownicy mogą odrzucić oczekujące aktualizacje konfiguracji, jeśli podczas walidacji zostaną znalezione problemy przy użyciu polecenia ViewDeviceConfiguration. Ta operacja przywraca stan zasobów ARM do jego ostatniej znanej dobrej konfiguracji i resetuje stan systemu z Akceptowane i Zablokowane na Sukces.

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

Chcesz wprowadzić więcej aktualizacji?

Odblokuj konfigurację, aby wprowadzić dalsze zmiany, a następnie powtórz kroki blokady/walidacji/zatwierdzenia.

Odblokuj przykład

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

Krok 4. Zatwierdzanie konfiguracji (obowiązkowe)

Zatwierdź konfigurację, aby zastosować zmiany wsadowe do wszystkich odpowiednich urządzeń sieci szkieletowej.

Polecenie Azure CLI

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

• Operacja zwraca stan: Succeeded, lub InProgressFailed

• Monitorowanie postępu za pomocą odpytywania interfejsu wiersza polecenia lub dzienników aktywności platformy Azure