Wzorzec hostingu zawartości statycznej

Wdróż zawartość statyczną do usługi magazynowania w chmurze, która może dostarczyć ją bezpośrednio do klienta. Takie podejście może zmniejszyć potrzebę potencjalnie kosztownych instancji obliczeniowych.

Kontekst i problem

Aplikacje często dostarczają zawartość, która nie wymaga przetwarzania dla każdego żądania. Przykłady obejmują strony HTML, obrazy, arkusze stylów, pliki JavaScript po stronie klienta, dokumenty PDF i pakiety oprogramowania. Tę zawartość można wygenerować podczas procesu kompilacji lub publikowania i aktualizować ją niezależnie.

Mimo że serwery internetowe są zoptymalizowane pod kątem dynamicznego renderowania i buforowania danych wyjściowych, nadal muszą obsługiwać żądania pobierania zawartości statycznej. Obsługa tych żądań zużywa moc obliczeniową, która może być używana przez aplikację do obsługi żądań dynamicznych.

Solution

W większości środowisk hostingu w chmurze niektóre zasoby aplikacji i statyczne strony można umieścić w usłudze pamięci masowej. Usługa magazynu może obsługiwać żądania dla tych zasobów, zmniejszając obciążenie zasobów obliczeniowych obsługujących inne żądania internetowe.

Koszt pamięci masowej hostowanej w chmurze jest zwykle znacznie mniejszy niż koszt instancji obliczeniowych. To, czy ten wzorzec zmniejsza koszty hostingu, zależy od kosztów obliczeniowych, których można uniknąć, oraz kosztów przechowywania i dostarczania zawartości.

Zaplanuj, jak wdrożyć aplikację i jej zasoby statyczne, oraz zabezpieczyć zasoby, które nie są przeznaczone do dostępu anonimowego.

Problemy i zagadnienia

Podczas podejmowania decyzji o zaimplementowaniu tego wzorca należy wziąć pod uwagę następujące kwestie:

  • Udostępnij punkt końcowy HTTP lub HTTPS dla klientów bezpośrednio z pamięci masowej lub za pośrednictwem sieci dostarczania treści (CDN) lub zwrotnego serwera proxy. Domyślnie używaj protokołu HTTPS, aby chronić dane podczas przesyłania.

    Protokół HTTP może być odpowiedni w przypadku dystrybucji artefaktów publicznych, gdy poufność nie jest wymagana, a klienci niezależnie weryfikują autentyczność i integralność zawartości, na przykład sprawdzając podpisy cyfrowe przy użyciu certyfikatu zaufanego wydawcy.

  • Rozważ użycie sieci CDN do buforowania zawartości w pobliżu klientów i zmniejszenia liczby żądań do źródła pamięci masowej. Jeśli Twoi klienci są rozmieszczeni na całym świecie, rozważ globalną sieć CDN, która buforuje zawartość z kontenera magazynu w lokalizacjach brzegowych na całym świecie. Korzyść zależy od lokalizacji klientów, wzorców żądań i współczynników trafień pamięci podręcznej.

  • Porównaj koszty magazynowania i transferu danych z kosztami mocy obliczeniowej, których możesz uniknąć. Oszacuj koszty przy użyciu oczekiwanego ruchu, rozmiarów zasobów, lokalizacji klientów i współczynników trafień pamięci podręcznej. Odciążanie zmniejsza koszty obliczeniowe tylko wtedy, gdy zmniejsza rozliczane użycie lub pozwala zmniejszyć pojemność hosta.

  • Wybierz opcję nadmiarowości danych spełniającą wymagania dotyczące dostępności i odzyskiwania. Rozróżnij ochronę przed awarią strefy od ochrony przed awarią regionalną. Replikacja między regionami może być asynchroniczna, więc lokalizacja pomocnicza może nie mieć najnowszych zasobów.

    Sieć CDN wprowadza dodatkową zależność w dostarczaniu, a jej pamięć podręczna może nie zawierać wszystkich zasobów potrzebnych klientom podczas awarii serwera źródłowego.

  • Monitoruj dostępność zasobów, czasy odpowiedzi oraz żądania, które zakończyły się niepowodzeniem lub są ograniczane w magazynie danych oraz w dowolnej sieci CDN lub na serwerze proxy. Utwórz alerty dotyczące problemów z dostawą.

  • Koordynowanie wdrożeń aplikacji i artefaktów. Opublikuj zmienione zasoby na nowych, wersjonowanych adresach URL przed wdrożeniem stron odwołujących się do nich. Zachowaj starsze zasoby, dopóki buforowane strony, obsługiwane wersje aplikacji lub procedury wycofywania nadal od nich zależą.

    Skonfiguruj klucze pamięci podręcznej, aby odróżnić wersje zawartości i warianty. Ponadto świadomie dobieraj czas życia pamięci podręcznej przeglądarki i CDN. Zmiana, usunięcie lub ograniczenie dostępu do treści źródłowej nie powoduje unieważnienia kopii w pamięci podręcznej. Czyść pamięć podręczną, gdy zajdzie taka potrzeba, ale należy uwzględnić czas propagacji i pamiętać, że czyszczenie pamięci podręcznej CDN nie czyści pamięci podręcznej przeglądarki. Aby uzyskać więcej informacji, zobacz Routing i wersjonowanie usługi CDN oraz przeczyszczanie pamięci podręcznej w Azure Front Door.

  • Ustaw i zweryfikuj właściwości PROTOKOŁU HTTP, takie jak Content-Type, Content-Encoding i Cache-Control podczas wdrażania zasobów, aby klienci prawidłowo interpretowali i buforowali pliki. Aby uzyskać wskazówki dotyczące Azure, zobacz Właściwości protokołu HTTP obiektu blob.

  • Obsługa adresów URL podczas przenoszenia plików między lokalizacjami magazynu. Użyj routingu lub przepisywania adresów URL, aby istniejące linki nadal działały, gdy jedyną zmianą jest układ przechowywania danych. Jeśli publiczny adres URL musi ulec zmianie, skonfiguruj przekierowanie w usłudze CDN, zwrotnym serwerze proxy lub innym składniku obsługującym protokół HTTP, który obsługuje wymagane mapowania. Aby uzyskać powiązane wskazówki, zobacz Zachowywanie linków podczas przemieszczania zawartości.

  • Zdecyduj, czy zasoby statyczne powinny używać publicznego originu aplikacji, czy oddzielnej nazwy hosta. Zwrotny serwer proxy może kierować ścieżki same-origin do magazynu, więc oddzielny magazyn nie zawsze wymaga odrębnych bezwzględnych adresów URL.

    W przypadku żądań między źródłami przeglądarki, które wymagają współużytkowania zasobów między źródłami (CORS), skonfiguruj wymagane nagłówki odpowiedzi. Aby uzyskać więcej informacji, zobacz Use Azure Front Door with Azure Storage blobs i CORS support for Azure Storage.

  • Zezwalaj na anonimowy dostęp do odczytu tylko dla zawartości, którą zamierzasz upublicznić. Publiczne dostarczanie może używać originu pamięci masowej, do którego dostęp może uzyskać tylko sieć CDN lub serwer proxy. Ogranicz bezpośredni dostęp do źródła, gdy mógłby ominąć kontrole warstwy dostarczania.

    Zachowaj zawartość prywatną w kontenerach, które wymagają autoryzacji. Ogranicz uprawnienia do przesyłania, zastępowania lub usuwania hostowanej zawartości zaufanym tożsamościom wdrożeniowym. Aby uzyskać więcej informacji, zobacz Bezpieczny dostęp do źródeł Azure Front Door.

  • Rozważ użycie klucza lub tokenu valet, aby kontrolować dostęp do zasobów, które nie powinny być dostępne anonimowo. W przypadku chronionych pobrań dostarczanych za pośrednictwem sieci CDN wyłącz buforowanie udostępnione, chyba że warstwa dostarczania weryfikuje uprawnienia dostępu do każdego żądania, nawet w przypadku obsługi buforowanej odpowiedzi. Aby uzyskać więcej informacji, zobacz Valet Key pattern i uwierzytelnianie zawartości usługi Blob Storage dostarczanej za pośrednictwem Azure Front Door.

Kiedy należy używać tego wzorca

Ten wzorzec jest przydatny w przypadku:

  • Minimalizacja kosztu hostingu witryn internetowych i aplikacji zawierających jakieś zasoby statyczne.

  • Minimalizacja kosztu hostingu witryn internetowych składających się tylko z zawartości statycznej i zasobów. W zależności od możliwości systemu pamięci masowej dostawcy hostingu może być możliwe hostowanie w pełni statycznej witryny internetowej w całości na koncie magazynu danych.

  • Udostępnianie zasobów statycznych i zawartości dla aplikacji działających w innych środowiskach hostingu lub na innych serwerach lokalnych.

  • Dystrybuowanie wstępnie utworzonych artefaktów, takich jak pakiety oprogramowania, które klienci mogą pobierać bez przetwarzania poszczególnych żądań. W przypadku artefaktów publicznych dostarczanych za pośrednictwem protokołu HTTP klienci powinni mieć możliwość niezależnego weryfikowania autentyczności i integralności. Aby zapoznać się z przykładem tego podejścia, zobacz zabezpieczenia usługi Windows Update.

  • Dystrybucja zawartości w więcej niż jednym obszarze geograficznym przy użyciu sieci dostarczania zawartości, która buforuje zawartość konta magazynu w wielu centrach danych na całym świecie.

  • Monitorowanie kosztów i użycia przepustowości. Używając oddzielnego konta magazynu dla części lub całości zawartości statycznej, można łatwiej oddzielić koszty hostingu od kosztów środowiska wykonawczego.

Ten wzorzec może nie być odpowiedni w następujących przypadkach:

  • Aplikacja musi przetwarzać lub personalizować treść dla każdego żądania przed jej dostarczeniem. Na przykład może być konieczne wstawienie danych specyficznych dla użytkownika do dokumentu.

  • Ilość zawartości statycznej jest bardzo mała. Koszty pobierania tej zawartości z oddzielnego magazynu mogą przeważyć zalety oddzielenia jej od zasobu obliczeniowego.

Projektowanie obciążenia pracy

Oceń, jak używać wzorca hostingu zawartości statycznej w projekcie obciążenia, aby uwzględnić cele i zasady omówione w filarach Azure Well-Architected Framework. Na przykład:

Filar Jak ten wzorzec obsługuje cele filaru
Optymalizacja kosztów koncentruje się na utrzymaniu i poprawiezwrotu z nakładu pracy. Przeniesienie zawartości statycznej do magazynu może zmniejszyć koszty zasobów obliczeniowych, jeśli zmniejsza rozliczane użycie lub pozwala zmniejszyć zasoby hosta aplikacji. Ogólnie rzecz biorąc, używanie platformy aplikacji do dostarczania zawartości statycznej nie jest opłacalne.

- CO:09 Koszty przepływu
- CO:10 Koszty danych
Efektywność wydajności pomaga wydajnie sprostać wymaganiom dzięki optymalizacjom skalowania, danych i kodu. Odciążanie dostarczania zawartości statycznej pomaga zmniejszyć przeciążenie i pozostawia zasoby obliczeniowe aplikacji dostępne dla logiki biznesowej.

- PE:07 Kod i infrastruktura

Jeśli ten wzorzec wprowadza kompromisy w ramach filaru, rozważ je przed celami innych filarów.

Example

Hostowanie statycznej witryny w usłudze Azure Blob Storage obsługuje pliki publiczne z kontenera $web za pośrednictwem anonimowych żądań tylko do odczytu. Domyślnie pliki mają adres URL w poddomenie typu core.windows.net, na przykład https://contoso.z4.web.core.windows.net/image.png. Możesz skonfigurować niestandardową nazwę domeny i użyć Azure Front Door Standard lub Premium, aby uzyskać dostęp do plików za pośrednictwem protokołu HTTPS. Aby uzyskać więcej informacji, zobacz Mapowanie domeny niestandardowej na punkt końcowy usługi Azure Blob Storage.

Diagram przedstawiający aplikację wysyłającą linki do stron do klienta, który żąda plików bezpośrednio z kontenera magazynu.

Aplikacja znajduje się w lewym górnym rogu, a klient znajduje się pod nią. Kontener znajduje się w prawym górnym rogu. Strzałka oznaczona etykietą „Dostarczanie stron zawierających linki do plików w usłudze przechowywania” prowadzi z aplikacji do klienta. Kontener zawiera dwie grupy plików: styles.css, sitecode.js, download.doc i samples.zip po lewej stronie oraz image1.png, image2.pngi image3.png po prawej stronie. Linia ze strzałkami na obu końcach łączy klienta z kontenerem. Jego etykieta brzmi „Żądanie plików z usługi magazynu”.

Statyczny punkt końcowy witryny internetowej nie obsługuje uwierzytelniania ani autoryzacji. Zmiana poziomu dostępu kontenera $web lub wyłączenie anonimowego dostępu do obiektów blob na koncie magazynu nie powoduje, że ten punkt końcowy jest prywatny. Nie przechowuj zawartości prywatnej w $web. Aby uzyskać więcej informacji, zobacz Wpływ ustawienia poziomu dostępu na kontenerze internetowym.

Aby obsługiwać zawartość prywatną, należy przechowywać pliki w osobnym prywatnym kontenerze Blob Storage i używać punktu końcowego usługi Blob, a nie statycznego punktu końcowego witryny internetowej. Po autoryzowaniu klienta wydaj krótkotrwałą sygnaturę dostępu współdzielonego (SAS) delegowania użytkownika z uprawnieniami tylko do odczytu, ograniczoną do wymaganych obiektów blob. Traktuj tokeny SAS jako poświadczenia i dystrybuuj je tylko za pośrednictwem protokołu HTTPS. Więcej informacji znajdziesz w artykule Najlepsze praktyki przy korzystaniu z SAS.

Włącz opcję Wymagany bezpieczny transfer na koncie magazynu, aby odrzucić żądania HTTP. Aby uzyskać więcej informacji, zobacz Wymagaj bezpiecznego transferu.

Jeśli pliki statyczne są obsługiwane z innej domeny niż strona, połącz się z pełnymi adresami URL, takimi jak https://static.contoso.com/image.png. Jeśli odwrotny serwer proxy obsługuje pliki w domenie aplikacji, możesz użyć ścieżek, takich jak /image.png zamiast tego. Jeśli zasób jest chroniony za pomocą sygnatury dostępu współdzielonego, dołącz token SAS w adresie URL zasobu.

Statyczny punkt końcowy witryny internetowej nie obsługuje reguł CORS usługi Azure Storage. Jeśli scenariusz przeglądarki wymaga dostępu między źródłami, użyj warstwy dostarczania, która dostarcza wymagane nagłówki CORS lub punkt końcowy obsługujący konfigurację mechanizmu CORS.

Przykład hostingu zawartości statycznej pokazuje, jak klient pobiera zasoby statyczne bezpośrednio z Blob Storage. Używa Bicep i Azure CLI do aprowizowania konta magazynu, włączania hostowania statycznej witryny internetowej i przekazywania arkusza stylów oraz niestandardowej strony 404 do kontenera $web.

Przykład generuje lokalny plik index.html, zastępując symbol zastępczy w szablonie HTML statycznym adresem URL witryny internetowej konta magazynu. Po otwarciu tego pliku w przeglądarce przeglądarka ładuje arkusz stylów bezpośrednio z pamięci masowej. W wdrożonym obciążeniu środowisko obliczeniowe aplikacji może obsługiwać strony odwołujące się do tych zasobów hostowanych w usłudze magazynu.

Następny krok

  • Wzorzec Valet Key. Jeśli zasoby docelowe nie powinny być dostępne dla użytkowników anonimowych, użyj tego wzorca, aby ograniczyć bezpośredni dostęp.