Automatyzowanie konfiguracji usługi API Management przy użyciu interfejsu wiersza polecenia usługi APIOps

Usługa Azure API Management

Azure DevOps

Azure Pipelines

GitHub

ApiOps to metodologia, która stosuje pojęcia metodyki GitOps i Metodyki DevOps do wdrażania interfejsu API. Ta architektura pokazuje, jak używać interfejsu wiersza polecenia apiOps do wyodrębniania, przeglądania i podwyższania poziomu konfiguracji Azure API Management za pomocą przepływu pracy opartego na usłudze Git. Użyj tego podejścia, aby zarządzać cyklem życia interfejsu API, poprawiać jakość interfejsu API i utrzymywać rekord z możliwością inspekcji zatwierdzonych zmian.

Architektura

Poniższy diagram przedstawia ogólny przepływ pracy promowania konfiguracji w narzędziu APIOps CLI. Zespoły przeglądają artefakty usługi API Management w repozytorium Git, a następnie potoki ciągłej integracji i ciągłego dostarczania (CI/CD) wdrażają zatwierdzoną konfigurację do docelowych środowisk API Management.

Diagram zawiera trzy sekcje od lewej do prawej. Po lewej stronie alternatywny wariant wejściowy A korzysta z przepływu pracy typu extract-first, który uruchamia `apiops extract` na istniejącej źródłowej konfiguracji usługi API Management. Alternatywna metoda wprowadzania B wykorzystuje tworzenie artefaktów API Management zgodnych z CLI zgodnie z podejściem code-first: plików informacyjnych JSON, plików XML zasad i specyfikacji interfejsu API. Oba wejścia wskazują na repozytorium Git w centrum, gdzie krok 1 tworzy zmianę konfiguracji w gałęzi, krok 2 przegląda i weryfikuje pull request, a krok 3 zatwierdza niezmienne wejście wdrożenia jako zatwierdzony commit. Strzałka prowadzi od kroku 3 do przepływu pracy CI/CD w sekcji „Kontrolowane wdrażanie” po prawej stronie. Przepływ pracy CI/CD wyświetla podgląd zatwierdzonych danych wejściowych w kroku 4, uruchamiając `apiops publish --dry-run`, publikuje je i promuje w kroku 5, uruchamiając `apiops publish`, oraz weryfikuje i uzgadnia stan docelowych środowisk usługi API Management w kroku 6.

Pobierz plik Visio tej architektury.

Workflow

Konfiguracja usługi API Management rozpoczyna się od wyodrębnienia istniejącej konfiguracji usługi API Management lub utworzenia artefaktów usługi API Management zgodnych z interfejsem wiersza polecenia. Przepływ pracy operacyjnej zaczyna się od jednego z tych artefaktów wejściowych. Obie ścieżki prowadzą do tego samego żądania ściągnięcia, weryfikacji, zatwierdzenia i procesu wdrażania:

• (A) Najpierw wyodrębnianie: Operator interfejsu API uruchamia apiops extract dla istniejącego wystąpienia usługi API Management, aby utworzyć pliki artefaktów API Management w lokalnej wyewidencjonowanej gałęzi repozytorium Git. Operator używa tych artefaktów do zaproponowania punktu odniesienia lub przechwycenia zatwierdzonej zmiany konfiguracji.

• (B) Code-first: Deweloper interfejsu API tworzy lub aktualizuje specyfikacje interfejsu API zgodne z narzędziem APIOps CLI, pliki informacyjne, zasady i powiązane artefakty usługi API Management w lokalnie wyewidencjonowanej gałęzi repozytorium Git.

Użyj następującego cyklu życia dla danych wejściowych:

1. Utwórz zmianę konfiguracji. Po początkowym wyodrębnieniu lub zapisaniu w repozytorium artefaktów utworzonych w podejściu code-first repozytorium konfiguracji API staje się głównym źródłem prawdy dla artefaktów konfiguracji usługi API Management. Repozytorium przechowuje historię wersji i rekord inspekcji dla każdego wdrożenia. Aby wprowadzić zmianę, operator interfejsu API lub deweloper tworzy gałąź z chronionej gałęzi w repozytorium konfiguracji interfejsu API i wprowadza jedną logiczną zmianę związaną z interfejsem API.

2. Przejrzyj i zweryfikuj zmianę. Operator lub deweloper otwiera pull request, aby scalić swoją gałąź z chronioną gałęzią. Wymagani właściciele i recenzenci kontraktu interfejsu API, zasad oraz konfiguracji usługi API Management przeglądają pull request. System CI/CD uruchamia następujące kontrole i testy:

   • Sprawdzanie specyfikacji API
   • Wykrywanie zmian niekompatybilnych względem zatwierdzonego kontraktu
   • Skanowanie zabezpieczeń specyfikacji i zawartości repozytorium
   • Testy API sprawdzające oczekiwane zachowanie, uwierzytelnianie, skutki zasad i zależności zaplecza

   Te testy nie wymagają Microsoft narzędzi. Zespół korzysta z jakichkolwiek odpowiednich narzędzi, które spełniają wymagania dotyczące pomocy technicznej, zabezpieczeń i licencjonowania organizacji.

3. Zatwierdź niezmienne dane wejściowe wdrożenia. Wymagani właściciele lub recenzenci zatwierdzają żądanie ściągnięcia, a autoryzowany opiekun repozytorium scala przeglądane zmiany po zakończeniu wszystkich wymaganych testów i przeglądów. Commit po scaleniu, niezmienny commit oraz artefakty chronionej gałęzi stają się podlegającym audytowi źródłem prawdy w repozytorium.

   Zespół chroni chronione gałęzie repozytorium przed bezpośrednimi wypychaniami, wymaga zatwierdzeń środowiska lub połączenia usług dla poufnych obiektów docelowych i używa oddzielnych tożsamości z najniższymi uprawnieniami do wyodrębniania i publikowania. Rejestrują zatwierdzony commit wraz z powiązanym pull requestem, przeglądami i wynikami walidacji na potrzeby audytu.

4. Wyświetl podgląd wdrożenia. Potok CI/CD uruchamia apiops publish --dry-run dla zatwierdzonego commitu, używając tego samego obiektu docelowego i pliku zastąpienia, bez publikacji. Osoba zatwierdzająca wdrożenie przegląda zasoby tworzone, aktualizowane, usuwane lub pomijane podczas próbnego uruchomienia. Zespół traktuje udaną próbę na sucho jako warunek dopuszczenia do wdrożenia, a nie jako zamiennik zautomatyzowanych testów interfejsu API.

5. Publikuj i promuj. Gdy próbny przebieg pomyślnie przejdzie weryfikację, potok CI/CD używa apiops publish, aby opublikować ten sam sprawdzony commit. W przypadku wielu środowisk zespół platformy utrzymuje stabilność wspólnych artefaktów i korzysta ze sprawdzonych plików konfiguracji nadpisującej dla wartości takich jak adresy URL usług zaplecza, identyfikatory zasobów i odwołania do sekretów. Zespół promuje zatwierdzenie przez nieprodukcję przed produkcją i zapobiega zapisaniu więcej niż jednego potoku do tego samego celu w tym samym czasie.

   Note

   Konfiguracja akceptuje przesłonięcia podrzędne obszaru roboczego, ale nie stosuje ich podczas publikowania. Publikowanie stosuje przesłonięcia tylko do samego kontenera obszaru roboczego. Nie należy polegać na przesłonięciach zasobów podrzędnych obszaru roboczego w celu przenoszenia interfejsów API obszaru roboczego, usług zaplecza, wartości nazwanych ani innych zasobów podrzędnych specyficznych dla danego środowiska. Zweryfikuj alternatywne podejście do promowania tych zasobów lub odrocz promowanie do czasu rozwiązania znanego problemu Workspace-scoped override properties not applied.

6. Zweryfikuj i uzgodnij po wdrożeniu. Po publikacji zespół operacyjny uruchamia zautomatyzowane testy smoke i regresji, monitoruje API Management oraz stan back-endu, a także porównuje wynik wdrożenia z zatwierdzonym commitem. Zespół analizuje i koryguje nieoczekiwane zmiany za pomocą pull requestów, zamiast wprowadzać zmiany bezpośrednio na produkcji.

   Jeśli operator interfejsu API wprowadzi zatwierdzoną zmianę awaryjną bezpośrednio w usłudze API Management, musi uruchomić ekstrakcję w lokalnej kopii roboczej repozytorium Git, przejrzeć zmianę artefaktu i zatwierdzić ją w swojej gałęzi, wypchnąć gałąź do repozytorium zdalnego oraz otworzyć żądanie scalenia. Wymagani właściciele lub recenzenci muszą przejrzeć i zatwierdzić żądanie ściągnięcia, a autoryzowany opiekun repozytorium musi je scalić, aby repozytorium pozostaje autorytatywne.

Składniki

• API Management to usługa zarządzana, która tworzy spójne bramy interfejsu API dla usług zaplecza. W tej architekturze udostępniane są konfiguracje źródłowe, które narzędzie APIOps CLI pobiera, oraz środowiska docelowe, w których APIOps CLI publikuje zatwierdzone definicje API, zasady, produkty, ustawienia diagnostyczne, wartości nazwane i inne obsługiwane konfiguracje.

• APIOps CLI to projekt open source, który udostępnia narzędzia dla ściśle określonego podejścia APIOps. W tej architekturze eksportuje konfigurację usługi API Management do plików artefaktów, publikuje artefakty do usługi API Management i może generować szablony przepływów pracy CI/CD.

• Repozytorium Git przechowuje artefakty usługi API Management i, jeśli ma to zastosowanie, kontrakty interfejsu API. Udostępnia historię przeglądów oraz zatwierdzone, wiarygodne źródło informacji o wdrożeniach potoków.

• System CI/CD uruchamia walidację, wyodrębnianie i publikację za pomocą tożsamości obciążenia roboczego lub innych obsługiwanych poświadczeń nieinteraktywnych. W tej architekturze GitHub Actions lub Azure Pipelines definiują przepływy pracy CI/CD.

Alternatywy

Możesz zastąpić lub rozszerzyć tę architekturę innymi usługami lub podejściami Azure, w zależności od wymagań funkcjonalnych i niefunkcjonalnych obciążenia. Rozważ następujące alternatywy i kompromisy.

Bicep, Terraform i APIOps mogą służyć różnym częściom tego samego rozwiązania. Zespół, który jest właścicielem zarówno konfiguracji usługi API Management, jak i infrastruktury, może używać infrastruktury jako kodu (IaC) do aprowizacji usługi API Management i jej infrastruktury pomocniczej oraz używać tego samego potoku IaC do zarządzania konfiguracją usługi API Management. Wybierz to podejście, gdy infrastruktura i konfiguracja zmieniają się i wdrażają razem, a kiedy parametry mogą wyrażać różnice między środowiskami.

Użyj wzorca APIOps, gdy definicje, zasady i powiązana konfiguracja interfejsu API mają oddzielnych właścicieli lub cykl życia wydania, który jest niezależny od infrastruktury usługi. Metodyka APIOps jest również odpowiednia, gdy musisz wyodrębnić istniejącą konfigurację, przejrzeć artefakty skoncentrowane na interfejsie API lub podwyższyć poziom tej samej zatwierdzonej konfiguracji w wielu środowiskach lub wystąpieniach usługi API Management. Częstsze zmiany interfejsu API i zasad lub większej liczby środowisk zwiększają wartość tego dedykowanego przepływu pracy.

Te czynniki nie mają stałych progów. Należy podjąć decyzję przede wszystkim na temat własności, przejrzeć wymagania i granice wdrożenia. W przypadku mniejszego środowiska API o niewielkiej częstotliwości zmian zacznij od ręcznego procesu obsługi pull requestów, a harmonogramy ekstrakcji lub automatyzację wdrażania dodawaj dopiero po ustaleniu bazowej zawartości repozytorium i procesu zatwierdzania.

Szczegóły scenariusza

Usługa APIOps używa kontroli wersji do zarządzania interfejsami API i tworzenia dziennika inspekcji zmian definicji interfejsu API, zasad, produktów, diagnostyki i innej konfiguracji usługi API Management. Przeglądanie zmian wcześniej i częściej ułatwia zespołom identyfikowanie odchyleń od standardów interfejsu API przed wdrożeniem. W miarę jak coraz więcej interfejsów API korzysta z tego samego procesu, zespoły mogą poprawić spójność w całym swoim portfolio API.

Ten przepływ pracy wdraża konfigurację usługi API Management do wystąpienia usługi API Management. Nie wdraża zapleczy interfejsu API, zasobów obliczeniowych aplikacji ani zasobów danych, sieci ani infrastruktury usługi API Management. Użyj oddzielnych zarządzanych potoków IaC i aplikacji, aby wdrożyć te warstwy.

To rozwiązanie pomaga zespołom:

• Miej przegląd środowisk i instancji usługi API Management.
• Śledź krytyczne zmiany w API i zasadach.
• Utwórz dziennik inspekcji dla zatwierdzonych wdrożeń.
• Uzgodnij zatwierdzone zmiany pochodzące spoza repozytorium.

Wybieranie źródeł artefaktów i własności

Wybierz spośród następujących sposobów, które artefakty wchodzą do repozytorium i kto jest ich właścicielem przed zautomatyzowanie wdrożenia:

• Najpierw wyodrębnij: Wyodrębnij sprawdzone wystąpienie usługi API Management, aby utworzyć początkowy poziom bazowy artefaktów. Przed uznaniem repozytorium za jedyne wiarygodne źródło przejrzyj wygenerowane artefakty zatwierdzone w repozytorium.
• Najpierw kod: Zachowaj kontrakt interfejsu API, taki jak opis interfejsu OpenAPI, ze źródłem aplikacji lub repozytorium APIOps. Zdefiniuj, kto przekształca ten kontrakt w artefakty usługi API Management publikowane przez potok. Zweryfikuj docelowy przepływ pracy związany z importem i artefaktami za pomocą nieprodukcyjnego wystąpienia usługi API Management. Nie zakładaj, że dowolny układ źródłowy może być bezpośrednio użyty przez CLI.
• Wspólna odpowiedzialność: Ustal, czy za zmiany zasad, produktów, diagnostyki, nazwanych wartości i definicji interfejsu API odpowiadają deweloperzy interfejsu API, operatorzy platformy czy obie strony. Po zaakceptowaniu punktu odniesienia należy skierować każdą zmianę do tego samego repozytorium i procesu przeglądu.

Potencjalne przypadki użycia

• Organizacje, które opracowują interfejsy API i zarządzają nimi, w tym organizacje z jednym interfejsem API uwidacznianym za pośrednictwem usługi API Management.

• Sektory podlegające ścisłym regulacjom, takie jak ubezpieczenia, bankowość, finanse i administracja publiczna, które wymagają możliwych do prześledzenia rejestrów przeglądów i wdrożeń.

Kwestie wymagające rozważenia

Te zagadnienia implementują filary struktury Azure Well-Architected, która jest zestawem wytycznych, których można użyć do poprawy jakości obciążenia. Aby uzyskać więcej informacji, zobacz Well-Architected Framework.

Reliability

Niezawodność pomaga zapewnić, że aplikacja może spełnić zobowiązania podjęte przez klientów. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu dotycząca niezawodności.

W przypadku zmian niezwiązanych z interfejsem API użyj poprawek usługi API Management , aby wdrożyć i przetestować niebieżną poprawkę przed wprowadzeniem jej do bieżącej wersji. Jeśli walidacja zakończy się niepowodzeniem po wydaniu, przywróć poprzednią wersję jako bieżącą. Używaj wersji interfejsu API w przypadku zmian powodujących niezgodność kontraktu, aby obecni odbiorcy mogli nadal korzystać z wcześniejszej wersji.

Koordynuj zmiany konfiguracji usługi API Management ze strategią wdrażania dla każdego zaplecza API. Przywracanie zatwierdzenia interfejsu APIOps przywraca tylko konfigurację reprezentowaną przez to zatwierdzenie. Nie powoduje przywrócenia niezgodnego lub niedostępnego zaplecza. Zarejestruj zatwierdzenie interfejsu APIOps, poprawkę usługi API Management i wydanie zaplecza, które tworzą każde znane dobre wdrożenie. Przetestuj pełną procedurę wycofywania w środowisku nieprodukcyjnym, w tym zasady, nazwane wartości, odwołania do wpisów tajnych, zależności i zgodność zaplecza.

Zabezpieczenia

Zabezpieczenia zapewniają ochronę przed celowymi atakami i nieprawidłowym użyciem cennych danych i systemów. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu dotycząca zabezpieczeń.

Użyj repozytorium i potoku wdrożeniowego jako standardowego sposobu wprowadzania zmian w usłudze API Management. Deweloperzy i operatorzy nie potrzebują stałego prawa zapisu do produkcyjnych wystąpień usługi API Management. Udziel dostępu z podwyższonym poziomem uprawnień tylko wtedy, gdy jest to konieczne, i tylko przez ograniczony czas. Uwzględnij w repozytorium wszelkie wynikające z tego zmiany.

Użyj następujących mechanizmów, aby chronić repozytorium Git, które przechowuje artefakty usługi API Management:

• Przegląd pull requestu: Chroń gałęzie wdrażające konfigurację i wymagaj zatwierdzenia przez odpowiednich recenzentów.
• Izolacja poświadczeń: Jeśli to możliwe, preferuj sfederowaną tożsamość obciążenia. Przechowuj wpisy tajne specyficzne dla środowiska w zatwierdzonym magazynie wpisów tajnych lub środowisku repozytorium, a nie w artefaktach lub plikach potoku.
• Integralność commitów: Wymagaj podpisywania commitów w celu weryfikacji ich pochodzenia. Skonfiguruj ochronę gałęzi, aby zapobiec wymuszonym wypchnięciom i usuwaniu gałęzi, wymagaj uwierzytelniania wieloskładnikowego od użytkowników zatwierdzających lub scalających zmiany oraz zachowaj historię commitów i pull requestów na potrzeby wdrożeń.
• Przegląd artefaktu: Sprawdź wyniki ekstrakcji i dane wejściowe publikacji pod kątem sekretów, znaczników ukrycia oraz niezamierzonych wartości zależnych od środowiska. Sprawdź, czy zmiana nie rozszerza dostępu do interfejsu API ani nie osłabia zasad.

Zarządzanie narzędziem wiersza polecenia APIOps jako zależnością repozytorium. Przypnij @azure-tools/apiops-cli w pliku package.json do przetestowanej wersji, zatwierdź plik lock i użyj npm ci. Przed włączeniem potoku produkcyjnego przejrzyj wygenerowane ustawienia tożsamości, zmienne, wyzwalacze i reguły ochrony.

Optymalizacja kosztów

Optymalizacja kosztów koncentruje się na sposobach zmniejszenia niepotrzebnych wydatków i poprawy wydajności operacyjnej. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu dotycząca optymalizacji kosztów.

Narzędzie APIOps CLI jest oprogramowaniem typu open source, jednak ten scenariusz wiąże się z kosztami instancji usługi API Management oraz wybranej platformy kontroli wersji i CI/CD. Nie podano pojedynczego stałego oszacowania, ponieważ ceny usługi API Management różnią się w zależności od regionu, warstwy, liczby jednostek, modelu pojemności, konfiguracji strefy dostępności lub wielu regionów oraz użycia. Opłaty za CI/CD zależą również od typu runnera, liczby minut wliczonych w cenę, współbieżności, przestrzeni dyskowej i okresu przechowywania.

Utwórz oszacowanie specyficzne dla scenariusza w kalkulatorze cen Azure i zapisz następujące założenia przy użyciu decyzji o architekturze:

Szacowanie danych wejściowych	Założenie dotyczące rejestrowania
Region usługi API Management	Region wdrażania dla każdego wystąpienia programistycznego, testowego, przejściowego i produkcyjnego.
Poziom i pojemność	Warstwa lub wersja 2, liczba jednostek lub bram oraz godziny pracy dla każdego środowiska.
Odporność	Każde wdrożenie strefy dostępności lub regionu dodatkowego, w tym jednostek w każdej lokalizacji.
Opłaty oparte na użyciu	Oczekiwane żądania lub operacje oraz wszelkie obowiązujące opłaty za obszar roboczy, bramę hostowaną samodzielnie, sieć, monitorowanie lub transfer danych.
platforma CI/CD	Agenci hostowani przez GitHub, hostowani samodzielnie lub agenci Azure Pipelines. Przewidywana liczba uruchomień potoku, czas trwania, współbieżność, pamięć masowa oraz przechowywanie dzienników lub artefaktów.
Kontrola źródła i licencje	Liczba użytkowników i wszystkie płatne funkcje GitHub lub planu Azure DevOps.

Użyj bieżących szczegółów cennika usługi API Management , aby wybrać odpowiedni model rozliczeń. Aby uzyskać informacje o założeniach dotyczących CI/CD i kontroli wersji, zobacz cennik Azure DevOps i cennik GitHub. Wyeksportuj lub przechwyć szacowanie kalkulatora, jego walutę, datę cenową i wszystkie założenia, aby recenzenci mogli go odtworzyć i zaktualizować. Przelicz przed wdrożeniem oraz gdy zmienią się regiony, poziomy, liczba jednostek, środowiska lub wykorzystanie potoku.

Doskonałość operacyjna

Doskonałość operacyjna obejmuje procesy operacyjne, które wdrażają aplikację i działają w środowisku produkcyjnym. Aby uzyskać więcej informacji, zobacz Lista kontrolna projektu dotycząca doskonałości operacyjnej.

Metodyka APIOps sprawia, że wdrożenia są powtarzalne i tworzy historię zatwierdzeń na potrzeby analizy po zmianie. Taguj lub w inny sposób rejestruj zatwierdzenie odbierane przez każde środowisko, zachowywanie dzienników potoków i monitorowanie wystąpienia usługi API Management i zależnych interfejsów API po wdrożeniu.

W przypadku wielu środowisk promuj ten sam sprawdzony artefakt przez środowiska programistyczne, testowe i produkcyjne. Użyj przesłonięć środowiska tylko dla wartości, które muszą się różnić między środowiskami, i przejrzyj te pliki z taką samą starannością jak artefakty. Przesłonięcia podrzędne obszaru roboczego nie są stosowane w czasie publikowania, więc nie używaj ich do podwyższania poziomu środowiska. Przetestuj procedury wycofywania zmian, zanim dojdzie do incydentu. Cofnięcie zmian w Git nadal wymaga weryfikacji i kontrolowanej publikacji w celu przywrócenia usługi API Management.

Interfejs wiersza polecenia udostępnia polecenia init, extract i publish oraz może generować szkielet dla GitHub Actions lub potoków Azure DevOps. Przejrzyj szczegóły polecenia w dokumentacji interfejsu wiersza polecenia apiOps.

Bezpieczne migrowanie ze starszego zestawu narzędzi APIOps Toolkit

Jeśli proces APIOps używa starszego zestawu narzędzi APIOps Toolkit, zaplanuj uaktualnienie. Takie podejście wykorzystuje oddzielne pliki binarne Extractor i Publisher oraz szablony potoków. CLI APIOps używa pojedynczego narzędzia CLI Node.js, ale jego format artefaktów został zaprojektowany tak, aby był zgodny z artefaktami istniejącego zestawu narzędzi. Traktuj migrację jako kontrolowane przełączenie, a nie jako bezpośrednią aktualizację środowiska produkcyjnego.

1. Oznacz znane dobre artefakty i potok zestawu narzędzi oraz zachowaj istniejącego wydawcę jako opcję wycofania. Nie zmieniaj starszego wydawcy i wprowadzaj nowego wydawcę w tym samym wdrożeniu.

2. W gałęzi migracyjnej użyj najnowszej wersji narzędzia APIOps CLI i uruchom polecenie apiops init bez użycia polecenia --force. Polecenie wykrywa pliki powodujące konflikty i kończy działanie, zamiast je nadpisywać. Porównaj i świadomie zintegruj wygenerowane potoki, wytyczne dotyczące tożsamości, filtry i pliki nadpisujące.

3. Użyj artefaktów z apiops publish --dry-run oraz przesłonięć środowiska docelowego w nieprodukcyjnym wystąpieniu usługi API Management. Przejrzyj zasoby, które interfejs wiersza polecenia tworzy, aktualizuje lub usuwa. Przetestuj jedną kontrolowaną publikację i zweryfikuj wdrożone interfejsy API, zasady, nazwane wartości i zależności.

4. Nie używaj przesłonięć podrzędnych obszaru roboczego, które nie są stosowane w czasie publikowania w ramach projektu migracji ani podwyższania poziomu. Zweryfikuj alternatywne podejście do promowania zasobów podrzędnych objętych problemem lub odłóż ich migrację do czasu rozwiązania znanego problemu Właściwości zastępowania o zakresie obszaru roboczego nie są stosowane.

5. Podczas przełączenia zezwalaj tylko jednemu wydawcy na zapisywanie do wystąpienia usługi API Management. Wyłącz starszy mechanizm wyzwalający publikowanie przed włączeniem mechanizmu publikowania CLI. Wdróż sprawdzony commit i monitoruj rezultat. Zachowaj oznaczony tagiem potok zestawu Toolkit i bazę artefaktu, dopóki nowy przepływ pracy nie zakończy się pomyślnym cyklem wydania.

Aby uzyskać informacje dotyczące zgodności oraz przykłady migracji dla poszczególnych poleceń, zobacz Migracja z narzędzia APIOps Toolkit.

Wdrażanie tego scenariusza

Postępuj zgodnie z dokumentacją narzędzia APIOps CLI w repozytorium GitHub APIOps CLI. Zacznij od nieprodukcyjnego wystąpienia usługi API Management i skorzystaj z bieżących wskazówek dotyczących aktualnej wersji narzędzia APIOps CLI. Aby rozpocząć pracę ze środowiskiem nieprodukcyjnym, zobacz Jak zarządzać konfiguracją usługi API Management za pomocą interfejsu wiersza polecenia usługi APIOps.

Współautorzy

Microsoft utrzymuje ten artykuł. Następujący współautorzy napisali ten artykuł.

Główni autorzy:

• Pat Altimore | Starszy deweloper zawartości
• Wael Kdouh | Starszy główny architekt rozwiązań
• Rishabh Saha | Starszy główny architekt rozwiązań

Aby wyświetlić niepubliczne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki

• APIOps CLI
• Jak zarządzać konfiguracją usługi API Management za pomocą interfejsu wiersza polecenia usługi APIOps
• Omówienie metodyki GitOps

Powiązane zasoby

• GitOps dla Azure Kubernetes Service (AKS)
• Migrowanie aplikacji internetowej przy użyciu usługi API Management
• Ochrona interfejsów API przy użyciu usługi Azure Application Gateway i usługi API Management

ApiOps to metodologia, która stosuje pojęcia metodyki GitOps i Metodyki DevOps do wdrażania interfejsu API. Ta architektura pokazuje, jak używać interfejsu wiersza polecenia apiOps do wyodrębniania, przeglądania i podwyższania poziomu konfiguracji Azure API Management za pomocą przepływu pracy opartego na usłudze Git. Użyj tego podejścia, aby zarządzać cyklem życia interfejsu API, poprawiać jakość interfejsu API i utrzymywać rekord z możliwością inspekcji zatwierdzonych zmian.

Architektura

Poniższy diagram przedstawia ogólny przepływ pracy promowania konfiguracji w narzędziu APIOps CLI. Zespoły przeglądają artefakty usługi API Management w repozytorium Git, a następnie potoki ciągłej integracji i ciągłego dostarczania (CI/CD) wdrażają zatwierdzoną konfigurację do docelowych środowisk API Management.

Diagram zawiera trzy sekcje od lewej do prawej. Po lewej stronie alternatywny wariant wejściowy A korzysta z przepływu pracy typu extract-first, który uruchamia `apiops extract` na istniejącej źródłowej konfiguracji usługi API Management. Alternatywna metoda wprowadzania B wykorzystuje tworzenie artefaktów API Management zgodnych z CLI zgodnie z podejściem code-first: plików informacyjnych JSON, plików XML zasad i specyfikacji interfejsu API. Oba wejścia wskazują na repozytorium Git w centrum, gdzie krok 1 tworzy zmianę konfiguracji w gałęzi, krok 2 przegląda i weryfikuje pull request, a krok 3 zatwierdza niezmienne wejście wdrożenia jako zatwierdzony commit. Strzałka prowadzi od kroku 3 do przepływu pracy CI/CD w sekcji „Kontrolowane wdrażanie” po prawej stronie. Przepływ pracy CI/CD wyświetla podgląd zatwierdzonych danych wejściowych w kroku 4, uruchamiając `apiops publish --dry-run`, publikuje je i promuje w kroku 5, uruchamiając `apiops publish`, oraz weryfikuje i uzgadnia stan docelowych środowisk usługi API Management w kroku 6.

Pobierz plik Visio tej architektury.

Workflow

Konfiguracja usługi API Management rozpoczyna się od wyodrębnienia istniejącej konfiguracji usługi API Management lub utworzenia artefaktów usługi API Management zgodnych z interfejsem wiersza polecenia. Przepływ pracy operacyjnej zaczyna się od jednego z tych artefaktów wejściowych. Obie ścieżki prowadzą do tego samego żądania ściągnięcia, weryfikacji, zatwierdzenia i procesu wdrażania:

• (A) Najpierw wyodrębnianie: Operator interfejsu API uruchamia apiops extract dla istniejącego wystąpienia usługi API Management, aby utworzyć pliki artefaktów API Management w lokalnej wyewidencjonowanej gałęzi repozytorium Git. Operator używa tych artefaktów do zaproponowania punktu odniesienia lub przechwycenia zatwierdzonej zmiany konfiguracji.

• (B) Code-first: Deweloper interfejsu API tworzy lub aktualizuje specyfikacje interfejsu API zgodne z narzędziem APIOps CLI, pliki informacyjne, zasady i powiązane artefakty usługi API Management w lokalnie wyewidencjonowanej gałęzi repozytorium Git.

Użyj następującego cyklu życia dla danych wejściowych:

1. Utwórz zmianę konfiguracji. Po początkowym wyodrębnieniu lub zapisaniu w repozytorium artefaktów utworzonych w podejściu code-first repozytorium konfiguracji API staje się głównym źródłem prawdy dla artefaktów konfiguracji usługi API Management. Repozytorium przechowuje historię wersji i rekord inspekcji dla każdego wdrożenia. Aby wprowadzić zmianę, operator interfejsu API lub deweloper tworzy gałąź z chronionej gałęzi w repozytorium konfiguracji interfejsu API i wprowadza jedną logiczną zmianę związaną z interfejsem API.

2. Przejrzyj i zweryfikuj zmianę. Operator lub deweloper otwiera pull request, aby scalić swoją gałąź z chronioną gałęzią. Wymagani właściciele i recenzenci kontraktu interfejsu API, zasad oraz konfiguracji usługi API Management przeglądają pull request. System CI/CD uruchamia następujące kontrole i testy:

   • Sprawdzanie specyfikacji API
   • Wykrywanie zmian niekompatybilnych względem zatwierdzonego kontraktu
   • Skanowanie zabezpieczeń specyfikacji i zawartości repozytorium
   • Testy API sprawdzające oczekiwane zachowanie, uwierzytelnianie, skutki zasad i zależności zaplecza

   Te testy nie wymagają Microsoft narzędzi. Zespół korzysta z jakichkolwiek odpowiednich narzędzi, które spełniają wymagania dotyczące pomocy technicznej, zabezpieczeń i licencjonowania organizacji.

3. Zatwierdź niezmienne dane wejściowe wdrożenia. Wymagani właściciele lub recenzenci zatwierdzają żądanie ściągnięcia, a autoryzowany opiekun repozytorium scala przeglądane zmiany po zakończeniu wszystkich wymaganych testów i przeglądów. Commit po scaleniu, niezmienny commit oraz artefakty chronionej gałęzi stają się podlegającym audytowi źródłem prawdy w repozytorium.

   Zespół chroni chronione gałęzie repozytorium przed bezpośrednimi wypychaniami, wymaga zatwierdzeń środowiska lub połączenia usług dla poufnych obiektów docelowych i używa oddzielnych tożsamości z najniższymi uprawnieniami do wyodrębniania i publikowania. Rejestrują zatwierdzony commit wraz z powiązanym pull requestem, przeglądami i wynikami walidacji na potrzeby audytu.

4. Wyświetl podgląd wdrożenia. Potok CI/CD uruchamia apiops publish --dry-run dla zatwierdzonego commitu, używając tego samego obiektu docelowego i pliku zastąpienia, bez publikacji. Osoba zatwierdzająca wdrożenie przegląda zasoby tworzone, aktualizowane, usuwane lub pomijane podczas próbnego uruchomienia. Zespół traktuje udaną próbę na sucho jako warunek dopuszczenia do wdrożenia, a nie jako zamiennik zautomatyzowanych testów interfejsu API.

5. Publikuj i promuj. Gdy próbny przebieg pomyślnie przejdzie weryfikację, potok CI/CD używa apiops publish, aby opublikować ten sam sprawdzony commit. W przypadku wielu środowisk zespół platformy utrzymuje stabilność wspólnych artefaktów i korzysta ze sprawdzonych plików konfiguracji nadpisującej dla wartości takich jak adresy URL usług zaplecza, identyfikatory zasobów i odwołania do sekretów. Zespół promuje zatwierdzenie przez nieprodukcję przed produkcją i zapobiega zapisaniu więcej niż jednego potoku do tego samego celu w tym samym czasie.

   Note

   Konfiguracja akceptuje przesłonięcia podrzędne obszaru roboczego, ale nie stosuje ich podczas publikowania. Publikowanie stosuje przesłonięcia tylko do samego kontenera obszaru roboczego. Nie należy polegać na przesłonięciach zasobów podrzędnych obszaru roboczego w celu przenoszenia interfejsów API obszaru roboczego, usług zaplecza, wartości nazwanych ani innych zasobów podrzędnych specyficznych dla danego środowiska. Zweryfikuj alternatywne podejście do promowania tych zasobów lub odrocz promowanie do czasu rozwiązania znanego problemu Workspace-scoped override properties not applied.

6. Zweryfikuj i uzgodnij po wdrożeniu. Po publikacji zespół operacyjny uruchamia zautomatyzowane testy smoke i regresji, monitoruje API Management oraz stan back-endu, a także porównuje wynik wdrożenia z zatwierdzonym commitem. Zespół analizuje i koryguje nieoczekiwane zmiany za pomocą pull requestów, zamiast wprowadzać zmiany bezpośrednio na produkcji.

   Jeśli operator interfejsu API wprowadzi zatwierdzoną zmianę awaryjną bezpośrednio w usłudze API Management, musi uruchomić ekstrakcję w lokalnej kopii roboczej repozytorium Git, przejrzeć zmianę artefaktu i zatwierdzić ją w swojej gałęzi, wypchnąć gałąź do repozytorium zdalnego oraz otworzyć żądanie scalenia. Wymagani właściciele lub recenzenci muszą przejrzeć i zatwierdzić żądanie ściągnięcia, a autoryzowany opiekun repozytorium musi je scalić, aby repozytorium pozostaje autorytatywne.

Składniki

• API Management to usługa zarządzana, która tworzy spójne bramy interfejsu API dla usług zaplecza. W tej architekturze udostępniane są konfiguracje źródłowe, które narzędzie APIOps CLI pobiera, oraz środowiska docelowe, w których APIOps CLI publikuje zatwierdzone definicje API, zasady, produkty, ustawienia diagnostyczne, wartości nazwane i inne obsługiwane konfiguracje.

• APIOps CLI to projekt open source, który udostępnia narzędzia dla ściśle określonego podejścia APIOps. W tej architekturze eksportuje konfigurację usługi API Management do plików artefaktów, publikuje artefakty do usługi API Management i może generować szablony przepływów pracy CI/CD.

• Repozytorium Git przechowuje artefakty usługi API Management i, jeśli ma to zastosowanie, kontrakty interfejsu API. Udostępnia historię przeglądów oraz zatwierdzone, wiarygodne źródło informacji o wdrożeniach potoków.

• System CI/CD uruchamia walidację, wyodrębnianie i publikację za pomocą tożsamości obciążenia roboczego lub innych obsługiwanych poświadczeń nieinteraktywnych. W tej architekturze GitHub Actions lub Azure Pipelines definiują przepływy pracy CI/CD.

Alternatywy

Możesz zastąpić lub rozszerzyć tę architekturę innymi usługami lub podejściami Azure, w zależności od wymagań funkcjonalnych i niefunkcjonalnych obciążenia. Rozważ następujące alternatywy i kompromisy.

Bicep, Terraform i APIOps mogą służyć różnym częściom tego samego rozwiązania. Zespół, który jest właścicielem zarówno konfiguracji usługi API Management, jak i infrastruktury, może używać infrastruktury jako kodu (IaC) do aprowizacji usługi API Management i jej infrastruktury pomocniczej oraz używać tego samego potoku IaC do zarządzania konfiguracją usługi API Management. Wybierz to podejście, gdy infrastruktura i konfiguracja zmieniają się i wdrażają razem, a kiedy parametry mogą wyrażać różnice między środowiskami.

Użyj wzorca APIOps, gdy definicje, zasady i powiązana konfiguracja interfejsu API mają oddzielnych właścicieli lub cykl życia wydania, który jest niezależny od infrastruktury usługi. Metodyka APIOps jest również odpowiednia, gdy musisz wyodrębnić istniejącą konfigurację, przejrzeć artefakty skoncentrowane na interfejsie API lub podwyższyć poziom tej samej zatwierdzonej konfiguracji w wielu środowiskach lub wystąpieniach usługi API Management. Częstsze zmiany interfejsu API i zasad lub większej liczby środowisk zwiększają wartość tego dedykowanego przepływu pracy.

Te czynniki nie mają stałych progów. Należy podjąć decyzję przede wszystkim na temat własności, przejrzeć wymagania i granice wdrożenia. W przypadku mniejszego środowiska API o niewielkiej częstotliwości zmian zacznij od ręcznego procesu obsługi pull requestów, a harmonogramy ekstrakcji lub automatyzację wdrażania dodawaj dopiero po ustaleniu bazowej zawartości repozytorium i procesu zatwierdzania.

Szczegóły scenariusza

Usługa APIOps używa kontroli wersji do zarządzania interfejsami API i tworzenia dziennika inspekcji zmian definicji interfejsu API, zasad, produktów, diagnostyki i innej konfiguracji usługi API Management. Przeglądanie zmian wcześniej i częściej ułatwia zespołom identyfikowanie odchyleń od standardów interfejsu API przed wdrożeniem. W miarę jak coraz więcej interfejsów API korzysta z tego samego procesu, zespoły mogą poprawić spójność w całym swoim portfolio API.

Ten przepływ pracy wdraża konfigurację usługi API Management do wystąpienia usługi API Management. Nie wdraża zapleczy interfejsu API, zasobów obliczeniowych aplikacji ani zasobów danych, sieci ani infrastruktury usługi API Management. Użyj oddzielnych zarządzanych potoków IaC i aplikacji, aby wdrożyć te warstwy.

To rozwiązanie pomaga zespołom:

• Miej przegląd środowisk i instancji usługi API Management.
• Śledź krytyczne zmiany w API i zasadach.
• Utwórz dziennik inspekcji dla zatwierdzonych wdrożeń.
• Uzgodnij zatwierdzone zmiany pochodzące spoza repozytorium.

Wybieranie źródeł artefaktów i własności

Wybierz spośród następujących sposobów, które artefakty wchodzą do repozytorium i kto jest ich właścicielem przed zautomatyzowanie wdrożenia:

• Najpierw wyodrębnij: Wyodrębnij sprawdzone wystąpienie usługi API Management, aby utworzyć początkowy poziom bazowy artefaktów. Przed uznaniem repozytorium za jedyne wiarygodne źródło przejrzyj wygenerowane artefakty zatwierdzone w repozytorium.
• Najpierw kod: Zachowaj kontrakt interfejsu API, taki jak opis interfejsu OpenAPI, ze źródłem aplikacji lub repozytorium APIOps. Zdefiniuj, kto przekształca ten kontrakt w artefakty usługi API Management publikowane przez potok. Zweryfikuj docelowy przepływ pracy związany z importem i artefaktami za pomocą nieprodukcyjnego wystąpienia usługi API Management. Nie zakładaj, że dowolny układ źródłowy może być bezpośrednio użyty przez CLI.
• Wspólna odpowiedzialność: Ustal, czy za zmiany zasad, produktów, diagnostyki, nazwanych wartości i definicji interfejsu API odpowiadają deweloperzy interfejsu API, operatorzy platformy czy obie strony. Po zaakceptowaniu punktu odniesienia należy skierować każdą zmianę do tego samego repozytorium i procesu przeglądu.

Potencjalne przypadki użycia

• Organizacje, które opracowują interfejsy API i zarządzają nimi, w tym organizacje z jednym interfejsem API uwidacznianym za pośrednictwem usługi API Management.

• Sektory podlegające ścisłym regulacjom, takie jak ubezpieczenia, bankowość, finanse i administracja publiczna, które wymagają możliwych do prześledzenia rejestrów przeglądów i wdrożeń.

Kwestie wymagające rozważenia

Te zagadnienia implementują filary struktury Azure Well-Architected, która jest zestawem wytycznych, których można użyć do poprawy jakości obciążenia. Aby uzyskać więcej informacji, zobacz Well-Architected Framework.

Reliability

Niezawodność pomaga zapewnić, że aplikacja może spełnić zobowiązania podjęte przez klientów. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu dotycząca niezawodności.

W przypadku zmian niezwiązanych z interfejsem API użyj poprawek usługi API Management , aby wdrożyć i przetestować niebieżną poprawkę przed wprowadzeniem jej do bieżącej wersji. Jeśli walidacja zakończy się niepowodzeniem po wydaniu, przywróć poprzednią wersję jako bieżącą. Używaj wersji interfejsu API w przypadku zmian powodujących niezgodność kontraktu, aby obecni odbiorcy mogli nadal korzystać z wcześniejszej wersji.

Koordynuj zmiany konfiguracji usługi API Management ze strategią wdrażania dla każdego zaplecza API. Przywracanie zatwierdzenia interfejsu APIOps przywraca tylko konfigurację reprezentowaną przez to zatwierdzenie. Nie powoduje przywrócenia niezgodnego lub niedostępnego zaplecza. Zarejestruj zatwierdzenie interfejsu APIOps, poprawkę usługi API Management i wydanie zaplecza, które tworzą każde znane dobre wdrożenie. Przetestuj pełną procedurę wycofywania w środowisku nieprodukcyjnym, w tym zasady, nazwane wartości, odwołania do wpisów tajnych, zależności i zgodność zaplecza.

Zabezpieczenia

Zabezpieczenia zapewniają ochronę przed celowymi atakami i nieprawidłowym użyciem cennych danych i systemów. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu dotycząca zabezpieczeń.

Użyj repozytorium i potoku wdrożeniowego jako standardowego sposobu wprowadzania zmian w usłudze API Management. Deweloperzy i operatorzy nie potrzebują stałego prawa zapisu do produkcyjnych wystąpień usługi API Management. Udziel dostępu z podwyższonym poziomem uprawnień tylko wtedy, gdy jest to konieczne, i tylko przez ograniczony czas. Uwzględnij w repozytorium wszelkie wynikające z tego zmiany.

Użyj następujących mechanizmów, aby chronić repozytorium Git, które przechowuje artefakty usługi API Management:

• Przegląd pull requestu: Chroń gałęzie wdrażające konfigurację i wymagaj zatwierdzenia przez odpowiednich recenzentów.
• Izolacja poświadczeń: Jeśli to możliwe, preferuj sfederowaną tożsamość obciążenia. Przechowuj wpisy tajne specyficzne dla środowiska w zatwierdzonym magazynie wpisów tajnych lub środowisku repozytorium, a nie w artefaktach lub plikach potoku.
• Integralność commitów: Wymagaj podpisywania commitów w celu weryfikacji ich pochodzenia. Skonfiguruj ochronę gałęzi, aby zapobiec wymuszonym wypchnięciom i usuwaniu gałęzi, wymagaj uwierzytelniania wieloskładnikowego od użytkowników zatwierdzających lub scalających zmiany oraz zachowaj historię commitów i pull requestów na potrzeby wdrożeń.
• Przegląd artefaktu: Sprawdź wyniki ekstrakcji i dane wejściowe publikacji pod kątem sekretów, znaczników ukrycia oraz niezamierzonych wartości zależnych od środowiska. Sprawdź, czy zmiana nie rozszerza dostępu do interfejsu API ani nie osłabia zasad.

Zarządzanie narzędziem wiersza polecenia APIOps jako zależnością repozytorium. Przypnij @azure-tools/apiops-cli w pliku package.json do przetestowanej wersji, zatwierdź plik lock i użyj npm ci. Przed włączeniem potoku produkcyjnego przejrzyj wygenerowane ustawienia tożsamości, zmienne, wyzwalacze i reguły ochrony.

Optymalizacja kosztów

Optymalizacja kosztów koncentruje się na sposobach zmniejszenia niepotrzebnych wydatków i poprawy wydajności operacyjnej. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu dotycząca optymalizacji kosztów.

Narzędzie APIOps CLI jest oprogramowaniem typu open source, jednak ten scenariusz wiąże się z kosztami instancji usługi API Management oraz wybranej platformy kontroli wersji i CI/CD. Nie podano pojedynczego stałego oszacowania, ponieważ ceny usługi API Management różnią się w zależności od regionu, warstwy, liczby jednostek, modelu pojemności, konfiguracji strefy dostępności lub wielu regionów oraz użycia. Opłaty za CI/CD zależą również od typu runnera, liczby minut wliczonych w cenę, współbieżności, przestrzeni dyskowej i okresu przechowywania.

Utwórz oszacowanie specyficzne dla scenariusza w kalkulatorze cen Azure i zapisz następujące założenia przy użyciu decyzji o architekturze:

Szacowanie danych wejściowych	Założenie dotyczące rejestrowania
Region usługi API Management	Region wdrażania dla każdego wystąpienia programistycznego, testowego, przejściowego i produkcyjnego.
Poziom i pojemność	Warstwa lub wersja 2, liczba jednostek lub bram oraz godziny pracy dla każdego środowiska.
Odporność	Każde wdrożenie strefy dostępności lub regionu dodatkowego, w tym jednostek w każdej lokalizacji.
Opłaty oparte na użyciu	Oczekiwane żądania lub operacje oraz wszelkie obowiązujące opłaty za obszar roboczy, bramę hostowaną samodzielnie, sieć, monitorowanie lub transfer danych.
platforma CI/CD	Agenci hostowani przez GitHub, hostowani samodzielnie lub agenci Azure Pipelines. Przewidywana liczba uruchomień potoku, czas trwania, współbieżność, pamięć masowa oraz przechowywanie dzienników lub artefaktów.
Kontrola źródła i licencje	Liczba użytkowników i wszystkie płatne funkcje GitHub lub planu Azure DevOps.

Użyj bieżących szczegółów cennika usługi API Management , aby wybrać odpowiedni model rozliczeń. Aby uzyskać informacje o założeniach dotyczących CI/CD i kontroli wersji, zobacz cennik Azure DevOps i cennik GitHub. Wyeksportuj lub przechwyć szacowanie kalkulatora, jego walutę, datę cenową i wszystkie założenia, aby recenzenci mogli go odtworzyć i zaktualizować. Przelicz przed wdrożeniem oraz gdy zmienią się regiony, poziomy, liczba jednostek, środowiska lub wykorzystanie potoku.

Doskonałość operacyjna

Doskonałość operacyjna obejmuje procesy operacyjne, które wdrażają aplikację i działają w środowisku produkcyjnym. Aby uzyskać więcej informacji, zobacz Lista kontrolna projektu dotycząca doskonałości operacyjnej.

Metodyka APIOps sprawia, że wdrożenia są powtarzalne i tworzy historię zatwierdzeń na potrzeby analizy po zmianie. Taguj lub w inny sposób rejestruj zatwierdzenie odbierane przez każde środowisko, zachowywanie dzienników potoków i monitorowanie wystąpienia usługi API Management i zależnych interfejsów API po wdrożeniu.

W przypadku wielu środowisk promuj ten sam sprawdzony artefakt przez środowiska programistyczne, testowe i produkcyjne. Użyj przesłonięć środowiska tylko dla wartości, które muszą się różnić między środowiskami, i przejrzyj te pliki z taką samą starannością jak artefakty. Przesłonięcia podrzędne obszaru roboczego nie są stosowane w czasie publikowania, więc nie używaj ich do podwyższania poziomu środowiska. Przetestuj procedury wycofywania zmian, zanim dojdzie do incydentu. Cofnięcie zmian w Git nadal wymaga weryfikacji i kontrolowanej publikacji w celu przywrócenia usługi API Management.

Interfejs wiersza polecenia udostępnia polecenia init, extract i publish oraz może generować szkielet dla GitHub Actions lub potoków Azure DevOps. Przejrzyj szczegóły polecenia w dokumentacji interfejsu wiersza polecenia apiOps.

Bezpieczne migrowanie ze starszego zestawu narzędzi APIOps Toolkit

Jeśli proces APIOps używa starszego zestawu narzędzi APIOps Toolkit, zaplanuj uaktualnienie. Takie podejście wykorzystuje oddzielne pliki binarne Extractor i Publisher oraz szablony potoków. CLI APIOps używa pojedynczego narzędzia CLI Node.js, ale jego format artefaktów został zaprojektowany tak, aby był zgodny z artefaktami istniejącego zestawu narzędzi. Traktuj migrację jako kontrolowane przełączenie, a nie jako bezpośrednią aktualizację środowiska produkcyjnego.

1. Oznacz znane dobre artefakty i potok zestawu narzędzi oraz zachowaj istniejącego wydawcę jako opcję wycofania. Nie zmieniaj starszego wydawcy i wprowadzaj nowego wydawcę w tym samym wdrożeniu.

2. W gałęzi migracyjnej użyj najnowszej wersji narzędzia APIOps CLI i uruchom polecenie apiops init bez użycia polecenia --force. Polecenie wykrywa pliki powodujące konflikty i kończy działanie, zamiast je nadpisywać. Porównaj i świadomie zintegruj wygenerowane potoki, wytyczne dotyczące tożsamości, filtry i pliki nadpisujące.

3. Użyj artefaktów z apiops publish --dry-run oraz przesłonięć środowiska docelowego w nieprodukcyjnym wystąpieniu usługi API Management. Przejrzyj zasoby, które interfejs wiersza polecenia tworzy, aktualizuje lub usuwa. Przetestuj jedną kontrolowaną publikację i zweryfikuj wdrożone interfejsy API, zasady, nazwane wartości i zależności.

4. Nie używaj przesłonięć podrzędnych obszaru roboczego, które nie są stosowane w czasie publikowania w ramach projektu migracji ani podwyższania poziomu. Zweryfikuj alternatywne podejście do promowania zasobów podrzędnych objętych problemem lub odłóż ich migrację do czasu rozwiązania znanego problemu Właściwości zastępowania o zakresie obszaru roboczego nie są stosowane.

5. Podczas przełączenia zezwalaj tylko jednemu wydawcy na zapisywanie do wystąpienia usługi API Management. Wyłącz starszy mechanizm wyzwalający publikowanie przed włączeniem mechanizmu publikowania CLI. Wdróż sprawdzony commit i monitoruj rezultat. Zachowaj oznaczony tagiem potok zestawu Toolkit i bazę artefaktu, dopóki nowy przepływ pracy nie zakończy się pomyślnym cyklem wydania.

Aby uzyskać informacje dotyczące zgodności oraz przykłady migracji dla poszczególnych poleceń, zobacz Migracja z narzędzia APIOps Toolkit.

Wdrażanie tego scenariusza

Postępuj zgodnie z dokumentacją narzędzia APIOps CLI w repozytorium GitHub APIOps CLI. Zacznij od nieprodukcyjnego wystąpienia usługi API Management i skorzystaj z bieżących wskazówek dotyczących aktualnej wersji narzędzia APIOps CLI. Aby rozpocząć pracę ze środowiskiem nieprodukcyjnym, zobacz Jak zarządzać konfiguracją usługi API Management za pomocą interfejsu wiersza polecenia usługi APIOps.

Współautorzy

Microsoft utrzymuje ten artykuł. Następujący współautorzy napisali ten artykuł.

Główni autorzy:

• Pat Altimore | Starszy deweloper zawartości
• Wael Kdouh | Starszy główny architekt rozwiązań
• Rishabh Saha | Starszy główny architekt rozwiązań

Aby wyświetlić niepubliczne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki

• APIOps CLI
• Jak zarządzać konfiguracją usługi API Management za pomocą interfejsu wiersza polecenia usługi APIOps
• Omówienie metodyki GitOps

Powiązane zasoby

• GitOps dla Azure Kubernetes Service (AKS)
• Migrowanie aplikacji internetowej przy użyciu usługi API Management
• Ochrona interfejsów API przy użyciu usługi Azure Application Gateway i usługi API Management