Configura un'origine

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

Configura 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.

Console

1. Nella console Google Cloud, vai alla pagina Origins di Media CDN.

   Vai a Origini

2. Fai clic su Crea origine.

3. Inserisci un nome per l'origine. Ad esempio: cloud-storage-origin.

4. (Facoltativo) Inserisci una descrizione.

5. Per Indirizzo di origine, scegli Seleziona un bucket Google Cloud Storage.

6. Vai al tuo bucket Cloud Storage e selezionalo.

7. Per Cloud Storage, mantieni il protocollo e la porta predefiniti impostazioni.

8. (Facoltativo) Affinché gli override dell'intestazione della richiesta di origine abbiano la precedenza sulle intestazioni inviate dal client o manipolate dalle azioni sulle intestazioni a livello di route, svolgi i seguenti passaggi:

   1. Seleziona Abilita override origine.
   2. Nella sezione Intestazioni, specifica le intestazioni aggiungendo una o più coppie nome-valore.

9. (Facoltativo) Seleziona un'origine di failover da provare nel caso in cui questa origine diventi non raggiungibile. Puoi aggiornare questo campo in un secondo momento.

10. Seleziona Condizioni di reindirizzamento.

11. Seleziona le condizioni di ripetizione.

12. In Numero massimo di tentativi, seleziona il numero massimo di tentativi di compilazione della cache da questa origine.

13. (Facoltativo) Specifica il seguente timeout valori:

    1. Per Timeout connessione, seleziona la durata massima di attesa per l'istituzione della connessione di origine.
    2. Per Timeout risposta, seleziona la durata massima per il completamento di una risposta.
    3. In Timeout lettura, seleziona la durata massima di attesa tra le letture di una singola connessione o stream HTTP.

14. (Facoltativo) Fai clic su Aggiungi etichetta e specifica una o più coppie chiave-valore.

15. Fai clic su Crea origine.

gcloud

Utilizza il comando gcloud edge-cache origins create:

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

Sostituisci quanto segue:

• ORIGIN: il nome della nuova origine
• ADDRESS: il nome del bucket, ad esempio gs://my-bucket

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 tuoi contenuti video on demand a uno e trasmettere i contenuti in live streaming in un secondo bucket. È utile se hai team diversi 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 basato negli Stati Uniti.

Importante: ti consigliamo di utilizzare un bucket multiregionale per lo spazio di archiviazione di origine, in quanto offre una redundanza geografica maggiore per gli oggetti archiviati.

Bucket Media CDN (fai clic per ingrandire).

Per i casi in cui la latenza di scrittura è fondamentale, come il live streaming a bassa latenza, puoi configurare un endpoint Cloud Storage a livello di regione il più vicino possibile utenti.

Autentica le richieste

Per verificare che una richiesta provenga da Media CDN, utilizza uno dei seguenti approcci supportati:

• Verifica che l'indirizzo IP di connessione provenga da Media CDN di riempimento della cache. 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 del token da convalidare nella (ad esempio, un valore casuale a 16 byte). L'origine può quindi rifiutare le richieste che non includono questo valore.

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

Configurare un protocollo di origine

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

Console

1. Nella console Google Cloud, vai alla pagina Origini di Media CDN.

   Vai a Origini

2. Seleziona la tua origine e fai clic su Modifica.

3. Per il protocollo, seleziona HTTPS o HTTP. Per HTTP, che specifica 80 come porta.

4. Fai clic su Aggiorna origine.

gcloud

Utilizza il comando gcloud edge-cache origins update:

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 IAM autorizzazioni.

Importante: per le route associate a un account Cloud Storage privato origine, imposta la modalità cache su FORCE_CACHE_ALL. In caso contrario, la memorizzazione nella cache viene impedita perché I bucket Cloud Storage impostano un'intestazione cache-control: private.

Per le origini Cloud Storage, segui questi passaggi:

• Concedi all'account di servizio Media CDN il objectViewer Autorizzazione IAM sui bucket Cloud Storage che usate come origini.
• Rimuovi l'autorizzazione allUsers.
• (Facoltativo) Rimuovi l'autorizzazione allAuthenticatedUsers.

Per modificare le autorizzazioni di un bucket Cloud Storage, è necessario Ruolo IAM Storage Admin.

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.

[e-mail]

Nota: 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 collegata 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:[e-mail] \
--role=roles/storage.objectViewer

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

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

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

Per confermare che l'accesso pubblico è stato rimosso, apri una finestra di navigazione in incognito finestra del browser e tentare di accedere a un oggetto bucket utilizzando https://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 [e-mail] sia il numero del progetto con le risorse EdgeCacheService che devono avere accesso. Puoi ripetere l'operazione per più progetti, soprattutto se alcuni di loro ospitare diversi ambienti Media CDN (come sviluppo, gestione temporanea o produzione) e un progetto separato contenente il video o i contenuti multimediali asset.

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

La configurazione di Cloud Storage privato non impedisce i contenuti memorizzati nella cache dall'accesso diretto 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 metodo round-robin o di un instradamento in base al carico su origini Compute Engine, GKE o on-premise, puoi configurare un bilanciatore del carico delle applicazioni esterno come origine.

Ciò ti consente di configurare, ad esempio, gli strumenti per la creazione di pacchetti in live streaming Media CDN o un gruppo di Proxy di Envoy gestiti da Cloud Service Mesh per riconnetterti alla tua 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 (inclusi VM di Compute Engine e cluster di Google Kubernetes Engine).
• Gruppi di endpoint di rete serverless (funzioni Cloud Run, App Engine e 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.

Deployment della cache di Edge (fai clic per ingrandire).

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 al tuo 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 verificare 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.
• Nel bilanciatore del carico è configurato un certificato SSL (TLS) pubblicamente attendibile per questi nomi host.

Ad esempio, se il nome di dominio pubblico punta al bilanciatore del carico regola di forwarding è origin-packager.example.com, devi creare un'etichetta con originAddress impostato su questo nome.

Console

1. Nella console Google Cloud, vai alla pagina Origini di Media CDN.

   Vai a Origini

2. Fai clic su Crea origine.

3. Inserisci un nome per l'origine. Ad esempio: load-balancer-origin.

4. (Facoltativo) Inserisci una descrizione.

5. Per Indirizzo di origine, scegli Specifica un FQDN o un indirizzo IP.

6. Inserisci il FQDN o l'indirizzo IP del bilanciatore del carico Google Cloud.

7. (Facoltativo) Seleziona un'origine di failover da provare nel caso in cui questa origine non sia più raggiungibile. Puoi aggiornare questo campo in un secondo momento.

8. Seleziona le condizioni di ripetizione.

9. In Numero massimo di tentativi, seleziona il numero massimo di tentativi di compilazione della cache da questa origine.

10. (Facoltativo) Specifica i seguenti valori di timeout:

    1. Per Timeout connessione, seleziona la durata massima di attesa per l'istituzione della connessione di origine.
    2. Per Timeout risposta, seleziona la durata massima per il completamento di una risposta.
    3. In Timeout lettura, seleziona la durata massima di attesa tra le letture di una singola connessione o stream HTTP.

11. (Facoltativo) Fai clic su Aggiungi etichetta e specifica una o più coppie chiave-valore.

12. Fai clic su Crea origine.

gcloud

Utilizza il comando gcloud edge-cache origins create:

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

Sostituisci quanto segue:

• LB_ORIGIN: il nome dell'origine
• LB_ADDRESS: il FQDN o l'indirizzo IP, ad esempio origin-packager.example.com

Se utilizzi l'indirizzo IP della regola di inoltro 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 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 base di failover EdgeCacheOrigin:

name: FAILOVER_ORIGIN
originAddress: FAILOVER_DOMAIN_NAME

Media CDN esegue un nuovo tentativo dell'origine principale della route per un massimo di tre prima di tentare un'origine di failover. In questa configurazione, dopo aver tentato tre volte l'origine principale, Media CDN tenta una singola relativa a FAILOVER_ORIGIN. Se Anche l'origine di failover non riesce a rispondere Media CDN restituisce l'intera risposta dell'origine oppure, in caso contrario viene ricevuto il 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. Aumentare ulteriormente i valori di timeout dell'origine (ad esempio connectTimeout) influisce sulla latenza di riempimento della cache perché aumenta il tempo di attesa un server di origine sovraccarico o occupato per rispondere.

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 nelle origini configurate: tentativo originale più un massimo di tre nuovi tentativi. Puoi configurare Valore maxAttempts per origine per determinare quanti nuovi tentativi vengono effettuati prima di 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

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

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

Di seguito è riportata una configurazione completata:

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

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

Nell'esempio precedente, l'impostazione originOverrideAction.hostRewrite utilizza la precedenza su eventuali riscritture delle intestazioni esistenti configurato su route che puntano a questa origine.

Puoi utilizzare requestHeadersToAdd intestazioni univoche per origine richieste da questo origine particolare. 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 esegue l'aggiunta alle intestazioni esistenti. Per sostituire le intestazioni esistenti, imposta headerAction.replace su true.

Failover dell'origine con reindirizzamento successivo

Ad esempio, supponi di aver configurato il seguente EdgeCacheOrigin e su cui sono configurate le route della risorsa EdgeCacheService usa 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, nel 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 positiva, Media CDN utilizza questa risposta 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. Il motivo è che, in questo esempio, PrimaryOrigin è configurato per due maxAttempts.

Se Media CDN esegue il failover su SecondaryOrigin, Media CDN utilizza la configurazione SecondaryOrigin e i tentativi per la connessione a secondary.example.com. Questo è il tentativo n. 1 di contattare l'origine, e tentativo al punto 3 in generale.

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 tentativo 2 di SecondaryOrigin e tentativo al punto 4 in generale.

Se il tentativo di contattare c.example.com restituisce una risposta positiva, Media CDN utilizza questa risposta 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 in tutte le origini, indipendentemente dalle configurazioni di 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 in base al carico tra le origini, puoi configurare un bilanciatore del carico delle applicazioni esterno come origine principale.

Configura i seguenti reindirizzamenti delle origini

Media CDN supporta i seguenti reindirizzamenti restituiti dalla tua origine internamente durante il riempimento della cache, invece di restituire direttamente le risposte di reindirizzamento al cliente. 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.

Avviso: la configurazione dei reindirizzamenti da un servizio di origine non attendibile o controllato da un malintenzionato potrebbe esporre la configurazione di Media CDN a vulnerabilità di reindirizzamento aperte.

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

Per attivare i seguenti reindirizzamenti dell'origine, aggiungi la seguente configurazione al tuo EdgeCacheOrigin risorsa:

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 di cui Media CDN potrebbe vengono reindirizzati al supporto dei protocolli richiesti. In particolare, se il protocollo è impostato su HTTPS, HTTP/2 o HTTP/3, Media CDN non si basa sulle connessioni HTTP/1.1 per seguire reindirizzamenti non sicuri. L'intestazione host inviata all'origine reindirizzata corrisponde alla URL di reindirizzamento. Media CDN segue un singolo reindirizzamento per EdgeCacheOrigin tentativo prima di restituire la risposta finale o di effettuare una valutazione di failover o di ripetizione.

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

Condizione	Descrizione
MOVED_PERMANENTLY	Segui il reindirizzamento per il codice di risposta HTTP 301
TROVATO	Segui il reindirizzamento per il codice di risposta HTTP 302
SEE_OTHER	Segui il reindirizzamento per il codice di risposta HTTP 303
TEMPORARY_REDIRECT	Segui il reindirizzamento per il codice di risposta HTTP 307
PERMANENT_REDIRECT	Segui il reindirizzamento per il codice di risposta HTTP 308

Risoluzione dei problemi relativi alle origini

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

Passaggi successivi

• Utilizza un bucket privato compatibile con Amazon S3 come origine
• Configurare le route dei servizi