Configura un origen

Puedes configurar orígenes para Media CDN de muchas maneras. En esta página, se muestra te enseñaremos a configurar orígenes.

Configura un bucket de Cloud Storage como origen

Media CDN admite buckets de Cloud Storage como backends para el contenido. Cada servicio puede hacer referencia a varios buckets configurando rutas para host, 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. Ingresa una descripción (opcional).

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

6. Navega hasta 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 del encabezado de la solicitud de origen tengan prioridad sobre encabezados enviados por el cliente o manipulados por acciones de encabezados a nivel de ruta haz lo siguiente:

   1. Selecciona Habilitar anulación de origen.
   2. En la sección Encabezados, agrega uno o varios encabezados para especificar los encabezados. nombre-valor.

9. Opcional: Selecciona un origen de conmutación por error para probar en caso de que este sea el siguiente inaccesible. Puedes actualizar este campo más adelante.

10. Selecciona las condiciones de redireccionamiento.

11. Selecciona reintentar las condiciones.

12. En Máx. de intentos, selecciona la cantidad máxima de intentos para completar la caché desde este origen.

13. Opcional: Especifica el siguiente tiempo de espera valores:

    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: Es el nombre del bucket, por ejemplo, gs://my-bucket.

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

Cuando configuras un servicio, puedes enrutar tu contenido de video on demand a un bucket y la transmisión de contenido en vivo a un segundo bucket. Esto es útil si tienes y equipos diferentes 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 servicio multirregional Bucket de Cloud Storage ubicado en la UE y us-media.example.com región (o coincidencia en la ruta de acceso, encabezado o parámetro de búsqueda) con un almacenamiento de EE.UU. bucket.

Importante: Te recomendamos que uses un bucket multirregional para el almacenamiento de origen, ya que un bucket multirregional proporciona más 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 la solicitud proviene de Media CDN, usa uno de los siguientes enfoques admitidos:

• Valida que la dirección IP de conexión sea de Media CDN los rangos de relleno de caché. Estos rangos se comparten entre todos los clientes, pero son Los recursos EdgeCacheService siempre lo usan cuando se conectan a un origen.
• Agrega un encabezado de solicitud personalizado con un valor de token que puedas validar en el origen (por ejemplo, un valor aleatorio de 16 bytes). De esta manera, el origen podrá rechazar las solicitudes que no incluyen este valor.

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

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 forma explícita de la siguiente manera:

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, también especifica 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 establecer el protocolo de forma explícita.

Configura buckets privados de Cloud Storage

Media CDN puede extraer contenido de cualquier HTTP o HTTPS al que se pueda acceder a Internet extremo. En algunos casos, podrías necesitar autenticación para solo permite que Media CDN extraiga contenido y evita que access. Cloud Storage lo admite a través de los permisos de IAM.

Importante: Para rutas que están asociadas con un bucket privado de Cloud Storage origen, 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 los orígenes de Cloud Storage, haz lo siguiente:

• Otorga objectViewer a la cuenta de servicio de Media CDN. permiso de IAM en los buckets de Cloud Storage usan como tus 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 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 Recursos de Media CDN en los proyectos que permitas de forma explícita

[e-mail]

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

Para que Media CDN pueda acceder a un bucket, otorga el permiso objectViewer. a la cuenta de servicio:

gsutil iam ch \
serviceAccount:[e-mail]:objectViewer gs://BUCKET

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

Para quitar todos los permisos de la función allUsers del bucket determinado, ejecuta el siguiente comando: siguiente comando:

gsutil iam ch -d allUsers gs://BUCKET

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

Para permitir el acceso de EdgeCacheService recursos dentro de un proyecto a un bucket de Cloud Storage en otro proyecto, puedes otorgarle La cuenta de servicio de Media CDN de ese proyecto tiene acceso al almacenamiento. bucket.

Para ello, asegúrate de que PROJECT_NUM en [e-mail] es el el número del proyecto con los EdgeCacheService recursos que necesitan access. Puedes repetir esto para varios proyectos, especialmente si algunos de ellos alojar diferentes entornos de Media CDN (como desarrollo, etapa de pruebas o producción) y un proyecto independiente que contenga tu video o contenido multimedia activos de datos de una empresa.

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

Configurar el almacenamiento privado de Cloud Storage no impide que se almacene el contenido almacenado en caché contra el acceso directo desde Media CDN. Para obtener información sobre cómo emitir solicitudes firmadas a usuarios individuales, consulta Solicitudes firmadas.

Configurar un balanceador de cargas de aplicaciones externo como origen

Si necesitas verificación de estado activa, round robin o direccionamiento adaptado a la carga en Compute Engine, GKE o orígenes locales, puedes configurar un balanceador de cargas de aplicaciones externo como origen.

Esto te permite configurar (por ejemplo) tus empaquetadores de transmisiones en vivo Media CDN o un grupo de Proxies de Envoy administrados por Cloud Service Mesh para volver a conectarte a la 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 Cloud Functions).

Una arquitectura que combina un origen de balanceador de cargas de aplicaciones externo para entregar videos manifiestos y un origen de Cloud Storage para el almacenamiento de segmentos se parece como se muestra a continuación, con dos orígenes asignados a rutas diferentes.

Implementación de 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 tu las 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).

Además, debes asegurarte de que se cumpla lo siguiente:

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

Por ejemplo, si el nombre de dominio público apuntado abalanceador de cargass de tu regla de reenvío es origin-packager.example.com, debes crear una origen con el originAddress configurado con este nombre.

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. Ingresa una descripción (opcional).

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 para probar en caso de que este sea el siguiente inaccesible. Puedes actualizar este campo más adelante.

8. Selecciona reintentar las condiciones.

9. En Máx. de intentos, selecciona la cantidad máxima de intentos para completar la caché desde este origen.

10. Opcional: Especifica el siguiente tiempo de espera valores:

    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 IP. dirección, por ejemplo, origin-packager.example.com

Si usas la dirección IP de tu regla de reenvío como dirección de origen, o no tienes un certificado SSL adjunto a tu balanceador de cargas, puedes configura el protocolo en HTTP para recurrir a conexiones no encriptadas. Recomendaciones que hagan esto solo para el desarrollo o las pruebas.

Configura la conmutación por error de origen

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

Conmutación por error de origen sin redireccionamiento después de

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 con un máximo de tres veces antes de intentar un origen de conmutación por error. En esta configuración, luego de intentar desde el origen principal tres veces, Media CDN intenta un solo al FAILOVER_ORIGIN. Si el botón origen de conmutación por error tampoco responde correctamente, entonces Media CDN devuelve la respuesta de origen completa o, si no hay ninguna. se recibe un 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 para reintentar los errores de conexión (como DNS, TCP o errores de TLS), respuestas HTTP 5xx del origen o HTTP 404 Not Found Después de dos intentos, se conmuta por error 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 de intentos de 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

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

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

A continuación, se muestra una configuración completa:

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

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

En el ejemplo anterior, la configuración originOverrideAction.hostRewrite toma prioridad sobre cualquier reescritura de encabezado existente que se configuran en las 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.

Conmutación por error de origen con redireccionamiento siguiente

Por ejemplo, supongamos que configuraste los siguientes EdgeCacheOrigin recursos y de que las rutas de tu recurso EdgeCacheService estén configuradas como Usa 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 ahora que primary.example.com muestra un 302 Found Redirect HTTP a Location: b.example.com. En el segundo intento de contactar al 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 se configuró 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. c.example.com En este ejemplo, el segundo intento para SecondaryOrigin y el cuarto intento 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 devuelve un redireccionamiento que Media CDN debe seguir según la configuración. Media CDN devuelve un error HTTP 502 Bad Gateway porque ha agotado la cantidad máxima de intentos para comunicarse con un origen. Media CDN realiza, como máximo, cuatro intentos en todos los orígenes, independientemente de la configuración de EdgeCacheOrigin. Por último, si Media CDN no puede comunicarse con c.example.com. Media CDN muestra una respuesta 504 Gateway Timeout o una Respuesta de 502 Bad Gateway.

Si necesitas verificación de estado, round robin o direccionamiento adaptado a la carga en de origen, puedes configurar una balanceador de cargas de aplicaciones externo como principal origen.

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 todos los servidores. Asegúrate de que todos los servidores a los que se pueda para admitir los protocolos necesarios. 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	Seguir el redireccionamiento para el código de respuesta HTTP 301
FOUND	Seguir el redireccionamiento para el código de respuesta HTTP 302
SEE_OTHER	Seguir el redireccionamiento para el código de respuesta HTTP 303
TEMPORARY_REDIRECT	Seguir el redireccionamiento para el código de respuesta HTTP 307
PERMANENT_REDIRECT	Seguir el redireccionamiento para el código de respuesta HTTP 308

Soluciona problemas de 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