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

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-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.

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. de cette origine.

13. (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.

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, que le bucket multirégional, birégional ou régional.

Lors de la configuration d'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 acheminer de la même manière la région eu-media.example.com vers un emplacement multirégional Bucket Cloud Storage situé dans l'UE et dans la région us-media.example.com (ou une correspondance avec le chemin d'accès, l'en-tête ou le paramètre de requête) à un stockage basé aux États-Unis bucket.

Important :Nous vous recommandons d'utiliser un bucket multirégional pour le stockage d'origine, car un bucket multirégional offre une redondance géographique accrue pour les objets stockés.

<ph type="x-smartling-placeholder">

</ph>

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érifiez que l'adresse IP de connexion provient de l'instance des plages de remplissage du cache. 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 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 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

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, également spécifiez 80 comme port.

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 protocole HTTP ou HTTPS accessible sur Internet 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 access. Cloud Storage est compatible avec cette fonctionnalité via les autorisations IAM.

Important :Pour les routes associées à un bucket Cloud Storage privé origine, définissez le mode de cache sur FORCE_CACHE_ALL. Sinon, la mise en cache n'est pas possible, car les buckets Cloud Storage privés définissent un en-tête cache-control: private.

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.

[e-mail]

Remarque :Vous devez créer au moins une ressource Media CDN pour déclencher la création d'un compte de service. Dans la plupart des cas, il s'agit de la ressource EdgeCacheOrigin. connecté à votre bucket Cloud Storage.

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

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

Remarque: La propagation de la configuration peut prendre au moins 10 minutes, avant que supprimant l'accès public à un bucket de stockage existant utilisé en tant que à l'origine.

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

gsutil iam ch -d allUsers gs://BUCKET

Pour confirmer la suppression de l'accès public, ouvrez une fenêtre de navigation privée et tenter d'accéder à un objet de bucket à l'aide de https://storage.googleapis.com/BUCKET/object.ext

Pour autoriser l'accès à EdgeCacheService ressources dans un projet à un bucket Cloud Storage d'un autre projet, vous pouvez accorder Le compte de service Media CDN de ce projet a accès à l'espace de stockage bucket.

Pour ce faire, assurez-vous que PROJECT_NUM dans [e-mail] est numéro du projet avec les ressources EdgeCacheService qui ont besoin access. 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 diffusions 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 (Cloud Run, App Engine et Cloud Functions).

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.

<ph type="x-smartling-placeholder">

</ph>

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 vous assurer que:

• 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

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. de cette origine.

10. (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.

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 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 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 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 entraîne Media CDN pour réessayer en cas d'erreurs de connexion (DNS, TCP ou les erreurs TLS), les réponses HTTP 5xx de l'origine ou les réponses 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 pour 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 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 pour toutes les origines, quelles que soient les 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.

Avertissement : La configuration de redirections provenant d'un service d'origine non approuvé ou contrôlé par un pirate informatique peut exposer votre configuration Media CDN à des failles de redirection ouverte.

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	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.

Étape suivante

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