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 le route per host, percorsi e altri attributi della richiesta.

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

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

Ciò vale indipendentemente dal fatto che il bucket sia multiregionale, 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 team diversi che gestiscono ogni flusso di lavoro. Per ridurre la latenza di riempimento della cache, puoi instradare in modo simile 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 basato negli Stati Uniti.

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

Autenticare 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 riempimento 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 della 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

Se l'origine supporta HTTP/2, non devi impostare esplicitamente il protocollo. 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 procedendo nel seguente modo:

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

Configura i bucket Cloud Storage privati

Media CDN può eseguire il pull dei contenuti da qualsiasi endpoint HTTP o HTTPS raggiungibile da internet. In alcuni casi, potresti voler richiedere l'autenticazione per consentire solo a Media CDN di recuperare i contenuti e impedire l'accesso non autorizzato. Cloud Storage supporta questa funzionalità tramite le autorizzazioni IAM.

Per le origini Cloud Storage, procedi nel seguente modo:

• Concedi all'account di servizio Media CDN l'autorizzazione IAM objectViewer sui 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 Storage Admin (roles/storage.admin).

Il account di servizio Media CDN è di proprietà del progetto Media CDN e non verrà visualizzato nell'elenco dei service account del tuo progetto. Il account di servizio concede l'accesso solo alle risorse Media CDN nei progetti che consenti esplicitamente.

Devi creare almeno una risorsa Media CDN per attivare la creazione dell'account di servizio. Nella maggior parte dei casi, si tratta della risorsa EdgeCacheOrigin connessa al tuo bucket Cloud Storage.

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

Sostituisci PROJECT_NUMBER con il numero di progetto.

Prima di rimuovere l'accesso pubblico a un bucket di archiviazione esistente utilizzato come origine di produzione, attendi almeno 10 minuti per la propagazione della configurazione.

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 bucket utilizzando https://storage.googleapis.com/BUCKET/object.ext.

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

A tal fine, verifica 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 richiedono l'accesso. Puoi ripetere questa operazione per più progetti, soprattutto se alcuni di questi contengono ambienti Media CDN diversi (ad esempio sviluppo, gestione temporanea o produzione) e un progetto separato contiene i tuoi asset video o multimediali.

Puoi proteggere l'accesso all'origine Cloud Storage senza abilitare le richieste firmate per questa route.

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

Configura un bilanciatore del carico delle applicazioni esterno come origine

Se hai bisogno di un controllo di integrità attivo, di un bilanciamento del carico round robin o di un routing basato sul carico tra 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 tuoi pacchetti di live streaming dietro Media CDN o un gruppo di proxy Envoy gestiti da Cloud Service Mesh per la connessione alla tua infrastruttura on-premise.

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

• Gruppi di istanze di macchine virtuali (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 Cloud Run Functions).

Un'architettura che combina un'origine del bilanciatore del carico delle applicazioni esterno per la pubblicazione di manifest video e un'origine Cloud Storage per l'archiviazione dei segmenti è simile alla seguente, con due origini mappate a route 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 punta alle regole di forwarding 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 confermare 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 che punta alla regola di forwardingo 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 non hai un certificato SSL collegato al bilanciatore del carico, puoi impostare il protocollo su HTTP per eseguire il failover alle connessioni non criptate. Ti consigliamo di farlo solo per lo sviluppo o i test.

Configurare una regione per la protezione flessibile

Puoi configurare una regione per la protezione flessibile quando crei o aggiorni un'origine.

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

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

Configura il failover dell'origine

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

Failover dell'origine senza seguire il reindirizzamento

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

name: FAILOVER_ORIGIN
originAddress: FAILOVER_DOMAIN_NAME

Media CDN ritenta la connessione all'origine principale della route un massimo di tre volte prima di tentare di connettersi a un'origine di failover. In questa configurazione, dopo aver provato l'origine principale tre volte, Media CDN tenta una singola richiesta rispetto a 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 di riempimento della cache aumenta con il numero di tentativi e di eventi di failover. L'aumento dei valori di timeout dell'origine (ad esempio connectTimeout) influisce ulteriormente sulla latenza di riempimento della cache perché aumenta il tempo di attesa della risposta di un server di origine sovraccarico o occupato.

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

Vengono effettuati un massimo di quattro tentativi totali nelle origini configurate: il tentativo originale più un massimo di tre 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 di aver configurato le seguenti risorse EdgeCacheOrigin e che le route della risorsa EdgeCacheService siano configurate 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, legge la configurazione di PrimaryOrigin e risponde di conseguenza.

Supponiamo che Media CDN si connetta a primary.example.com come tentativo n. 1 di 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 HTTP 302 Found Redirect a Location: b.example.com. Quindi, come tentativo n. 2 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 riuscita, 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 sul 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 SecondaryOrigin e tenta di connettersi a secondary.example.com. Questo è il primo tentativo di contattare l'origine e il terzo tentativo in totale.

In questo caso, Media CDN esegue le seguenti operazioni:

• Se secondary.example.com restituisce una risposta riuscita, Media CDN utilizza questa risposta per il riempimento della cache.
• Se secondary.example.com restituisce un errore HTTP 302 Found Redirect a Location: c.example.com, Media CDN tenta di contattare c.example.com. In questo esempio, si tratta del tentativo n. 2 per SecondaryOrigin e del tentativo n. 4 in totale.

Se il tentativo di contattare c.example.com restituisce una risposta riuscita, Media CDN utilizza questa risposta per il riempimento della cache. Se il tentativo restituisce un reindirizzamento che Media CDN è configurata per seguire, Media CDN restituisce un codice di stato HTTP 502 Bad Gateway perché ha esaurito il numero massimo di tentativi per contattare un'origine. Media CDN esegue al massimo quattro tentativi su tutte le origini, indipendentemente dalle configurazioni EdgeCacheOrigin. Infine, se Media CDN non riesce a contattare c.example.com, Media CDN restituisce una risposta 504 Gateway Timeout o 502 Bad Gateway.

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

Configura i reindirizzamenti dell'origine successivi

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

Come best practice, configura il reindirizzamento dell'origine solo per le origini di cui ti fidi e che controlli. Assicurati di considerare attendibile ogni origine in una catena di reindirizzamento perché ogni origine produce contenuti pubblicati dal tuo EdgeCacheService.

Per attivare il reindirizzamento dell'origine, 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. Verifica che tutti i server a cui Media CDN potrebbe essere reindirizzato forniscano supporto per i protocolli richiesti. In particolare, se il protocollo è impostato su HTTPS, HTTP/2 o HTTP/3, Media CDN non esegue il failover alle connessioni HTTP/1.1 per seguire i reindirizzamenti non protetti. L'intestazione host inviata all'origine reindirizzata corrisponde all'URL reindirizzato. La CDN per i contenuti multimediali 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 quali codici di risposta HTTP fanno sì che Media CDN segua un reindirizzamento per ogni origine.

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

Se l'origine richiede una riscrittura dell'host o una modifica dell'intestazione specifica per l'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 qualsiasi riscrittura dell'intestazione configurata sui percorsi che puntano a questa origine.

Puoi utilizzare le intestazioni uniche per origine requestHeadersToAdd richieste da quell'origine specifica. 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 aggiungono le intestazioni esistenti con lo 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, vedi Impostare intestazioni personalizzate.

Risoluzione dei 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 le route di servizio