Configurer une origine

Vous pouvez configurer des origines pour Media CDN de différentes manières. Cette page vous explique comment configurer des origines.

Configurer un bucket Cloud Storage en tant qu'origine

Media CDN est compatible avec les buckets Cloud Storage en tant que backends pour le contenu. Chaque service peut référencer plusieurs buckets en configurant des routes pour l'hôte, les chemins d'accès et d'autres attributs de requête.

Les buckets Cloud Storage sont configurés en utilisant l'URL du bucket (par exemple, gs://my-bucket) comme adresse d'origine lors de la création d'une ressource d'origine.

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

La procédure est la même, que le bucket soit multirégional, birégional ou régional.

Lors de la configuration d'un service, vous pouvez acheminer votre contenu vidéo à la demande vers un premier bucket et votre contenu en diffusion en direct vers un second bucket. Cela peut s'avérer utile si plusieurs workflows sont gérés par différentes équipes. Pour réduire la latence de remplissage de cache, vous pouvez également acheminer la région eu-media.example.com vers un bucket Cloud Storage multirégional situé dans l'UE et la région us-media.example.com (ou utiliser une correspondance de chemin, d'en-tête ou de paramètre de requête) vers un bucket de stockage basé aux États-Unis.

Dans les cas où la latence d'écriture est essentielle, par exemple pour la diffusion en direct à faible latence, vous pouvez configurer un point de terminaison Cloud Storage régional aussi proche que possible de vos utilisateurs.

Authentifier les requêtes

Pour confirmer qu'une requête provient de Media CDN, utilisez l'une des méthodes suivantes:

• Vérifier que l'adresse IP de connexion provient des plages de remplissage de cache de Media CDN. Ces plages sont partagées entre tous les clients, mais sont toujours utilisées par les ressources EdgeCacheService lors de la connexion à une origine.
• Ajoutez un en-tête de requête personnalisé avec une valeur de jeton que vous validez sur l'origine (par exemple, une valeur aléatoire de 16 octets). Votre origine peut ensuite rejeter les requêtes qui n'incluent pas cette valeur.

Configurer un protocole d'origine

Pour les origines compatibles uniquement avec HTTPS (HTTP/1.1 via TLS) ou HTTP/1.1 (sans TLS), définissez le champ protocol explicitement en procédant comme suit:

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

Si votre origine est compatible avec HTTP/2, vous n'avez pas besoin de définir explicitement le protocole.

Configurer des buckets Cloud Storage privés

Media CDN peut extraire du contenu depuis n'importe quel point de terminaison HTTP ou HTTPS accessible via Internet. Dans certains cas, vous pouvez exiger une authentification afin de n'autoriser que Media CDN à extraire le contenu et ainsi empêcher tout accès non autorisé. Cloud Storage est compatible avec cette fonctionnalité via les autorisations IAM.

Pour les origines Cloud Storage, procédez comme suit:

• Accordez au compte de service Media CDN l'autorisation IAM objectViewer sur les buckets Cloud Storage que vous utilisez comme origines.
• Supprimer l'autorisation allUsers.
• Facultatif: supprimez l'autorisation allAuthenticatedUsers.

Pour modifier les autorisations d'un bucket Cloud Storage, vous devez disposer du rôle IAM "Administrateur Storage".

Le compte de service Media CDN appartient au projet Media CDN et n'apparaît pas dans la liste des comptes de service de votre projet.

Le compte de service a le format suivant et n'accorde l'accès aux ressources Media CDN que dans les projets que vous autorisez explicitement.

service-PROJECT_NUM@gcp-sa-mediaedgefill.iam.gserviceaccount.com

Pour accorder à Media CDN l'accès à un bucket, attribuez le rôle objectViewer au compte de service:

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

Utilisez la commande gcloud storage buckets remove-iam-policy-binding pour supprimer les autorisations accordées au rôle allUsers pour le bucket donné. Par exemple, si le bucket accorde le rôle objectViewer à allUsers, supprimez l'autorisation à l'aide de la commande suivante:

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

Pour vérifier que l'accès public a été supprimé, ouvrez une fenêtre de navigation privée et essayez d'accéder à un objet de bucket à l'aide de https://storage.googleapis.com/BUCKET/object.ext.

Pour autoriser les ressources EdgeCacheService d'un projet à accéder à un bucket Cloud Storage d'un autre projet, vous pouvez accorder au compte de service Media CDN de ce projet l'accès au bucket de stockage.

Pour ce faire, assurez-vous que PROJECT_NUM dans service-PROJECT_NUM@gcp-sa-mediaedgefill.iam.gserviceaccount.com correspond bien au numéro du projet contenant les ressources EdgeCacheService qui ont besoin d'un accès. Vous pouvez répéter cette opération pour plusieurs projets, en particulier si certains d'entre eux hébergent différents environnements Media CDN (développement, préproduction ou production, par exemple) et qu'un projet distinct contient vos éléments vidéo ou multimédias.

Vous pouvez protéger l'accès à votre origine Cloud Storage sans activer les requêtes signées pour cette route.

La configuration d'un stockage Cloud Storage privé n'empêche pas l'accès direct à votre contenu mis en cache depuis Media CDN. Pour en savoir plus sur la manière d'émettre des requêtes signées pour des utilisateurs individuels, consultez la page Requêtes signées.

Configurer un équilibreur de charge d'application externe en tant qu'origine

Si vous avez besoin d'une vérification d'état active, d'un round-robin (tentatives à tour de rôle) ou d'une orientation basée sur la charge entre les origines Compute Engine, GKE ou sur site, vous pouvez configurer un équilibreur de charge d'application externe en tant qu'origine.

Cela vous permet (par exemple) de configurer vos empaqueteurs de diffusion en direct derrière Media CDN ou de configurer un groupe de proxys Envoy gérés par Cloud Service Mesh pour qu'il se reconnecte à votre infrastructure sur site.

Les équilibreurs de charge vous permettent de configurer des backends pour les éléments suivants:

• Groupes d'instances de VM Compute Engine.
• Groupes de points de terminaison du réseau (y compris les VM Compute Engine et les clusters Google Kubernetes Engine).
• Groupes de points de terminaison du réseau sans serveur (Cloud Run, App Engine et Cloud Run Functions).

Une architecture qui combine une origine d'équilibreur de charge d'application externe pour diffuser des fichiers manifestes vidéo et une origine Cloud Storage pour le stockage de segments se présente comme suit, avec deux origines mappées sur différentes routes.

Pour configurer un équilibreur de charge d'application externe en tant qu'origine, vous devez créer une ressource d'origine avec l'adresse IP ou le nom d'hôte public pointant vers vos règles de transfert d'équilibreur de charge. Un nom d'hôte public (nom de domaine) est à privilégier, car il est requis pour le certificat SSL (TLS) et pour les versions modernes du protocole HTTP (HTTP/2 et HTTP/3).

Vous devez également vous assurer que:

• Votre équilibreur de charge dispose d'une route correspondant au nom d'hôte utilisé pour votre ressource EdgeCacheService ou vous avez configuré un urlRewrite.hostRewrite pour les routes sur lesquelles votre équilibreur de charge est configuré en tant qu'origine.
• Votre équilibreur de charge dispose d'un certificat SSL (TLS) publiquement approuvé, configuré pour ces noms d'hôte.

Par exemple, si le nom de domaine public pointant vers la règle de transfert de votre équilibreur de charge est origin-packager.example.com, vous devez créer une origine avec le paramètre originAddress défini sur ce nom.

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

Si vous utilisez l'adresse IP de votre règle de transfert comme adresse d'origine ou si aucun certificat SSL n'est associé à votre équilibreur de charge, vous pouvez définir le protocole sur HTTP pour basculer vers des connexions non chiffrées. Nous vous recommandons de ne procéder ainsi qu'à des fins de développement ou de test.

Configurer le basculement de l'origine

Les sections suivantes vous expliquent comment configurer le comportement de basculement de l'origine.

Basculement d'origine sans suivi de redirection

Voici une configuration de basculement EdgeCacheOrigin basique :

name: FAILOVER_ORIGIN
originAddress: FAILOVER_DOMAIN_NAME

Media CDN effectue une nouvelle tentative sur l'origine principale de la route jusqu'à trois fois avant d'essayer l'origine de basculement. Dans cette configuration, après avoir essayé trois fois l'origine principale, Media CDN tente d'exécuter une seule requête sur FAILOVER_ORIGIN. Si l'origine du basculement ne répond pas non plus, Media CDN renvoie l'intégralité de la réponse d'origine ou, si aucun code d'état n'est reçu, une réponse HTTP 502 Bad Gateway.

La latence de remplissage du cache augmente en fonction du nombre de tentatives et des événements de basculement. L'augmentation des valeurs de délai d'expiration d'origine (par exemple, connectTimeout) affectent davantage la latence de remplissage de cache, car elle augmente le temps d'attente de réponse d'un serveur d'origine surchargé ou occupé.

L'exemple suivant illustre une configuration qui envoie des requêtes de remplissage à MY_ORIGIN. La configuration oblige Media CDN à effectuer de nouvelles tentatives en cas d'erreur de connexion (par exemple, des erreurs DNS, TCP ou TLS), de réponse HTTP 5xx provenant de l'origine ou d'erreur HTTP 404 Not Found. Après deux tentatives, elle bascule sur FAILOVER_ORIGIN.

Un maximum de quatre tentatives est effectué sur vos origines configurées : la tentative initiale plus jusqu'à trois nouvelles tentatives. Vous pouvez configurer une valeur maxAttempts par origine pour déterminer le nombre de nouvelles tentatives avant le basculement.

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

Basculement d'origine avec suivi de redirection

Supposons par exemple que vous ayez configuré les ressources EdgeCacheOrigin suivantes et que les routes de votre ressource EdgeCacheService soient configurées pour utiliser PrimaryOrigin pour le remplissage du cache:

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]

Dans cet exemple, lorsque Media CDN effectue un remplissage de cache, il lit la configuration de la PrimaryOrigin et répond en conséquence.

Supposons que Media CDN se connecte à primary.example.com pour la première tentative de contact de l'origine. Si primary.example.com renvoie une réponse positive, Media CDN utilise cette réponse pour le remplissage du cache.

Supposons maintenant que primary.example.com renvoie un 302 Found Redirect HTTP vers Location: b.example.com. Ensuite, pour la seconde tentative de contact de l'origine, Media CDN suit la redirection vers b.example.com. Dans ce cas, Media CDN effectue les opérations suivantes :

• Si b.example.com renvoie une réponse positive, Media CDN utilise cette réponse pour le remplissage du cache.
• Si b.example.com renvoie une redirection ou une réponse d'échec, Media CDN bascule sur la SecondaryOrigin configurée. En effet, dans cet exemple, PrimaryOrigin est configuré avec une valeur maxAttempts égale à 2.

Si Media CDN bascule sur SecondaryOrigin, il utilise la configuration SecondaryOrigin et tente de se connecter à secondary.example.com. Il s'agit alors de la première tentative de contact de l'origine, et de la troisième tentative au total.

Dans ce cas, Media CDN effectue les opérations suivantes :

• Si secondary.example.com renvoie une réponse positive, Media CDN utilise cette réponse pour le remplissage du cache.
• Si secondary.example.com renvoie un 302 Found Redirect HTTP vers Location: c.example.com, Media CDN tente de contacter c.example.com. Dans cet exemple, il s'agit de la seconde tentative pour SecondaryOrigin et de la quatrième tentative au total.

Si la tentative de contact de c.example.com renvoie une réponse positive, Media CDN utilise cette réponse pour le remplissage du cache. Si la tentative renvoie une redirection que Media CDN est configuré pour suivre, Media CDN renvoie une erreur HTTP 502 Bad Gateway car il a épuisé le nombre maximal de tentatives pour contacter une origine. Media CDN effectue au maximum quatre tentatives sur toutes les origines, indépendamment des configurations EdgeCacheOrigin. Enfin, si Media CDN ne parvient pas à contacter c.example.com, il renvoie une réponse 504 Gateway Timeout ou 502 Bad Gateway.

Si vous avez besoin d'une vérification d'état active, d'un round-robin (tentatives à tour de rôle) ou d'une orientation basée sur la charge entre les origines, vous pouvez configurer un équilibreur de charge d'application externe en tant qu'origine principale.

Configurer le suivi des redirections d'origine

Media CDN accepte le suivi des redirections renvoyées par votre origine en interne lors du remplissage du cache, plutôt que de renvoyer directement les réponses de redirection au client. Lorsque Media CDN est configuré pour suivre les redirections d'origine, Media CDN récupère le contenu depuis l'emplacement de redirection avant de mettre en cache et de renvoyer la réponse redirigée au client. Media CDN suit les redirections entre les domaines.

Nous vous recommandons de configurer la redirection d'origine uniquement pour les origines fiables et contrôlées. Assurez-vous que toutes les origines d'une chaîne de redirection sont fiables, car chacune d'elles produit du contenu diffusé par votre EdgeCacheService.

Pour activer le suivi des redirections d'origine, ajoutez la configuration suivante à votre ressource EdgeCacheOrigin:

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

Media CDN utilise le protocole spécifié dans les redirections pour atteindre tous les serveurs. Assurez-vous que tous les serveurs vers lesquels Media CDN peut être redirigé sont bien compatibles avec les protocoles requis. En particulier, si le protocole est défini sur HTTPS, HTTP/2 ou HTTP/3, Media CDN ne bascule pas vers des connexions HTTP/1.1 afin de suivre des redirections non sécurisées. L'en-tête d'hôte envoyé à l'origine redirigée correspond à l'URL redirigée. Media CDN suit une seule redirection par tentative EdgeCacheOrigin avant de renvoyer la réponse finale ou d'évaluer des conditions de nouvelle tentative ou de basculement.

Le paramètre redirectConditions indique les codes de réponse HTTP qui obligent Media CDN à suivre une redirection pour chaque origine.

Configurer des réécritures d'hôte ou des modifications d'en-tête spécifiques à l'origine

Si votre origine nécessite une réécriture d'hôte ou une modification d'en-tête spécifique à l'origine, utilisez l'exemple de configuration originOverrideAction suivant pour les définir:

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

Le paramètre originOverrideAction.hostRewrite est prioritaire sur les réécritures d'en-tête existantes configurées sur les routes pointant vers cette origine.

Vous pouvez utiliser les en-têtes par origine uniques requestHeadersToAdd demandés par cette origine spécifique. Un cas d'utilisation courant ajoute des en-têtes Authorization statiques. Ces manipulations d'en-tête étant exécutées lors de la requête d'origine, les en-têtes ajoutés par origine remplacent les en-têtes existants portant le même nom de champ ou les ajoutent. Par défaut, Media CDN ajoute les en-têtes aux en-têtes existants. Pour remplacer les en-têtes existants, définissez headerAction.replace sur true.

Pour savoir comment définir des en-têtes de requête par route, consultez la section Définir des en-têtes personnalisés.

Résoudre les problèmes liés aux origines

Si une origine ne se comporte pas comme prévu, découvrez comment résoudre les problèmes liés aux origines.

Étape suivante

• Utiliser un bucket privé compatible Amazon S3 comme origine
• Configurer des routes de service