Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Ten artykuł zawiera podsumowanie najlepszych rozwiązań dotyczących korzystania z usługi Azure Front Door.
Ogólne sprawdzone metody postępowania
Informacje o tym, kiedy połączyć usługę Traffic Manager i usługę Front Door
W przypadku większości rozwiązań zalecamy użycie usługi Front Door lubAzure Traffic Manager, ale nie obu tych rozwiązań. Usługa Azure Traffic Manager to oparty na systemie DNS moduł równoważenia obciążenia. Wysyła ruch bezpośrednio do punktów końcowych źródła. Z kolei usługa Azure Front Door przerywa połączenia w punktach obecności (PoPs) w pobliżu klienta i ustanawia oddzielne długotrwałe połączenia ze źródłami. Produkty działają inaczej i są przeznaczone do różnych przypadków użycia.
Jeśli potrzebujesz buforowania i dostarczania zawartości (CDN), zakończenia protokołu TLS, zaawansowanych funkcji routingu lub zapory aplikacji internetowej (WAF), rozważ użycie usługi Front Door. W przypadku prostego globalnego równoważenia obciążenia z połączeniami bezpośrednimi od klienta do punktów końcowych rozważ użycie usługi Traffic Manager. Aby uzyskać więcej informacji na temat wybierania opcji równoważenia obciążenia, zobacz Opcje równoważenia obciążenia.
Jednak w ramach złożonej architektury wymagającej wysokiej dostępności można umieścić usługę Azure Traffic Manager przed usługą Azure Front Door. W mało prawdopodobnym przypadku niedostępności usługi Azure Front Door, usługa Azure Traffic Manager może następnie kierować ruch do alternatywnego miejsca docelowego, takiego jak Azure Application Gateway lub partnerska sieć dostarczania treści (CDN).
Ważne
Nie umieszczaj usługi Azure Traffic Manager za usługą Azure Front Door. Usługa Azure Traffic Manager powinna zawsze znajdować się przed usługą Azure Front Door.
Ogranicz ruch do swoich źródeł
Funkcje usługi Front Door działają najlepiej, gdy ruch przepływa tylko przez usługę Front Door. Należy skonfigurować źródło, aby blokować ruch, który nie został wysłany za pośrednictwem usługi Front Door. Aby uzyskać więcej informacji, zobacz Bezpieczne przesyłanie ruchu do punktów końcowych Azure Front Door.
Korzystanie z najnowszej wersji interfejsu API i wersji zestawu SDK
Podczas pracy z usługą Front Door przy użyciu interfejsów API, szablonów usługi ARM, bibliotek Bicep lub zestawów SDK platformy Azure ważne jest użycie najnowszej dostępnej wersji interfejsu API lub zestawu SDK. Aktualizacje interfejsu API i zestawu SDK są wykonywane, gdy są dostępne nowe funkcje, a także zawierają ważne poprawki zabezpieczeń i poprawki błędów.
Konfigurowanie dzienników
Usługa Front Door śledzi obszerne dane telemetryczne dotyczące każdego żądania. Po włączeniu buforowania serwery źródłowe mogą nie odbierać każdego żądania, dlatego ważne jest, aby korzystać z dzienników usługi Front Door, aby zrozumieć, jak działa Twoje rozwiązanie i jak odpowiada na żądania klientów. Aby uzyskać więcej informacji na temat metryk i dzienników, które rejestruje usługa Azure Front Door, zobacz Monitorowanie metryk i dzienników w Azure Front Door oraz dzienniki zapory aplikacji sieci Web (WAF).
Aby skonfigurować rejestrowanie dla własnej aplikacji, zobacz Konfigurowanie dzienników usługi Azure Front Door
Najlepsze rozwiązania dotyczące protokołu TLS
Używanie kompleksowego protokołu TLS
Usługa Front Door kończy połączenia TCP i TLS z klientami. Następnie ustanawia nowe połączenia z każdego punktu obecności (PoP) do punktu początkowego. Dobrym rozwiązaniem jest zabezpieczenie każdego z tych połączeń przy użyciu protokołu TLS, nawet w przypadku źródeł hostowanych na platformie Azure. Takie podejście zapewnia, że dane są zawsze szyfrowane podczas przesyłania.
Aby uzyskać więcej informacji, zobacz Pełne wdrożenie TLS z usługą Azure Front Door.
Przekierowanie HTTP do HTTPS
Dobrym rozwiązaniem jest użycie protokołu HTTPS do nawiązania połączenia z usługą przez klientów. Czasami jednak należy zaakceptować żądania HTTP, aby umożliwić starszym klientom lub klientom, którzy mogą nie rozumieć najlepszych rozwiązań.
Usługę Front Door można skonfigurować tak, aby automatycznie przekierowywała żądania HTTP w celu korzystania z protokołu HTTPS. Należy włączyć ustawienie Przekierowanie całego ruchu, aby używać ustawienia HTTPS na trasie.
Używanie zarządzanych certyfikatów TLS
Gdy usługa Front Door zarządza certyfikatami TLS, zmniejszają się koszty operacyjne i łatwiej jest uniknąć kosztownych przestojów spowodowanych zapomnieniem o odnowieniu certyfikatu. Usługa Front Door automatycznie wystawia zarządzane certyfikaty TLS i zapewnia ich rotację.
Aby uzyskać więcej informacji, zobacz Konfigurowanie protokołu HTTPS w domenie niestandardowej usługi Azure Front Door przy użyciu witryny Azure Portal.
Używanie najnowszej wersji dla certyfikatów zarządzanych przez klienta
Jeśli zdecydujesz się używać własnych certyfikatów TLS, rozważ ustawienie wersji certyfikatu usługi Key Vault na wartość "Latest". Korzystając z opcji "Najnowsze", należy unikać ponownego konfigurowania usługi Front Door w celu używania nowych wersji certyfikatu i oczekiwania na wdrożenie certyfikatu w środowiskach usługi Front Door.
Aby uzyskać więcej informacji, zobacz Wybieranie certyfikatu dla usługi Azure Front Door do wdrożenia.
Najlepsze rozwiązania dotyczące nazw domen
Wdrażanie domen niestandardowych
Wdrożenie domen niestandardowych dla punktów końcowych usługi Front Door zapewnia lepszą dostępność i elastyczność podczas zarządzania domenami i ruchem. Nie twardo koduj domen udostępnianych przez usługę AFD (takich jak *.azurefd.z01.net) w klientach/kodach źródłowych/zaporze sieciowej. W takich scenariuszach należy używać domen niestandardowych.
Użyj tej samej nazwy domeny w usłudze Front Door i w źródle.
Usługa Front Door może modyfikować nagłówek Host w żądaniach przychodzących. Ta funkcja może być przydatna w przypadku zarządzania zestawem niestandardowych nazw domen przeznaczonych dla klientów kierowanych do pojedynczego źródła. Ta funkcja może również pomóc, jeśli chcesz uniknąć konfigurowania niestandardowych nazw domen w usłudze Front Door i w miejscu pochodzenia. Jednak ponowne zapisywanie nagłówka Host może spowodować przerwanie żądań plików cookie i przekierowań adresów URL. W szczególności w przypadku korzystania z platform, takich jak usługi Azure App Service, funkcje, takie jak afinitet sesji oraz uwierzytelnianie i autoryzacja, mogą nie działać poprawnie.
Przed ponownym zapisem Host nagłówka żądań należy dokładnie rozważyć, czy aplikacja będzie działać poprawnie.
pl-PL: Aby uzyskać więcej informacji, zobacz Zachowywanie oryginalnej nazwy hosta HTTP między serwerem proxy zwrotnym a jego aplikacją internetową zaplecza.
Zapora aplikacji internetowej
Włącz WAF (zapora aplikacji internetowej)
W przypadku aplikacji internetowych zalecamy włączenie zapory aplikacji internetowej usługi Front Door (WAF) i skonfigurowanie jej pod kątem używania reguł zarządzanych. Kiedy używasz WAF (zapory aplikacji internetowej) oraz reguł zarządzanych przez firmę Microsoft, Twoja aplikacja jest chroniona przed szeroką gamą ataków.
Aby uzyskać więcej informacji, zobacz Web Application Firewall (WAF) w usłudze Azure Front Door.
Postępuj zgodnie z najlepszymi praktykami dotyczącymi zapory aplikacji internetowych
Zapora aplikacji internetowej dla usługi Front Door ma własny zestaw najlepszych rozwiązań dotyczących konfiguracji i użycia. Aby uzyskać więcej informacji, zobacz Najlepsze rozwiązania dotyczące zapory aplikacji internetowej w usłudze Azure Front Door.
Najlepsze praktyki dotyczące sondy kondycji zdrowotnej
Wyłącz sondy kondycji, gdy istnieje tylko jedno źródło w grupie źródeł
Sondy diagnostyczne usługi Front Door są przeznaczone do wykrywania sytuacji, w których źródło jest niedostępne lub nieprawidłowo działające. Gdy sonda kondycji wykryje problem z źródłem, można skonfigurować usługę Front Door do wysyłania ruchu do innego źródła w grupie pochodzenia.
Jeśli masz tylko jedno źródło, usługa Front Door zawsze kieruje ruch do tego źródła, nawet jeśli jego sonda kondycji zgłasza niekorzystny stan. Stan zgłaszany przez sondę kondycji nie zmienia zachowania usługi Front Door. W tym scenariuszu sondy kondycji nie zapewniają korzyści i należy je wyłączyć, aby zmniejszyć ruch w miejscu pochodzenia.
Aby uzyskać więcej informacji, zobacz Sondy kondycji.
Dobrze wybrać punkty końcowe sondy monitorującej kondycję
Zastanów się nad lokalizacją, którą wskażesz sondzie kondycji usługi Front Door do monitorowania. Zazwyczaj dobrym pomysłem jest monitorowanie strony internetowej lub lokalizacji, którą specjalnie projektujesz pod kątem monitorowania kondycji. Logika aplikacji może uwzględniać stan wszystkich krytycznych składników wymaganych do obsługi ruchu produkcyjnego, w tym serwerów aplikacji, baz danych i pamięci podręcznych. W ten sposób, jeśli którykolwiek komponent ulegnie awarii, Front Door może skierować ruch do innego wystąpienia tej samej usługi.
Aby uzyskać więcej informacji, zobacz wzorzec monitorowania stanu punktu końcowego .
Korzystanie z sond kondycji HEAD
Sondy kondycji mogą używać metody GET lub HEAD HTTP. Dobrym zwyczajem jest użycie metody HEAD dla sond zdrowotnych, co zmniejsza obciążenie ruchu na źródłach.
Aby uzyskać więcej informacji, zobacz Obsługiwane metody HTTP dla sond kondycji.