Configurar uma origem

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

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

Isso é o mesmo se o bucket for 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ê tiver 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.

Para casos em que a latência de gravação é crítica, como a transmissão ao vivo de baixa latência, é possível configurar um endpoint regional do Cloud Storage o mais próximo possível dos usuários.

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 EdgeCacheService ao 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:

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 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:

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

Use o comando gcloud storage buckets remove-iam-policy-binding. para remover as permissões concedidas ao papel allUsers do bucket especificado. Para exemplo, se o bucket conceder a allUsers o papel objectViewer, remova o conceder usando o seguinte comando:

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

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 seja acessado diretamente pelo 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:

• Grupos de instâncias de VM do Compute Engine.
• Grupos de endpoints de rede (incluindo VMs do Compute Engine e clusters do Google Kubernetes Engine).
• Grupos de endpoints de rede sem servidor (funções do Cloud Run, App Engine e Cloud Run).

Uma arquitetura que combina uma origem externa do Application Load Balancer para veicular manifestos de vídeo e uma origem do Cloud Storage para armazenamento de segmentos é semelhante à seguinte, 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. Recomendamos um nome de host público (nome de domínio), porque ele é necessário para um protocolo (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 EdgeCacheService ou que tenha configurado um urlRewrite.hostRewrite para 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.

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

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 que você 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 tem precedência sobre qualquer reescrita de cabeçalho configurada 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 realiza um preenchimento de cache, ele lê a configuração do PrimaryOrigin e responde de acordo.

Suponha que o Media CDN se conecte a primary.example.com como a primeira tentativa de 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, a CDN de mídia faz o seguinte:

• Se b.example.com retornar uma resposta bem-sucedida, o Media CDN usa essa resposta para o preenchimento do cache.
• Se b.example.com retornar um redirecionamento ou uma resposta de falha, O Media CDN faz o failover para o SecondaryOrigin configurado. Isso ocorre porque, neste exemplo, PrimaryOrigin está configurado para dois maxAttempts.

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.com retornar uma resposta bem-sucedida, O Media CDN usa essa resposta para o preenchimento do cache.
• Se secondary.example.com retornar um 302 Found Redirect HTTP para Location: c.example.com, o Media CDN tentará entrar em contato com c.example.com. Neste exemplo, é a segunda tentativa para SecondaryOrigin. 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.

Solucionar problemas de origens

Se uma origem não estiver se comportando como esperado, confira como resolver problemas de origens.

A seguir

• Usar um bucket particular compatível com o Amazon S3 como origem
• Configurar rotas de serviço