Configurer une origine

Vous pouvez configurer les 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 accepte 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.

Console

  1. Dans la console Google Cloud, accédez à la page Origines de Media CDN.

    Accéder à Origins

  2. Cliquez sur Créer une origine.

  3. Saisissez un nom pour l'origine. Exemple : cloud-storage-origin.

  4. Facultatif: saisissez une description.

  5. Pour l'adresse d'origine, choisissez Sélectionner un bucket Google Cloud Storage.

  6. Accédez à votre bucket Cloud Storage et sélectionnez-le.

  7. Pour Cloud Storage, conservez les paramètres de protocole et de port par défaut.

  8. Facultatif: Pour que les remplacements d'en-en-tête de requête d'origine prévalent sur les en-têtes envoyés par le client ou manipulés par des actions d'en-tête au niveau de la route, procédez comme suit:

    1. Sélectionnez Activer le remplacement de l'origine.
    2. Dans la section Headers (En-têtes), spécifiez les en-têtes en ajoutant une ou plusieurs paires nom/valeur.

  9. Facultatif: Sélectionnez une origine de basculement à essayer au cas où elle deviendrait inaccessible. Vous pourrez mettre à jour ce champ ultérieurement.

  10. Sélectionnez Conditions de redirection.

  11. Sélectionnez Conditions de nouvelle tentative.

  12. Dans Nombre maximal de tentatives, sélectionnez le nombre maximal de tentatives de remplissage du cache à partir de cette origine.

  13. (Facultatif) Spécifiez les valeurs timeout suivantes :

    1. Pour Délai avant expiration de la connexion, sélectionnez la durée maximale d'attente de la connexion d'origine.
    2. Pour Délai avant expiration de la réponse, sélectionnez la durée maximale autorisée pour l'exécution d'une réponse.
    3. Pour Délai avant expiration de la lecture, sélectionnez la durée maximale d'attente entre les lectures d'une même connexion HTTP ou d'un même unique.

  14. (Facultatif) Cliquez sur Ajouter une étiquette et spécifiez une ou plusieurs paires clé-valeur.

  15. Cliquez sur Créer une origine.

gcloud

Exécutez la commande gcloud edge-cache origins create :

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

Remplacez les éléments suivants :

  • ORIGIN: nom de la nouvelle origine
  • ADDRESS: nom du bucket (par exemple, gs://my-bucket)

Il en va de même pour le bucket multirégional, birégional ou régional.

Lorsque vous configurez un service, vous pouvez acheminer votre contenu de vidéo à la demande vers un bucket et le contenu diffusé en direct vers un autre bucket. C'est utile si plusieurs équipes gèrent chaque workflow. Pour réduire la latence de remplissage du 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 une correspondance selon le chemin d'accès, l'en-tête ou le paramètre de requête) vers un bucket de stockage basé aux États-Unis.

Buckets Media CDN.
Buckets Media CDN (cliquez pour agrandir).

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 approches compatibles suivantes:

  • Vérifiez que l'adresse IP de connexion provient des plages de remplissage du 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 alors rejeter les requêtes qui n'incluent pas cette valeur.

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

Configurer un protocole d'origine

Pour les origines qui n'acceptent que HTTPS (HTTP/1.1 sur TLS) ou HTTP/1.1 (sans TLS), définissez explicitement le champ protocol en procédant comme suit:

Console

  1. Dans la console Google Cloud, accédez à la page Origines de Media CDN.

    Accéder à Origins

  2. Sélectionnez votre origine, puis cliquez sur Modifier.

  3. Comme protocole, sélectionnez HTTPS ou HTTP. Pour HTTP, spécifiez également le port 80.

  4. Cliquez sur Mettre à jour l'origine.

gcloud

Exécutez la commande gcloud edge-cache origins update :

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 de n'importe quel point de terminaison HTTP ou HTTPS accessible sur Internet. Dans certains cas, vous pouvez exiger une authentification afin de n'autoriser que Media CDN à extraire du contenu et à 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 qu'aux ressources Media CDN 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, accordez le rôle objectViewer au compte de service:

gsutil iam ch \
serviceAccount:service-PROJECT_NUM@gcp-sa-mediaedgefill.iam.gserviceaccount.com:objectViewer gs://BUCKET

Pour supprimer toutes les autorisations du rôle allUsers pour le bucket donné, exécutez la commande suivante:

gsutil iam ch -d allUsers gs://BUCKET

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 est le numéro du projet avec les ressources EdgeCacheService nécessitant 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 (par exemple, développement, préproduction ou production) 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 Cloud Storage privé n'empêche pas l'accès direct au 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 de l'état active, d'une règle de round robin (à tour de rôle) ou d'une direction basée sur la charge sur des origines Compute Engine, GKE ou sur site, vous pouvez configurer un équilibreur de charge d'application externe en tant qu'origine.

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

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

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 est semblable à ce qui suit, avec deux origines mappées à des routes différentes.

Déploiement de la mise en cache périphérique
Déploiement de la mise en cache périphérique (cliquez pour agrandir).

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 les règles de transfert de votre é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 qui correspond au nom d'hôte utilisé pour votre ressource EdgeCacheService ou pour laquelle vous avez configuré un urlRewrite.hostRewrite pour les routes dont l'équilibreur de charge est configuré en tant qu'origine.
  • Votre équilibreur de charge dispose d'un certificat SSL (TLS) publiquement approuvé et 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.

Console

  1. Dans la console Google Cloud, accédez à la page Origines de Media CDN.

    Accéder à Origins

  2. Cliquez sur Créer une origine.

  3. Saisissez un nom pour l'origine. Exemple : load-balancer-origin.

  4. Facultatif: saisissez une description.

  5. Sous Adresse d'origine, sélectionnez Spécifier un nom de domaine complet ou une adresse IP.

  6. Saisissez le nom de domaine complet ou l'adresse IP de votre équilibreur de charge Google Cloud.

  7. Facultatif: Sélectionnez une origine de basculement à essayer au cas où elle deviendrait inaccessible. Vous pourrez mettre à jour ce champ ultérieurement.

  8. Sélectionnez Conditions de nouvelle tentative.

  9. Dans Nombre maximal de tentatives, sélectionnez le nombre maximal de tentatives de remplissage du cache à partir de cette origine.

  10. (Facultatif) Spécifiez les valeurs timeout suivantes :

    1. Pour Délai avant expiration de la connexion, sélectionnez la durée maximale d'attente de la connexion d'origine.
    2. Pour Délai avant expiration de la réponse, sélectionnez la durée maximale autorisée pour l'exécution d'une réponse.
    3. Pour Délai avant expiration de la lecture, sélectionnez la durée maximale d'attente entre les lectures d'une même connexion HTTP ou d'un même unique.

  11. (Facultatif) Cliquez sur Ajouter une étiquette et spécifiez une ou plusieurs paires clé-valeur.

  12. Cliquez sur Créer une origine.

gcloud

Exécutez la commande gcloud edge-cache origins create :

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

Remplacez les éléments suivants :

  • LB_ORIGIN: nom de l'origine
  • LB_ADDRESS: nom de domaine complet ou adresse IP (par exemple, origin-packager.example.com)

Si vous utilisez l'adresse IP de votre règle de transfert comme adresse d'origine ou si vous n'avez pas associé de certificat SSL à votre équilibreur de charge, vous pouvez définir le protocole sur HTTP pour revenir à des connexions non chiffrées. Nous vous recommandons de le faire uniquement pour le développement ou les tests.

Configurer le basculement d'origine

Les sections suivantes expliquent comment configurer le comportement du basculement depuis 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 relance l'origine principale de la route au maximum trois fois avant de tenter une origine de basculement. Dans cette configuration, après trois tentatives avec l'origine principale, Media CDN tente d'envoyer une seule requête à l'FAILOVER_ORIGIN. Si l'origine du basculement échoue également, Media CDN renvoie l'intégralité de la réponse de l'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 entraîne de nouvelles tentatives de Media CDN en cas d'erreurs de connexion (telles que des erreurs DNS, TCP ou TLS), de réponses HTTP 5xx de l'origine ou de HTTP 404 Not Found. Après deux tentatives, il bascule vers 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 tentatives effectuées avant de tenter 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

Si votre origine nécessite une réécriture d'hôte ou une modification d'en-tête spécifiques à 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

Voici une configuration complète :

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

Dans l'exemple précédent, le paramètre originOverrideAction.hostRewrite est prioritaire sur toutes les réécritures d'en-tête existantes configurées sur les routes qui pointent 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.

Basculement d'origine avec suivi de la redirection

Par exemple, supposons 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 à Location: b.example.com. Ensuite, pour la deuxième 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é pour deux maxAttempts.

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 à Location: c.example.com, Media CDN tente de contacter c.example.com. Dans cet exemple, il s'agit de la deuxième tentative pour SecondaryOrigin et de la tentative n°4 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 le nombre maximal de tentatives de contact d'une origine a été atteint. Media CDN effectue au maximum quatre tentatives pour toutes les origines, quelles que soient les 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 de l'état, de l'interrogation à répétition alternée 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 les redirections d'origine suivantes, 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 peuvent être redirigés pour être 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.

Condition Description
MOVED_PERMANENTLY Suivre la redirection pour le code de réponse HTTP 301
FOUND Suivre la redirection pour le code de réponse HTTP 302
SEE_OTHER Suivre la redirection pour le code de réponse HTTP 303
TEMPORARY_REDIRECT Suivre la redirection pour le code de réponse HTTP 307
PERMANENT_REDIRECT Suivre la redirection pour le code de réponse HTTP 308

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.

Étapes suivantes