Configurare un'origine

Puoi configurare le origini per Media CDN in molti modi. Questa pagina mostra come configurare le origini.

Configurare un bucket Cloud Storage come origine

Media CDN supporta i bucket Cloud Storage come backend per i contenuti. Ogni servizio può fare riferimento a più bucket configurando route per host, percorsi e altri attributi della richiesta.

I bucket Cloud Storage vengono configurati utilizzando l'URL del bucket, ad esempiogs://my-bucket, come indirizzo di origine durante la creazione di una risorsa di origine.

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

Il risultato è lo stesso indipendentemente dal fatto che il bucket sia a più regioni, a due regioni o regionale.

Quando configuri un servizio, puoi indirizzare i contenuti video on demand a un bucket e i contenuti in live streaming a un secondo bucket. Questo è utile se hai diversi team che gestiscono ogni flusso di lavoro. Per ridurre la latenza di aggiornamento della cache, puoi anche indirizzare la regione eu-media.example.com a un bucket Cloud Storage multiregionale situato nell'UE e la regione us-media.example.com (o la corrispondenza su percorso, intestazione o parametro di query) a un bucket di archiviazione negli Stati Uniti.

Nei casi in cui la latenza di scrittura sia fondamentale, ad esempio per i live streaming a bassa latenza, puoi configurare un endpoint Cloud Storage regionale il più vicino possibile ai tuoi utenti.

Autentica le richieste

Per confermare che una richiesta proviene da Media CDN, utilizza uno dei seguenti approcci supportati:

• Verifica che l'indirizzo IP di connessione provenga dagli intervalli di compilazione della cache di Media CDN. Questi intervalli sono condivisi tra tutti i clienti, ma vengono sempre utilizzati dalle risorse EdgeCacheService quando si connettono a un'origine.
• Aggiungi un'intestazione di richiesta personalizzata con un valore token che convalidi sull'origine (ad esempio un valore casuale di 16 byte). L'origine può quindi rifiutare le richieste che non includono questo valore.

Configurare un protocollo di origine

Per le origini che supportano solo HTTPS (HTTP/1.1 su TLS) o HTTP/1.1 (senza TLS), imposta il campo protocol in modo esplicito nel seguente modo:

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

Se l'origine supporta HTTP/2, non è necessario impostare esplicitamente il protocollo.

Configurare i bucket Cloud Storage privati

Media CDN può estrarre contenuti da qualsiasi endpoint HTTP o HTTPS accessibile tramite internet. In alcuni casi, potrebbe essere opportuno richiedere l'autenticazione per consentire solo a Media CDN di estrarre i contenuti ed evitare accessi non autorizzati. Cloud Storage supporta questa funzionalità tramite le autorizzazioni IAM.

Per le origini Cloud Storage:

• Concedi all'account di servizio Media CDN l'objectViewer autorizzazione IAM per i bucket Cloud Storage che utilizzi come origini.
• Rimuovi l'autorizzazione allUsers.
• (Facoltativo) Rimuovi l'autorizzazione allAuthenticatedUsers.

Per modificare le autorizzazioni di un bucket Cloud Storage, devi disporre del ruolo IAM Amministratore Storage.

L'account di servizio Media CDN è di proprietà del progetto Media CDN e non viene visualizzato nell'elenco degli account di servizio del progetto.

L'account di servizio ha il seguente formato e concede l'accesso solo alle risorse CDN multimediali nei progetti che consenti esplicitamente.

service-PROJECT_NUM@gcp-sa-mediaedgefill.iam.gserviceaccount.com

Per concedere a Media CDN l'accesso a un bucket, concedi il ruolo objectViewer all'account di servizio:

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

Utilizza il comando gcloud storage buckets remove-iam-policy-binding per rimuovere le autorizzazioni concesse al ruolo allUsers per il bucket specificato. Ad esempio, se il bucket concede a allUsers il ruolo objectViewer, rimuovi la concessione utilizzando il seguente comando:

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

Per verificare che l'accesso pubblico sia stato rimosso, apri una finestra del browser in incognito e prova ad accedere a un oggetto del bucket utilizzandohttps://storage.googleapis.com/BUCKET/object.ext.

Per consentire alle risorse EdgeCacheService di un progetto di accedere a un bucket Cloud Storage di un altro progetto, puoi concedere all'account di servizio Media CDN di quel progetto l'accesso al bucket di archiviazione.

A tal fine, assicurati che PROJECT_NUM in service-PROJECT_NUM@gcp-sa-mediaedgefill.iam.gserviceaccount.com sia il numero di progetto del progetto con le risorse EdgeCacheService che devono avere accesso. Puoi ripetere questa operazione per più progetti, in particolare se alcuni ospitano diversi ambienti Media CDN (come sviluppo, gestione temporanea o produzione) e un progetto distinto contiene i tuoi asset video o multimediali.

Puoi proteggere l'accesso all'origine Cloud Storage senza attivare le richieste firmate per quel percorso.

La configurazione di Cloud Storage privato non impedisce l'accesso diretto ai contenuti memorizzati nella cache da Media CDN. Per informazioni su come emettere richieste firmate per singoli utenti, consulta le richieste firmate.

Configura un bilanciatore del carico delle applicazioni esterno come origine

Se hai bisogno di controlli di stato attivi, di un criterio di assegnazione round robin o di un criterio di assegnazione in base al carico su origini Compute Engine, GKE o on-premise, puoi configurare un bilanciatore del carico delle applicazioni esterno come origine.

In questo modo puoi configurare, ad esempio, i pacchettizzatori di live streaming dietro Media CDN o un gruppo di proxy Envoy gestiti da Cloud Service Mesh per riconnetterti all'infrastruttura on-premise.

I bilanciatori del carico ti consentono di configurare i backend per:

• Gruppi di istanze VM Compute Engine.
• Gruppi di endpoint di rete (incluse VM Compute Engine e cluster Google Kubernetes Engine).
• Gruppi di endpoint di rete serverless (Cloud Run, App Engine e funzioni Cloud Run).

Un'architettura che combina un'origine bilanciatore del carico delle applicazioni esterno per la pubblicazione di manifest video e un'origine Cloud Storage per lo spazio di archiviazione dei segmenti è simile alla seguente, con due origini mappate a percorsi diversi.

Per configurare un bilanciatore del carico delle applicazioni esterno come origine, devi creare una risorsa di origine con l'indirizzo IP o il nome host pubblico che rimandi alle regole di inoltro del bilanciatore del carico. È preferibile un nome host pubblico (nome di dominio), perché è necessario per un certificato SSL (TLS) e per le versioni HTTP moderne (HTTP/2 e HTTP/3).

Devi inoltre assicurarti di quanto segue:

• Il bilanciatore del carico ha una route che corrisponde al nome host utilizzato per la risorsa EdgeCacheService o hai configurato un urlRewrite.hostRewrite per le route in cui il bilanciatore del carico è configurato come origine.
• Il bilanciatore del carico ha un certificato SSL (TLS) attendibile pubblicamente configurato per questi nomi host.

Ad esempio, se il nome di dominio pubblico a cui rimanda la regola di forwarding del bilanciatore del carico è origin-packager.example.com, devi creare un'origine con originAddress impostato su questo nome.

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

Se utilizzi l'indirizzo IP della regola di forwarding come indirizzo di origine o se non hai un certificato SSL associato al bilanciatore del carico, puoi impostare il protocollo su HTTP per eseguire il fallback alle connessioni non criptate. Ti consigliamo di eseguire questa operazione solo per lo sviluppo o i test.

Configura il failover dell'origine

Le sezioni riportate di seguito mostrano come configurare il comportamento di failover dell'origine.

Failover dell'origine senza seguire il reindirizzamento

Di seguito è riportata una configurazione di base del failover EdgeCacheOrigin:

name: FAILOVER_ORIGIN
originAddress: FAILOVER_DOMAIN_NAME

Media CDN esegue nuovamente il tentativo di connessione all'origine principale del route fino a tre volte prima di tentare con un'origine di failover. In questa configurazione, dopo aver provato l'origine principale tre volte, Media CDN tenta una singola richiesta all'FAILOVER_ORIGIN. Se anche l'origine di failover non risponde correttamente, Media CDN restituisce l'intera risposta dell'origine o, se non viene ricevuto alcun codice di stato, una risposta HTTP 502 Bad Gateway.

La latenza del riempimento della cache aumenta con il numero di nuovi tentativi ed eventi di failover. L'aumento dei valori di timeout dell'origine (ad esempio connectTimeout) influisce ulteriormente sulla latenza del riempimento della cache perché aumenta il tempo di attesa per la risposta di un server di origine sovraccaricato o occupato.

L'esempio seguente mostra una configurazione che invia richieste di completamento a MY_ORIGIN. La configurazione fa in modo che Media CDN riprovi in caso di errori di connessione (ad esempio errori DNS, TCP o TLS), risposte HTTP 5xx dall'origine o HTTP404 Not Found. Dopo due tentativi, viene eseguito il failover su FAILOVER_ORIGIN.

Vengono effettuati un massimo di quattro tentativi totali nelle origini configurate: il tentativo originale più fino a tre nuovi tentativi. Puoi configurare un valore maxAttempts per origine per determinare il numero di tentativi effettuati prima di tentare il failover.

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

Failover dell'origine con reindirizzamento successivo

Ad esempio, supponiamo che tu abbia configurato le seguenti risorse EdgeCacheOrigin e che i percorsi della risorsa EdgeCacheService siano configurati per utilizzare PrimaryOrigin per il riempimento della cache:

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 questo esempio, quando Media CDN esegue un riempimento della cache, Media CDN legge la configurazione del PrimaryOrigin e risponde di conseguenza.

Supponiamo che Media CDN si connetta a primary.example.com come tentativo 1 per contattare l'origine. Se primary.example.com restituisce una risposta positiva, Media CDN la utilizza per il riempimento della cache.

Supponiamo ora che primary.example.com restituisca un 302 Found Redirect HTTP a Location: b.example.com. Poi, come secondo tentativo di contattare l'origine, Media CDN segue il reindirizzamento a b.example.com. In questo caso, Media CDN esegue le seguenti operazioni:

• Se b.example.com restituisce una risposta positiva, Media CDN la utilizza per il riempimento della cache.
• Se b.example.com restituisce un reindirizzamento o una risposta di errore, Media CDN esegue il failover su SecondaryOrigin configurato. Questo perché, in questo esempio, PrimaryOrigin è configurato per due maxAttempts.

Se Media CDN esegue il failover su SecondaryOrigin, Media CDN utilizza la configurazione di SecondaryOrigin e tenta di connettersi a secondary.example.com. Questo è il primo tentativo di contattare l'origine e il terzo tentativo complessivo.

In questo caso, Media CDN esegue le seguenti operazioni:

• Se secondary.example.com restituisce una risposta positiva, Media CDN la utilizza per il riempimento della cache.
• Se secondary.example.com restituisce un 302 Found Redirect HTTP a Location: c.example.com, Media CDN tenta di contattare c.example.com. In questo esempio, si tratta del secondo tentativo per SecondaryOrigin e del quarto tentativo complessivo.

Se il tentativo di contattare c.example.com restituisce una risposta positiva, Media CDN la utilizza per il riempimento della cache. Se il tentativo restituisce un reindirizzamento che Media CDN è configurato per seguire, Media CDN restituisce un errore HTTP 502 Bad Gateway perché ha esaurito i tentativi massimi per contattare un'origine. Media CDN effettua al massimo quattro tentativi su tutte le origini, indipendentemente dalle configurazioni EdgeCacheOrigin. Infine, se Media CDN non riesce a contattare c.example.com, restituisce una risposta 504 Gateway Timeout o 502 Bad Gateway.

Se hai bisogno di controlli di integrità, di un criterio di assegnazione round robin o di gestione del carico tra le origini, puoi configurare un bilanciatore del carico delle applicazioni esterno come origine principale.

Configura i seguenti reindirizzamenti di origine

Media CDN supporta i reindirizzamenti restituiti dall'origine internamente durante il riempimento della cache, anziché restituire le risposte di reindirizzamento direttamente al client. Quando Media CDN è configurato per seguire i reindirizzamenti dell'origine, recupera i contenuti dalla posizione del reindirizzamento prima di memorizzare nella cache e restituire la risposta reindirizzata al client. Media CDN segue i reindirizzamenti tra domini.

Come best practice, configura il reindirizzamento delle origini solo per quelle di cui ti fidi e che controlli. Assicurati di considerare attendibili tutte le origini in una catena di reindirizzamento, perché ciascuna produce contenuti pubblicati dal tuo EdgeCacheService.

Per attivare i reindirizzamenti di origine successivi, aggiungi la seguente configurazione alla risorsa EdgeCacheOrigin:

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

Media CDN utilizza il protocollo specificato nei reindirizzamenti per raggiungere tutti i server. Assicurati che tutti i server a cui Media CDN potrebbe essere reindirizzato supportino i protocolli richiesti. In particolare, se il protocollo è impostato su HTTPS, HTTP/2 o HTTP/3, Media CDN non ricorre alle connessioni HTTP/1.1 per seguire i reindirizzamenti non sicuri. L'intestazione Host inviata all'origine reindirizzata corrisponde all'URL reindirizzato. Media CDN segue un singolo reindirizzamento per EdgeCacheOrigin tentativo prima di restituire la risposta finale o valutare le condizioni di ripetizione o failover.

L'impostazione redirectConditions specifica i codici di risposta HTTP che fanno sì che Media CDN segua un reindirizzamento per ogni origine.

Configurare le riscritture dell'host o le modifiche dell'intestazione specifiche dell'origine

Se l'origine richiede una riscrittura dell'host o una modifica dell'intestazione specifica dell'origine, utilizza il seguente esempio di configurazione originOverrideAction per impostarli:

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

L'impostazione originOverrideAction.hostRewrite ha la precedenza su eventuali rielaborazioni dell'intestazione configurate sui percorsi che rimandano a questa origine.

Puoi utilizzare requestHeadersToAdd intestazioni univoche per ogni origine richieste dalla singola origine. Un caso d'uso comune aggiunge intestazioni Authorization statiche. Poiché queste manipolazioni delle intestazioni vengono eseguite durante la richiesta di origine, le intestazioni aggiunte per origine sostituiscono o vengono aggiunte alle intestazioni esistenti dello stesso nome di campo. Per impostazione predefinita, Media CDN aggiunge le intestazioni esistenti. Per sostituire le intestazioni esistenti, imposta headerAction.replace su true.

Per informazioni su come impostare le intestazioni delle richieste per route, consulta Impostare intestazioni personalizzate.

Risolvere i problemi relativi alle origini

Se un'origine non si comporta come previsto, scopri come risolvere i problemi relativi alle origini.

Passaggi successivi

• Utilizzare un bucket privato compatibile con Amazon S3 come origine
• Configurare i percorsi dei servizi