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
En la consola de Google Cloud, ve a la página Origins de Media CDN.
Haz clic en Crear origen.
Ingresa un nombre para el origen. Por ejemplo:
cloud-storage-origin.Ingresa una descripción (opcional).
En Dirección de origen, selecciona Seleccionar un bucket de Google Cloud Storage.
Navega hasta tu bucket de Cloud Storage y selecciónalo.
Para Cloud Storage, conserva la configuración de puerto y protocolo predeterminada.
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:
- Selecciona Habilitar anulación de origen.
- En la sección Encabezados, agrega uno o varios encabezados para especificar los encabezados. nombre-valor.
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.
Selecciona condiciones de redireccionamiento.
Selecciona reintentar las condiciones.
En Máx. de intentos, selecciona la cantidad máxima de intentos para completar la caché desde este origen.
Opcional: Especifica los siguientes valores de tiempo de espera:
- En Tiempo de espera de Connect, selecciona la duración máxima a fin de esperar que se establezca la conexión de origen.
- En Tiempo de espera de la respuesta, selecciona la duración máxima para permitir que se complete una respuesta.
- 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.
Opcional: Haz clic en Agregar etiqueta y especifica uno o más pares clave-valor.
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 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 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
EdgeCacheServicesiempre lo usan 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.
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
En la consola de Google Cloud, ve a la página Origins de Media CDN.
Selecciona tu origen y haz clic en Editar.
En el protocolo, selecciona HTTPS o HTTP. Para HTTP, también especifica el puerto como
80.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 extremo HTTP o HTTPS accesible a través de Internet. En algunos casos, podrías necesitar autenticación para solo permite que Media CDN extraiga contenido y evita que el acceso a los datos. Cloud Storage lo admite a través de los permisos de IAM.
Para los orígenes de Cloud Storage, haz lo siguiente:
- Otorga
objectViewera 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
service-PROJECT_NUM@gcp-sa-mediaedgefill.iam.gserviceaccount.com
Para que Media CDN pueda acceder a un bucket, otorga el permiso 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
Usa el comando gcloud storage buckets remove-iam-policy-binding.
Para quitar los permisos otorgados a la función allUsers del bucket determinado. Para
Por ejemplo, si el bucket otorga a allUsers el rol objectViewer, quita el
otorgar 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
ventana del navegador e intentar acceder a un objeto del bucket con
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
service-PROJECT_NUM@gcp-sa-mediaedgefill.iam.gserviceaccount.com es el
el número del proyecto con los EdgeCacheService recursos que necesitan
el acceso a los datos. 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 Run).
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.
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
EdgeCacheServiceo que configuraste unaurlRewrite.hostRewritepara 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
En la consola de Google Cloud, ve a la página Origins de Media CDN.
Haz clic en Crear origen.
Ingresa un nombre para el origen. Por ejemplo:
load-balancer-origin.Ingresa una descripción (opcional).
En Dirección de origen, selecciona Especificar un FQDN o una dirección IP.
Ingresa el FQDN o la dirección IP para tu balanceador de cargas de Google Cloud.
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.
Selecciona reintentar las condiciones.
En Máx. de intentos, selecciona la cantidad máxima de intentos para completar la caché desde este origen.
Opcional: Especifica los siguientes valores de tiempo de espera:
- En Tiempo de espera de Connect, selecciona la duración máxima a fin de esperar que se establezca la conexión de origen.
- En Tiempo de espera de la respuesta, selecciona la duración máxima para permitir que se complete una respuesta.
- 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.
Opcional: Haz clic en Agregar etiqueta y especifica uno o más pares clave-valor.
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 del 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.
si 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 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, 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 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.
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.commuestra una respuesta correcta, Media CDN usa esa respuesta para el llenado de caché. - Si
b.example.commuestra un redireccionamiento o una respuesta de falla, Media CDN conmuta por error alSecondaryOriginconfigurado. Esto se debe a que, en este ejemplo,PrimaryOriginse configuró para dosmaxAttempts
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.commuestra una respuesta correcta, Media CDN usa esa respuesta para el llenado de caché. - Si
secondary.example.comdevuelve un302 Found RedirectHTTP aLocation: c.example.com, Media CDN intenta comunicarse.c.example.comEn este ejemplo, el segundo intento paraSecondaryOriginy 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.
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 | Sigue 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.