Operacje na obciążeniach o znaczeniu krytycznym na platformie Azure

Podobnie jak w przypadku dowolnej aplikacji, zmiany występują w obciążeniach o znaczeniu krytycznym. Aplikacja będzie ewoluować wraz z upływem czasu, klucze wygasną, poprawki zostaną wydane i nie tylko. Wszystkie zmiany i utrzymanie powinny być stosowane przy użyciu potoków wdrożeniowych. Ten artykuł zawiera wskazówki operacyjne dotyczące wprowadzania typowych zmian i aktualizacji.

Wyrównanie organizacyjne jest równie ważne dla procedur operacyjnych. Jest to kluczowe dla sukcesu operacyjnego obciążenia o znaczeniu krytycznym, że kompleksowe obowiązki należą do jednego zespołu, zespołu DevOps.

Wykonanie techniczne powinno korzystać z natywnych dla platformy Azure możliwości platformy Azure oraz używania zautomatyzowanych usług Azure Pipelines do wdrażania zmian w aplikacji, infrastrukturze i konfiguracji. Ponownie, zadania konserwacyjne powinny być zautomatyzowane, a unikać należy zadań ręcznych.

W poniższych sekcjach opisano podejścia do obsługi różnych typów zmian.

Automatyzacja aplikacji

Ciągła integracja i ciągłe wdrażanie (CI/CD) umożliwia właściwe wdrażanie i weryfikację obciążeń o znaczeniu krytycznym. CI/CD to preferowane podejście do wdrażania zmian w dowolnym środowisku, deweloperskim/testowym, produkcyjnym i innych. W przypadku obciążeń o znaczeniu krytycznym zmiany wymienione w poniższej sekcji powinny spowodować wdrożenie zupełnie nowej sygnatury. Nowy znaczek powinien być dokładnie przetestowany w ramach procesu wdrażania, zanim ruch zostanie przekierowany do znaczka przy użyciu strategii wdrażania niebieskiego/zielonego.

W poniższych sekcjach opisano zmiany, które należy wdrożyć, tam, gdzie to możliwe, za pośrednictwem CI/CD.

Zmiany aplikacji

Wszystkie zmiany w kodzie aplikacji powinny być wdrażane za pomocą CI/CD. Kod powinien zostać skompilowany, przeanalizowany pod kątem błędów i przetestowany pod kątem regresji. Zależności aplikacji, takie jak środowisko uruchomieniowe lub pakiety, powinny być monitorowane, a aktualizacje wdrażane za pośrednictwem ciągłej integracji/ciągłego wdrażania (CI/CD).

Zmiany infrastruktury

Infrastruktura powinna być modelowana i aprowizowana jako kod. Ta praktyka jest często nazywana infrastrukturą jako kodem (IaC). Wszystkie zmiany IaC powinny być wdrażane za pośrednictwem potoków CI/CD. Aktualizacje infrastruktury, takie jak stosowanie poprawek systemu operacyjnego, powinny być również zarządzane za pośrednictwem potoków CI/CD.

Zmiany konfiguracji

Zmiany konfiguracji są częstą przyczyną awarii aplikacji. Aby zwalczać te awarie, konfiguracja aplikacji lub infrastruktury powinna zostać przechwycona jako kod. Ta praktyka jest znana jako Konfiguracja jako kod (CaC). Zmiany w CaC powinny być wdrażane za pośrednictwem potoków CI/CD.

Aktualizacje biblioteki/zestawu SDK

W przypadku aplikacji o znaczeniu krytycznym ważne jest, aby kod źródłowy i zależności były aktualizowane po udostępnieniu nowych wersji. Zalecane podejście polega na wykorzystaniu procesu zmiany zarządzania konfiguracją w repozytorium kodu źródłowego. To narzędzie należy skonfigurować tak, aby automatycznie tworzyło Pull Requesty dla różnych aktualizacji zależności, takich jak:

• Pakiety NuGet platformy .NET
• Pakiety menedżera pakietów Node Package Manager (NPM) dla JavaScript
• Dostawca narzędzia Terraform

W poniższym scenariuszu przedstawiono przykład automatyzowania aktualizacji bibliotek przy użyciu dependabot w repozytorium GitHub.

1. Funkcja Dependabot wykrywa aktualizacje bibliotek i zestawu SDK używanego w kodzie aplikacji

2. Dependabot aktualizuje kod aplikacji w gałęzi i tworzy żądanie ściągnięcia (PR) z tymi zmianami względem gałęzi głównej. Żądanie pull request zawiera wszystkie istotne informacje i jest gotowe do ostatecznego przeglądu.

3. Po zakończeniu przeglądu i testowania kodu, Pull Request można połączyć z gałęzią główną.

W przypadku zależności, których Dependabot nie jest w stanie monitorować, upewnij się, że masz procesy służące do wykrywania nowych wersji.

Rotacje klucza/tajnego klucza/certyfikatu

Rotacja (odnawianie) kluczy i tajnych danych powinna być standardową procedurą we wszystkich obciążeniach roboczych. Tajne informacje mogą wymagać zmiany w krótkim czasie po ujawnieniu lub regularnie jako dobra praktyka bezpieczeństwa.

Ponieważ wygasłe lub nieprawidłowe wpisy tajne mogą powodować awarie aplikacji (zobacz Analiza błędów), ważne jest, aby mieć jasno zdefiniowany i sprawdzony proces. W przypadku platformy Azure Mission-Critical sygnatury powinny być aktywne tylko przez kilka tygodni. Z tego powodu zarządzanie tajnymi zasobami pieczęci nie jest problemem. Jeśli wpisy tajne w jednej sygnaturze wygasną, aplikacja jako całość będzie nadal działać.

Zarządzanie tajemnicami w celu uzyskania dostępu do długotrwałych zasobów globalnych ma jednak kluczowe znaczenie. Godnym uwagi przykładem są klucze interfejsu API usługi Azure Cosmos DB. Jeśli klucze interfejsu API usługi Azure Cosmos DB wygasną, wszystkie komponenty będą miały wpływ jednocześnie i spowodują całkowitą awarię aplikacji.

Poniższe podejście to przetestowane i udokumentowane podejście do rotacji kluczy usługi Azure Cosmos DB bez powodowania przestojów dla usług uruchomionych w usłudze Azure Kubernetes Service.

1. Zaktualizuj znaczki za pomocą klucza pomocniczego. Domyślnie podstawowy klucz interfejsu API dla usługi Azure Cosmos DB jest przechowywany jako wpis tajny w usłudze Azure Key Vault w każdej sygnaturze. Utwórz pull request, który aktualizuje kod szablonu IaC, używający drugiego klucza API Azure Cosmos DB. Przeprowadź tę zmianę przez standardową procedurę przeglądu i aktualizacji pull requestów, aby wdrożyć ją jako nową wersję lub poprawkę krytyczną.

2. (opcjonalnie) Jeśli aktualizacja została wdrożona jako poprawka pilna do istniejącej wersji, zasobniki automatycznie pobierają nowy sekret z Azure Key Vault po kilku minutach. Jednak kod klienta usługi Azure Cosmos DB obecnie nie inicjuje się przy użyciu zmienionego klucza. Aby rozwiązać ten problem, uruchom ponownie wszystkie pody ręcznie, używając następujących poleceń w klastrze:

   kubectl rollout restart deployment/CatalogService-deploy -n workload
   kubectl rollout restart deployment/BackgroundProcessor-deploy -n workload
   kubectl rollout restart deployment/healthservice-deploy -n workload
   

3. Nowo wdrożone lub zrestartowane zasobniki korzystają teraz z pomocniczego klucza interfejsu API do połączenia z usługą Azure Cosmos DB.

4. Po ponownym uruchomieniu wszystkich zasobników na wszystkich sygnaturach lub wdrożeniu nowej sygnatury ponownie wygeneruj podstawowy klucz interfejsu API dla usługi Azure Cosmos DB. Oto przykład polecenia:

   az cosmosdb keys regenerate --key-kind primary --name MyCosmosDBDatabaseAccount --resource-group MyResourceGroup
   

5. Zmień szablon IaC, aby użyć podstawowego klucza interfejsu API na potrzeby przyszłych wdrożeń. Alternatywnie możesz nadal używać klucza pomocniczego i przełączać się z powrotem do podstawowego klucza interfejsu API, gdy nadszedł czas na odnowienie pomocniczego klucza.

Alerty

Alerty są kluczem do zrozumienia, czy i kiedy występują problemy ze środowiskiem. Zmiany w alertach i/lub grupach akcji powinny być implementowane za pośrednictwem potoków CI/CD. Aby uzyskać więcej informacji na temat alertów, zobacz Modelowanie kondycji i obserwowanie obciążeń o krytycznym znaczeniu w usłudze Azure.

Automatyzacja

Wiele platform i usług działających na platformie Azure zapewnia automatyzację typowych działań operacyjnych. Ta automatyzacja obejmuje skalowanie automatyczne i zautomatyzowaną obsługę kluczy i certyfikatów.

Skalowanie

W ramach projektu aplikacji należy określić wymagania dotyczące skalowania, które definiują jednostkę skalowania dla sygnatury jako całości. Poszczególne usługi w ramach znacznika muszą być w stanie skalować się poziomo, aby sprostać szczytowemu zapotrzebowaniu lub skalować w dół, aby zaoszczędzić pieniądze lub zasoby.

Usługi, które nie mają wystarczającej ilości zasobów, mogą wykazywać różne skutki uboczne, w tym następującą listę:

• Niewystarczająca liczba podów przetwarzających komunikaty z kolejki lub partycji skutkuje wzrostem liczby nieprzetworzonych komunikatów. Ten wynik jest czasami określany jako rosnąca głębokość kolejki.
• Niewystarczające zasoby w węźle usługi Azure Kubernetes Service mogą spowodować, że zasobniki nie będą mogły działać.
• Rezultatem tego jest ograniczanie żądań:
  • Niewystarczające jednostki żądań (RU) dla usługi Azure Cosmos DB
  • Niewystarczająca liczba jednostek przetwarzania (PU) dla usługi Event Hubs w wersji Premium lub jednostek przepustowości (TU) dla wersji standardowej.
  • Niewystarczające jednostki obsługi komunikatów (MU) dla warstwy Premium usługi Service Bus

Skorzystaj z funkcji skalowania automatycznego usług, jeśli to możliwe, aby zapewnić wystarczającą ilość zasobów, aby zaspokoić zapotrzebowanie. Poniżej przedstawiono funkcje automatycznego skalowania, z których można korzystać:

• Poziome Autoskalowanie Podów pozwala zwiększać lub zmniejszać liczbę podów uruchomionych obciążeń roboczych zależnie od zapotrzebowania.
• Funkcja automatycznego skalowania klastra usługi AKS pozwala zwiększyć lub zmniejszyć liczbę węzłów w klastrze w zależności od zapotrzebowania.
• Możesz automatycznie zwiększać jednostki przepływności usługi Azure Event Hubs (warstwa standardowa)
• Możesz automatycznie aktualizować jednostki obsługi komunikatów przestrzeni nazw usługi Azure Service Bus

Zarządzanie kluczami, wpisami tajnymi i certyfikatami

Użyj tożsamości zarządzanych, jeśli to możliwe, aby uniknąć konieczności zarządzania kluczami interfejsu API lub wpisami tajnymi, takimi jak hasła.

Jeśli używasz kluczy, wpisów tajnych lub certyfikatów, użyj funkcji platformy natywnej platformy Azure, jeśli jest to możliwe. Poniżej przedstawiono kilka przykładów tych możliwości na poziomie platformy:

• Usługa Azure Front Door ma wbudowane funkcje zarządzania certyfikatami TLS i ich odnawiania.
• Usługa Azure Key Vault obsługuje automatyczną rotację kluczy.

Operacje ręczne

Istnieją działania operacyjne, które wymagają ręcznej interwencji. Te procesy powinny być testowane.

Wiadomości niedoręczone

Komunikaty, których nie można przetworzyć, powinny być kierowane do kolejki wiadomości nieprzetworzonych z alertem skonfigurowanym dla tej kolejki. Te komunikaty zwykle wymagają ręcznej interwencji, aby zrozumieć i rozwiązać problem. Należy utworzyć możliwość wyświetlania, aktualizowania i odtwarzania utraconych komunikatów.

Przywracanie usługi Azure Cosmos DB

Jeśli dane usługi Azure Cosmos DB są przypadkowo usuwane, aktualizowane lub uszkodzone, należy wykonać przywracanie z okresowej kopii zapasowej. Przywracanie z okresowej kopii zapasowej można wykonać tylko za pośrednictwem zgłoszenia serwisowego. Ten proces powinien być udokumentowany i okresowo testowany.

Zwiększenie limitu przydziału

Subskrypcje platformy Azure mają limity przydziału. Wdrożenia mogą zakończyć się niepowodzeniem po osiągnięciu tych limitów. Niektóre limity przydziału są regulowane. W przypadku dostosowywalnych limitów przydziału możesz zażądać zwiększenia z strony Moje przydziały w portalu Azure. W przypadku stałych przydziałów należy przesłać wniosek o pomoc techniczną. Zespół pomocy technicznej platformy Azure współpracuje z Tobą, aby znaleźć rozwiązanie.

Ważny

Zobacz Procedury operacyjne dla obciążeń o znaczeniu krytycznym na platformie Azure, aby zapoznać się z zagadnieniami i zaleceniami dotyczącymi projektowania operacyjnego.

Współpracownicy

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

Główni autorzy

• Rob Bagby | Główny deweloper zawartości
• Allen Sudbring | Starszy deweloper zawartości

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

Następne kroki

Wdróż implementację referencyjną, aby uzyskać pełną wiedzę na temat zasobów i ich konfiguracji używanej w tej architekturze.

Implementacja : Mission-Critical Online