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 le contenu fréquemment consulté au plus près des utilisateurs finaux, en interrompant les connexions au plus près des clients, en réutilisant les connexions jusqu'à l'origine et en adoptant des protocoles et personnalisations de réseau modernes.

Media CDN, le réseau périphérique mondial de GCP pour la diffusion de contenus multimédias, offre de nombreuses Les fonctionnalités de base sont destinées à répondre aux cas d'utilisation les plus courants, mais il est possible que certaines de vos exigences ne soient pas couvertes par cet ensemble de fonctionnalités essentielles.

Les extensions de service pour Media CDN, parfois également 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 débloque des cas d'utilisation supplémentaires : normalisation des clés de cache, authentification et révocation des jetons, champs de journaux personnalisés supplémentaires, tests A/B, page d'erreur personnalisée, etc.

Objectifs de l'atelier

Dans cet atelier de programmation, vous allez découvrir les étapes à suivre pour déployer un environnement de diffusion CDN compatible avec Edge Compute, avec Media CDN (CDN) + Extensions de service (programmabilité Edge) + 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
• Comment vérifier que le plug-in d'extension de service fonctionne comme prévu
• (Facultatif) Gestion d'un plug-in d'extension de service (mise à jour, référencement, rollback, suppression d'une version spécifique du plug-in, etc.)

Prérequis

• Connaissances de base sur la mise en réseau et le protocole HTTP
• Connaissances de base de la ligne de commande Unix/Linux

2. Avant de commencer

Demande de liste d'autorisation Media CDN et Liste d'autorisation des extensions de service

Attention: Assurez-vous que votre projet figure sur la liste d'autorisation pour Media CDN et les extensions de service pour Media CDN. Vous ne pourrez pas terminer cet atelier si votre projet ne figure pas sur la liste d'autorisation.

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

• Si vous souhaitez demander l'accès à la fois à Media CDN et aux extensions de service pour Media CDN, veuillez contacter l'équipe chargée de votre compte Google 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 chefs de projet pour Media CDN et les extensions de service afin de leur 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 IAM et Accès

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

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

Dans Cloud Shell, assurez-vous que vos 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

Activer Media CDN et API d'extensions de service via les 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 d'emplacements tels qu'un bucket Cloud Storage, un emplacement de stockage tiers ou tout point de terminaison HTTP(HTTPS) accessible publiquement.

Dans cet atelier de programmation, nous stockerons le contenu dans un bucket Cloud Storage.

Remarque:Les noms des buckets Cloud Storage doivent être uniques. Pour éviter tout conflit, nous allons utiliser 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

Si vous le souhaitez, vous pouvez créer un bucket Cloud Storage à l'aide de l'IUG 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. - i.e. "mediacdn-bucket-$PROJECT_ID".
4. Conservez les valeurs par défaut des autres paramètres.
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éer un fichier dans Cloud Shell, puis l'importer dans le bucket à l'aide de gsutil

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

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

Remarque:Media CDN est compatible avec les buckets privés comme 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. Autoriser Media CDN à accéder 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 comprend deux ressources principales:

• EdgeCacheService, responsable de la configuration orientée client (TLS, adressage IP), du routage, de la configuration CDN (modes de cache, valeurs TTL, signature) et des règles de sécurité
• EdgeCacheOrigin, responsable de la configuration par origine pour toute origine 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 d'origine de la mise en cache périphérique.
5. Sous "Origin address" (Adresse de départ) :
6. choisissez "Sélectionner un bucket Google Cloud Storage".
7. PARCOURIR le bucket Cloud Storage nommé "mediacdn-bucket-$PROJECT_ID".
8. cliquez sur "SÉLECTIONNER".
9. Conservez les valeurs par défaut des autres paramètres.
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 "Origins".

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ÉBERGEMENT.
6. Saisissez le caractère générique "*" dans le champ "Hôtes".

7. Cliquez sur AJOUTER UNE RÈGLE DE ROUTE.
8. Dans le champ "Priorité", indiquez "1".
9. Cliquez sur AJOUTER UNE CONDITION DE CORRESPONDANCE. Pour "Correspondance de chemin", sélectionnez "Correspondance de préfixe". comme Type de correspondance, spécifiez "/" dans le champ "Correspondance de chemin", puis cliquez sur "OK".
10. Sélectionnez Extraire d'une origine sous "Action principale", puis sélectionnez l'origine que vous avez configurée dans la liste déroulante.

11. Cliquez sur CONFIGURATIONS AVANCÉES pour étendre d'autres options de configuration.
12. Dans l'action de routage, cliquez sur AJOUTER UN ÉLÉMENT. Ensuite, procédez comme suit :
13. Dans "Type", sélectionnez "Règle CDN".
14. Pour le mode Cache, sélectionnez "Forcer la mise en cache".
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 nouvellement créée apparaît sur la page "Services" dans 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, envoyez des requêtes et vérifiez les réponses à l'aide de l'outil de ligne de commande curl.

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

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

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

Vous venez de créer un déploiement MediaCDN avec Cloud Storage comme origine.

7. Configurer Artifact Registry pour les extensions de service

Avant de créer une extension de service, nous devons configurer Artifact Registry. Artifact Registry est le gestionnaire de packages universel de Google Cloud qui permet de 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 sur votre déploiement Media CDN.

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

Nous allons utiliser la commande gcloudartifact 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

Si vous le souhaitez, vous pouvez créer un Repository à l'aide de l'IUG comme suit:

1. Dans la console Google Cloud, accédez à la page Artifact Registry.
2. Cliquez sur le bouton + CRÉER UN DÉPÔT.
3. Saisissez un nom pour le dépôt. Exemple : "service-extension-$PROJECT_ID".
4. Format : "Docker" Mode - "Standard", Type d'emplacement - "Région" et 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 de transférer et d'extraire des packages à l'aide de ce dépôt.

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

Sortie :

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

8. Configurer des extensions de service sur Media CDN

Nous allons maintenant voir 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 Authorization 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".

Petit rappel sur les extensions de service : trois ressources clés sont disponibles : WasmAction, WasmPlugin et WasmPluginVersion.

• Une ressource WasmAction est ce qui est associé à votre service Media CDN EdgeCacheService. 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 référence une image de conteneur provenant d'Artifact Registry. Lorsque vous apportez des modifications à vos plug-ins proxy-wasm, vous créez différentes versions WasmPluginVersions.

Veuillez vous reporter au schéma 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 de la page https://www.rust-lang.org/tools/install.

Attention: Veillez à suivre les instructions d'invite pour installer la chaîne d'outils Rust.

Si vous obtenez le message "-bash: rustup: command not found" lors de l'exécution de "rustup", essayez source "$HOME/.cargo/env". ' pour actualiser l'environnement PATH dans Cloud Shell.

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

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

rustup target add wasm32-wasi

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

cargo new --lib my-wasm-plugin

Sortie :

Created library `my-wasm-plugin` package

4. Saisissez le répertoire my-wasm-plugin. Vous devriez y trouver un fichier Cargo.toml et un répertoire src.

cd my-wasm-plugin
ls

Sortie :

Cargo.toml  src

5. Configurez ensuite votre package Rust en modifiant le fichier Cargo.toml. Après la ligne [dependencies] dans le fichier Cargo.toml, ajoutez ce qui suit:

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 les modifications effectuées, le fichier Cargo.toml devrait se présenter 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 de Cloud Shell.

Remarque: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 recettes de code, consultez network-actions-recipes.

Dans cet atelier de programmation, notre code vérifie que chaque requête HTTP contient un en-tête "Authorization" avec la valeur "secret" et génère une réponse "HTTP 403 Forbidden" si la requête ne contient pas cet en-tête.

8. Une fois les modifications effectuées, le fichier lib.rs devrait se présenter 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 les fichiers créés:

ls ./target

Le résultat s'affiche comme suit:

CACHEDIR.TAG release wasm32-wasi

Publier un plug-in Proxy-Wasm sur 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 commençons par empaqueter les plug-ins Proxy-Wasm dans une image de conteneur.

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

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

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

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

Attention: Si vous utilisez Apple Silicon (architecture ARM) ou tout autre processeur autre que x86, vous devez d'abord activer la compatibilité WASM dans 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 envoyez votre plug-in Proxy-Wasm vers Artifact Registry. Nous ajouterons à notre image de conteneur le tag "prod" .

Remarque: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 dans le dépôt.

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

Sortie :

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

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

Si un message "Autorisation refusée" s'affiche lors du transfert du conteneur vers Artifact Registry, revenez à la page 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

Sortie :

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

Vous êtes maintenant prêt à 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. Tout d'abord, nous créons une ressource de plug-in Wasm pour notre plug-in Proxy-Wasm.

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

2. Nous créons ensuite une version 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. Nous allons ensuite spécifier 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é à Container Image 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

Sortie :

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. Nous créons ensuite 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

Sortie :

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

5. Nous devons maintenant exporter la configuration de notre service 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 action wasmAction à routeAction pour la route donnée. Celle-ci fait référence à la ressource WasmPlugin créée précédemment.

wasmAction: "my-wasm-action-resource"

7. Une fois les modifications effectuées, le fichier my-service.yaml devrait se présenter comme suit:

...

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 lors de l'importation du fichier yaml modifié dans l'API des services de mise en cache périphérique, vérifiez le fichier yaml et assurez-vous que la ligne wasmAction a été ajoutée à la section routeAction. Veillez à n'utiliser que des espaces pour les retraits. 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 Proxy-Wasm d'extensions de service sur Media CDN

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

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

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

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

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

Maintenant, émettez à nouveau la requête avec un en-tête Authorization et sa valeur de secret

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

La 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 que vous 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 afin d'é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, compilez, empaquetez 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 un nouveau WasmPluginVersion, puis mettre à jour la version –main-version du WasmPlugin pour référencer 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 à la mettre en ligne sur votre déploiement Media CDN.

Effectuer un rollback vers une version précédente

Pour effectuer un rollback vers une version précédente d'un plug-in, vous pouvez mettre à jour la ressource de plug-in Wasm afin qu'elle fasse référence à une version précédente.

Tout d'abord, nous indiquons 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 qu'elle fasse référence à 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 condensé de l'image de votre image Docker chaque fois qu'une ressource de plug-in Wasm est créée, le rollback utilise la version de votre code qui était en cours d'exécution 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 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"

Suppression d'un élément WasmAction et WasmPlugin

Pour supprimer un WasmAction, un WasmPlugin et les WasmPluginVersions associés, procédez comme suit.

Commencez par supprimer la référence à WasmAction dans votre 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

Remplacez ensuite la version principale de WasmPlugin par une chaîne "".

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

""

Enfin, effectuez 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 fonctionner et généreront des coûts.

Les commandes suivantes suppriment le service Media CDN EdgeCache, la configuration EdgeCache et le plug-in d'extensions de service. Effectuez 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
• Comment vérifier que le plug-in d'extension de service fonctionne comme prévu
• (Facultatif) Gestion d'un plug-in d'extension de service (mise à jour, référencement, rollback, suppression d'une version spécifique du plug-in, etc.)

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 worker hautes performances
• Stratégies de mise en cache des service workers basées sur les types de requêtes

Documents de référence

• Documentation sur les fichiers manifestes d'application Web
• Propriétés du fichier manifeste d'application Web (MDN)
• Installation et Ajouter à l'écran d'accueil
• Présentation de Service Worker
• Cycle de vie d'un service worker
• Chargement de service worker hautes performances
• Livre de recettes hors connexion