Configurar uma origem

É possível configurar origens para a 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 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.

Console

1. No console do Google Cloud, acesse a página Origens do Media CDN.

   Acessar "Origens"

2. Clique em Criar origem.

3. Insira um nome para a origem. Por exemplo, cloud-storage-origin.

4. Opcional: insira uma descrição.

5. Em Endereço de origem, escolha Selecionar um bucket do Google Cloud Storage.

6. Navegue até o bucket do Cloud Storage e selecione-o.

7. Para o Cloud Storage, mantenha as configurações padrão do protocolo e da porta.

8. Opcional: para que as substituições de cabeçalho da solicitação de origem tenham precedência sobre os cabeçalhos enviados pelo cliente ou manipulados por ações de cabeçalho em nível de rota, faça o seguinte:

   1. Selecione Ativar a substituição de origem.
   2. Na seção Headers, especifique cabeçalhos adicionando um ou mais pares de nome-valor.

9. Opcional: selecione uma origem de failover para tentar, caso ela se torne inacessível. Você pode atualizar esse campo mais tarde.

10. Selecione Condições de redirecionamento.

11. Selecione Condições de nova tentativa.

12. Em Tentativas máximas, selecione o número máximo de tentativas para preencher o cache dessa origem.

13. Opcional: especifique os seguintes valores de tempo limite:

    1. Em Tempo limite de conexão, selecione a duração máxima para aguardar a conexão de origem ser estabelecida.
    2. Em Tempo limite de resposta, selecione a duração máxima para permitir que uma resposta seja concluída.
    3. Em Tempo limite de leitura, selecione a duração máxima de espera entre as leituras de uma única conexão ou stream HTTP.

14. Opcional: clique em Adicionar rótulo e especifique um ou mais pares de chave-valor.

15. 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 for multirregional, birregional ou regional.

Ao configurar um serviço, você pode direcionar seu conteúdo de vídeo on demand para um bucket e o conteúdo de transmissão ao vivo para outro. Isso é útil se você tiver equipes diferentes gerenciando cada fluxo de trabalho. Para reduzir a latência de preenchimento do cache, você pode encaminhar 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 correspondência no caminho, cabeçalho ou parâmetro de consulta) para um bucket de armazenamento nos EUA.

Importante: recomendamos que você use um bucket multirregional para o armazenamento de origem, porque ele oferece maior redundância geográfica para os objetos armazenados.

Buckets do Media CDN (clique para ampliar).

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 da CDN de mídia, use uma das seguintes abordagens com suporte:

• 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 são sempre usados pelos 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

Para origens que oferecem suporte apenas a HTTPS (HTTP/1.1 sobre TLS) ou HTTP/1.1 (sem TLS), defina o campo protocol explicitamente:

Console

1. No console do Google Cloud, acesse a página Origens do Media CDN.

   Acessar "Origens"

2. Selecione a origem e clique em Editar.

3. Para o protocolo, selecione HTTPS ou HTTP. Para HTTP, especifique a porta como 80.

4. 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 for compatível com HTTP/2, não será necessário definir o protocolo explicitamente.

Configurar buckets privados do Cloud Storage

A CDN de mídia 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 o Media CDN extraia conteúdo e evite o acesso não autorizado. O Cloud Storage oferece suporte a isso por meio de permissões do IAM.

Importante: para rotas associadas a uma origem privada do Cloud Storage, defina o modo de cache como FORCE_CACHE_ALL. Caso contrário, o armazenamento em cache é impedido porque os buckets privados do Cloud Storage definem um cabeçalho cache-control: private.

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

• Conceda à conta de serviço do Media CDN a permissão objectViewer do IAM 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 do papel de administrador do IAM do Storage.

A conta de serviço do Media CDN é de propriedade do projeto Media CDN e não aparece na lista de contas de serviço do projeto.

A conta de serviço tem o seguinte formato e concede acesso apenas aos recursos do Media CDN nos projetos que você permitir explicitamente.

[e-mail]

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

Para conceder à CDN de mídia acesso a um bucket, conceda o papel objectViewer à conta de serviço:

gcloud storage buckets add-iam-policy-binding gs://BUCKET \
--member=serviceAccount:[e-mail] \
--role=roles/storage.objectViewer

Observação: aguarde pelo menos 10 minutos para que a configuração seja propagada antes de remover o acesso público a um bucket de armazenamento usado como origem de produção.

Use o comando gcloud storage buckets remove-iam-policy-binding para remover as permissões concedidas ao papel allUsers para o bucket. Por exemplo, se o bucket conceder a allUsers o papel 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 de navegador anônimo e tente acessar um objeto de bucket usando https://storage.googleapis.com/BUCKET/object.ext.

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

Para isso, verifique se PROJECT_NUM em [e-mail] é o número do projeto com os recursos EdgeCacheService que precisam de acesso. Você pode repetir esse processo para vários projetos, especialmente se alguns deles tiverem diferentes ambientes da CDN de mídia (como desenvolvimento, preparação 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 as 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 solicitações assinhadas.

Configurar um balanceador de carga de aplicativo externo como uma origem

Se você precisar de verificação de integridade ativa, round-robin ou direcionamento sensível à carga no Compute Engine, no GKE ou em origens locais, configure um balanceador de carga de aplicativo externo como origem.

Isso permite configurar, por exemplo, os pacotes de transmissão ao vivo por trás do CDN de mídia ou de um grupo de proxies Envoy gerenciados pela Cloud Service Mesh para se conectar novamente à infraestrutura local.

Os balanceadores de carga permitem configurar back-ends para:

• 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 (Cloud Run, App Engine e Cloud Functions).

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.

Implantação do cache de borda (clique para ampliar).

Para configurar um balanceador de carga de aplicativo externo como uma origem, é necessário criar um recurso de origem com o endereço IP ou o nome de host público apontando para as regras de encaminhamento do balanceador de carga. Um nome de host público (nome de domínio) é o preferido, porque é necessário para um certificado SSL (TLS) e para versões modernas do HTTP (HTTP/2 e HTTP/3).

Além disso, você precisa garantir 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) de confiança pública 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, será necessário criar uma origem com o originAddress definido como esse nome.

Console

1. No console do Google Cloud, acesse a página Origens do Media CDN.

   Acesse "Origens"

2. Clique em Criar origem.

3. Insira um nome para a origem. Por exemplo, load-balancer-origin.

4. Opcional: insira uma descrição.

5. Em Endereço de origem, escolha Especificar um endereço FQDN ou IP.

6. Insira o FQDN ou o endereço IP do balanceador de carga do Google Cloud.

7. Opcional: selecione uma origem de failover para tentar, caso ela se torne inacessível. Você pode atualizar esse campo mais tarde.

8. Selecione Condições de nova tentativa.

9. Em Tentativas máximas, selecione o número máximo de tentativas para preencher o cache dessa origem.

10. Opcional: especifique os seguintes valores de tempo limite:

    1. Em Tempo limite de conexão, selecione a duração máxima para aguardar a conexão de origem ser estabelecida.
    2. Em Tempo limite de resposta, selecione a duração máxima para permitir que uma resposta seja concluída.
    3. Em Tempo limite de leitura, selecione a duração máxima de espera entre as leituras de uma única conexão ou stream HTTP.

11. Opcional: clique em Adicionar rótulo e especifique um ou mais pares de chave-valor.

12. 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 o endereço IP, por exemplo, origin-packager.example.com

Se você estiver usando o endereço IP da regra de encaminhamento como o endereço de origem ou não tiver um certificado SSL anexado ao balanceador de carga, 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 de failover da origem.

Failover de origem sem redirecionamento subsequente

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

name: FAILOVER_ORIGIN
originAddress: FAILOVER_DOMAIN_NAME

A CDN de mídia tenta acessar 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 contra o FAILOVER_ORIGIN. Se a origem de failover também não responder, o 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) ainda afeta 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 CDN de mídia tente novamente em caso de 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 falha em FAILOVER_ORIGIN.

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

Failover de origem com redirecionamento

Por exemplo, suponha que você tenha configurado os seguintes recursos EdgeCacheOrigin e que as rotas do recurso EdgeCacheService estejam configuradas para usar 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, 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 uma resposta positiva, o Media CDN vai usar essa resposta para preencher o cache.

Suponha agora que primary.example.com retorne um 302 Found Redirect HTTP para Location: b.example.com. Em seguida, como a segunda tentativa de 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 usará essa resposta para preencher o cache.
• Se b.example.com retornar um redirecionamento ou uma resposta de falha, a CDN de mídia vai falhar para o SecondaryOrigin configurado. Isso ocorre porque, neste exemplo, PrimaryOrigin está configurado para dois maxAttempts.

Se o Media CDN falhar para SecondaryOrigin, ele vai usar a configuração SecondaryOrigin e tentar se conectar a secondary.example.com. Esta é a tentativa 1 de entrar em contato com a origem e a tentativa 3 no geral.

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

• Se secondary.example.com retornar uma resposta bem-sucedida, o Media CDN vai usar essa resposta para preencher o 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, esta é a tentativa 2 para SecondaryOrigin e a tentativa 4 no geral.

Se a tentativa de contato com c.example.com retornar uma resposta bem-sucedida, o Media CDN vai usar essa resposta para preencher o cache. Se a tentativa retornar um redirecionamento que o Media CDN está configurado para seguir, ele retornará um erro HTTP 502 Bad Gateway porque esgotou 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, independente das configurações de EdgeCacheOrigin. Por fim, se o Media CDN não conseguir entrar em contato com o c.example.com, ele vai retornar uma resposta 504 Gateway Timeout ou 502 Bad Gateway.

Se você precisar de verificação de integridade, round-robin ou direcionamento sensível à carga em origens, configure um balanceador de carga de aplicativo externo como a origem principal.

Configurar os redirecionamentos de origem a seguir

O Media CDN oferece suporte aos redirecionamentos retornados pela origem de forma interna durante o preenchimento do cache, em vez de retornar respostas de redirecionamento diretamente ao cliente. Quando o Media CDN está 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. O Media CDN segue redirecionamentos entre domínios.

Aviso: configurar redirecionamentos de um serviço de origem não confiável ou controlado por um invasor pode expor a configuração do CDN de mídia a vulnerabilidades de redirecionamento abertas.

Como prática recomendada, configure o redirecionamento de origem apenas para origens em que você confia e controla. Confie em todas as origens em uma cadeia de redirecionamento, porque cada origem produz conteúdo veiculado pelo EdgeCacheService.

Para ativar os 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 Media CDN usa o protocolo especificado nos redirecionamentos para alcançar todos os servidores. Verifique se todos os servidores que a Media CDN pode redirecionar são compatíveis com os protocolos necessários. Especificamente, 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 de host enviado para a origem redirecionada corresponde ao URL redirecionado. O Media CDN segue um único redirecionamento por tentativa EdgeCacheOrigin antes de retornar a resposta final ou avaliar as condições de repetição ou failover.

A configuração redirectConditions especifica quais códigos de resposta HTTP fazem com que o Media CDN siga 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

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

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

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 anexam cabeçalhos existentes do mesmo nome de campo. Por padrão, o Media CDN é anexado aos cabeçalhos existentes. Para substituir cabeçalhos atuais, defina headerAction.replace como true.

Para saber como definir cabeçalhos de solicitação por rota, consulte Definir cabeçalhos personalizados.

Como resolver problemas de origem

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

A seguir

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