Cette page a été traduite par l'API Cloud Translation.

Configurer une origine

Vous pouvez configurer les origines pour Media CDN de différentes manières. Cette page affiche comment configurer les 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 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

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

Accéder à Origins
Cliquez sur Créer une origine.
Saisissez un nom pour l'origine. Exemple : cloud-storage-origin.
Facultatif: saisissez une description.
Pour l'adresse d'origine, choisissez Sélectionner un bucket Google Cloud Storage.
Accédez à votre bucket Cloud Storage et sélectionnez-le.
Pour Cloud Storage, conservez les paramètres de protocole et de port par défaut.
Facultatif: Pour que les remplacements d'en-tête de requête "Origine" soient prioritaires 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, effectuer les opérations suivantes:
1. Sélectionnez Activer le remplacement de l'origine.
2. Dans la section Headers (En-têtes), spécifiez des en-têtes en ajoutant un ou plusieurs nom-valeur.
Facultatif : sélectionnez une origine de basculement à essayer si cette origine devient inaccessible. Vous pourrez mettre à jour ce champ ultérieurement.
Sélectionnez Conditions de redirection.
Sélectionnez Conditions de nouvelle tentative.
Dans Nombre maximal de tentatives, sélectionnez le nombre maximal de tentatives de remplissage du cache. de cette origine.
Facultatif: spécifiez le délai avant expiration suivant :
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.
(Facultatif) Cliquez sur Ajouter une étiquette et spécifiez une ou plusieurs paires clé-valeur.
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, que 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 et le streaming en direct vers un second bucket. Ceci est utile si vous avez différentes équipes qui gèrent chaque flux de travail. 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 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.

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 acceptées 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é 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 le (par exemple, une valeur aléatoire de 16 octets). Votre origine peut ensuite 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 en-têtes personnalisés.

Configurer un protocole d'origine

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

Console

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

Accéder à Origins
Sélectionnez votre origine, puis cliquez sur Modifier.
Comme protocole, sélectionnez HTTPS ou HTTP. Pour HTTP, également spécifiez 80 comme port.
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 protocole HTTP ou HTTPS accessible sur Internet et un point de terminaison unique. Dans certains cas, vous devrez peut-être exiger une authentification, afin de n'autoriser que Media CDN à extraire du contenu et à empêcher les accès non autorisés y accéder. Cloud Storage est compatible avec cette fonctionnalité via les autorisations IAM.

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

Attribuez le objectViewer au compte de service Media CDN une autorisation IAM sur les buckets Cloud Storage que vous 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, 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

Exécutez la commande gcloud storage buckets remove-iam-policy-binding. pour supprimer les autorisations accordées au rôle allUsers pour le bucket donné. Pour exemple, si le bucket accorde à allUsers le rôle objectViewer, supprimez le accorder à 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 navigateur en mode 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 numéro du projet avec les ressources EdgeCacheService qui ont besoin y accéder. Vous pouvez répéter cette opération pour plusieurs projets, surtout si certains d'entre eux hébergent différents environnements Media CDN (développement, préproduction ou production), et un projet distinct contient vos vidéos ou contenus multimédias éléments.

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 votre contenu mis en cache contre les accès direct 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'un round robin (à tour de rôle) ou d'une orientation basée sur la charge sur Compute Engine, GKE ou sur site, vous pouvez configurer un équilibreur de charge d'application externe comme origine.

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

Les équilibreurs de charge 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 (fonctions Cloud Run, App Engine et Cloud Run).

Architecture qui combine une origine d'équilibreur de charge d'application externe pour diffuser des vidéos et une origine Cloud Storage pour le stockage de segments ci-dessous, avec deux points de départ mappés à des itinéraires différents.

Déploiement du 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 ressource d'origine avec l'adresse IP ou le nom d'hôte public pointant vers votre règles de transfert de l'é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 vérifier les points suivants:

Votre équilibreur de charge dispose d'une route qui correspond au nom d'hôte utilisé pour votre EdgeCacheService ou que vous avez configuré une urlRewrite.hostRewrite pour les routes où votre équilibreur de charge est configuré comme origine.
Un certificat SSL (TLS) publiquement approuvé est configuré pour votre équilibreur de charge pour ces noms d'hôte.

Par exemple, si le nom de domaine public pointait vers le réseau de transfert est origin-packager.example.com, vous devez alors créer une origine avec le originAddress défini sur ce nom.

Console

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

Accéder à Origins
Cliquez sur Créer une origine.
Saisissez un nom pour l'origine. Exemple : load-balancer-origin.
Facultatif : saisissez une description.
Sous Adresse d'origine, sélectionnez Spécifier un nom de domaine complet ou une adresse IP.
Saisissez le nom de domaine complet ou l'adresse IP de votre équilibreur de charge Google Cloud.
Facultatif: Sélectionnez une origine de basculement à essayer au cas où elle deviendrait inaccessible. Vous pourrez mettre à jour ce champ ultérieurement.
Sélectionnez Conditions de nouvelle tentative.
Dans Nombre maximal de tentatives, sélectionnez le nombre maximal de tentatives de remplissage du cache. de cette origine.
Facultatif : spécifiez les valeurs de délai avant expiration 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.
(Facultatif) Cliquez sur Ajouter une étiquette et spécifiez une ou plusieurs paires clé-valeur.
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 aucun certificat SSL n'est associé à votre équilibreur de charge, vous pouvez Définissez le protocole sur HTTP pour revenir à des connexions non chiffrées. Nous vous recommandons que pour le développement ou les tests.

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 relance l'origine principale de la route pendant trois tentatives au maximum avant de tenter une origine de basculement. Dans cette configuration, après avoir essayé l'origine principale à trois reprises, Media CDN tente requête sur FAILOVER_ORIGIN. Si le l'origine de basculement ne répond pas non plus correctement, Media CDN renvoie l'intégralité de la réponse de l'origine ou, si aucune code d'état 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, 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 un Valeur maxAttempts par origine pour déterminer le nombre de tentatives effectuées avant lors d'un 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 prend avant toute réécriture d'en-tête existante configurés sur des 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.

Basculement d'origine avec suivi de la redirection

Par exemple, supposons que vous ayez configuré les éléments EdgeCacheOrigin suivants : ressources et que les routes de votre ressource EdgeCacheService sont configurées pour Utilisez 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 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 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 de contact d'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, Media CDN renvoie une réponse 504 Gateway Timeout ou une réponse 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 origines, vous pouvez configurer équilibreur de charge d'application externe en tant qu'équilibreur de charge principal origine.

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 sur lesquels Media CDN peuvent redirigé pour prendre en charge 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	Suivi de redirection pour le code de réponse HTTP `301`
FOUND	Suivre la redirection pour le code de réponse HTTP `302`
SEE_OTHER	Suivi de 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.

Configurer une origine

Configurer un bucket Cloud Storage en tant qu'origine

Console

gcloud

Authentifier les requêtes

Configurer un protocole d'origine

Console

gcloud

Configurer des buckets Cloud Storage privés

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

Console

gcloud

Configurer le basculement de l'origine

Basculement d'origine sans suivi de redirection

Basculement d'origine avec suivi de la redirection

Configurer le suivi des redirections d'origine

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

Étape suivante