Configura un origen

Puedes configurar los orígenes de Media CDN de muchas maneras. En esta página, se muestra cómo configurar los 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 mediante la configuración de 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.

Console

1. En la consola de Google Cloud, ve a la página Orígenes de Media CDN.

   Ir a Orígenes

2. Haz clic en Crear origen.

3. Ingresa un nombre para el origen. Por ejemplo: cloud-storage-origin.

4. Opcional: Ingresa una descripción.

5. En Dirección de origen, selecciona Seleccionar un bucket de Google Cloud Storage.

6. Navega a tu bucket de Cloud Storage y selecciónalo.

7. Para Cloud Storage, conserva la configuración de puerto y protocolo predeterminada.

8. Opcional: Para que las anulaciones de encabezados de solicitud de origen tengan prioridad sobre los encabezados que envía el cliente o que manipulan las acciones de encabezados a nivel de la ruta, haz lo siguiente:

   1. Selecciona Habilitar la anulación de origen.
   2. En la sección Encabezados, especifica los encabezados agregando uno o más parejas nombre-valor.

9. Opcional: Selecciona un origen de conmutación por error en caso de que no se pueda acceder a este. Puedes actualizar este campo más adelante.

10. Selecciona condiciones de redireccionamiento.

11. Selecciona reintentar las condiciones.

12. En Cantidad máxima de intentos, selecciona la cantidad máxima de intentos para llenar la caché desde este origen.

13. Opcional: Especifica los siguientes valores de tiempo de espera:

    1. En Tiempo de espera de Connect, selecciona la duración máxima a fin de esperar que se establezca la conexión de origen.
    2. En Tiempo de espera de la respuesta, selecciona la duración máxima para permitir que se complete una respuesta.
    3. En Tiempo de espera de lectura, selecciona la duración máxima para esperar entre las lecturas de una sola conexión HTTP o transmisión.

14. Opcional: Haz clic en Agregar etiqueta y especifica uno o más pares clave-valor.

15. Haz clic en Crear origen.

gcloud

Usa el comando gcloud edge-cache origins create:

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

Reemplaza lo siguiente:

• ORIGIN: Es el nombre del origen nuevo.
• ADDRESS: El nombre del bucket, por ejemplo, gs://my-bucket

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 diferentes equipos 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.

Importante: Te recomendamos que uses un bucket multirregional para el almacenamiento de origen, ya que proporciona mayor redundancia geográfica para los objetos almacenados.

Buckets de Media CDN (haz clic para ampliar).

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

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 mediante los siguientes pasos:

Console

1. En la consola de Google Cloud, ve a la página Orígenes de Media CDN.

   Ir a Orígenes

2. Selecciona tu origen y haz clic en Editar.

3. En el protocolo, selecciona HTTPS o HTTP. Para HTTP, especifica también el puerto como 80.

4. Haz clic en Actualizar origen.

gcloud

Usa el comando gcloud edge-cache origins update:

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

Si tu origen admite HTTP/2, no necesitas configurar el protocolo de forma explícita.

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.

Importante: Para las rutas que están asociadas a un origen privado de Cloud Storage, establece el modo de almacenamiento en caché en FORCE_CACHE_ALL. De lo contrario, se evita el almacenamiento en caché porque los buckets privados de Cloud Storage establecen un encabezado cache-control: private.

Para 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 origen.
• Quita el permiso allUsers.
• Opcional: Quita el permiso allAuthenticatedUsers.

Para cambiar los permisos de un bucket de Cloud Storage, necesitas el rol de IAM de administrador de almacenamiento.

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 tiene el siguiente formato y otorga acceso solo a los recursos de Media CDN en los proyectos que permites de forma explícita.

[e-mail]

Nota: 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:[e-mail] \
--role=roles/storage.objectViewer

Nota: Espera al menos 10 minutos para que la configuración se propague, antes de quitar el acceso público a un bucket de almacenamiento existente que se usa como origen de producción.

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 a allUsers el rol objectViewer, quita la otorgación 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 mediante https://storage.googleapis.com/BUCKET/object.ext.

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

Para ello, asegúrate de que PROJECT_NUM en [e-mail] sea el número de proyecto con los recursos EdgeCacheService que necesitan acceso. Puedes repetir esto para varios proyectos, en especial si algunos de ellos albergan 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 paquetes 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 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 al siguiente, con dos orígenes asignados a diferentes rutas.

Implementación de almacenamiento en caché perimetral (haz clic para ampliar).

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 asegurarte de lo siguiente:

• El balanceador de cargas tiene una ruta que coincide con el nombre de host que se usa para tu recurso EdgeCacheService o que configuraste un urlRewrite.hostRewrite para las rutas en las que el balanceador de cargas está configurado como el origen.
• Que tu balanceador de cargas tenga 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.

Console

1. En la consola de Google Cloud, ve a la página Orígenes de Media CDN.

   Ir a Orígenes

2. Haz clic en Crear origen.

3. Ingresa un nombre para el origen. Por ejemplo: load-balancer-origin.

4. Opcional: Ingresa una descripción.

5. En Dirección de origen, selecciona Especificar un FQDN o una dirección IP.

6. Ingresa el FQDN o la dirección IP para tu balanceador de cargas de Google Cloud.

7. Opcional: Selecciona un origen de conmutación por error en caso de que no se pueda acceder a este. Puedes actualizar este campo más adelante.

8. Selecciona reintentar las condiciones.

9. En Cantidad máxima de intentos, selecciona la cantidad máxima de intentos para llenar la caché desde este origen.

10. Opcional: Especifica los siguientes valores de tiempo de espera:

    1. En Tiempo de espera de Connect, selecciona la duración máxima a fin de esperar que se establezca la conexión de origen.
    2. En Tiempo de espera de la respuesta, selecciona la duración máxima para permitir que se complete una respuesta.
    3. En Tiempo de espera de lectura, selecciona la duración máxima para esperar entre las lecturas de una sola conexión HTTP o transmisión.

11. Opcional: Haz clic en Agregar etiqueta y especifica uno o más pares clave-valor.

12. Haz clic en Crear origen.

gcloud

Usa el comando gcloud edge-cache origins create:

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

Reemplaza lo siguiente:

• LB_ORIGIN: Es el nombre del origen.
• LB_ADDRESS: Es el FQDN o la dirección IP, por ejemplo, origin-packager.example.com.

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 la conmutación por error del origen

En las siguientes secciones, se muestra cómo configurar el comportamiento de conmutación por error de 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 la conmutación por error tampoco responde correctamente, Media CDN muestra 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 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), HTTP 5xx de 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 a Location: b.example.com. Luego, como el intento #2 para comunicarse 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 muestra un HTTP 302 Found Redirect 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 error 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.

Advertencia: La configuración de redireccionamientos desde un servicio de origen no confiable o controlado por un atacante puede exponer tu configuración de Media CDN a fin de abrir vulnerabilidades de redireccionamiento.

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. Asegúrate de que todos los servidores que Media CDN pueda redireccionarse para admitir los protocolos requeridos. 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.

Condición	Descripción
MOVED_PERMANENTLY	Sigue el redireccionamiento para el código de respuesta HTTP 301
FOUND	Sigue el redireccionamiento para el código de respuesta HTTP 302
SEE_OTHER	Sigue el redireccionamiento para el código de respuesta HTTP 303
TEMPORARY_REDIRECT	Sigue el redireccionamiento para el código de respuesta HTTP 307
PERMANENT_REDIRECT	Sigue el redireccionamiento para el código de respuesta HTTP 308

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

Si tu origen requiere una reescritura del host específica de origen o alguna otra modificación de encabezado específico 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

La configuración de 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 Establece encabezados personalizados.

Cómo solucionar problemas de 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