Configurar uma origem

É possível configurar origens para a Media CDN de várias maneiras. Nesta página, mostramos como configurar origens.

Configurar um bucket do Cloud Storage como origem

A Media CDN é compatível com buckets do Cloud Storage como back-ends de conteúdo. Cada serviço pode referenciar vários buckets configurando 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 é válido para buckets multirregionais, birregionais ou regionais.

Ao configurar um serviço, você pode encaminhar o conteúdo de vídeo on demand para um bucket e o conteúdo de 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, você pode rotear a região eu-media.example.com para um bucket multirregional do Cloud Storage localizado na UE e a região us-media.example.com (ou corresponder por caminho, cabeçalho ou parâmetro de consulta) para um bucket de armazenamento nos EUA.

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

Autenticar solicitações

Para confirmar se uma solicitação está vindo da CDN de mídia, use uma das seguintes abordagens compatíveis:

• Valide se o endereço IP de conexão é dos intervalos de preenchimento de cache da Media CDN. Esses intervalos são compartilhados entre todos os clientes, mas sempre usados 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 na origem (por exemplo, um valor aleatório de 16 bytes). Sua origem pode rejeitar solicitações que não incluem esse valor.

Configurar um protocolo de origem

Se a origem for compatível com HTTP/2, não será necessário definir o protocolo explicitamente. Para origens que oferecem suporte apenas a 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

Configurar buckets privados do Cloud Storage

A Media CDN pode extrair conteúdo de qualquer endpoint HTTP ou HTTPS acessível pela Internet. Em alguns casos, talvez seja necessário exigir autenticação para permitir que a Media CDN extraia conteúdo e evitar acesso não autorizado. O Cloud Storage oferece suporte a isso com permissões do IAM.

Para origens do Cloud Storage, faça o seguinte:

• Conceda à conta de serviço da Media CDN a permissão do IAM objectViewer nos buckets do Cloud Storage que você está 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 da função de administrador do Storage (roles/storage.admin).

A conta de serviço da Media CDN é de propriedade do projeto da Media CDN 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 você permite explicitamente.

É necessário criar pelo menos um recurso da Media CDN para acionar a criação da conta de serviço. Na maioria dos casos, esse é o recurso EdgeCacheOrigin conectado ao bucket do Cloud Storage.

Para conceder acesso da Media CDN a um bucket, atribua o papel objectViewer à 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

Substitua PROJECT_NUMBER pelo número do projeto.

Antes de remover o acesso público a um bucket de armazenamento 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 permissões concedidas ao papel allUsers no bucket especificado. Por exemplo, se o bucket conceder a allUsers a função objectViewer, remova a concessão usando o seguinte comando:

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

Para validar se o acesso público foi removido, abra uma janela anônima do navegador e tente acessar um objeto do bucket usando https://storage.googleapis.com/BUCKET/object.ext.

Para permitir que recursos EdgeCacheService em um projeto acessem um bucket do Cloud Storage em outro projeto, conceda à conta de serviço da Media CDN nesse projeto acesso ao bucket de armazenamento.

Para 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 de acesso. É possível repetir esse processo para vários projetos, principalmente se alguns deles tiverem ambientes diferentes da CDN de mídia (como desenvolvimento, preparo ou produção) e um projeto separado contiver seus recursos de vídeo ou mídia.

É possível proteger o acesso à origem do Cloud Storage sem ativar os pedidos assinados para essa rota.

Configurar o Cloud Storage particular não impede que o conteúdo armazenado em cache seja acessado diretamente do Media CDN. Para informações sobre como emitir solicitações assinadas para usuários individuais, consulte solicitações assinadas.

Configurar um balanceador de carga de aplicativo externo como uma origem

Se você precisar de verificação de integridade ativa, round-robin ou encaminhamento com reconhecimento de carga em origens do Compute Engine, do GKE ou locais, configure um balanceador de carga de aplicativo externo como uma origem.

Isso permite configurar (por exemplo) seus empacotadores de transmissão ao vivo por trás do Media CDN ou de um grupo de proxies do Envoy gerenciados pelo Cloud Service Mesh para se conectar novamente à sua infraestrutura local.

Os balanceadores de carga permitem configurar back-ends para o seguinte:

• Grupos de instâncias de máquina virtual (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 (Cloud Run, App Engine e Cloud Run functions).

Uma arquitetura que combina uma origem do balanceador de carga de aplicativo externo 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 uma origem, crie um recurso de origem com o endereço IP ou o nome do host público apontando para as regras de encaminhamento do balanceador de carga. É preferível usar um nome de host público (nome de domínio), porque ele é necessário para um certificado SSL (TLS) e para versões modernas do HTTP (HTTP/2 e HTTP/3).

Você também precisa confirmar o seguinte:

• O balanceador de carga tem uma rota que corresponde ao nome do host usado para o recurso EdgeCacheService ou você configurou 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) confiável publicamente configurado para esses nomes de host.

Por exemplo, se o nome de domínio público apontado para a regra de encaminhamento do balanceador de carga for origin-packager.example.com, crie uma origem com o originAddress definido como esse nome.

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

Se você estiver usando o endereço IP da regra de encaminhamento como endereço de origem ou não tiver um certificado SSL anexado ao balanceador de carga, defina o protocolo como HTTP para voltar a conexões sem criptografia. Recomendamos que você faça isso apenas para desenvolvimento ou teste.

Configurar uma região para proteção flexível

É possível configurar uma região para proteção flexível ao criar ou atualizar uma origem.

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

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

Configurar failover de origem

As seções a seguir mostram como configurar o comportamento de failover de origem.

Failover de origem sem seguir redirecionamentos

Confira a seguir uma configuração básica de failover EdgeCacheOrigin:

name: FAILOVER_ORIGIN
originAddress: FAILOVER_DOMAIN_NAME

A Media CDN tenta novamente a origem principal da rota no máximo três vezes antes de tentar uma origem de failover. Nessa configuração, depois de tentar a origem principal três vezes, o Media CDN tenta uma única solicitação no FAILOVER_ORIGIN. Se a origem de failover também não responder, a Media CDN vai retornar toda a resposta da origem ou, se nenhum código de status 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. Aumentar os valores de tempo limite da origem (como connectTimeout) afeta ainda mais a latência de preenchimento do cache, porque aumenta o tempo gasto esperando que um servidor de origem sobrecarregado ou ocupado responda.

O exemplo a seguir demonstra uma configuração que envia solicitações de preenchimento para MY_ORIGIN. A configuração faz com que a Media CDN tente novamente em erros de conexão (como erros de DNS, TCP ou TLS), respostas HTTP 5xx da origem ou HTTP 404 Not Found. Após duas tentativas, ele faz failover para FAILOVER_ORIGIN.

Um total máximo de quatro tentativas é feito nas origens configuradas: a tentativa original mais até três novas tentativas. É possível configurar um valor de maxAttempts por origem para determinar quantas novas tentativas são feitas antes de tentar fazer 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 de origem com acompanhamento de redirecionamento

Por exemplo, suponha que você tenha configurado os seguintes recursos EdgeCacheOrigin e que as rotas do recurso EdgeCacheService estejam configuradas para usar PrimaryOrigin no preenchimento do 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 tentativa nº 1 de entrar em contato com a origem. Se primary.example.com retornar uma resposta bem-sucedida, a Media CDN vai usar essa resposta para o preenchimento do cache.

Suponha agora que primary.example.com retorne um HTTP 302 Found Redirect para Location: b.example.com. Em seguida, como tentativa nº 2 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, a Media CDN vai usar essa resposta para o preenchimento do cache.
• Se b.example.com retornar um redirecionamento ou uma resposta de falha, a Media CDN fará failover para o SecondaryOrigin configurado. Isso acontece porque, neste exemplo, PrimaryOrigin está configurado para dois maxAttempts.

Se o Media CDN fizer failover para SecondaryOrigin, ele usará a configuração SecondaryOrigin e tentará se conectar a secondary.example.com. Esta é a tentativa nº 1 de contato com a origem e a tentativa nº 3 no geral.

Nesse caso, a CDN de mídia faz o seguinte:

• Se secondary.example.com retornar uma resposta bem-sucedida, a Media CDN vai usar essa resposta para preencher o cache.
• Se secondary.example.com retornar um HTTP 302 Found Redirect para Location: c.example.com, o Media CDN tentará entrar em contato com c.example.com. Neste exemplo, essa é a tentativa nº 2 para SecondaryOrigin e a tentativa nº 4 no geral.

Se a tentativa de contato com c.example.com retornar uma resposta bem-sucedida, o Media CDN usará essa resposta para o preenchimento do cache. Se a tentativa retornar um redirecionamento que a Media CDN está configurada para seguir, a Media CDN vai retornar um código de status HTTP 502 Bad Gateway porque esgotou o número máximo de tentativas de entrar em contato com uma origem. O Media CDN faz no máximo quatro tentativas em todas as origens, independente das configurações de EdgeCacheOrigin. Por fim, se a Media CDN não conseguir entrar em contato com c.example.com, ela vai retornar uma resposta 504 Gateway Timeout ou 502 Bad Gateway.

Se você precisar de verificação de integridade, round-robin ou encaminhamento com reconhecimento de carga entre origens, configure um balanceador de carga de aplicativo externo como uma origem principal.

Configurar os seguintes redirecionamentos de origem

A Media CDN oferece suporte a redirecionamentos retornados pela origem internamente durante o preenchimento do cache, em vez de retornar respostas de redirecionamento diretamente ao cliente. Quando o Media CDN é configurado para seguir redirecionamentos de origem, ele recupera o conteúdo do local de redirecionamento antes de armazenar em cache e retornar a resposta redirecionada ao cliente. A Media CDN segue redirecionamentos entre domínios.

Como prática recomendada, configure o redirecionamento de origem apenas para origens confiáveis e controladas. Confie em todas as origens em uma cadeia de redirecionamento, porque cada uma delas produz conteúdo veiculado pelo seu EdgeCacheService.

Para ativar o redirecionamento de origem, adicione a seguinte configuração ao recurso EdgeCacheOrigin:

name: MY_ORIGIN
originAddress: DOMAIN_NAME
maxAttempts: 2
originRedirect:
  redirectConditions: [FOUND, TEMPORARY_REDIRECT]

A Media CDN usa o protocolo especificado nos redirecionamentos para alcançar todos os servidores. Confirme se todos os servidores para os quais a Media CDN pode ser redirecionada oferecem suporte aos protocolos necessários. Em particular, se o protocolo estiver definido como HTTPS, HTTP/2 ou HTTP/3, o Media CDN não vai recorrer a conexões HTTP/1.1 para seguir redirecionamentos não seguros. O cabeçalho host enviado para a origem redirecionada corresponde ao URL redirecionado. A Media CDN segue um único redirecionamento por tentativa de EdgeCacheOrigin antes de retornar a resposta final ou avaliar condições de nova tentativa ou failover.

A configuração redirectConditions especifica quais códigos de resposta HTTP fazem com que a Media CDN siga um redirecionamento para cada origem.

Configurar substituições de host ou modificações de cabeçalho específicas da origem

Se a origem exigir uma regravação de host ou modificação de cabeçalho específica da origem, use o exemplo de configuração originOverrideAction a seguir para defini-las:

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

A configuração originOverrideAction.hostRewrite tem precedência sobre todas as reescritas de cabeçalho configuradas em rotas que apontam para essa origem.

É possível usar cabeçalhos requestHeadersToAdd exclusivos por origem solicitados por essa 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 adicionados por origem substituem ou são anexados aos cabeçalhos existentes do mesmo nome de campo. Por padrão, o Media CDN anexa aos cabeçalhos atuais. Para substituir os cabeçalhos atuais, defina headerAction.replace como true.

Para informações sobre como definir cabeçalhos de solicitação por rota, consulte Definir cabeçalhos personalizados.

Solução de problemas de origens

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

A seguir

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