É possível configurar origens do Media CDN de várias maneiras. Esta página mostra como configurar origens.
Configurar um bucket do Cloud Storage como origem
O Media CDN oferece suporte a buckets do Cloud Storage como back-ends para conteúdo. Cada serviço pode referenciar vários buckets ao configurar rotas para host, caminhos e outros atributos de solicitação.
Os buckets do Cloud Storage são configurados usando o URL do bucket, como
gs://my-bucket, como o endereço de origem ao criar um recurso de origem.
Console
No console do Google Cloud, acesse a página Origens do Media CDN.
Clique em Criar origem.
Digite um nome para a origem. Por exemplo,
cloud-storage-origin.Opcional: insira uma descrição.
Em Endereço de origem, escolha Selecionar um bucket do Google Cloud Storage.
Procure e selecione o bucket do Cloud Storage.
No Cloud Storage, mantenha o protocolo e a porta padrão configurações.
Opcional: para que as substituições de cabeçalho da solicitação de origem tenham precedência sobre cabeçalhos enviados pelo cliente ou manipulados por ações de cabeçalho no nível da rota, faça o seguinte:
- Selecione Ativar substituição de origem.
- Na seção Cabeçalhos, especifique cabeçalhos adicionando um ou mais nome-valor.
Opcional: selecione uma origem de failover para testar caso ela se torne inacessível. É possível atualizar esse campo mais tarde.
Selecione as condições de redirecionamento.
Selecione as condições de nova tentativa.
Em Máximo de tentativas, selecione o número máximo de tentativas de preenchimento do cache. desta origem.
Opcional: especifique o seguinte tempo limite valores:
- Em Tempo limite da conexão, selecione a duração máxima para aguardar que a conexão de origem seja estabelecida.
- Em Tempo limite de resposta, selecione a duração máxima para permitir um resposta seja concluída.
- Em Tempo limite de leitura, selecione a duração máxima de espera e leituras de um único fluxo ou conexão HTTP.
Opcional: clique em Adicionar rótulo e especifique um ou mais pares de chave-valor.
Clique em Criar origem.
gcloud
Use o comando gcloud edge-cache origins create:
gcloud edge-cache origins create ORIGIN \
--origin-address=ADDRESS
Substitua:
ORIGIN: o nome da nova origem.ADDRESS: o nome do bucket, por exemplo,gs://my-bucket.
Isso é o mesmo se o bucket multirregional, birregional ou regional.
Ao configurar um serviço, é possível rotear seu conteúdo de vídeo on demand para um
e transmissão ao vivo para um segundo bucket. Isso é útil se você tem
equipes diferentes gerenciando cada fluxo de trabalho. Para reduzir a latência de preenchimento do cache, é possível
de maneira semelhante, encaminhe a região eu-media.example.com para uma
bucket do Cloud Storage localizado na UE e no us-media.example.com
região (ou correspondência no caminho, cabeçalho ou parâmetro de consulta) a um armazenamento nos EUA
do Google Cloud.
Nos casos em que a latência de gravação é crítica, como transmissão ao vivo de baixa latência, é possível configurar um endpoint regional do Cloud Storage o mais próximo aos usuários possível.
Autenticar solicitações
Para confirmar que uma solicitação está vindo do Media CDN, faça o seguinte: use uma das seguintes abordagens compatíveis:
- Confira se o endereço IP de conexão vem do endereço IP do Media CDN
dos intervalos de preenchimento de cache. Esses intervalos são compartilhados com todos os clientes, mas
sempre usado por recursos
EdgeCacheServiceao se conectar a uma origem. - Adicione um cabeçalho de solicitação personalizado com um valor de token que você valida no origem (por exemplo, um valor aleatório de 16 bytes). A origem poderá rejeitar solicitações que não incluem esse valor.
Para informações sobre como definir cabeçalhos de solicitação por rota, consulte cabeçalhos personalizados.
Configurar um protocolo de origem
Para origens compatíveis apenas com HTTPS (HTTP/1.1 sobre TLS) ou HTTP/1.1 (sem
TLS), defina o campo protocol explicitamente fazendo o seguinte:
Console
No console do Google Cloud, acesse a página Origens do Media CDN.
Selecione sua origem e clique em Editar.
Como protocolo, selecione HTTPS ou HTTP. Para HTTP, também especifique a porta como
80.Clique em Atualizar origem.
gcloud
Use o comando gcloud edge-cache origins update:
gcloud edge-cache origins update LEGACY_ORIGIN \
--protocol=HTTPS
Se a origem oferecer suporte a HTTP/2, não será necessário definir o protocolo explicitamente.
Configurar buckets particulares do Cloud Storage
O Media CDN pode extrair conteúdo de qualquer HTTP ou HTTPS acessível pela Internet endpoint do Google Cloud. Em alguns casos, você pode exigir autenticação para só permite que o Media CDN extraia conteúdo e evite que o tráfego acesso. O Cloud Storage é compatível com esse recurso por meio do IAM do Cloud Storage.
Para origens do Cloud Storage, faça o seguinte:
- Conceda
objectViewerà conta de serviço do Media CDN permissão do IAM nos buckets do Cloud Storage estão usando como suas origens. - Remova a permissão
allUsers. - Opcional: remova a permissão
allAuthenticatedUsers.
Para mudar as permissões de um bucket do Cloud Storage, você precisa do Papel do IAM de administrador do Storage.
A conta de serviço do Media CDN pertence ao projeto do Media CDN. Ele não vai aparecer na lista de e contas de serviço.
A conta de serviço tem o formato a seguir e concede acesso apenas a Recursos do Media CDN nos projetos que você permitir explicitamente.
service-PROJECT_NUM@gcp-sa-mediaedgefill.iam.gserviceaccount.com
Para conceder acesso ao Media CDN a um bucket, conceda a objectViewer
para a conta de serviço:
gsutil iam ch \ serviceAccount:service-PROJECT_NUM@gcp-sa-mediaedgefill.iam.gserviceaccount.com:objectViewer gs://BUCKET
Para remover todas as permissões do papel allUsers de determinado bucket, execute o
seguinte comando:
gsutil iam ch -d allUsers gs://BUCKET
Para confirmar que o acesso público foi removido, abra uma janela anônima
do navegador e tentar acessar um objeto de bucket usando
https://storage.googleapis.com/BUCKET/object.ext:
Permitir o acesso de EdgeCacheService recursos em um projeto
a um bucket do Cloud Storage em outro projeto, é possível conceder
o acesso da conta de serviço do Media CDN desse projeto ao armazenamento
do Google Cloud.
Para fazer isso, verifique se PROJECT_NUM em
service-PROJECT_NUM@gcp-sa-mediaedgefill.iam.gserviceaccount.com é o
número do projeto com os recursos EdgeCacheService que precisam
acesso. Você pode repetir isso para vários projetos, especialmente se alguns deles
abrigam diferentes ambientes do Media CDN (como desenvolvimento,
ou produção) e um projeto separado contém seu vídeo ou mídia
de uma empresa.
É possível proteger o acesso à sua origem do Cloud Storage sem ativar solicitações assinadas para essa rota.
A configuração do Cloud Storage particular não impede que o conteúdo armazenado em cache de serem acessados diretamente do Media CDN. Para informações sobre como emitir solicitações assinadas para usuários individuais, consulte assinado solicitações.
Configurar um balanceador de carga de aplicativo externo como origem
Se você precisar de verificação de integridade ativa, round-robin ou direção com reconhecimento de carga no Compute Engine, no GKE ou em origens locais, configure um balanceador de carga de aplicativo externo como uma origem.
Isso permite que você configure (por exemplo) os empacotadores de transmissão ao vivo por trás Media CDN ou um grupo de Proxies Envoy gerenciados pelo Cloud Service Mesh para acessar a infraestrutura no local.
Com os balanceadores de carga, é possível configurar back-ends para o seguinte:
- Compute Engine. Grupos de instâncias de VM.
- Grupos de endpoints de rede (incluindo VMs do Compute Engine e clusters do Google Kubernetes Engine).
- Grupos de endpoints de rede sem servidor (Cloud Run, App Engine e Cloud Functions).
Arquitetura que combina uma origem externa do balanceador de carga de aplicativo para veicular vídeos e uma origem do Cloud Storage para armazenamento de segmentos é semelhante a a seguir, com duas origens mapeadas para rotas diferentes.
Para configurar um balanceador de carga de aplicativo externo como origem, crie um recurso de origem com o endereço IP ou o nome do host público apontando para sua regras de encaminhamento do balanceador de carga. É preferível usar um nome de host público (nome de domínio), porque isso é necessário para um protocolo SSL (TLS) e para versões HTTP modernas (HTTP/2 e HTTP/3).
Verifique também o seguinte:
- Seu balanceador de carga tem uma rota que corresponde ao nome do host usado para seu
recurso
EdgeCacheServiceou que tenha configurado umurlRewrite.hostRewritepara rotas em que o balanceador de carga está configurado como a origem. - o balanceador de carga tem um certificado SSL (TLS) público configurado para esses nomes de host.
Por exemplo, se o nome de domínio público apontado para o endereço
regra de encaminhamento for origin-packager.example.com, será preciso criar uma
origem com o originAddress definido para esse nome.
Console
No console do Google Cloud, acesse a página Origens do Media CDN.
Clique em Criar origem.
Digite um nome para a origem. Por exemplo,
load-balancer-origin.Opcional: insira uma descrição.
Em Endereço de origem, escolha Especificar um FQDN ou um endereço IP.
Insira o endereço IP ou FQDN do seu balanceador de carga do Google Cloud.
Opcional: selecione uma origem de failover para testar caso ela se torne inacessível. É possível atualizar esse campo mais tarde.
Selecione as condições de nova tentativa.
Em Máximo de tentativas, selecione o número máximo de tentativas de preenchimento do cache. desta origem.
Opcional: especifique o seguinte tempo limite valores:
- Em Tempo limite da conexão, selecione a duração máxima para aguardar que a conexão de origem seja estabelecida.
- Em Tempo limite de resposta, selecione a duração máxima para permitir um resposta seja concluída.
- Em Tempo limite de leitura, selecione a duração máxima de espera e leituras de um único fluxo ou conexão HTTP.
Opcional: clique em Adicionar rótulo e especifique um ou mais pares de chave-valor.
Clique em Criar origem.
gcloud
Use o comando gcloud edge-cache origins create:
gcloud edge-cache origins create LB_ORIGIN \
--origin-address=LB_ADDRESS
Substitua:
LB_ORIGIN: o nome da origem.LB_ADDRESS: o FQDN ou IP endereço, por exemplo,origin-packager.example.com
Se você estiver usando o endereço IP da sua regra de encaminhamento como o endereço de origem,
ou não tem um certificado SSL anexado ao balanceador de carga, é possível
defina o protocolo como HTTP para usar conexões não criptografadas. Recomendamos
faça isso apenas para desenvolvimento ou teste.
Configurar failover de origem
As seções a seguir mostram como configurar o comportamento do failover de origem.
Failover de origem sem redirecionamento seguinte
Veja a seguir uma configuração básica de EdgeCacheOrigin de failover:
name: FAILOVER_ORIGIN
originAddress: FAILOVER_DOMAIN_NAME
O Media CDN tenta executar a origem principal da rota no máximo três vezes
vezes antes de tentar uma origem de failover. Nessa configuração, depois de tentar
a origem primária três vezes, o Media CDN tenta uma conexão
no FAILOVER_ORIGIN. Se o
a origem de failover também não responderá com êxito,
O Media CDN retorna a resposta de origem inteira ou, caso não haja
for recebido, uma resposta HTTP 502 Bad Gateway.
A latência de preenchimento do cache aumenta com o número de novas tentativas e eventos de failover.
Aumente ainda mais os valores de tempo limite da origem (como connectTimeout)
afeta a latência de preenchimento do cache porque aumenta o tempo gasto aguardando uma
servidor de origem sobrecarregado ou ocupado
para responder.
O exemplo a seguir demonstra uma configuração que envia solicitações de preenchimento para
MY_ORIGIN: A configuração faz com que
Media CDN para tentar novamente em erros de conexão (como DNS, TCP ou
erros de TLS), respostas HTTP 5xx da origem ou HTTP
404 Not Found. Após duas tentativas, ele falha para
FAILOVER_ORIGIN:
São feitas no máximo quatro tentativas nas origens configuradas: o
da tentativa original mais até três tentativas. É possível configurar um
Valor de maxAttempts por origem para determinar quantas tentativas são feitas antes de
para fazer o 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 a origem exigir uma regravação ou modificação do cabeçalho específica do host,
Use o seguinte exemplo de configuração de originOverrideAction para fazer a definição delas:
name: FAILOVER_ORIGIN
originAddress: "FAILOVER_ORIGIN_HOST"
originOverrideAction:
urlRewrite:
hostRewrite: "FAILOVER_ORIGIN_HOST"
headerAction:
requestHeadersToAdd:
- headerName: "Authorization"
headerValue: "AUTH-KEY"
replace: true
Confira a seguir uma configuração completa:
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
No exemplo anterior, a configuração originOverrideAction.hostRewrite usa
precedência sobre quaisquer reescritas de cabeçalho existentes
configurados em rotas que apontam para essa origem.
Você pode usar requestHeadersToAdd cabeçalhos exclusivos por origem solicitados por esse
origem específica. Um caso de uso comum adiciona cabeçalhos Authorization estáticos.
Como essas manipulações de cabeçalho são executadas durante a solicitação de origem, os cabeçalhos
adicionadas por origem substituem ou anexam a cabeçalhos existentes do mesmo campo
nome. Por padrão, o Media CDN é anexado aos cabeçalhos atuais. Para
substituir os cabeçalhos atuais, defina headerAction.replace como true.
Failover de origem com redirecionamento seguinte
Por exemplo, suponha que você tenha configurado as seguintes EdgeCacheOrigin
e que as rotas do recurso EdgeCacheService estejam configuradas para
use PrimaryOrigin para preenchimento de 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]
Neste exemplo, quando o Media CDN executa um preenchimento de cache,
O Media CDN lê a configuração de PrimaryOrigin e
responde de acordo.
Suponha que o Media CDN se conecte a primary.example.com
tentativa no 1 de entrar em contato com a origem. Se primary.example.com retornar um
resposta, o Media CDN usa essa resposta para o preenchimento do cache.
Suponha agora que primary.example.com retorna um 302 Found Redirect HTTP para
Location: b.example.com Então, como a segunda tentativa de entrar em contato com a origem,
O Media CDN segue o redirecionamento para b.example.com. Nesse caso,
O Media CDN faz o seguinte:
- Se
b.example.comretornar uma resposta bem-sucedida, o Media CDN usa essa resposta para o preenchimento do cache. - Se
b.example.comretornar um redirecionamento ou uma resposta de falha, O Media CDN faz o failover para oSecondaryOriginconfigurado. Isso ocorre porque, neste exemplo,PrimaryOriginestá configurado para doismaxAttempts.
Se o Media CDN fizer o failover para SecondaryOrigin,
O Media CDN usa a configuração SecondaryOrigin e tenta
para se conectar a secondary.example.com. Esta é a primeira tentativa de entrar em contato com a origem,
e a terceira tentativa geral.
Nesse caso, o Media CDN faz o seguinte:
- Se
secondary.example.comretornar uma resposta bem-sucedida, O Media CDN usa essa resposta para o preenchimento do cache. - Se
secondary.example.comretornar um HTTP302 Found RedirectparaLocation: c.example.com, o Media CDN tentará entrar em contatoc.example.com. Neste exemplo, é a segunda tentativa paraSecondaryOrigin. e a quarta tentativa, no geral.
Se a tentativa de entrar em contato com c.example.com retornar uma resposta bem-sucedida,
O Media CDN usa essa resposta para o preenchimento do cache. Se a tentativa
retorna um redirecionamento que o Media CDN está configurado para seguir,
O Media CDN retorna um erro HTTP 502 Bad Gateway porque
tenha esgotado o número máximo de tentativas de contato com uma origem.
O Media CDN faz no máximo quatro tentativas em todas as origens,
independentemente das configurações de EdgeCacheOrigin. Por fim, se
O Media CDN não consegue entrar em contato com c.example.com,
O Media CDN retorna uma resposta 504 Gateway Timeout ou
Resposta 502 Bad Gateway.
Se você precisar da verificação de integridade, do round-robin ou do direcionamento com reconhecimento de carga origens, é possível configurar uma Balanceador de carga de aplicativo externo como um primário origem.
Configurar os seguintes redirecionamentos de origem
O Media CDN é compatível com os seguintes redirecionamentos retornados pela sua origem internamente durante o preenchimento do cache, em vez de retornar respostas de redirecionamento diretamente ao cliente. Quando o Media CDN está configurado para seguir a origem redirecionamentos, o Media CDN recupera o conteúdo do local de redirecionamento antes de armazenar em cache e retornar a resposta redirecionada ao cliente. O Media CDN segue redirecionamentos entre domínios.
Como prática recomendada, configure o redirecionamento apenas para origens confiáveis
e o controle de acesso. Confie em todas as origens de uma cadeia de redirecionamento
cada origem produz conteúdo que é veiculado pelo EdgeCacheService.
Para ativar os seguintes redirecionamentos de origem, adicione a seguinte configuração ao seu
Recurso EdgeCacheOrigin:
name: MY_ORIGIN
originAddress: "DOMAIN_NAME"
maxAttempts: 2
originRedirect:
redirectConditions: [FOUND, TEMPORARY_REDIRECT]
O Media CDN usa o protocolo especificado nos redirecionamentos para alcançar
de todos os servidores. Verifique se todos os servidores disponíveis para o Media CDN
redirecionado para oferecer suporte aos protocolos necessários.
Se o protocolo estiver definido como HTTPS, HTTP/2 ou HTTP/3,
O Media CDN não usa conexões HTTP/1.1 para seguir
redirecionamentos não seguros. O cabeçalho do host enviado para a origem redirecionada corresponde ao
URL redirecionado. O Media CDN segue um único redirecionamento por
EdgeCacheOrigin tentativa antes de retornar a resposta final ou avaliar
nas condições de nova tentativa
ou failover.
A configuração redirectConditions especifica quais códigos de resposta HTTP causam
Media CDN para seguir um redirecionamento para cada origem.
| Condição | Descrição |
|---|---|
| MOVED_PERMANENTLY | Siga o redirecionamento para o código de resposta HTTP 301 |
| FOUND | Siga o redirecionamento para o código de resposta HTTP 302 |
| SEE_OTHER | Siga o redirecionamento para o código de resposta HTTP 303 |
| TEMPORARY_REDIRECT | Siga o redirecionamento para o código de resposta HTTP 307 |
| PERMANENT_REDIRECT | Siga o redirecionamento para o código de resposta HTTP 308 |
Solucionar problemas de origens
Se uma origem não estiver se comportando como esperado, confira como resolver problemas de origens.