Configura un origen

Puedes configurar orígenes para Media CDN de muchas maneras. En esta página, se muestra cómo configurar orígenes.

Configura un bucket de Cloud Storage como origen

Media CDN admite buckets de Cloud Storage como backends para contenido. Cada servicio puede hacer referencia a varios buckets configurando rutas para el host, las rutas de acceso y otros atributos de la solicitud.

Los buckets de Cloud Storage se configuran con la URL del bucket, como gs://my-bucket, como la dirección de origen cuando se crea un recurso de origen.

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

Esto es lo mismo si el bucket es multirregional, birregional o regional.

Cuando configuras un servicio, puedes enrutar tu contenido de video on demand a un bucket y transmitir contenido en vivo a un segundo bucket. Esto es útil si tienes equipos diferentes que administran cada flujo de trabajo. Para reducir la latencia de llenado de caché, puedes enrutar de manera similar la región eu-media.example.com a un bucket de Cloud Storage multirregional ubicado en la UE y la región us-media.example.com (o hacer coincidir la ruta, el encabezado o el parámetro de consulta) a un bucket de almacenamiento ubicado en EE.UU.

Para los casos en los que la latencia de escritura es crítica, como la transmisión en vivo de latencia baja, puedes configurar un extremo regional de Cloud Storage lo más cerca posible de tus usuarios.

Autentica solicitudes

Para confirmar que una solicitud proviene de Media CDN, usa uno de los siguientes enfoques compatibles:

• Valida que la dirección IP de conexión sea de los rangos de llenado de caché de Media CDN. Estos rangos se comparten entre todos los clientes, pero siempre los usan los recursos de EdgeCacheService cuando se conectan a un origen.
• Agrega un encabezado de solicitud personalizado con un valor de token que valides en el origen (por ejemplo, un valor aleatorio de 16 bytes). Tu origen puede rechazar solicitudes que no incluyen este valor.

Configura un protocolo de origen

Si tu origen admite HTTP/2, no necesitas configurar el protocolo explícitamente. Para orígenes que solo admiten HTTPS (HTTP/1.1 a través de TLS) o HTTP/1.1 (sin TLS), configura el campo protocol de manera explícita con los siguientes pasos:

gcloud edge-cache origins update LEGACY_ORIGIN \
    --protocol=HTTPS

Configura buckets privados de Cloud Storage

Media CDN puede extraer contenido de cualquier extremo HTTP o HTTPS accesible a través de Internet. En algunos casos, es posible que desees solicitar autenticación para permitir solo que Media CDN extraiga contenido y evite el acceso no autorizado. Cloud Storage lo admite a través de los permisos de IAM.

Para los orígenes de Cloud Storage, haz lo siguiente:

• Otorga a la cuenta de servicio de Media CDN el permiso objectViewer de IAM en los buckets de Cloud Storage que usas como orígenes.
• Quita el permiso allUsers.
• Opcional: Quita el permiso allAuthenticatedUsers.

Para cambiar los permisos de un bucket de Cloud Storage, necesitas el rol de administrador de almacenamiento (roles/storage.admin).

La cuenta de servicio de Media CDN es propiedad del proyecto de Media CDN y no aparecerá en la lista de cuentas de servicio de tu proyecto. La cuenta de servicio solo otorga acceso a los recursos de Media CDN en los proyectos que permites de forma explícita.

Debes crear al menos un recurso de Media CDN para activar la creación de la cuenta de servicio. En la mayoría de los casos, este es el recurso EdgeCacheOrigin conectado a tu bucket de Cloud Storage.

Para otorgar acceso a la CDN de Media a un bucket, otorga el rol objectViewer a la cuenta de servicio:

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

Reemplaza PROJECT_NUMBER por el número del proyecto.

Antes de quitar el acceso público a un bucket de almacenamiento existente que se usa como origen de producción, permite que la configuración se propague durante al menos 10 minutos.

Usa el comando gcloud storage buckets remove-iam-policy-binding para quitar los permisos otorgados al rol allUsers para el bucket determinado. Por ejemplo, si el bucket otorga el rol objectViewer a allUsers, quita el otorgamiento con el siguiente comando:

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

Para validar que se quitó el acceso público, abre una ventana del navegador de incógnito y, luego, intenta acceder a un objeto de bucket con https://storage.googleapis.com/BUCKET/object.ext.

Para permitir que los recursos de EdgeCacheService dentro de un proyecto accedan a un bucket de Cloud Storage en otro proyecto, puedes otorgar a la cuenta de servicio de Media CDN en ese proyecto acceso al bucket de almacenamiento.

Para ello, verifica que PROJECT_NUM en service-PROJECT_NUM@gcp-sa-mediaedgefill.iam.gserviceaccount.com sea el número de proyecto con los recursos de EdgeCacheService que necesitan acceso. Puedes repetir este proceso para varios proyectos, en especial si algunos de ellos alojan diferentes entornos de Media CDN (como desarrollo, etapa de pruebas o producción) y un proyecto independiente contiene tus recursos de video o multimedia.

Puedes proteger el acceso a tu origen de Cloud Storage sin habilitar las solicitudes firmadas para esa ruta.

Configurar Cloud Storage privado no evita que se acceda a tu contenido almacenado en caché directamente desde Media CDN. Para obtener información sobre cómo emitir solicitudes firmadas a usuarios individuales, consulta Solicitudes firmadas.

Configura un balanceador de cargas de aplicaciones externo como origen

Si necesitas una verificación de estado activa, un round robin o una dirección que tome en cuenta la carga en Compute Engine, GKE o en los orígenes locales, puedes configurar un balanceador de cargas de aplicaciones externo como origen.

Esto te permite configurar (por ejemplo) tus empaquetadores de transmisión en vivo detrás de Media CDN o un grupo de proxies de Envoy administrados por Cloud Service Mesh para volver a conectarte a tu infraestructura local.

Los balanceadores de cargas te permiten configurar backends para lo siguiente:

• Grupos de instancias de máquinas virtuales (VM) de Compute Engine
• Grupos de extremos de red (incluidas las VM de Compute Engine y los clústeres de Google Kubernetes Engine).
• Grupos de extremos de red sin servidores (Cloud Run, App Engine y funciones de Cloud Run).

Una arquitectura que combina un origen de balanceador de cargas de aplicaciones externo para entregar manifiestos de video y un origen de Cloud Storage para el almacenamiento de segmentos se asemeja a la siguiente, con dos orígenes asignados a diferentes rutas.

Para configurar un balanceador de cargas de aplicaciones externo como origen, debes crear un recurso de origen con la dirección IP o el nombre de host público que apunte a tus reglas de reenvío del balanceador de cargas. Se prefiere un nombre de host público (nombre de dominio), ya que esto es necesario para un certificado SSL (TLS) y para versiones HTTP modernas (HTTP/2 y HTTP/3).

También debes confirmar lo siguiente:

• El balanceador de cargas tiene una ruta que coincide con el nombre de host que se usa para tu recurso EdgeCacheService, o bien configuraste un urlRewrite.hostRewrite para las rutas en las que el balanceador de cargas está configurado como el origen.
• Tu balanceador de cargas tiene un certificado SSL (TLS) de confianza pública configurado para estos nombres de host.

Por ejemplo, si el nombre de dominio público que apunta a la regla de reenvío de tu balanceador de cargas es origin-packager.example.com, debes crear un origen con el originAddress configurado como este nombre.

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

Si usas la dirección IP de la regla de reenvío como dirección de origen o no tienes un certificado SSL adjunto al balanceador de cargas, puedes configurar el protocolo como HTTP para volver a no estar encriptado. Solo recomendamos que lo hagas para fines de desarrollo o prueba.

Configura una región para la protección flexible

Puedes configurar una región para el protección flexible cuando creas o actualizas un origen.

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

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

Configura la conmutación por error del origen

En las siguientes secciones, se muestra cómo configurar el comportamiento de conmutación por error del origen.

Conmutación por error de origen sin redireccionamiento

La siguiente es una configuración básica de conmutación por error EdgeCacheOrigin:

name: FAILOVER_ORIGIN
originAddress: FAILOVER_DOMAIN_NAME

Media CDN vuelve a intentar el origen principal de la ruta un máximo de tres veces antes de intentar un origen de conmutación por error. En esta configuración, después de probar el origen principal tres veces, Media CDN intenta realizar una sola solicitud con el FAILOVER_ORIGIN. Si el origen de conmutación por error tampoco responde correctamente, Media CDN muestra la respuesta completa del origen o, si no se recibe ningún código de estado, una respuesta HTTP 502 Bad Gateway.

La latencia de llenado de caché aumenta con la cantidad de reintentos y eventos de conmutación por error. Aumentar los valores de tiempo de espera de origen (como connectTimeout) afecta aún más la latencia de llenado de caché, ya que aumenta el tiempo de espera de que responda un servidor de origen sobrecargado o ocupado.

En el ejemplo siguiente, se muestra una configuración que envía solicitudes de relleno a MY_ORIGIN. La configuración hace que Media CDN vuelva a intentar los errores de conexión (como los errores de DNS, TCP o TLS), las respuestas HTTP 5xx del origen o HTTP 404 Not Found. Después de dos intentos, la conmutación por error pasa a FAILOVER_ORIGIN.

Se realiza un máximo de cuatro intentos en todos los orígenes configurados: el intento original más hasta tres intentos de reintento. Puedes configurar un valor maxAttempts por origen para determinar cuántos reintentos se realizan antes de intentar la conmutación por error.

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

Conmutación por error de origen con redireccionamiento a continuación

Por ejemplo, supongamos que configuraste los siguientes recursos EdgeCacheOrigin y que las rutas de tus recursos EdgeCacheService están configuradas para usar PrimaryOrigin para el llenado de caché:

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]

En este ejemplo, cuando Media CDN realiza un llenado de caché, lee la configuración de PrimaryOrigin y responde según corresponda.

Supongamos que Media CDN se conecta a primary.example.com como el intento #1 para contactar al origen. Si primary.example.com muestra una respuesta correcta, Media CDN usa esa respuesta para el llenado de caché.

Supongamos que primary.example.com muestra un 302 Found Redirect HTTP en Location: b.example.com. Luego, como el intento #2 para comunicarte con el origen, Media CDN sigue el redireccionamiento a b.example.com. En este caso, Media CDN hace lo siguiente:

• Si b.example.com muestra una respuesta correcta, Media CDN usa esa respuesta para el llenado de caché.
• Si b.example.com muestra un redireccionamiento o una respuesta de falla, Media CDN conmuta por error al SecondaryOrigin configurado. Esto se debe a que, en este ejemplo, PrimaryOrigin está configurado para dos maxAttempts.

Si Media CDN conmuta por error a SecondaryOrigin, Media CDN usa la configuración SecondaryOrigin y, luego, intenta conectarse a secondary.example.com. Este es el intento #1 para comunicarse con el origen y el intento #3 en general.

En este caso, Media CDN hace lo siguiente:

• Si secondary.example.com muestra una respuesta correcta, Media CDN usa esa respuesta para el llenado de caché.
• Si secondary.example.com devuelve un 302 Found Redirect HTTP a Location: c.example.com, Media CDN intenta comunicarse con c.example.com. En este ejemplo, este es el intento #2 para SecondaryOrigin y el intento #4 en general.

Si el intento de contactar a c.example.com muestra una respuesta correcta, Media CDN usa esa respuesta para el llenado de caché. Si el intento muestra un redireccionamiento que la CDN de medios está configurada para seguir, Media CDN muestra un código de estado HTTP 502 Bad Gateway porque se agotó el máximo de intentos de comunicarse con un origen. Media CDN realiza como máximo cuatro intentos en todos los orígenes, sin importar la configuración EdgeCacheOrigin. Por último, si Media CDN no puede comunicarse con c.example.com, Media CDN muestra una respuesta 504 Gateway Timeout o una respuesta 502 Bad Gateway.

Si necesitas verificaciones de estado, round robin o dirección de reconocimiento de carga en los orígenes, puedes configurar un balanceador de cargas de aplicaciones externo como origen principal.

Configura los siguientes redireccionamientos de origen

Media CDN admite los siguientes redireccionamientos que muestra tu origen de forma interna durante el llenado de caché, en lugar de mostrar respuestas de redireccionamiento directamente al cliente. Cuando Media CDN está configurada para seguir los redireccionamientos de origen, este servicio recupera el contenido de la ubicación de redireccionamiento antes de almacenar en caché y mostrar la respuesta redireccionada al cliente. Media CDN sigue los redireccionamientos en todos los dominios.

Como práctica recomendada, configura el redireccionamiento de origen solo para orígenes que confíes y controles. Asegúrate de confiar en cada origen en una cadena de redireccionamiento, ya que cada origen produce contenido que entrega tu EdgeCacheService.

Para habilitar los siguientes redireccionamientos de origen, agrega la siguiente configuración a tu recurso EdgeCacheOrigin:

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

Media CDN usa el protocolo especificado en los redireccionamientos para llegar a todos los servidores. Confirma que todos los servidores a los que se pueda redireccionar Media CDN admitan los protocolos que necesitas. En particular, si el protocolo se configura en HTTPS, HTTP/2 o HTTP/3, la CDN de Media no recurre a conexiones HTTP/1.1 para seguir redireccionamientos no seguros. El encabezado del host que se envía al origen redireccionado coincide con la URL redireccionada. Media CDN sigue un solo redireccionamiento por cada intento EdgeCacheOrigin antes de mostrar la respuesta final o evaluar las condiciones de reintento o conmutación por error.

La configuración redirectConditions especifica qué códigos de respuesta HTTP hacen que Media CDN siga un redireccionamiento para cada origen.

Configura reescrituras del host o modificaciones de encabezado específicas del origen

Si tu origen requiere una reescritura del host o una modificación del encabezado específicos del origen, usa el siguiente ejemplo de configuración originOverrideAction para configurarlos:

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

El parámetro de configuración originOverrideAction.hostRewrite tiene prioridad sobre cualquier reescritura de encabezado existente configurada en rutas que apuntan a este origen.

Puedes usar encabezados requestHeadersToAdd únicos por origen que solicite ese origen en particular. Un caso práctico común agrega encabezados Authorization estáticos. Debido a que estas manipulaciones de encabezados se ejecutan durante la solicitud de origen, los encabezados agregados por origen reemplazan o agregan a los encabezados existentes del mismo nombre de campo. De forma predeterminada, Media CDN adjunta a los encabezados existentes. Para reemplazar encabezados existentes, configura headerAction.replace en true.

Para obtener información sobre cómo configurar los encabezados de solicitud por ruta, consulta Cómo establecer encabezados personalizados.

Solución de problemas relacionados con los orígenes

Si un origen no se comporta como se espera, consulta cómo solucionar problemas de orígenes.

¿Qué sigue?

• Usa un bucket privado compatible con Amazon S3 como origen
• Configura rutas de servicio