Configurar un origen

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

Configurar un segmento de Cloud Storage como origen

Media CDN admite segmentos de Cloud Storage como backends de contenido. Cada servicio puede hacer referencia a varios segmentos configurando rutas para hosts, rutas y otros atributos de solicitud.

Los segmentos de Cloud Storage se configuran mediante la URL del segmento, como gs://my-bucket, como dirección de origen al crear un recurso de origen.

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

Esto es igual tanto si el segmento es multirregional, birregional o regional.

Al configurar un servicio, puede dirigir su contenido de vídeo a la carta a un contenedor y el contenido de emisión en directo a otro. Esto resulta útil si tienes diferentes equipos que gestionan cada flujo de trabajo. Para reducir la latencia de llenado de la caché, puedes enrutar de forma similar la región eu-media.example.com a un segmento 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 segmento de almacenamiento ubicado en EE. UU.

En los casos en los que la latencia de escritura es fundamental, como en la emisión en directo con baja latencia, puedes configurar un endpoint regional de Cloud Storage lo más cerca posible de tus usuarios.

Autenticar solicitudes

Para confirmar que una solicitud procede de Media CDN, usa uno de los siguientes métodos admitidos:

• Valida que la dirección IP de conexión proceda de los intervalos de relleno de caché de Media CDN. Estos intervalos se comparten entre todos los clientes, pero los recursos de EdgeCacheService siempre los utilizan al conectarse a un origen.
• Añade un encabezado de solicitud personalizado con un valor de token que valides en el origen (por ejemplo, un valor aleatorio de 16 bytes). De esta forma, tu origen puede rechazar las solicitudes que no incluyan este valor.

Configurar un protocolo de origen

Si tu origen admite HTTP/2, no es necesario que definas el protocolo de forma explícita. En el caso de los orígenes que solo admiten HTTPS (HTTP/1.1 a través de TLS) o HTTP/1.1 (sin TLS), define el campo protocol explícitamente de la siguiente manera:

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

Configurar segmentos privados de Cloud Storage

Media CDN puede extraer contenido de cualquier endpoint HTTP o HTTPS accesible a través de Internet. En algunos casos, puede que quiera requerir autenticación para permitir que solo Media CDN extraiga contenido y evitar el acceso no autorizado. Cloud Storage admite esta función mediante permisos de gestión de identidades y accesos.

En el caso de los orígenes de Cloud Storage, haz lo siguiente:

• Concede a la cuenta de servicio de Media CDN el objectViewerpermiso de gestión de identidades y accesos (IAM) en los segmentos de Cloud Storage que utilices como orígenes.
• Quita el permiso allUsers.
• Opcional: Quita el permiso allAuthenticatedUsers.

Para cambiar los permisos de un segmento de Cloud Storage, necesitas el rol Administrador de Storage (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 concede acceso a los recursos de Media CDN de los proyectos a los que le des permiso explícitamente.

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, se trata del recurso EdgeCacheOrigin conectado a tu segmento de Cloud Storage.

Para conceder acceso a Media CDN a un segmento, asigna 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

Sustituye PROJECT_NUMBER por el número del proyecto.

Antes de quitar el acceso público a un segmento de almacenamiento que se use como origen de producción, espera al menos 10 minutos para que se propague la configuración.

Usa el comando gcloud storage buckets remove-iam-policy-binding para quitar los permisos concedidos al rol allUsers en el segmento en cuestión. Por ejemplo, si el segmento concede el rol objectViewer a allUsers, quita la concesión con el siguiente comando:

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

Para comprobar que se ha retirado el acceso público, abre una ventana de incógnito del navegador e intenta acceder a un objeto de un segmento mediante https://storage.googleapis.com/BUCKET/object.ext.

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

Para ello, comprueba que PROJECT_NUM en service-PROJECT_NUM@gcp-sa-mediaedgefill.iam.gserviceaccount.com sea el número de proyecto del proyecto con los recursos EdgeCacheService que necesiten acceso. Puedes repetir este proceso con varios proyectos, sobre todo si algunos de ellos alojan diferentes entornos de Media CDN (como desarrollo, staging o producción) y otro proyecto contiene tus recursos de vídeo o multimedia.

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

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

Configurar un balanceador de carga de aplicaciones externo como origen

Si necesitas comprobaciones de estado activas, round-robin o direccionamiento con reconocimiento de carga en orígenes de Compute Engine, GKE o locales, puedes configurar un balanceador de carga de aplicaciones externo como origen.

De esta forma, puedes configurar, por ejemplo, tus empaquetadores de streaming en directo detrás de Media CDN o un grupo de proxies de Envoy gestionados por Cloud Service Mesh para conectarte de nuevo a tu infraestructura local.

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

• Grupos de instancias de máquina virtual (VM) de Compute Engine.
• Grupos de puntos finales de red (incluidas las VMs de Compute Engine y los clústeres de Google Kubernetes Engine).
• Grupos de endpoints de red sin servidor (Cloud Run, App Engine y Cloud Functions).

Una arquitectura que combina un origen de Application Load Balancer externo para publicar manifiestos de vídeo y un origen de Cloud Storage para almacenar segmentos se parece a la siguiente, con dos orígenes asignados a rutas diferentes.

Para configurar un balanceador de carga de aplicación externo como origen, debe crear un recurso de origen con la dirección IP o el nombre de host público que apunte a las reglas de reenvío del balanceador de carga. Es preferible usar un nombre de host público (nombre de dominio), ya que es necesario para obtener un certificado SSL (TLS) y para las versiones HTTP modernas (HTTP/2 y HTTP/3).

También debes confirmar lo siguiente:

• Tu balanceador de carga tiene una ruta que coincide con el nombre de host usado en tu recurso EdgeCacheService o has configurado un urlRewrite.hostRewrite para las rutas en las que tu balanceador de carga está configurado como origen.
• Tu balanceador de carga tiene configurado un certificado SSL (TLS) de confianza pública 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 carga es origin-packager.example.com, debes crear un origen con el valor originAddress definido con este nombre.

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

Si usas la dirección IP de tu regla de reenvío como dirección de origen o no tienes ningún certificado SSL asociado a tu balanceador de carga, puedes definir el protocolo como HTTP para volver a las conexiones sin cifrar. Te recomendamos que solo lo hagas en entornos de desarrollo o de prueba.

Configurar una región para el cifrado flexible

Puede configurar una región para el protección flexible cuando cree o actualice 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

Configurar la conmutación por error del origen

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

Failover de origen sin seguimiento de redirección

A continuación, se muestra una configuración básica de EdgeCacheOrigin:

name: FAILOVER_ORIGIN
originAddress: FAILOVER_DOMAIN_NAME

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

La latencia de relleno de la caché aumenta con el número de reintentos y eventos de conmutación por error. Si aumentas los valores de tiempo de espera del origen (como connectTimeout), la latencia de llenado de la caché se verá aún más afectada, ya que se incrementará el tiempo que se espera a que responda un servidor de origen sobrecargado u ocupado.

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

Se realizan un máximo de cuatro intentos en total en los orígenes configurados: el intento original más un máximo de tres reintentos. Puedes configurar un valor de maxAttempts por origen para determinar cuántos reintentos se realizan antes de intentar conmutar 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 seguimiento de redirección

Por ejemplo, supongamos que ha configurado los siguientes recursos de EdgeCacheOrigin y que las rutas de su recurso EdgeCacheService están configuradas para usar PrimaryOrigin para rellenar la 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 relleno de caché, Media CDN lee la configuración de PrimaryOrigin y responde en consecuencia.

Supongamos que Media CDN se conecta a primary.example.com como intento n.º 1 para ponerse en contacto con el origen. Si primary.example.com devuelve una respuesta correcta, Media CDN usa esa respuesta para rellenar la caché.

Supongamos ahora que primary.example.com devuelve un HTTP 302 Found Redirect a Location: b.example.com. A continuación, en el segundo intento de ponerse en contacto con el origen, Media CDN sigue la redirección a b.example.com. En este caso, Media CDN hace lo siguiente:

• Si b.example.com devuelve una respuesta correcta, Media CDN utiliza esa respuesta para rellenar la caché.
• Si b.example.com devuelve una redirección o una respuesta de error, Media CDN pasa a la SecondaryOrigin configurada. Esto se debe a que, en este ejemplo, PrimaryOrigin está configurado para dos maxAttempts.

Si Media CDN falla y pasa a SecondaryOrigin, Media CDN usa la configuración de SecondaryOrigin e intenta conectarse a secondary.example.com. Este es el primer intento de contactar con el origen y el tercer intento en total.

En este caso, Media CDN hace lo siguiente:

• Si secondary.example.com devuelve una respuesta correcta, Media CDN la usa para rellenar la caché.
• Si secondary.example.com devuelve un HTTP 302 Found Redirect a Location: c.example.com, Media CDN intenta ponerse en contacto con c.example.com. En este ejemplo, es el segundo intento de SecondaryOrigin y el cuarto en total.

Si el intento de contactar con c.example.com devuelve una respuesta correcta, Media CDN usa esa respuesta para rellenar la caché. Si el intento devuelve una redirección que Media CDN está configurada para seguir, Media CDN devuelve un código de estado HTTP 502 Bad Gateway porque ha agotado el número máximo de intentos para ponerse en contacto con un origen. Media CDN hace como máximo cuatro intentos en todos los orígenes, independientemente de las configuraciones de EdgeCacheOrigin. Por último, si Media CDN no puede ponerse en contacto con c.example.com, devuelve una respuesta 504 Gateway Timeout o 502 Bad Gateway.

Si necesitas comprobaciones de estado, round-robin o direccionamiento en función de la carga entre orígenes, puedes configurar un balanceador de carga de aplicación externo como origen principal.

Configurar el seguimiento de redirecciones de origen

Media CDN admite el seguimiento de las redirecciones devueltas por tu origen internamente durante el llenado de la caché, en lugar de devolver las respuestas de redirección directamente al cliente. Cuando Media CDN está configurado para seguir las redirecciones del origen, Media CDN obtiene el contenido de la ubicación de redirección antes de almacenarlo en caché y devolver la respuesta redirigida al cliente. Media CDN sigue las redirecciones entre dominios.

Como práctica recomendada, configura la redirección de origen solo para los orígenes en los que confíes y que controles. Asegúrese de que confía en todos los orígenes de una cadena de redirección, ya que cada origen genera contenido que sirve su EdgeCacheService.

Para habilitar el seguimiento de las redirecciones de origen, añade la siguiente configuración al recurso EdgeCacheOrigin:

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

Media CDN usa el protocolo especificado en las redirecciones para acceder a todos los servidores. Confirma que todos los servidores a los que se pueda redirigir Media CDN admiten los protocolos que necesitas. En concreto, si el protocolo se define como HTTPS, HTTP/2 o HTTP/3, Media CDN no recurre a las conexiones HTTP/1.1 para seguir redirecciones no seguras. El encabezado Host enviado al origen redirigido coincide con la URL redirigida. Media CDN sigue una sola redirección por EdgeCacheOrigin intento antes de devolver la respuesta final o evaluar las condiciones de reintento o de conmutación por error.

El ajuste redirectConditions especifica qué códigos de respuesta HTTP hacen que Media CDN siga una redirección para cada origen.

Configurar reescrituras de host o modificaciones de encabezado específicas de un origen

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

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

El ajuste originOverrideAction.hostRewrite tiene prioridad sobre cualquier reescritura de encabezados configurada en las rutas que apuntan a este origen.

Puedes usar encabezados únicos por origen requestHeadersToAdd solicitados por ese origen concreto. Un caso de uso habitual es añadir encabezados Authorization estáticos. Como estas manipulaciones de encabezados se ejecutan durante la solicitud de origen, los encabezados que se añaden por origen sustituyen o se añaden a los encabezados que ya tengan el mismo nombre de campo. De forma predeterminada, Media CDN añade contenido a las cabeceras. Para sustituir los encabezados, asigna el valor true a headerAction.replace.

Para obtener información sobre cómo definir encabezados de solicitud por ruta, consulta Definir encabezados personalizados.

Solucionar problemas de orígenes

Si un origen no se comporta como esperabas, consulta cómo solucionar problemas con los orígenes.

Siguientes pasos

• Usar un segmento privado compatible con Amazon S3 como origen
• Configurar rutas de servicio