Atelier: Extensions de service sur Media CDN

1. Introduction

Dernière mise à jour : 01/05/2024

Les réseaux de diffusion de contenu (CDN) améliorent les performances des utilisateurs en mettant en cache les contenus fréquemment consultés au plus près des utilisateurs finaux, en mettant fin aux connexions au plus près des clients, en réutilisant les connexions à l'origine et en adoptant des protocoles et des personnalisations de mise en réseau modernes.

Media CDN, le réseau périphérique mondial de GCP pour le streaming multimédia, offre de nombreuses fonctionnalités intégrées ou "de base". Ces fonctionnalités de base sont conçues pour répondre aux cas d'utilisation les plus courants, mais vous pouvez également avoir des exigences qui ne sont pas couvertes par cet ensemble de fonctionnalités de base.

Les extensions de service pour Media CDN, parfois appelées programmabilité en périphérie, vous permettent d'exécuter votre propre code en périphérie pour personnaliser le comportement de Media CDN. Cela permet d'accéder à d'autres cas d'utilisation, allant de la normalisation de la clé de cache à l'authentification et à la révocation de jetons personnalisées, en passant par des champs de journaux personnalisés supplémentaires, les tests A/B et les pages d'erreur personnalisées.

Objectifs de l'atelier

Dans cet atelier de programmation, nous allons vous guider tout au long des étapes nécessaires pour déployer un environnement de diffusion CDN compatible avec Edge Compute, avec Media CDN (CDN) + Service Extensions (programmabilité en périphérie) + Cloud Storage (source du CDN).

Points abordés

• Configurer Media CDN avec un bucket Cloud Storage défini comme origine
• Créer un plug-in d'extension de service avec une authentification HTTP personnalisée et l'associer à Media CDN
• Valider que le plug-in Service Extension fonctionne comme prévu
• (Facultatif) Comment gérer un plug-in d'extension de service, par exemple en mettant à jour, en référençant, en rétablissant et en supprimant une version spécifique d'un plug-in

Prérequis

• Connaissances de base sur la gestion de réseaux et le protocole HTTP
• Connaissances de base de la ligne de commande Unix/Linux

2. Avant de commencer

Demande d'ajout à la liste d'autorisation Media CDN et à la liste d'autorisation des extensions de service

Attention : Veuillez vous assurer que votre projet est autorisé pour Media CDN et les extensions de service pour Media CDN. Vous ne pourrez pas terminer cet atelier si votre projet n'est pas autorisé.

Avant de commencer, vous devez vous assurer que votre projet a été ajouté à la liste d'autorisation de la preview privée pour Media CDN et les extensions de service pour Media CDN.

• Pour demander l'accès à Media CDN et aux extensions de service pour Media CDN, veuillez contacter votre équipe Google Account afin qu'elle crée une demande d'accès en votre nom pour Media CDN et les extensions de service.

Remarques : Si vous faites partie de Google et que vous souhaitez tester les extensions de service avec Media CDN, contactez les responsables produit de Media CDN et des extensions de service pour demander l'accès.

3. Préparation

Démarrer Cloud Shell

Bien que Google Cloud puisse être utilisé à distance depuis votre ordinateur portable, nous allons nous servir de Google Cloud Shell pour cet atelier de programmation, un environnement de ligne de commande exécuté dans le cloud.

Depuis la console GCP, cliquez sur l'icône Cloud Shell de la barre d'outils située dans l'angle supérieur droit :

Le provisionnement et la connexion à l'environnement prennent quelques instants seulement. Une fois l'opération terminée, le résultat devrait ressembler à ceci :

Cette machine virtuelle contient tous les outils de développement nécessaires. Elle comprend un répertoire d'accueil persistant de 5 Go et s'exécute sur Google Cloud, ce qui améliore nettement les performances du réseau et l'authentification. Vous pouvez réaliser toutes les activités de cet atelier dans un simple navigateur.

Avant de commencer

Rôles et accès IAM

Voici les autorisations IAM (Identity and Access Management) requises pour créer des ressources Media CDN et Artifact Registry :

• roles/networkservices.edgeCacheAdmin
• roles/networkservices.edgeCacheUser
• roles/networkservices.edgeCacheViewer
• roles/artifactregistry.repoAdmin

Dans Cloud Shell, assurez-vous que les variables d'environnement project_id, project_num, location et repository sont configurées.

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
PROJECT_ID=[YOUR-PROJECT-NAME]
PROJECT_NUM=[YOUR-PROJECT-NUMBER]
LOCATION=us-central1
REPOSITORY=service-extension-$PROJECT_ID

Activer les API

Activez les API Media CDN et Service Extensions à l'aide des commandes ci-dessous.

gcloud services enable networkservices.googleapis.com
gcloud services enable networkactions.googleapis.com
gcloud services enable edgecache.googleapis.com
gcloud services enable artifactregistry.googleapis.com

4. Créer un bucket Cloud Storage

Le contenu Media CDN peut provenir de différents emplacements, comme un bucket Cloud Storage, un emplacement de stockage tiers ou n'importe quel point de terminaison HTTP(HTTPS) accessible au public.

Dans cet atelier de programmation, nous allons stocker du contenu dans un bucket Cloud Storage.

Remarques : Les noms de buckets Cloud Storage doivent être uniques. Pour éviter tout conflit, nous utiliserons la variable d'environnement $PROJECT_ID dans le nom du bucket.

Nous allons utiliser la commande gsutil mb pour créer le bucket.

gsutil mb gs://mediacdn-bucket-$PROJECT_ID

Vous pouvez également créer un bucket Cloud Storage à l'aide de l'interface utilisateur, comme suit :

1. Dans la console Google Cloud, accédez à la page Cloud Storage.
2. Cliquez sur le bouton CRÉER.
3. Saisissez un nom pour le bucket. (par exemple, "mediacdn-bucket-$PROJECT_ID").
4. Conservez les autres paramètres par défaut.
5. Cliquez sur le bouton CRÉER.

5. Importer un objet de test dans le bucket Cloud Storage

Nous allons maintenant importer un objet dans le bucket Cloud Storage.

1. Créez un fichier dans Cloud Shell, puis importez-le dans le bucket à l'aide de gsutil.

echo media-cdn-service-extensions-test > file.txt

gsutil cp file.txt gs://mediacdn-bucket-$PROJECT_ID

Remarques : Media CDN est compatible avec les buckets privés en tant qu'origine. Pour autoriser Media CDN à accéder au contenu d'un bucket Cloud Storage privé, vous devez configurer IAM afin d'accorder l'accès objectViewer au compte de service Media CDN.

Le compte de service a le format suivant :

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

2. Accorder à Media CDN l'accès au bucket

gsutil iam ch \
serviceAccount:service-$[e-mail]:objectViewer gs://mediacdn-bucket-$PROJECT_ID

6. Configurer Media CDN

Nous allons maintenant créer une configuration Media CDN.

Chaque configuration Media CDN se compose de deux ressources principales :

• EdgeCacheService, responsable de la configuration client (TLS, adressage IP), du routage, de la configuration CDN (modes de cache, valeurs TTL, signature) et des stratégies de sécurité.
• EdgeCacheOrigin, responsable de la configuration par origine pour toute origine basée sur HTTP, ainsi que des conditions de nouvelle tentative lorsque le contenu n'est pas disponible ou accessible.

Configurer une origine de mise en cache périphérique

Créons maintenant une origine qui pointe vers le bucket Cloud Storage que vous venez de créer.

1. Dans la console Google Cloud, accédez à la page Media CDN.
2. Cliquez sur l'onglet ORIGINES.
3. Cliquez sur CRÉER UNE ORIGINE.
4. Saisissez "cloud-storage-origin" comme nom de l'origine du cache Edge.
5. Sous "Adresse d'origine" :
6. Choisissez "Sélectionner un bucket Google Cloud Storage".
7. Accédez au bucket Cloud Storage nommé "mediacdn-bucket-$PROJECT_ID".
8. Cliquez sur SÉLECTIONNER.
9. Conservez les autres paramètres par défaut.
10. Cliquez sur CRÉER UNE ORIGINE.

La ressource EdgeCacheOrigin nouvellement créée apparaît dans la liste des origines de votre projet sur la page "Origines".

Configurer un service de mise en cache périphérique

1. Dans la console Google Cloud, accédez à la page Media CDN.
2. Cliquez sur l'onglet SERVICES.
3. Cliquez sur CRÉER UN SERVICE.
4. Saisissez un nom unique pour votre service (par exemple, "media-cdn"), puis cliquez sur "Suivant".

5. Dans la section "Routage", cliquez sur AJOUTER UNE RÈGLE D'HÔTE.
6. Saisissez le caractère générique "*" dans le champ "Hôtes".

7. Cliquez sur AJOUTER UNE RÈGLE DE ROUTE.
8. Pour la priorité, spécifiez "1".
9. Cliquez sur AJOUTER UNE CONDITION DE CORRESPONDANCE. Pour "Chemin d'accès correspondant", sélectionnez "Correspondance du préfixe" comme type de correspondance, spécifiez "/" dans le champ "Chemin d'accès correspondant", puis cliquez sur "OK".
10. Sous "Action principale", sélectionnez Extraire d'une origine, puis sélectionnez l'origine que vous avez configurée dans la liste déroulante.

11. Cliquez sur CONFIGURATIONS AVANCÉES pour afficher d'autres options de configuration.
12. Dans "Action de routage", cliquez sur AJOUTER UN ÉLÉMENT. Ensuite, procédez comme suit :
13. Dans le champ "Type", sélectionnez "Règle CDN".
14. Pour le mode Cache, sélectionnez "Forcer la mise en cache de tout".
15. Conservez les autres valeurs par défaut.
16. Cliquez sur "OK".
17. Cliquez sur Enregistrer.

18. Cliquez sur CRÉER UN SERVICE.

La ressource EdgeCacheService que vous venez de créer s'affiche sur la page "Services" de la liste des services de votre projet.

Récupérer l'adresse IP MediaCDN et effectuer des tests

1. Dans la console Google Cloud, accédez à la page Media CDN.
2. Accéder à Media CDN
3. Cliquez sur l'onglet Services.
4. Pour votre service, consultez la colonne Adresses.

Pour vérifier que votre service est correctement configuré pour mettre en cache le contenu, utilisez l'outil de ligne de commande curl pour émettre des requêtes et vérifier les réponses.

curl -svo /dev/null "http://MEDIA_CDN_IP_ADDRESS/file.txt"

Cette commande doit produire un résultat semblable à celui-ci :

< HTTP/2 200 OK
...
media-cdn-service-extensions-test
...

Vous avez créé un déploiement MediaCDN avec Cloud Storage comme origine.

7. Configurer Artifact Registry pour les extensions de service

Avant de créer des extensions de service, nous devons configurer Artifact Registry. Artifact Registry est le gestionnaire de packages universel de Google Cloud pour gérer les artefacts de compilation. Les plug-ins d'extension de service (Proxy-Wasm) sont publiés dans Artifact Registry. Une fois publiés dans Artifact Registry, les plug-ins Proxy-Wasm peuvent être déployés dans votre déploiement Media CDN.

Remarques : Les noms de dépôts Artifact Registry doivent être uniques. Pour éviter tout conflit, nous utiliserons la variable d'environnement $PROJECT_ID dans le nom du dépôt.

Nous allons utiliser la commande gcloud artifacts repositories create pour créer le dépôt.

gcloud artifacts repositories create service-extension-$PROJECT_ID \
    --repository-format=docker \
    --location=$LOCATION \
    --description="Repo for Service Extension" \
    --async

Vous pouvez également créer un dépôt à l'aide de l'interface utilisateur graphique comme suit :

1. Dans la console Google Cloud, accédez à la page Artifact Registry.
2. Cliquez sur le bouton + CRÉER DÉPÔT.
3. Saisissez un nom pour le dépôt (par exemple, "service-extension-$PROJECT_ID").
4. Format : "Docker", Mode : "Standard", Type d'emplacement : "Région", puis sélectionnez "us-central1 (Iowa)".
5. Cliquez sur le bouton CRÉER.

La ressource de dépôt Artifact Registry que vous venez de créer doit apparaître sur la page "Dépôts".

Une fois la ressource "Repository" créée, exécutez la commande suivante dans Cloud Shell pour configurer votre client Docker Cloud Shell afin qu'il transfère et extraie des packages à l'aide de ce dépôt.

gcloud auth configure-docker $LOCATION-docker.pkg.dev

Résultat :

...
Adding credentials for: us-central1-docker.pkg.dev
Docker configuration file updated.

8. Configurer les extensions de service sur Media CDN

Nous allons maintenant vous montrer comment écrire et créer un plug-in d'extension de service (Proxy-Wasm) pouvant être déployé sur Media CDN à l'aide du langage de programmation Rust.

Dans cet exemple, nous allons créer un plug-in Proxy-Wasm qui vérifie que chaque requête HTTP contient un en-tête d'autorisation avec la valeur "secret". Si la requête ne contient pas cet en-tête, le plug-in génère une réponse HTTP 403 "Forbidden" (Interdit).

Pour rappel, les extensions de service comportent trois ressources clés : WasmAction, WasmPlugin et WasmPluginVersion.

• Une ressource WasmAction est ce qui est associé à votre EdgeCacheService Media CDN. Une WasmAction fait référence à une ressource WasmPlugin.
• Une ressource WasmPlugin possède une version principale qui correspond à la version WasmPluginVersion active actuelle.
• Un WasmPluginVersions fait référence à une image de conteneur provenant d'Artifact Registry. Lorsque vous modifiez vos plug-ins proxy-wasm, vous créez différentes versions WasmPluginVersion.

Veuillez consulter le diagramme ci-dessous pour mieux comprendre la relation entre ces ressources.

Écrire et créer un plug-in d'extension de service

1. Installez la chaîne d'outils Rust en suivant les instructions sur https://www.rust-lang.org/tools/install.

Attention : Veuillez suivre les instructions de l'invite pour installer la chaîne d'outils Rust.

Si vous obtenez l'erreur -bash: rustup: command not found lorsque vous exécutez"rustup", essayez source "$HOME/.cargo/env pour recharger l'environnement PATH dans Cloud Shell.

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

2. Ensuite, ajoutez la prise en charge de Wasm à votre chaîne d'outils Rust en exécutant la commande suivante :

rustup target add wasm32-wasi

3. Créez un package Rust appelé my-wasm-plugin :

cargo new --lib my-wasm-plugin

Résultat :

Created library `my-wasm-plugin` package

4. Accédez au répertoire my-wasm-plugin. Vous devriez voir un fichier Cargo.toml et un répertoire src.

cd my-wasm-plugin
ls

Résultat :

Cargo.toml  src

5. Ensuite, configurez votre package Rust en modifiant le fichier Cargo.toml. Après la ligne [dependencies] dans le fichier Cargo.toml, ajoutez les éléments suivants :

proxy-wasm = "0.2"
log = "0.4"

[lib]
crate-type = ["cdylib"]

[profile.release]
lto = true
opt-level = 3
codegen-units = 1
panic = "abort"
strip = "debuginfo"

6. Une fois vos modifications effectuées, le fichier Cargo.toml devrait se présenter à peu près comme suit :

[package]
name = "my-wasm-plugin"
version = "0.1.0"
edition = "2021"

[dependencies]
proxy-wasm = "0.2"
log = "0.4"

[lib]
crate-type = ["cdylib"]

[profile.release]
lto = true
opt-level = 3
codegen-units = 1
panic = "abort"
strip = "debuginfo"

7.  Téléchargez le fichier sample_code. Copiez l'intégralité du contenu du fichier sample_code dans le fichier lib.rs du répertoire src dans Cloud Shell.

Remarques : Le fichier lib.rs est l'emplacement de votre code source. Le code source doit être écrit dans le langage de programmation RUST. Pour obtenir d'autres exemples de code, veuillez consulter network-actions-recipes.

Dans cet atelier de programmation, notre code vérifie que chaque requête HTTP contient un en-tête d'autorisation avec la valeur "secret". Si la requête ne contient pas cet en-tête, une réponse HTTP 403 (Interdit) est générée.

8. Une fois vos modifications effectuées, le fichier lib.rs devrait se présenter à peu près comme suit :

use log::info;
use proxy_wasm::traits::*;
use proxy_wasm::types::*;

...

struct DemoPlugin;

impl HttpContext for DemoPlugin {
    fn on_http_request_headers(&mut self, _: usize, _: bool) -> Action {
        if self.get_http_request_header("Authorization") == Some(String::from("secret")) {
            info!("Access granted.");
            Action::Continue
        } else {
            self.send_http_response(403, vec![], Some(b"Access forbidden.\n"));
            Action::Pause
        }
    }
}

impl Context for DemoPlugin {}

9. Maintenant que nous avons configuré le fichier manifeste Cargo.toml et écrit notre code Proxy-Wasm dans le fichier lib.rs , nous pouvons créer notre plug-in Proxy-Wasm.

cargo build --release --target wasm32-wasi

Une fois la compilation terminée, un message semblable à celui-ci s'affiche :

Finished release [optimized] target(s) in 1.01s

Vérifions également le répertoire target et vérifions que les fichiers ont été créés :

ls ./target

Vous obtiendrez le résultat suivant :

CACHEDIR.TAG release wasm32-wasi

Publier un plug-in Proxy-Wasm dans Artifact Registry

Nous allons maintenant publier notre plug-in Proxy-Wasm dans le dépôt Artifact Registry que vous avez créé précédemment afin qu'il puisse être déployé sur Media CDN.

Nous empaquetons d'abord les plug-ins Proxy-Wasm dans une image de conteneur.

1. Créez un fichier Dockerfile dans le même répertoire my-wasm-plugin, avec le contenu suivant :

FROM scratch 
COPY target/wasm32-wasi/release/my_wasm_plugin.wasm plugin.wasm

2. Ensuite, créez l'image du conteneur :

docker build --no-cache --platform wasm -t my-wasm-plugin .

Attention : Si vous utilisez Apple Silicon (architecture basée sur ARM) ou tout autre processeur non x86, vous devez d'abord activer la prise en charge de WASM sur Docker (https://docs.docker.com/desktop/wasm/#turn-on-wasm-workloads), puis exécuter la commande suivante pour créer l'image de conteneur.

(Processeurs non x86 uniquement) Créez ensuite l'image du conteneur :

docker build --no-cache --platform wasm --provenance=false -t my-wasm-plugin . 

Sortie

[+] Building 0.2s (5/5) FINISHED                                     docker:default
...

3. Ensuite, publiez ou "transférez" votre plug-in Proxy-Wasm vers Artifact Registry. Nous allons taguer notre image de conteneur avec le tag "prod".

Remarques : Artifact Registry utilise une convention d'attribution de noms pour identifier les dépôts et les images.

Le nom complet d'une image Docker dans un dépôt est au format suivant :

LOCATION-docker.pkg.dev/PROJECT-ID/REPOSITORY/IMAGE:TAG

docker tag my-wasm-plugin $LOCATION-docker.pkg.dev/$PROJECT_ID/$REPOSITORY/my-wasm-plugin:prod

Nous allons maintenant transférer l'image de conteneur "prod" taguée vers le dépôt.

docker push $LOCATION-docker.pkg.dev/$PROJECT_ID/$REPOSITORY/my-wasm-plugin:prod

Résultat :

The push refers to repository 
...
8564ddd9910a: Pushed 
prod: digest: sha256:f3ae4e392eb45393bfd9c200cf8c0c261762f7f39dde5c7cd4b9a8951c6f2812 size: 525

Attention : Assurez-vous d'avoir configuré gcloud en tant qu'assistant d'identification pour le domaine Artifact Registry associé à l'emplacement du dépôt.

Si vous obtenez une erreur "Autorisation refusée" lorsque vous transférez le conteneur vers Artifact Registry, revenez à la section Configurer Artifact Registry pour les extensions de service et exécutez à nouveau la commande gcloud auth.

Vérifions maintenant que l'image de conteneur du plug-in Proxy-Wasm a bien été transférée vers Artifact Registry. Vous devriez obtenir un résultat semblable à celui-ci :

gcloud artifacts docker images list $LOCATION-docker.pkg.dev/$PROJECT_ID/$REPOSITORY/my-wasm-plugin --include-tags

Résultat :

Listing items under project 
...
IMAGE                                         DIGEST           TAGS  CREATE_TIME          UPDATE_TIME
<LOCATION>-docker.pkg.dev/.../my-wasm-plugin  sha256:08c12...  prod  2021-11-10T23:31:27  2021-11-10T23:31:27

Associer un plug-in Proxy-Wasm à votre déploiement Media CDN

Nous sommes maintenant prêts à associer le plug-in Proxy-Wasm à votre déploiement Media CDN.

Les plug-ins Proxy-Wasm sont associés aux routes Media CDN dans la ressource EdgeCacheService.

Attention : La création de chaque ressource Proxy-Wasm peut prendre un certain temps.

Veuillez attendre que le message de confirmation s'affiche avant de passer aux étapes suivantes.

1. Commençons par créer une ressource Wasm-plugin pour notre plug-in Proxy-Wasm.

gcloud alpha service-extensions wasm-plugins create my-wasm-plugin-resource

2. Nous allons ensuite créer un WasmPluginVersion.

gcloud alpha service-extensions wasm-plugin-versions create my-version-1 \
    --wasm-plugin=my-wasm-plugin-resource \
    --image="$LOCATION-docker.pkg.dev/$PROJECT_ID/$REPOSITORY/my-wasm-plugin:prod"

3. Ensuite, nous spécifions la version principale de notre plug-in Proxy-Wasm.

gcloud alpha service-extensions wasm-plugins update my-wasm-plugin-resource \
    --main-version=my-version-1

Vérifions maintenant que le plug-in Proxy-Wasm a bien été associé à l'image de conteneur qui réside dans le dépôt Artifact Registry. Vous devriez obtenir un résultat semblable à celui-ci :

gcloud alpha service-extensions wasm-plugin-versions list --wasm-plugin=my-wasm-plugin-resource

Résultat :

NAME   WASM_IMAGE WASM_IMAGE_DIGEST CONFIG_SIZE  CONFIG_IMAGE CONFIG_IMAGE_DIGEST UPDATE_TIME                                            
c7cfa2 <LOCATION>-docker.pkg.dev/.../my-wasm-plugin@sha256:6d663... ... ... 
...

4. Ensuite, nous créons une ressource WasmAction faisant référence à notre ressource de plug-in Wasm.

gcloud alpha service-extensions wasm-actions create my-wasm-action-resource \
    --wasm-plugin=my-wasm-plugin-resource

Vérifions également que la ressource WasmAction a bien été associée au plug-in Proxy-Wasm. Vous devriez obtenir un résultat semblable à celui-ci :

gcloud alpha service-extensions wasm-actions list

Résultat :

NAME                                     WASMPLUGIN                                            
my-wasm-action-resource                  projects/805782461588/locations/global/wasmPlugins/myenvoyfilter-resource
...

5. Nous devons maintenant exporter la configuration de notre Media CDN EdgeCacheService :

gcloud edge-cache services export media-cdn --destination=my-service.yaml

6. Ouvrez ensuite le fichier my-service.yaml et ajoutez une wasmAction à la routeAction pour l'itinéraire donné, qui fait référence à la ressource WasmPlugin créée précédemment.

wasmAction: "my-wasm-action-resource"

7. Une fois vos modifications effectuées, le fichier my-service.yaml devrait ressembler à ceci :

...

pathMatchers:
  - name: routes
    routeRules:
    - headerAction: {}
      matchRules:
      - prefixMatch: /
      origin: projects/<PROJECT_NUM>/locations/global/edgeCacheOrigins/cloud-storage-origin
      priority: '1'
      routeAction:
        cdnPolicy:
          cacheKeyPolicy: {}
          cacheMode: FORCE_CACHE_ALL
          defaultTtl: 3600s
          signedRequestMode: DISABLED
        wasmAction: "my-wasm-action-resource"
...

8. Nous enregistrons ensuite la configuration mise à jour avec la configuration Proxy-Wasm dans le fichier my-service-with-wasm.yaml.

Attention : Si vous rencontrez une erreur de validation de la configuration lorsque vous importez le fichier YAML modifié dans l'API Edge-Cache Services, vérifiez le fichier YAML et assurez-vous que la ligne wasmAction est ajoutée dans la section routeAction. Veuillez vous assurer d'utiliser uniquement des espaces pour l'indentation. Les tabulations ne sont pas acceptées par YAML.

9. Enfin, nous importons la configuration mise à jour pour l'environnement de production Media CDN :

$ gcloud alpha edge-cache services import media-cdn --source=my-service-with-wasm.yaml

9. Valider le plug-in Service Extensions Proxy-Wasm sur Media CDN

Pour vérifier que votre service est correctement configuré pour mettre en cache le contenu, utilisez l'outil de ligne de commande curl pour émettre des requêtes et vérifier les réponses.

Remarques : La propagation de la modification sur l'ensemble du réseau MediaCDN peut prendre jusqu'à 10 minutes. En attendant, il est possible que vous ne puissiez pas voir l'erreur HTTP 403. Réessayez jusqu'à ce que l'erreur 403 s'affiche.

curl -svo /dev/null "http://IP_ADDRESS/file.txt"

Cette commande doit produire un résultat semblable à celui-ci :

< HTTP/2 403 Forbidden
...
Access forbidden.
...

Maintenant, envoyez à nouveau la requête avec un en-tête d'autorisation et sa valeur secrète.

curl -svo /dev/null "http://IP_ADDRESS/file.txt" -H "Authorization: secret"

Cette commande doit produire un résultat semblable à celui-ci :

< HTTP/2 200 OK
...
media-cdn-service-extensions-test
...

10. Facultatif : Gérer les plug-ins Proxy-Wasm

Mettre à jour un plug-in Proxy-Wasm

Lorsque vous apportez des améliorations ou ajoutez de nouvelles fonctionnalités à vos plug-ins Proxy-Wasm, vous devez déployer vos plug-ins mis à jour sur Media CDN. Vous trouverez ci-dessous la procédure à suivre pour déployer une version mise à jour d'un plug-in.

Par exemple, vous pouvez mettre à jour l'exemple de code du plug-in pour évaluer l'en-tête "Authorization" par rapport à une autre valeur d'authentification, en modifiant le code comme suit.

Commencez par mettre à jour le fichier source src/lib.rs avec le code ci-dessous :

use log::{info, warn};
use proxy_wasm::traits::*;
use proxy_wasm::types::*;

...

struct DemoPlugin;

impl HttpContext for DemoPlugin {
    fn on_http_request_headers(&mut self, _: usize, _: bool) -> Action {
        if self.get_http_request_header("Authorization") == Some(String::from("another_secret")) {
            info!("Access granted.");
            Action::Continue
        } else {
            warn!("Access forbidden.");
            self.send_http_response(403, vec![], Some(b"Access forbidden.\n"));
            Action::Pause
        }
    }
}

impl Context for DemoPlugin {}

Ensuite, créez, packagez et publiez le plug-in mis à jour :

cargo build --release --target wasm32-wasi
docker build --no-cache --platform wasm -t my-wasm-plugin .
docker tag my-wasm-plugin $LOCATION-docker.pkg.dev/$PROJECT_NUM/$REPOSITORY/my-wasm-plugin:prod
docker push $LOCATION-docker.pkg.dev/$PROJECT_NUM/$REPOSITORY>/my-wasm-plugin:prod

Une fois l'image de conteneur mise à jour dans Artifact Registry, nous devons créer une version WasmPluginVersion, puis mettre à jour la version principale de WasmPlugin pour faire référence à la nouvelle version.

gcloud alpha service-extensions wasm-plugin-versions create my-version-2 \
    --wasm-plugin=my-wasm-plugin-resource \
   --image="$LOCATION-docker.pkg.dev/$PROJECT_NUM/$REPOSITORY>/my-wasm-plugin:prod"

gcloud alpha service-extensions wasm-plugins update my-wasm-plugin-resource \
    --main-version=my-version-2

Vous avez maintenant mis à jour la version de l'image de conteneur à importer depuis Artifact Registry et à déployer dans votre déploiement Media CDN.

Effectuer un rollback vers une version précédente

Pour revenir à une version précédente d'un plug-in, vous pouvez mettre à jour la ressource de plug-in Wasm afin de faire référence à une version antérieure.

Tout d'abord, nous listons les versions disponibles :

gcloud alpha service-extensions wasm-plugin-versions list --wasm-plugin=my-wasm-plugin-resource

Vous devriez obtenir le résultat suivant :

NAME   WASM_IMAGE WASM_IMAGE_DIGEST CONFIG_SIZE  CONFIG_IMAGE CONFIG_IMAGE_DIGEST UPDATE_TIME                                            
c7cfa2 <LOCATION>-docker.pkg.dev/.../my-wasm-plugin@sha256:6d663... ... ... 
a2a8ce <LOCATION>-docker.pkg.dev/.../my-wasm-plugin@sha256:08c12... ... ... 

Ensuite, nous mettons à jour la ressource du plug-in Wasm pour référencer la version précédente, "a2a8ce" :

$ gcloud alpha service-extensions wasm-plugins update my-wasm-plugin-resource \
    --main-version="a2a8ce"

Une fois l'opération réussie, le résultat suivant doit s'afficher :

✓ WASM Plugin [my-wasm-plugin-resource] is now serving version "a2a8ce"

Étant donné que Media CDN enregistre le résumé de l'image Docker chaque fois qu'une nouvelle ressource de plug-in Wasm est créée, la restauration utilisera la version de votre code qui était exécutée avant le dernier déploiement.

gcloud alpha service-extensions wasm-plugins describe my-wasm-plugin-resource \
  --expand-config

Pour la version "a2a8ce", il s'agit de la version avec le condensé sha256:08c12… :

name: "my-wasm-plugin-resource"
mainVersion: "a2a8ce"
mainVersionDetails:
  image: "<LOCATION>-docker.pkg.dev/<PROJECT>/<REPOSITORY>/my-wasm-plugin"
  imageDigest: "<LOCATION>-docker.pkg.dev/<PROJECT>/<REPOSITORY>/my-wasm-plugin@sha256:08c121dd7fd1e4d3a116a28300e9fc1fa41b2e9775620ebf3d96cb7119bd9976"

Supprimer un WasmAction et un WasmPlugin

Pour supprimer un WasmAction, un WasmPlugin et les WasmPluginVersions associés, veuillez suivre ces étapes.

Commencez par supprimer la référence à WasmAction dans la configuration Media CDN EdgeCacheService.

Ligne de référence à supprimer :

wasmAction: "my-wasm-action-resource"

Ensuite, nous mettons à jour la configuration EdgeCacheService modifiée.

gcloud alpha edge-cache services import prod-media-service --source=my-service.yaml

Ensuite, définissez la version principale de votre WasmPlugin sur une chaîne vide ("").

gcloud alpha service-extensions wasm-plugins update my-wasm-plugin-resource --main-version=

""

Enfin, suivez les étapes de suppression ci-dessous dans l'ordre.

gcloud alpha service-extensions wasm-actions delete my-wasm-action-resource

gcloud alpha service-extensions wasm-plugin-versions delete my-version \ --wasm-plugin=my-wasm-plugin-resource

gcloud alpha service-extensions wasm-plugins delete my-wasm-plugin-resource

11. Nettoyer l'environnement de l'atelier

Une fois l'atelier de programmation terminé, n'oubliez pas de nettoyer les ressources de l'atelier. Sinon, elles continueront de s'exécuter et d'engendrer des coûts.

Les commandes suivantes suppriment le service Media CDN EdgeCache, la configuration EdgeCache et le plug-in d'extensions de service. Suivez les étapes de suppression ci-dessous dans l'ordre.

gcloud edge-cache services delete media-cdn

gcloud edge-cache origins delete cloud-storage-origin

gcloud alpha service-extensions wasm-actions delete my-wasm-action-resource

gcloud alpha service-extensions wasm-plugins update my-wasm-plugin-resource --main-version=""

gcloud alpha service-extensions wasm-plugin-versions delete my-version-1 --wasm-plugin=my-wasm-plugin-resource

gcloud alpha service-extensions wasm-plugins delete my-wasm-plugin-resource

gcloud artifacts repositories delete service-extension-$PROJECT_ID --location=$LOCATION

Chacune des commandes ci-dessus devrait vous demander de confirmer la suppression de la ressource.

12. Félicitations !

Félicitations, vous avez terminé l'atelier de programmation sur les extensions de service sur Media CDN.

Points abordés

• Configurer Media CDN avec un bucket Cloud Storage défini comme origine
• Créer un plug-in d'extension de service avec une authentification HTTP personnalisée et l'associer à Media CDN
• Valider que le plug-in Service Extension fonctionne comme prévu
• (Facultatif) Découvrez comment gérer un plug-in d'extension de service, par exemple comment mettre à jour, référencer, rétablir et supprimer une version spécifique d'un plug-in.

Et ensuite ?

Découvrez quelques-uns des ateliers de programmation...

• Ajouter des notifications push à une application Web
• Créer une PWA à l'aide de Workbox

Complément d'informations

• Chargement de service workers hautes performances
• Stratégies de mise en cache des service workers en fonction des types de requêtes

Documents de référence

• Documentation sur le fichier manifeste d'application Web
• Propriétés du fichier manifeste d'application Web (MDN)
• Installer et ajouter à l'écran d'accueil
• Présentation des service workers
• Cycle de vie du service worker
• Chargement de service workers hautes performances
• Livre de recettes hors connexion