Muster für das Hosten von statischen Inhalten

Stellen Sie statische Inhalte auf einem cloudbasierten Speicherdienst bereit, der diese direkt an den Client ausliefern kann. Dieser Ansatz kann die Notwendigkeit für potenziell teure Computeinstanzen verringern.

Kontext und Problem

Anwendungen liefern häufig Inhalte, die für jede Anforderung keine Verarbeitung erfordern. Beispiele sind HTML-Seiten, Bilder, Stylesheets, clientseitige JavaScript-Dateien, PDF-Dokumente und Softwarepakete. Sie können diese Inhalte während eines Build- oder Veröffentlichungsprozesses generieren und unabhängig aktualisieren.

Webserver sind zwar für dynamisches Rendering und Ausgabezwischenspeicherung optimiert, müssen aber dennoch Anforderungen für das Herunterladen statischer Inhalte verarbeiten. Die Bearbeitung dieser Anfragen beansprucht Rechenkapazität, die die Anwendung für dynamische Anfragen nutzen könnte.

Solution

In den meisten Cloudhostingumgebungen kann ein Teil der Ressourcen und statischen Seiten einer Anwendung in einem Speicherdienst platziert werden. Die Speicherdienst kann Anforderungen für diese Ressourcen bedienen, um die Computeressourcen für die Verarbeitung anderer Webanforderungen zu entlasten.

Die Kosten für Cloud-Speicher sind in der Regel deutlich niedriger als die Kosten für Recheninstanzen. Ob dieses Muster die Hostingkosten reduziert, hängt von den Berechnungskosten ab, die Sie vermeiden können, sowie von den Kosten für das Speichern und Bereitstellen der Inhalte.

Planen Sie die Bereitstellung der Anwendung und deren statischen Ressourcen sowie schützen Sie Ressourcen, die nicht für anonymen Zugriff vorgesehen sind.

Probleme und Überlegungen

Berücksichtigen Sie die folgenden Punkte, wenn Sie sich für die Implementierung dieses Musters entscheiden:

• Machen Sie einen HTTP- oder HTTPS-Endpunkt für Clients verfügbar, entweder direkt aus dem Speicher oder über ein CdN (Content Delivery Network) oder Reverseproxy. Verwenden Sie HTTPS standardmäßig, um Daten während der Übertragung zu schützen.

  HTTP kann für die öffentliche Verteilung von Artefakten geeignet sein, wenn keine Vertraulichkeit erforderlich ist und die Clients die Authentizität sowie die Integrität der Inhalte eigenständig überprüfen – beispielsweise durch die Validierung digitaler Signaturen im Abgleich mit einem vertrauenswürdigen Herausgeber.

• Ziehen Sie den Einsatz eines CDN in Betracht, um Inhalte in der Nähe der Clients zwischenzuspeichern und die Anzahl der Anfragen an den ursprünglichen Speicherort zu verringern. Wenn Ihre Clients weltweit verteilt sind, sollten Sie ein globales CDN in Betracht ziehen, das Inhalte aus dem Speichercontainer an Edgestandorten auf der ganzen Welt zwischenspeichert. Der Vorteil hängt von Clientstandorten, Anforderungsmustern und Cachetreffraten ab.

• Vergleichen Sie die Speicher- und Lieferkosten mit den Compute-Kosten, die Sie vermeiden können. Schätzen Sie die Kosten mithilfe von erwarteten Datenverkehr, Ressourcengrößen, Clientstandorten und Cachetreffraten. Durch die Auslagerung werden die Berechnungskosten nur reduziert, wenn dadurch die abgerechnete Nutzung reduziert wird oder Sie die Hostkapazität reduzieren können.

• Wählen Sie eine Speicherredundanzoption aus, die Ihre Verfügbarkeits- und Wiederherstellungsanforderungen erfüllt. Unterscheiden Sie den Schutz vor einem Ausfall einer Zone von dem Schutz vor einem regionalen Ausfall. Die regionsübergreifende Replikation kann asynchron sein, sodass ein sekundärer Speicherort möglicherweise nicht über die neuesten Ressourcen verfügt.

  Ein CDN führt eine weitere Auslieferungsabhängigkeit ein, und sein Cache enthält möglicherweise nicht alle Ressourcen, die Clients während eines Ausfalls des Origin-Servers benötigen.

• Überwachen Sie die Verfügbarkeit von Ressourcen, Antwortzeiten und fehlgeschlagenen oder gedrosselten Anfragen über Speicher und CDN oder Proxy hinweg. Erstellen Sie Benachrichtigungen für Zustellprobleme.

• Koordinieren Sie Anwendungs- und Asset-Bereitstellungen. Veröffentlichen Sie geänderte Ressourcen bei neuen, versionsierten URLs, bevor Sie Seiten bereitstellen, die darauf verweisen. Ältere Ressourcen beibehalten, während zwischengespeicherte Seiten, unterstützte Anwendungsversionen oder Rollbackprozeduren weiterhin von ihnen abhängig sind.

  Konfigurieren Sie Cacheschlüssel, um Inhaltsversionen und Varianten zu unterscheiden. Wählen Sie außerdem bewusst Browser- und CDN-Cachelebensdauern aus. Durch Das Ändern, Löschen oder Einschränken des Zugriffs auf Den Ursprungsinhalt werden zwischengespeicherte Kopien nicht ungültig. Löschen Sie Caches, wenn Sie dies benötigen, aber berücksichtigen Sie die Propagationszeit, und denken Sie daran, dass CDN-Löschvorgänge keine Browsercaches löschen. Weitere Informationen finden Sie unter CDN-Routing und Versionsverwaltung und Cache in Azure Front Door leeren.

• Legen Sie HTTP-Eigenschaften wie Content-Type, Content-Encoding und Cache-Control fest und überprüfen Sie sie bei der Bereitstellung von Ressourcen, damit Clients Dateien richtig interpretieren und zwischenspeichern. Informationen zu Azure-spezifischen Hinweisen finden Sie unter Blob HTTP-Eigenschaften.

• URLs beim Verschieben von Dateien zwischen Speicherorten behandeln Verwenden Sie Routing- oder URL-Umschreibung, um vorhandene Verknüpfungen beizubehalten, wenn sich nur das Speicherlayout ändert. Wenn sich eine öffentliche URL ändern muss, konfigurieren Sie eine Umleitung im CDN, im Reverseproxy oder in einer anderen HTTP-dienstbasierten Komponente, die die erforderlichen Zuordnungen unterstützt. Verwandte Anleitungen finden Sie unter Beibehalten von Links beim Verschieben von Inhalten.

• Entscheiden Sie, ob statische Ressourcen den öffentlichen Ursprung der Anwendung oder einen separaten Hostnamen verwenden sollen. Ein Reverseproxy kann Pfade derselben Origin an den Speicher weiterleiten, sodass separater Speicher keine eindeutigen absoluten URLs erfordert.

  Konfigurieren Sie für ursprungsübergreifende Browseranforderungen, die eine ursprungsübergreifende Ressourcenfreigabe (CROSS-Origin Resource Sharing, CORS) erfordern, die erforderlichen Antwortheader. Weitere Informationen finden Sie unter Verwenden von Azure Front Door mit Azure Storage Blobs und CORS-Unterstützung für Azure Storage.

• Anonymen Lesezugriff nur für Inhalte zulassen, die Sie öffentlich machen möchten. Öffentliche Bereitstellung kann einen Speicherursprung verwenden, auf den nur ein CDN oder Proxy zugreifen kann. Beschränken Sie den direkten Zugriff auf den Ursprungsserver, wenn dadurch Kontrollmechanismen der Bereitstellungsschicht umgangen würden.

  Bewahren Sie private Inhalte in Containern auf, die eine Autorisierung erfordern. Beschränken Sie die Berechtigungen zum Hochladen, Ersetzen oder Löschen gehosteter Inhalte auf vertrauenswürdige Bereitstellungsidentitäten. Weitere Informationen finden Sie unter "Sicherer Zugriff auf Azure Front Door-Ursprungsserver".

• Verwenden Sie ggf. einen Valetschlüssel oder ein Token, um den Zugriff auf Ressourcen zu steuern, die nicht anonym verfügbar sein sollen. Deaktivieren Sie für geschützte Downloads, die über ein CDN bereitgestellt werden, freigegebene Zwischenspeicherung, es sei denn, die Übermittlungsschicht überprüft Zugriffsberechtigungen für jede Anforderung, auch wenn eine zwischengespeicherte Antwort bereitgestellt wird. Weitere Informationen finden Sie unter Valet Key pattern und Authentifizierung für über Azure Front Door bereitgestellte Blob Storage-Inhalte.

Wann dieses Muster verwenden

Dieses Muster ist hilfreich:

• Zum Minimieren der Hostingkosten für Websites und Anwendungen, die statische Ressourcen enthalten.

• Zum Minimieren der Hostingkosten für Websites, die nur aus statischen Inhalten und Ressourcen bestehen. Abhängig von den Funktionen des Speichersystems des Hostinganbieters kann ggf. eine gesamte vollständig statische Website in einem Speicherkonto gehostet werden.

• Zum Verfügbarmachen statischer Ressourcen und Inhalte für Anwendungen, die in anderen Hostumgebungen oder auf lokalen Servern ausgeführt werden.

• Die Verteilung vorerstellter Artefakte, z. B. Softwarepakete, die Clients ohne Anforderungsverarbeitung herunterladen können. Bei öffentlichen Artefakten, die über HTTP bereitgestellt werden, sollten Clients in der Lage sein, Authentizität und Integrität unabhängig zu überprüfen. Ein Beispiel für diesen Ansatz finden Sie unter Windows Update Sicherheit.

• Verteilen von Inhalten in mehr als einem geografischen Bereich mithilfe eines Inhaltsübermittlungsnetzwerks, das den Inhalt des Speicherkontos in mehreren Rechenzentren auf der ganzen Welt zwischenspeichert.

• Zum Überwachen von Kosten und Bandbreitennutzung. Durch die Verwendung eines eigenen Speicherkontos für einige oder alle statischen Inhalte lassen sich die Hosting- und Laufzeitkosten leichter trennen.

Dieses Muster ist möglicherweise nicht geeignet, wenn:

• Die Anwendung muss Inhalte für jede Anfrage verarbeiten oder personalisieren, bevor sie ausgeliefert werden. Es kann z. B. erforderlich sein, benutzerspezifische Daten in ein Dokument einzufügen.

• Die Menge statischer Inhalte ist sehr gering. Der Mehraufwand für das Abrufen dieser Inhalte aus einem separaten Speicher kann den Kostenvorteil überwiegen, der durch die Trennung von der Rechenressource entsteht.

Arbeitslastgestaltung

Bewerten Sie, wie Sie das Muster für das Hosting statischer Inhalte im Entwurf einer Workload verwenden, um die in den Azure Well-Architected Framework-Säulen behandelten Ziele und Prinzipien zu erfüllen. Beispiele:

Säule	So unterstützt dieses Muster die Säulenziele
Kostenoptimierung konzentriert sich auf die Aufrechterhaltung und Verbesserung der Kapitalrendite Ihrer Arbeitslast.	Durch das Auslagern statischer Inhalte in Storage können Rechenkosten reduziert werden, wenn dadurch die abgerechnete Nutzung reduziert wird oder Sie die Kapazität des Anwendungshosts reduzieren können. Im Allgemeinen ist die Verwendung einer Anwendungsplattform zum Bereitstellen statischer Inhalte nicht kosteneffizient. - CO:09 Durchlaufkosten - CO:10 Datenkosten
Performance Efficiency hilft Ihrem Workload durch Optimierungen bei Skalierung, Daten und Code, die Anforderungen effizient zu erfüllen .	Durch die Auslagerung der Bereitstellung statischer Inhalte wird die Überlastung verringert und die Anwendungsrechenkapazität für die Geschäftslogik verfügbar gehalten. - PE:07-Code und -Infrastruktur

Wenn dieses Muster Kompromisse innerhalb einer Säule einführt, sollten Sie sie gegen die Ziele der anderen Säulen berücksichtigen.

Example

Azure Blob Storage statisches Websitehosting stellt öffentliche Dateien aus dem $web-Container über anonyme Leseanforderungen mit Schreibschutz bereit. Standardmäßig besitzen Dateien eine URL in einer Unterdomäne von core.windows.net (etwa https://contoso.z4.web.core.windows.net/image.png). Sie können einen benutzerdefinierten Domänennamen konfigurieren und Azure Front Door Standard oder Premium verwenden, um auf die Dateien über HTTPS zuzugreifen. Weitere Informationen finden Sie unter Zuordnen einer benutzerdefinierten Domäne zu einem Azure Blob Storage-Endpunkt.

Die Anwendung befindet sich in der oberen linken Ecke, und der Client befindet sich darunter. Ein Container befindet sich in der oberen rechten Ecke. Ein Pfeil mit der Bezeichnung "Liefern von Seiten mit Links zu Dateien im Speicherdienst" führt von der Anwendung zum Client. Der Container enthält zwei Gruppen von Dateien: styles.css, sitecode.js, download.doc und samples.zip auf der linken Seite sowie image1.png, image2.pngund image3.png auf der rechten Seite. Eine Linie mit Pfeilspitzen an beiden Enden verbindet den Client mit dem Container. Die Bezeichnung lautet "Dateien vom Speicherdienst anfordern".

Der Endpunkt der statischen Website unterstützt keine Authentifizierung oder Autorisierung. Wenn Sie die Zugriffsebene des $web Containers ändern oder anonymen BLOB-Zugriff auf das Speicherkonto deaktivieren, wird dieser Endpunkt nicht privat. Speichern Sie keine privaten Inhalte in $web. Weitere Informationen finden Sie unter "Auswirkungen des Festlegens der Zugriffsebene auf den Webcontainer".

Um private Inhalte zu bedienen, speichern Sie die Dateien in einem separaten privaten Blob Storage-Container und verwenden den Blob-Dienstendpunkt anstelle des statischen Websiteendpunkts. Stellen Sie nach der Autorisierung des Clients eine kurzlebige, schreibgeschützte Shared Access Signature (SAS) für die Benutzerdelegierung für die erforderlichen Blobs aus. Behandeln Sie SAS-Token als Anmeldeinformationen, und verteilen Sie sie nur über HTTPS. Weitere Informationen finden Sie unter Best Practices bei der Verwendung von SAS.

Aktivieren Sie Sichere Übertragung erforderlich für das Speicherkonto, um HTTP-Anforderungen abzulehnen. Weitere Informationen finden Sie unter "Sichere Übertragung erforderlich".

Wenn statische Dateien von einer anderen Domäne als der Seite bereitgestellt werden, verknüpfen Sie ihre vollständigen URLs, z. B. https://static.contoso.com/image.png. Wenn ein Reverseproxy die Dateien unter der Domäne der Anwendung bedient, können Sie stattdessen z. B. Pfade wie /image.png verwenden. Wenn die Ressource mit einer SAS geschützt ist, schließen Sie das SAS-Token in die Ressourcen-URL ein.

Der endpunkt der statischen Website unterstützt Azure Storage CORS-Regeln nicht. Wenn für Ihr Browserszenario ein ursprungsübergreifender Zugriff erforderlich ist, verwenden Sie eine Bereitstellungsebene, die die erforderlichen CORS-Header bereitstellt, oder einen Endpunkt, der die CORS-Konfiguration unterstützt.

Das Beispiel für das Hosting statischer Inhalte veranschaulicht, wie ein Client statische Ressourcen direkt aus Blob Storage abruft. Es verwendet Bicep und die Azure CLI, um ein Speicherkonto bereitzustellen, statisches Websitehosting zu aktivieren und ein Stylesheet und eine benutzerdefinierte 404-Seite in den $web Container hochzuladen.

Im Beispiel wird eine lokale index.html Datei generiert, indem ein Platzhalter in einer HTML-Vorlage durch die statische Website-URL des Speicherkontos ersetzt wird. Wenn Sie diese Datei in einem Browser öffnen, lädt der Browser das Stylesheet direkt aus dem Speicher. In einer bereitgestellten Workload können Anwendungs-Computeressourcen Seiten ausliefern, die auf diese im Speicher abgelegten Assets verweisen.

Nächster Schritt

• Verwenden Sie Azure Front Door mit Azure Storage Blobs. Wenden Sie dieses Muster mit Edgezwischenspeicherung, HTTPS und einem eingeschränkten Storage-Origin an.

Verwandte Ressource

• Valet Key-Muster. Wenn die Zielressourcen nicht für anonyme Benutzer verfügbar sein sollten, verwenden Sie dieses Muster, um den direkten Zugriff einzuschränken.