Ursprung konfigurieren

Sie können Ursprünge für Media CDN auf viele Arten konfigurieren. Auf dieser Seite erfahren Sie, wie Sie Ursprünge konfigurieren.

Cloud Storage-Bucket als Ursprung konfigurieren

Media CDN unterstützt Cloud Storage-Buckets als Back-Ends für Inhalte. Jeder Dienst kann auf mehrere Buckets verweisen, indem er Routen für den Host, Pfade und andere Anfrageattribute konfiguriert.

Cloud Storage-Buckets werden konfiguriert, indem die Bucket-URL, z. B. gs://my-bucket, als Ursprungsadresse beim Erstellen einer Ursprungsressource verwendet wird.

gcloud edge-cache origins create ORIGIN \
    --origin-address=ADDRESS

Dies ist unabhängig davon, ob der Bucket multiregional, biregional oder regional ist.

Wenn Sie einen Dienst konfigurieren, können Sie Ihre Video-on-Demand-Inhalte an einen Bucket weiterleiten und Livestreaming-Inhalte an einen zweiten Bucket streamen. Dies ist nützlich, wenn diese Workflows von verschiedenen Teams verwaltet werden. Um die Latenz für die Cache-Füllung zu reduzieren, können Sie die Region eu-media.example.com an einen multiregionalen Cloud Storage-Bucket in der EU und die Region us-media.example.com (oder eine Übereinstimmung in Pfad, Header oder Abfrageparameter) an einen US-basierten Storage-Bucket weiterleiten.

In Fällen, in denen die Schreiblatenz von kritischer Bedeutung ist, z. B. beim Livestreaming mit niedriger Latenz, können Sie einen regionalen Cloud Storage-Endpunkt so nah wie möglich bei Ihren Nutzern konfigurieren.

Anfragen authentifizieren

Verwenden Sie einen der folgenden unterstützten Ansätze, um zu bestätigen, dass eine Anfrage von Media CDN stammt:

• Prüfen Sie, ob die IP-Adresse der Verbindung aus den Cache-Fill-Bereichen von Media CDN stammt. Diese Bereiche werden von allen Kunden gemeinsam genutzt, aber immer von EdgeCacheService-Ressourcen verwendet, wenn eine Verbindung zu einem Ursprung hergestellt wird.
• Fügen Sie einen benutzerdefinierten Anfrageheader mit einem Tokenwert hinzu, den Sie am Ursprung validieren (z. B. ein zufälliger 16‑Byte-Wert). Ihr Ursprung kann dann Anfragen ablehnen, die diesen Wert nicht enthalten.

Ursprungsprotokoll konfigurieren

Wenn Ihr Ursprung HTTP/2 unterstützt, müssen Sie das Protokoll nicht explizit festlegen. Für Ursprünge, die nur HTTPS (HTTP/1.1 über TLS) oder HTTP/1.1 (ohne TLS) unterstützen, legen Sie das Feld protocol explizit fest. Gehen Sie dazu so vor:

gcloud edge-cache origins update LEGACY_ORIGIN \
    --protocol=HTTPS

Private Cloud Storage-Buckets konfigurieren

Media CDN kann Inhalte von jedem über das Internet erreichbaren HTTP- oder HTTPS-Endpunkt abrufen. In einigen Fällen kann es sein, dass Sie eine Authentifizierung erforderlich machen möchten, damit nur Media CDN Inhalte abrufen kann und nicht autorisierter Zugriff verhindert wird. Cloud Storage unterstützt dies über IAM-Berechtigungen.

Gehen Sie für Cloud Storage-Ursprünge so vor:

• Dem Media CDN-Dienstkonto die IAM-Berechtigung objectViewer für die Cloud Storage-Buckets gewähren, die Sie als Ursprünge verwenden.
• Die Berechtigung allUsers entfernen.
• Optional: Entfernen Sie die Berechtigung allAuthenticatedUsers.

Zum Ändern der Berechtigungen eines Cloud Storage-Bucket benötigen Sie die Rolle „Storage-Administrator“ (roles/storage.admin).

Das Media CDN-Dienstkonto gehört zum Media CDN-Projekt und wird nicht in der Liste der Dienstkonten Ihres Projekts angezeigt. Das Dienstkonto gewährt nur Zugriff auf Media CDN-Ressourcen in den Projekten, die Sie explizit zulassen.

Sie müssen mindestens eine Media CDN-Ressource erstellen, um die Erstellung des Dienstkontos auszulösen. In den meisten Fällen ist das die EdgeCacheOrigin-Ressource, die mit Ihrem Cloud Storage-Bucket verbunden ist.

Um Media CDN Zugriff auf einen Bucket zu gewähren, weisen Sie dem Dienstkonto die Rolle objectViewer zu:

gcloud storage buckets add-iam-policy-binding gs://BUCKET \
    --member=serviceAccount:service-PROJECT_NUM@gcp-sa-mediaedgefill.iam.gserviceaccount.com \
    --role=roles/storage.objectViewer

Ersetzen Sie PROJECT_NUMBER durch die Projektnummer.

Bevor Sie den öffentlichen Zugriff auf einen vorhandenen Storage-Bucket entfernen, der als Produktionsursprung verwendet wird, warten Sie mindestens 10 Minuten, bis die Konfiguration übernommen wurde.

Verwenden Sie den Befehl gcloud storage buckets remove-iam-policy-binding, um die Berechtigungen zu entfernen, die der Rolle allUsers für den angegebenen Bucket gewährt wurden. Wenn dem Bucket beispielsweise die Rolle objectViewer für allUsers gewährt wurde, entfernen Sie die Gewährung mit dem folgenden Befehl:

gcloud storage buckets remove-iam-policy-binding gs://BUCKET \
    --member=allUsers --role=roles/storage.objectViewer

Um zu prüfen, ob der öffentliche Zugriff entfernt wurde, öffnen Sie ein Inkognitofenster und versuchen Sie, über https://storage.googleapis.com/BUCKET/object.ext auf ein Bucket-Objekt zuzugreifen.

Wenn Sie EdgeCacheService-Ressourcen in einem Projekt den Zugriff auf einen Cloud Storage-Bucket in einem anderen Projekt ermöglichen möchten, können Sie dem Media CDN-Dienstkonto in diesem Projekt Zugriff auf den Speicher-Bucket gewähren.

Achten Sie dabei darauf, dass die PROJECT_NUM in service-PROJECT_NUM@gcp-sa-mediaedgefill.iam.gserviceaccount.com die Projektnummer des Projekts mit den EdgeCacheService-Ressourcen ist, die Zugriff benötigen. Sie können dies für mehrere Projekte wiederholen, insbesondere wenn einige von ihnen unterschiedliche Media CDN-Umgebungen (z. B. Entwicklung, Staging oder Produktion) enthalten und ein separates Projekt Ihre Video- oder Medien-Assets enthält.

Sie können den Zugriff auf Ihren Cloud Storage-Ursprung schützen, ohne signierte Anfragen für diese Route zu aktivieren.

Die Konfiguration von privatem Cloud Storage verhindert nicht, dass von Media CDN direkt auf Ihre im Cache gespeicherten Inhalte zugegriffen wird. Informationen darüber, wie Sie signierte Anfragen an einzelne Nutzer senden können, finden Sie unter signierte Anfragen.

Externen Application Load Balancer als Ursprung konfigurieren

Wenn Sie eine aktive Systemdiagnose, Round Robin- oder lastenabhängiges Steuern über Compute Engine-, GKE- oder lokale Ursprünge hinweg benötigen, können Sie einen externen Application Load Balancer als Ursprung konfigurieren.

Auf diese Weise können Sie (beispielsweise) Ihre Livestreaming-Verpacker hinter Media CDN oder eine Gruppe von Envoy-Proxys konfigurieren, die von Cloud Service Mesh verwaltet werden, um eine Verbindung zurück zur lokalen Infrastruktur herzustellen.

Mit Load-Balancern können Sie Back-Ends für folgende Komponenten konfigurieren:

• Compute Engine-VM-Instanzgruppen.
• Netzwerk-Endpunktgruppen (einschließlich Compute Engine-VMs und Google Kubernetes Engine-Clustern).
• Serverlose Netzwerk-Endpunktgruppen (Cloud Run, App Engine und Cloud Run Functions).

Eine Architektur, die einen externen Application Load Balancer-Ursprung für die Bereitstellung von Videomanifesten und einen Cloud Storage-Ursprung für die Segmentspeicherung kombiniert, sieht folgendermaßen aus, wobei zwei Ursprünge verschiedenen Routen zugeordnet werden.

Zum Konfigurieren eines externen Application Load Balancers als Ursprung müssen Sie eine Ursprungsressource erstellen, wobei die IP-Adresse oder der öffentliche Hostname auf die Weiterleitungsregeln Ihres Load Balancers verweist. Ein öffentlicher Hostname (Domainname) ist vorzuziehen, da er für ein SSL-(TLS-)Zertifikat und für moderne HTTP-Versionen (HTTP/2 und HTTP/3) erforderlich ist.

Außerdem müssen Sie Folgendes bestätigen:

• Ihr Load-Balancer hat eine Route, die mit dem Hostnamen übereinstimmt, der für Ihre EdgeCacheService-Ressource verwendet wird, oder Sie haben eine urlRewrite.hostRewrite für Routen konfiguriert, bei denen Ihr Load-Balancer als Ursprung konfiguriert ist.
• Ihr Load-Balancer verfügt über ein öffentlich vertrauenswürdiges SSL-(TLS-)Zertifikat, das für diese Hostnamen konfiguriert ist.

Wenn beispielsweise der Name der öffentlichen Domain, der auf die Weiterleitungsregel Ihres Load-Balancers verweist, origin-packager.example.com lautet, dann müssen Sie einen Ursprung erstellen, bei dem die originAddress auf diesen Namen festgelegt ist.

gcloud edge-cache origins create LB_ORIGIN \
    --origin-address=LB_ADDRESS

Wenn Sie die IP-Adresse Ihrer Weiterleitungsregel als Ursprungsadresse verwenden oder an Ihren Load-Balancer kein SSL-Zertifikat angehängt ist, können Sie das Protokoll auf HTTP setzen, um ein Fallback auf unverschlüsselte Verbindungen auszuführen. Wir empfehlen, dies nur für die Entwicklung oder das Testen zu tun.

Region für flexiblen Schutz konfigurieren

Sie können eine Region für flexibles Shielding konfigurieren, wenn Sie einen Ursprung erstellen oder aktualisieren.

gcloud edge-cache origins update ORIGIN \
    --origin-address=ADDRESS \
    --flex-shielding=REGION

name: ORIGIN
originAddress: ADDRESS
# ... Other fields
flexShielding:
  flexShieldingRegions:
    - REGION
# ... Other fields

Ursprungs-Failover konfigurieren

In den folgenden Abschnitten wird beschrieben, wie Sie das Failover-Verhalten des Ursprungs konfigurieren.

Ursprungs-Failover ohne Folgen der Weiterleitung

Im Folgenden ist eine grundlegende Failover-EdgeCacheOrigin-Konfiguration aufgeführt:

name: FAILOVER_ORIGIN
originAddress: FAILOVER_DOMAIN_NAME

Media CDN wiederholt den primären Ursprung der Route maximal dreimal, bevor ein Failover-Ursprung versucht wird. In dieser Konfiguration probiert Media CDN, nachdem der primäre Ursprung dreimal versucht wurde zu erreichen, eine einzelne Anfrage mit FAILOVER_ORIGIN. Wenn der Failover-Ursprung ebenfalls nicht erfolgreich antwortet, gibt Media CDN entweder die gesamte Ursprungsantwort oder, falls kein Statuscode empfangen wird, eine HTTP-502 Bad Gateway-Antwort zurück.

Die Latenz beim Befüllen des Cache steigt mit der Anzahl der Wiederholungsversuche und Failover-Ereignisse. Das Erhöhen der Ursprungs-Zeitlimitwerte (z. B. connectTimeout) wirkt sich weiter auf die Cache-Füllungslatenz aus, weil dadurch die Zeit erhöht wird, die mit dem Warten auf die Antwort eines überlasteten oder ausgelasteten Ursprungsservers verbracht wird.

Das folgende Beispiel zeigt eine Konfiguration, die Füllungsanfragen an MY_ORIGIN sendet. Die Konfiguration bewirkt, dass Media CDN bei Verbindungsfehlern (wie DNS-, TCP- oder TLS-Fehlern), HTTP 5xx-Antworten vom Ursprung oder HTTP 404 Not Found Wiederholungsversuche unternimmt. Nach zwei Versuchen wird auf FAILOVER_ORIGIN umgestellt.

Es werden insgesamt maximal vier Versuche über Ihre konfigurierten Ursprünge hinweg unternommen: der ursprüngliche Versuch plus bis zu drei Wiederholungsversuche. Sie können einen maxAttempts-Wert pro Ursprung konfigurieren, um festzulegen, wie viele Wiederholungsversuche ausgeführt werden, bevor ein Failover durchgeführt wird.

name: MY_ORIGIN
originAddress: DOMAIN_NAME
maxAttempts: 2 # the number of attempts to make before trying the failoverOrigin
failoverOrigin: FAILOVER_ORIGIN
# what conditions trigger a retry or failover
retryConditions:
- CONNECT_FAILURE
- HTTP_5xx # any HTTP 5xx response
- NOT_FOUND # retry on a HTTP 404
timeout:
  maxAttemptsTimeout: 10s # set a deadline for all retries and failover

Ursprungs-Failover mit Folgen von Weiterleitungen

Angenommen, Sie haben die folgenden EdgeCacheOrigin-Ressourcen konfiguriert und die Routen Ihrer EdgeCacheService-Ressource sind so konfiguriert, dass PrimaryOrigin für die Cache-Befüllung verwendet wird:

name: PrimaryOrigin
originAddress: "primary.example.com"
maxAttempts: 2
failoverOrigin: "SecondaryOrigin"
retryConditions: [CONNECT_FAILURE]
originRedirect:
  redirectConditions: [FOUND, TEMPORARY_REDIRECT]

name: SecondaryOrigin
originAddress: "secondary.example.com"
maxAttempts: 3
originRedirect:
  redirectConditions: [FOUND, TEMPORARY_REDIRECT]

In diesem Beispiel liest Media CDN, wenn es eine Cache-Füllung durchführt, die Konfiguration der PrimaryOrigin und reagiert entsprechend.

Angenommen, Media CDN stellt als Versuch Nr. 1, den Ursprung zu kontaktieren, eine Verbindung zu primary.example.com her. Wenn primary.example.com eine erfolgreiche Antwort zurückgibt, verwendet Media CDN diese Antwort zum Füllen des Cache.

Angenommen weiter, primary.example.com gibt einen HTTP-302 Found Redirect an Location: b.example.com zurück. Als Versuch Nr. 2, den Ursprung zu kontaktieren, folgt Media CDN der Weiterleitung zu b.example.com. In diesem Fall führt Media CDN die folgenden Schritte aus:

• Wenn b.example.com eine erfolgreiche Antwort zurückgibt, verwendet Media CDN diese Antwort für das Auffüllen des Cache.
• Wenn b.example.com eine Weiterleitung oder eine Fehlerantwort zurückgibt, erfolgt ein Failover von Media CDN auf den konfigurierten SecondaryOrigin. Das liegt daran, dass in diesem Beispiel PrimaryOrigin für zwei maxAttempts konfiguriert ist.

Wenn Media CDN ein Failover auf SecondaryOrigin ausführt, wird die Konfiguration von SecondaryOrigin verwendet und es wird versucht, eine Verbindung zu secondary.example.com herzustellen. Dies ist Versuch Nr. 1, den Ursprung zu kontaktieren, und Versuch Nr. 3 insgesamt.

In diesem Fall führt Media CDN die folgenden Schritte aus:

• Wenn secondary.example.com eine erfolgreiche Antwort zurückgibt, verwendet Media CDN diese Antwort für das Auffüllen des Cache.
• Wenn secondary.example.com einen HTTP-302 Found Redirect-Fehler an Location: c.example.com zurückgibt, versucht Media CDN, c.example.com zu kontaktieren. In diesem Beispiel ist dies Versuch Nr. 2 für SecondaryOrigin und Versuch Nr. 4 insgesamt.

Wenn beim Versuch, c.example.com zu kontaktieren, eine erfolgreiche Antwort zurückgegeben wird, verwendet Media CDN diese Antwort für das Auffüllen des Cache. Wenn der Versuch eine Weiterleitung zurückgibt, für dessen Folgen Media CDN konfiguriert ist, gibt Media CDN den HTTP-Statuscode 502 Bad Gateway zurück, da die maximale Anzahl von Versuchen zur Kontaktaufnahme mit einem Ursprung erschöpft ist. Media CDN führt unabhängig von EdgeCacheOrigin-Konfigurationen höchstens vier Versuche über alle Ursprünge hinweg durch. Wenn Media CDN schließlich bei der Kontaktaufnahme mit c.example.com fehlschlägt, gibt Media CDN entweder eine 504 Gateway Timeout-Antwort oder eine 502 Bad Gateway-Antwort zurück.

Wenn Sie eine Systemdiagnose, Round Robin- oder lastenabhängiges Steuern über Ursprünge hinweg benötigen, können Sie einen externen Application Load Balancer als primären Ursprung konfigurieren.

Folgen von Ursprungsweiterleitungen konfigurieren

Media CDN unterstützt das Folgen von Weiterleitungen, die von Ihrem Ursprung intern während der Cache-Füllung zurückgegeben werden, anstatt Weiterleitungsantworten direkt an den Client zurückzugeben. Wenn Media CDN so konfiguriert ist, dass es Ursprungsweiterleitungen folgt, ruft Media CDN Inhalte vom Weiterleitungsstandort ab, bevor die weitergeleitete Antwort an den Client im Cache gespeichert und zurückgegeben wird. Media CDN folgt domainübergreifenden Weiterleitungen.

Als Best Practice sollten Sie die Ursprungsweiterleitung nur für Ursprünge konfigurieren, denen Sie vertrauen und die Sie kontrollieren. Sie müssen jedem Ursprung in einer Weiterleitungskette vertrauen, da jeder Ursprung Inhalte erzeugt, die von Ihrem EdgeCacheService bereitgestellt werden.

Fügen Sie die folgende Konfiguration zu Ihrer EdgeCacheOrigin-Ressource hinzu, um das Folgen von Ursprungsweiterleitungen zu aktivieren:

name: MY_ORIGIN
originAddress: DOMAIN_NAME
maxAttempts: 2
originRedirect:
  redirectConditions: [FOUND, TEMPORARY_REDIRECT]

Media CDN verwendet das in den Weiterleitungen angegebene Protokoll, um alle Server zu erreichen. Prüfen Sie, ob alle Server, an die Media CDN weitergeleitet werden könnte, Ihre erforderlichen Protokolle unterstützen. Speziell wenn das Protokoll auf HTTPS, HTTP/2 oder HTTP/3 gesetzt ist, führt Media CDN kein Fallback auf HTTP/1.1-Verbindungen aus, um ungesicherten Weiterleitungen zu folgen. Der Host-Header, der an den weitergeleiteten Ursprung gesendet wird, stimmt mit der weitergeleiteten URL überein. Media CDN folgt einer einzelnen Weiterleitung pro EdgeCacheOrigin-Versuch, bevor die endgültige Antwort zurückgegeben oder Bedingungen für Wiederholungen oder Failover ausgewertet werden.

Mit der Einstellung redirectConditions wird angegeben, bei welchen HTTP-Antwortcodes Media CDN einer Weiterleitung für jeden Ursprung folgt.

Ursprungsspezifische Host-Umschreibungen oder Header-Änderungen konfigurieren

Wenn Ihr Ursprung eine ursprungsspezifische Host-Umschreibung oder Header-Änderung erfordert, verwenden Sie das folgende originOverrideAction-Konfigurationsbeispiel, um sie festzulegen:

name: FAILOVER_ORIGIN
originAddress: FAILOVER_ORIGIN_HOST"
originOverrideAction:
  urlRewrite:
    hostRewrite: FAILOVER_ORIGIN_HOST"
  headerAction:
    requestHeadersToAdd:
    - headerName: "Authorization"
      headerValue: "AUTH-KEY"
      replace: true

Die Einstellung originOverrideAction.hostRewrite hat Vorrang vor allen vorhandenen Header-Neuschreibungen, die für Routen konfiguriert sind, die auf diesen Ursprung verweisen.

Sie können mit requestHeadersToAdd eindeutige Header pro Ursprung verwenden, die von diesem bestimmten Ursprung angefordert werden. Ein häufiger Anwendungsfall ist das Hinzufügen statischer Authorization-Headern. Da die Header-Manipulationen während der Ursprungsanfrage ausgeführt werden, ersetzen Header, die pro Ursprung hinzugefügt werden, entweder vorhandene Header desselben Feldnamens oder sie werden diesen angefügt. Standardmäßig fügt Media CDN an vorhandene Header an. Wenn Sie vorhandene Header ersetzen möchten, legen Sie headerAction.replace auf true fest.

Informationen zum Festlegen von Anfrageheadern pro Route finden Sie unter Benutzerdefinierte Header festlegen.

Fehlerbehebung bei Ursprüngen

Wenn sich ein Ursprung nicht wie erwartet verhält, finden Sie hier Informationen zur Fehlerbehebung.

Nächste Schritte

• Privaten Amazon S3-kompatiblen Bucket als Ursprung verwenden
• Dienstrouten konfigurieren