Pode configurar origens para a RFC de multimédia de várias formas. Esta página mostra como configurar origens.
Configure um contentor do Cloud Storage como uma origem
A RFC de multimédia suporta contentores do Cloud Storage como back-ends para conteúdo. Cada serviço pode referenciar vários contentores configurando rotas para o anfitrião, os caminhos e outros atributos de pedidos.
Os contentores do Cloud Storage são configurados através do URL do contentor, como gs://my-bucket, como endereço de origem quando cria um recurso de origem.
Consola
Na Google Cloud consola, aceda à página RFC de multimédia.
Clique no separador Origens.
Clique em Criar origem.
Introduza um nome para a origem. Por exemplo:
cloud-storage-origin.Opcional: introduza uma descrição.
Para a Morada de origem, escolha Selecionar um contentor do Google Cloud Storage.
Procure o seu contentor do Cloud Storage e selecione-o.
Para o Cloud Storage, mantenha as definições predefinidas de protocolo e porta.
Opcional: para que as substituições de cabeçalhos de pedidos de origem tenham precedência sobre os cabeçalhos enviados pelo cliente ou manipulados por ações de cabeçalhos ao nível da rota, faça o seguinte:
- Selecione Ativar substituição de origem.
- Na secção Cabeçalhos, especifique cabeçalhos adicionando um ou mais pares de nome-valor.
Opcional: selecione uma origem de alternativa para experimentar caso esta origem fique inacessível. Pode atualizar este campo mais tarde.
Selecione condições de redirecionamento.
Selecione condições de nova tentativa.
Para Máximo de tentativas, selecione o número máximo de tentativas para preencher a cache a partir desta origem.
Opcional: especifique os seguintes valores de tempo limite:
- Para Tempo limite de ligação, selecione a duração máxima de espera para que a ligação de origem seja estabelecida.
- Para Tempo limite de resposta, selecione a duração máxima para permitir que uma resposta seja concluída.
- Para Tempo limite de leitura, selecione a duração máxima de espera entre leituras de uma única ligação HTTP ou stream.
Opcional: clique em Adicionar etiqueta 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 o seguinte:
ORIGIN: o nome da nova origemADDRESS: o nome do contentor, por exemplo,gs://my-bucket
Isto é igual quer o contentor seja multirregional, de duas regiões ou regional.
Quando configura um serviço, pode encaminhar o conteúdo de vídeo a pedido para um contentor e o conteúdo de streaming em direto para um segundo contentor. Isto é útil se tiver
equipas diferentes a gerir cada fluxo de trabalho. Para reduzir a latência de preenchimento da cache, pode encaminhar de forma semelhante a região eu-media.example.com para um contentor do Cloud Storage multirregional localizado na UE e a região us-media.example.com (ou fazer a correspondência no caminho, no cabeçalho ou no parâmetro de consulta) para um contentor de armazenamento baseado nos EUA.
Nos casos em que a latência de escrita é fundamental, como o streaming em direto de baixa latência, pode configurar um ponto final do Cloud Storage regional o mais próximo possível dos seus utilizadores.
Autentique pedidos
Para confirmar que um pedido está a ser feito a partir da RFC, use uma das seguintes abordagens suportadas:
- Valide se o endereço IP de ligação é dos intervalos de preenchimento da cache da rede CDN de multimédia. Estes intervalos são partilhados por todos os clientes, mas são sempre usados por recursos
EdgeCacheServicequando se ligam a uma origem. - Adicione um cabeçalho de pedido personalizado com um valor de token que valida na origem (por exemplo, um valor aleatório de 16 bytes). Em seguida, a sua origem pode rejeitar pedidos que não incluam este valor.
Configure um protocolo de origem
Se a sua origem suportar HTTP/2, não precisa de definir explicitamente o protocolo.
Para origens que suportam apenas HTTPS (HTTP/1.1 sobre TLS) ou HTTP/1.1 (sem TLS), defina o campo protocol explicitamente da seguinte forma:
Consola
Na Google Cloud consola, aceda à página RFC de multimédia.
Clique no separador Origens.
Selecione a sua origem e clique em Editar.
Para o 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
Substitua LEGACY_ORIGIN pelo nome da origem.
Configure contentores privados do Cloud Storage
A RFC de multimédia pode extrair conteúdo de qualquer ponto final HTTP ou HTTPS acessível através da Internet. Em alguns casos, pode querer exigir autenticação para permitir que apenas a RFC de multimédia extraia conteúdo e impedir o acesso não autorizado. O Cloud Storage suporta esta funcionalidade através de autorizações do IAM.
Para origens do Cloud Storage, faça o seguinte:
- Conceda à conta de serviço da Media CDN a autorização da IAM nos contentores do Cloud Storage que está a usar como origens.
objectViewer - Remova a autorização
allUsers. - Opcional: remova a autorização
allAuthenticatedUsers.
Para alterar as autorizações de um contentor do Cloud Storage, precisa da
função de administrador do armazenamento
(roles/storage.admin).
A conta de serviço da RFC é propriedade do projeto da RFC e não aparece na lista de contas de serviço do seu projeto. A conta de serviço concede acesso apenas aos recursos da Media CDN nos projetos que permite explicitamente.
Tem de criar, pelo menos, um recurso da RFC para acionar a criação da conta de serviço. Na maioria dos casos, este é o recurso EdgeCacheOriginassociado
ao seu contentor do Cloud Storage.
Para conceder acesso do Media CDN a um contentor, conceda a função à conta de serviço:objectViewer
gcloud storage buckets add-iam-policy-binding gs://BUCKET \
--member=serviceAccount:service-PROJECT_NUMBER@gcp-sa-mediaedgefill.iam.gserviceaccount.com \
--role=roles/storage.objectViewer
Substitua PROJECT_NUMBER pelo número do projeto.
Antes de remover o acesso público a um contentor de armazenamento existente usado como origem de produção, aguarde, pelo menos, 10 minutos para que a configuração seja propagada.
Use o comando gcloud storage buckets remove-iam-policy-binding
para remover as autorizações concedidas à função allUsers para o contentor especificado. Por exemplo, se o contentor conceder a função allUsers a objectViewer, remova a concessão através do seguinte comando:
gcloud storage buckets remove-iam-policy-binding gs://BUCKET \
--member=allUsers --role=roles/storage.objectViewer
Para validar que o acesso público foi removido, abra uma janela do navegador
em modo de navegação anónima e tente aceder a um objeto de contentor através de
https://storage.googleapis.com/BUCKET/object.ext.
Para permitir que os recursos EdgeCacheService num projeto acedam a um contentor do Cloud Storage noutro projeto, pode conceder à conta de serviço do Media CDN nesse projeto acesso ao contentor de armazenamento.
Para o fazer, verifique se PROJECT_NUMBER em
service-PROJECT_NUMBER@gcp-sa-mediaedgefill.iam.gserviceaccount.com é o número do projeto com os recursos EdgeCacheService que precisam de
acesso. Pode repetir este processo para vários projetos, especialmente se alguns deles alojarem diferentes ambientes da RFC (como desenvolvimento, teste ou produção) e um projeto separado contiver os seus recursos de vídeo ou multimédia.
Pode proteger o acesso à sua origem do Cloud Storage sem ativar os pedidos assinados para essa rota.
A configuração do Cloud Storage privado não impede o acesso direto ao conteúdo em cache a partir da RFC para conteúdo multimédia. Para obter informações sobre como pode emitir pedidos assinados a utilizadores individuais, consulte pedidos assinados.
Configure um balanceador de carga de aplicações externo como origem
Se precisar de verificação de estado ativa, round robin ou encaminhamento com reconhecimento de carga em origens do Compute Engine, GKE ou no local, pode configurar um Application Load Balancer externo como origem.
Isto permite-lhe configurar (por exemplo) os seus pacotes de streaming em direto atrás da rede de CDN de multimédia ou de um grupo de proxies do Envoy geridos pela Cloud Service Mesh para estabelecer ligação à sua infraestrutura no local.
Os balanceadores de carga permitem-lhe configurar back-ends para o seguinte:
- Grupos de instâncias de máquinas virtuais (VMs) do Compute Engine.
- Grupos de pontos finais da rede (incluindo VMs do Compute Engine e clusters do Google Kubernetes Engine).
- Grupos de pontos finais de rede sem servidor (Cloud Run, App Engine e funções do Cloud Run).
Uma arquitetura que combina uma origem do Application Load Balancer externa para publicar manifestos de vídeo e uma origem do Cloud Storage para o armazenamento de segmentos é semelhante à seguinte, com duas origens mapeadas para rotas diferentes.
Para configurar um Application Load Balancer externo como origem, tem de criar um recurso de origem com o endereço IP ou o nome do anfitrião público que aponta para as regras de encaminhamento do equilibrador de carga. É preferível um nome de anfitrião público (nome de domínio) porque é necessário para um certificado SSL (TLS) e para versões HTTP modernas (HTTP/2 e HTTP/3).
Também tem de confirmar o seguinte:
- O balanceador de carga tem uma rota que corresponde ao nome do anfitrião usado para o recurso
EdgeCacheServiceou configurou umurlRewrite.hostRewritepara rotas onde o balanceador de carga está configurado como a origem. - O seu equilibrador de carga tem um certificado SSL (TLS) fidedigno publicamente configurado para estes nomes de anfitrião.
Por exemplo, se o nome do domínio público apontar para a regra de encaminhamento do balanceador de carga for origin-packager.example.com, tem de criar uma origem com o originAddress definido para este nome.
Consola
Na Google Cloud consola, aceda à página RFC de multimédia.
Clique no separador Origens.
Clique em Criar origem.
Introduza um nome para a origem. Por exemplo:
load-balancer-origin.Opcional: introduza uma descrição.
Para a Morada de origem, escolha Especificar um FQDN ou um endereço IP.
Introduza o FQDN ou o endereço IP do seu Google Cloud equilibrador de carga.
Opcional: selecione uma origem de alternativa para experimentar caso esta origem fique inacessível. Pode atualizar este campo mais tarde.
Selecione condições de nova tentativa.
Para Máximo de tentativas, selecione o número máximo de tentativas para preencher a cache a partir desta origem.
Opcional: especifique os seguintes valores de tempo limite:
- Para Tempo limite de ligação, selecione a duração máxima de espera para que a ligação de origem seja estabelecida.
- Para Tempo limite de resposta, selecione a duração máxima para permitir que uma resposta seja concluída.
- Para Tempo limite de leitura, selecione a duração máxima de espera entre leituras de uma única ligação HTTP ou stream.
Opcional: clique em Adicionar etiqueta 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 o seguinte:
LB_ORIGIN: o nome da origemLB_ADDRESS: o FQDN ou o endereço IP, por exemplo,origin-packager.example.com
Se estiver a usar o endereço IP da sua regra de encaminhamento como endereço de origem,
ou não tiver um certificado SSL anexado ao seu equilibrador de carga, pode
definir o protocolo como HTTP para reverter para ligações não encriptadas. Recomendamos que o faça apenas para fins de desenvolvimento ou testes.
Configure uma região para a ocultação flexível
Pode configurar uma região para a proteção flexível quando cria ou atualiza uma origem.
gcloud
Para configurar a proteção flexível para uma região numa origem existente, use o comando
gcloud edge-cache origins update:
gcloud edge-cache origins update ORIGIN \
--origin-address=ADDRESS \
--flex-shielding=REGION
Substitua o seguinte:
ORIGIN: o nome da origemADDRESS: a morada da origemREGION: a região para a proteção de origem. Os valores válidos sãoafrica_south1eme_central1.
Para repor a proteção de origem predefinida, execute o mesmo comando depois de definir a opção flex-shielding como vazia.
yaml
Para configurar a proteção de origem para uma região numa origem existente, adicione uma secção flexShielding à configuração do recurso EdgeCacheOrigin:
name: ORIGIN
originAddress: ADDRESS
# ... Other fields
flexShielding:
flexShieldingRegions:
- REGION
# ... Other fields
Substitua o seguinte:
ORIGIN: o nome da origemADDRESS: a morada da origemREGION: a região para a proteção de origem. Os valores válidos sãoafrica_south1eme_central1.
Para repor a proteção de origem para a predefinição, remova a secção flexShielding.
Configure a comutação por falha de origem
As secções seguintes mostram como configurar o comportamento de comutação por falha de origem.
Comutação em caso de falha de origem sem seguimento de redirecionamentos
Segue-se uma configuração básica de EdgeCacheOrigin de alternativa:
name: FAILOVER_ORIGIN
originAddress: FAILOVER_DOMAIN_NAME
A RFC do CDN de multimédia tenta novamente a origem principal do trajeto um máximo de três vezes antes de tentar uma origem de alternativa. Nesta configuração, depois de tentar o
origem principal três vezes, a RFC de multimédia tenta um único
pedido em relação ao FAILOVER_ORIGIN. Se a origem de
failover também não responder com êxito, o
Media CDN devolve a resposta de origem completa ou, se não for recebido nenhum
código de estado, uma resposta HTTP 502 Bad Gateway.
A latência de preenchimento da cache aumenta com o número de novas tentativas e eventos de comutação por falha.
Aumentar ainda mais os valores de limite de tempo de origem (como connectTimeout) afeta a latência de preenchimento da cache, porque aumenta o tempo gasto à espera que um servidor de origem sobrecarregado ou ocupado responda.
O exemplo seguinte demonstra uma configuração que envia pedidos de preenchimento para
MY_ORIGIN. A configuração faz com que a RFC de multimédia volte a tentar em erros de ligação (como erros de DNS, TCP ou TLS), respostas HTTP 5xx da origem ou HTTP 404 Not Found. Após duas tentativas, muda para FAILOVER_ORIGIN.
É feito um máximo total de quatro tentativas nas origens configuradas: a tentativa original mais até três tentativas. Pode configurar um valor maxAttempts por origem para determinar quantas novas tentativas são feitas antes de tentar a comutação por falha.
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
Comutação por falha de origem com seguimento de redirecionamentos
Por exemplo, suponhamos que configurou os seguintes recursos e que as rotas do recurso EdgeCacheService estão configuradas para usar PrimaryOrigin para o preenchimento da cache:EdgeCacheOrigin
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 a RFC de multimédia executa um preenchimento da cache, a RFC de multimédia lê a configuração do PrimaryOrigin e responde em conformidade.
Suponhamos que a RFC 7230 se liga a primary.example.com como tentativa n.º 1 de contactar a origem. Se primary.example.com devolver uma resposta bem-sucedida, a RFC usa essa resposta para o preenchimento da cache.
Suponhamos agora que primary.example.com devolve um HTTP 302 Found Redirect para Location: b.example.com. Em seguida, na tentativa n.º 2 de contactar a origem, o RFC de multimédia segue o redirecionamento para b.example.com. Neste caso,
a RFC de multimédia faz o seguinte:
- Se
b.example.comdevolver uma resposta bem-sucedida, a RFC 7231 usa essa resposta para o preenchimento da cache. - Se
b.example.comdevolver um redirecionamento ou uma resposta de falha, o Media CDN muda para oSecondaryOriginconfigurado. Isto acontece porque, neste exemplo,PrimaryOriginestá configurado para doismaxAttempts.
Se a RFC de multimédia comutar para SecondaryOrigin,
a RFC de multimédia usa a configuração SecondaryOrigin e tenta
estabelecer ligação a secondary.example.com. Esta é a tentativa n.º 1 de contactar a origem e a tentativa n.º 3 no total.
Neste caso, a RFC de multimédia faz o seguinte:
- Se
secondary.example.comdevolver uma resposta bem-sucedida, a RFC de multimédia usa essa resposta para o preenchimento da cache. - Se
secondary.example.comdevolver um HTTP302 Found RedirectaLocation: c.example.com, a RFC de multimédia tenta contactarc.example.com. Neste exemplo, esta é a tentativa n.º 2 paraSecondaryOrigine a tentativa n.º 4 no total.
Se a tentativa de contacto com c.example.com devolver uma resposta bem-sucedida, o Media CDN usa essa resposta para o preenchimento da cache. Se a tentativa
devolver um redirecionamento que a RFC de multimédia esteja configurada para seguir,
a RFC de multimédia devolve um código de estado HTTP 502 Bad Gateway porque
esgotou o número máximo de tentativas de contactar uma origem.
A RFC de multimédia faz, no máximo, quatro tentativas em todas as origens, independentemente das configurações da EdgeCacheOrigin. Por último, se o Media CDN não conseguir contactar c.example.com, o Media CDN devolve uma resposta 504 Gateway Timeout ou uma resposta 502 Bad Gateway.
Se precisar de verificações de funcionamento, round-robin ou encaminhamento com reconhecimento de carga em várias origens, pode configurar um Application Load Balancer externo como uma origem principal.
Configure o seguimento de redirecionamentos de origem
A RFC 7231 define os redirecionamentos HTTP como respostas com códigos de estado na gama 300. O Media CDN suporta o seguimento de redirecionamentos devolvidos pela sua origem internamente durante o preenchimento da cache, em vez de devolver respostas de redirecionamento diretamente ao cliente. Quando a RFC de multimédia está configurada para seguir os redirecionamentos de origem, a RFC de multimédia obtém conteúdo da localização de redirecionamento antes de colocar em cache e devolver a resposta redirecionada ao cliente. A RFC de multimédia segue os redirecionamentos em vários domínios.
Como prática recomendada, configure o redirecionamento de origem apenas para origens fidedignas
e que controla. Certifique-se de que confia em todas as origens numa cadeia de redirecionamentos, porque cada origem produz conteúdo publicado pelo seu EdgeCacheService.
Para ativar o seguimento de redirecionamentos de origem, adicione a seguinte configuração ao recurso EdgeCacheOrigin:
name: MY_ORIGIN
originAddress: DOMAIN_NAME
maxAttempts: 2
originRedirect:
redirectConditions: [FOUND, TEMPORARY_REDIRECT]
A RFC usa o protocolo especificado nos redirecionamentos para alcançar todos os servidores. Confirme que todos os servidores para os quais o Media CDN pode ser redirecionado oferecem suporte para os protocolos necessários.
Em particular, se o protocolo estiver definido como HTTPS, HTTP/2 ou HTTP/3, a RFC de multimédia não recorre a ligações HTTP/1.1 para seguir redirecionamentos não seguros. O cabeçalho do anfitrião enviado para a origem redirecionada corresponde ao URL redirecionado. A RFC 7231 define o número máximo de redirecionamentos para 5. O CDN de multimédia segue um único redirecionamento por tentativa antes de devolver a resposta final ou avaliar as condições de repetição ou de alternativa.EdgeCacheOrigin
A definição redirectConditions especifica os códigos de resposta HTTP que fazem com que a RFC de multimédia siga um redirecionamento para cada origem.
| Condição | Descrição |
|---|---|
| MOVED_PERMANENTLY | Seguir redirecionamento para o código de resposta HTTP 301 |
| FOUND | Seguir redirecionamento para o código de resposta HTTP 302 |
| SEE_OTHER | Seguir redirecionamento para o código de resposta HTTP 303 |
| TEMPORARY_REDIRECT | Seguir redirecionamento para o código de resposta HTTP 307 |
| PERMANENT_REDIRECT | Seguir redirecionamento para o código de resposta HTTP 308 |
Configure reescritas de anfitriões ou modificações de cabeçalhos específicas da origem
Se a sua origem exigir uma reescrita do anfitrião ou uma modificação do cabeçalho específica da origem,
use o seguinte exemplo de configuração originOverrideAction para as definir:
name: FAILOVER_ORIGIN
originAddress: FAILOVER_ORIGIN_HOST"
originOverrideAction:
urlRewrite:
hostRewrite: FAILOVER_ORIGIN_HOST"
headerAction:
requestHeadersToAdd:
- headerName: "Authorization"
headerValue: "AUTH-KEY"
replace: true
A definição originOverrideAction.hostRewrite tem
precedência sobre quaisquer reescritas de cabeçalhos
configuradas em rotas que apontam para esta origem.
Pode usar requestHeadersToAdd cabeçalhos únicos por origem pedidos por essa origem específica. Um exemplo de utilização comum adiciona cabeçalhos Authorization estáticos.
Uma vez que estas manipulações de cabeçalhos são executadas durante o pedido de origem, os cabeçalhos
adicionados por origem substituem ou acrescentam aos cabeçalhos existentes do mesmo nome
do campo. Por predefinição, a app Media CDN anexa-se aos cabeçalhos existentes. Para
substituir os cabeçalhos existentes, defina headerAction.replace como true.
Para obter informações sobre como definir cabeçalhos de pedidos por rota, consulte o artigo Defina cabeçalhos personalizados.
Resolução de problemas de origens
Se uma origem não estiver a funcionar como esperado, verifique como resolver problemas de origens.