Laboratorium: rozszerzenia usług w Media CDN

1. Wprowadzenie

Last Updated: 2024-05-01

Sieci dystrybucji treści (CDN) zwiększają wydajność użytkowników, przechowując w pamięci podręcznej często używane treści bliżej użytkowników końcowych, zamykając połączenia bliżej klientów, ponownie wykorzystując połączenia z punktem początkowym oraz stosując nowoczesne protokoły sieciowe i dostosowania.

Media CDN, globalna sieć brzegowa GCP do strumieniowego przesyłania multimediów, oferuje wiele wbudowanych lub „podstawowych” funkcji.Funkcje podstawowe są przeznaczone do obsługi najczęstszych przypadków użycia, ale możesz mieć też wymagania, które nie są spełniane przez ten podstawowy zestaw funkcji.

Service Extensions dla Media CDN, czasami nazywane też programowaniem na brzegu sieci, umożliwiają uruchamianie własnego kodu na brzegu sieci w celu dostosowania działania Media CDN. Umożliwia to dodatkowe zastosowania, takie jak normalizacja klucza pamięci podręcznej, uwierzytelnianie za pomocą tokena niestandardowego i unieważnianie tokena, dodatkowe niestandardowe pola logów, testy A/B i niestandardowa strona błędu.

Co utworzysz

W tym laboratorium dowiesz się, jak wdrożyć środowisko dostarczania treści CDN z obliczeniami brzegowymi za pomocą Media CDN (CDN) + Service Extensions (programowalność na brzegu sieci) + Cloud Storage (źródło CDN).

Czego się nauczysz

• Konfigurowanie Media CDN z zasobnikiem Cloud Storage ustawionym jako punkt początkowy
• Tworzenie wtyczki rozszerzenia usługi z niestandardowym uwierzytelnianiem HTTP i powiązywanie jej z Media CDN
• Jak sprawdzić, czy wtyczka Service Extension działa prawidłowo
• (opcjonalnie) Jak zarządzać wtyczką rozszerzenia usługi, np. aktualizować, odwoływać się do niej, cofać zmiany i usuwać konkretną wersję wtyczki.

Czego potrzebujesz

• Podstawowa znajomość sieci i protokołu HTTP
• Podstawowa znajomość wiersza poleceń w systemach Unix i Linux

2. Zanim zaczniesz

Request for Media CDN Allowlist & Service Extensions Allowlist

Uwaga: upewnij się, że Twój projekt znajduje się na liście dozwolonych projektów w przypadku Media CDN i Service Extensions dla Media CDN. Jeśli Twój projekt nie znajduje się na liście dozwolonych, nie będziesz w stanie ukończyć tego modułu.

Zanim zaczniesz, musisz zadbać o to, aby Twój projekt został dodany do listy dozwolonych w ramach prywatnej wersji testowej zarówno Media CDN, jak i Service Extensions dla Media CDN.

• Aby poprosić o dostęp do Media CDN i Service Extensions dla Media CDN, skontaktuj się z zespołem ds. kont Google, który w Twoim imieniu utworzy prośbę o dostęp do Media CDN i Service Extensions.

Uwagi: jeśli pracujesz w Google i chcesz przetestować Service Extensions w Media CDN, skontaktuj się z menedżerami produktów Media CDN i Service Extensions, aby poprosić o dostęp.

3. Konfiguracja i wymagania

Uruchamianie Cloud Shell

Z Google Cloud można korzystać zdalnie na laptopie, ale w tym ćwiczeniu użyjesz Google Cloud Shell, czyli środowiska wiersza poleceń działającego w chmurze.

W konsoli GCP kliknij ikonę Cloud Shell na pasku narzędzi w prawym górnym rogu:

Uzyskanie dostępu do środowiska i połączenie się z nim powinno zająć tylko kilka chwil. Po zakończeniu powinno wyświetlić się coś takiego:

Ta maszyna wirtualna zawiera wszystkie potrzebne narzędzia dla programistów. Zawiera również stały katalog domowy o pojemności 5 GB i działa w Google Cloud, co znacznie zwiększa wydajność sieci i usprawnia proces uwierzytelniania. Wszystkie zadania w tym module możesz wykonać w przeglądarce.

Zanim zaczniesz

Role i dostęp

Aby utworzyć zasoby Media CDN i Artifact Registry, musisz mieć te uprawnienia Identity and Access Management (IAM):

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

W Cloud Shell sprawdź, czy zmienne środowiskowe project_id, project_num, location i repository są skonfigurowane.

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

włączyć interfejsy API,

Włącz interfejsy API Media CDN i Service Extensions za pomocą tych poleceń:

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. Tworzenie zasobnika Cloud Storage

Treści Media CDN mogą pochodzić z lokalizacji takich jak zasobnik Cloud Storage, lokalizacja pamięci innej firmy lub dowolny publicznie dostępny punkt końcowy HTTP(S).

W tym ćwiczeniu będziemy przechowywać treści w zasobniku Cloud Storage.

Uwagi: nazwy zasobników Cloud Storage muszą być globalnie unikalne. Aby uniknąć konfliktów, użyjemy zmiennej środowiskowej $PROJECT_ID jako części nazwy zasobnika.

Do utworzenia zasobnika użyjemy polecenia gsutil mb.

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

Opcjonalnie możesz utworzyć zasobnik Cloud Storage za pomocą interfejsu GUI w ten sposób:

1. W konsoli Google Cloud otwórz stronę Cloud Storage.
2. Kliknij przycisk UTWÓRZ.
3. Wpisz nazwę zasobnika. – np. „mediacdn-bucket-$PROJECT_ID”.
4. Pozostałe ustawienia pozostaw domyślne.
5. Kliknij przycisk UTWÓRZ.

5. Przesyłanie obiektu testowego do zasobnika Cloud Storage

Teraz prześlemy obiekt do zasobnika Cloud Storage.

1. Utwórz plik w Cloud Shell, a następnie prześlij go do zasobnika za pomocą polecenia gsutil.

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

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

Uwagi: Media CDN obsługuje prywatne zasobniki jako źródło. Aby zezwolić usłudze Media CDN na dostęp do treści z prywatnego zasobnika Cloud Storage, musisz skonfigurować IAM, aby przyznać kontu usługi Media CDN dostęp objectViewer.

Konto usługi ma następujący format:

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

2. Przyznawanie Media CDN dostępu do zasobnika

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

6. Konfigurowanie Media CDN

Następnie utworzymy konfigurację Media CDN.

Każda konfiguracja Media CDN składa się z 2 głównych zasobów:

• EdgeCacheService, która odpowiada za konfigurację widoczną dla klienta (TLS, adresowanie IP), routing, konfigurację CDN (tryby pamięci podręcznej, TTL, podpisywanie) i zasady bezpieczeństwa.
• EdgeCacheOrigin, który odpowiada za konfigurację poszczególnych źródeł w przypadku dowolnego źródła opartego na protokole HTTP, a także za warunki ponawiania prób, gdy treści są niedostępne lub nie można się z nimi połączyć.

Konfigurowanie źródła tymczasowego przechowywania danych na serwerach brzegowych

Teraz utwórzmy punkt początkowy, który będzie wskazywać utworzony przed chwilą zasobnik Cloud Storage.

1. W konsoli Google Cloud otwórz stronę Media CDN.
2. Kliknij kartę ŹRÓDŁA.
3. Kliknij UTWÓRZ PUNKT POCZĄTKOWY.
4. Jako nazwę źródła tymczasowego przechowywania danych na serwerach brzegowych wpisz „cloud-storage-origin”.
5. W sekcji Adres źródła:
6. kliknij „Wybierz zasobnik Cloud Storage”.
7. Przejdź do zasobnika Cloud Storage o nazwie „mediacdn-bucket-$PROJECT_ID”.
8. kliknij WYBIERZ.
9. Pozostałe ustawienia pozostaw domyślne.
10. Kliknij UTWÓRZ PUNKT POCZĄTKOWY.

Nowo utworzony zasób EdgeCacheOrigin pojawi się na liście punktów początkowych w projekcie na stronie Punkty początkowe.

Konfigurowanie usługi tymczasowego przechowywania danych na serwerach brzegowych

1. W konsoli Google Cloud otwórz stronę Media CDN.
2. Kliknij kartę USŁUGI.
3. Kliknij UTWÓRZ USŁUGĘ.
4. Wpisz niepowtarzalną nazwę usługi, np. „media-cdn”, a następnie kliknij Dalej.

5. W sekcji Routing (Routing) kliknij ADD HOST RULE (DODAJ REGUŁĘ HOSTÓW).
6. W polu Hosty wpisz symbol wieloznaczny „*”.

7. Kliknij DODAJ REGUŁĘ TRASY.
8. W polu Priorytet podaj „1”.
9. Kliknij DODAJ WARUNEK DOPASOWANIA, w sekcji Dopasowanie ścieżki wybierz „Dopasowanie prefiksu” jako Typ dopasowania, w polu Dopasowanie ścieżki wpisz „/”, a potem kliknij Gotowe.
10. W sekcji Działanie główne kliknij Pobierz z punktu początkowego, a następnie wybierz skonfigurowany przez Ciebie punkt początkowy z listy.

11. Kliknij ZAAWANSOWANE KONFIGURACJE, aby wyświetlić więcej opcji konfiguracji.
12. W sekcji Działanie związane z trasą kliknij DODAJ ELEMENT. Następnie wykonaj te czynności:
13. W polu Typ wybierz „Zasada CDN”.
14. W przypadku opcji Tryb pamięci podręcznej wybierz „Wymuś zapisywanie wszystkiego w pamięci podręcznej”.
15. W pozostałych miejscach pozostaw wartości domyślne.
16. Kliknij Gotowe.
17. Kliknij Zapisz.

18. Kliknij UTWÓRZ USŁUGĘ.

Nowo utworzony zasób EdgeCacheService pojawi się na stronie Usługi na liście usług w Twoim projekcie.

Pobieranie adresu IP MediaCDN i testowanie

1. W konsoli Google Cloud otwórz stronę Media CDN.
2. Otwórz Media CDN
3. Kliknij kartę Usługi.
4. W przypadku usługi sprawdź kolumnę Adresy.

Aby sprawdzić, czy usługa jest prawidłowo skonfigurowana do buforowania treści, użyj narzędzia wiersza poleceń curl do wysyłania żądań i sprawdzania odpowiedzi.

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

Polecenie powinno wyświetlić dane wyjściowe podobne do tych poniżej:

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

Udało Ci się utworzyć wdrożenie MediaCDN z Cloud Storage jako punktem początkowym.

7. Konfigurowanie Artifact Registry pod kątem rozszerzeń usługi

Zanim utworzysz rozszerzenia usługi, musisz skonfigurować Artifact Registry. Artifact Registry to uniwersalny system zarządzania pakietami w Google Cloud, który służy do zarządzania artefaktami kompilacji. Wtyczki rozszerzeń usług (Proxy-Wasm) są publikowane w Artifact Registry. Po opublikowaniu w Artifact Registry wtyczki Proxy-Wasm można wdrożyć w Media CDN.

Uwagi: nazwy repozytoriów Artifact Registry muszą być globalnie unikalne. Aby uniknąć konfliktów, użyjemy zmiennej środowiskowej $PROJECT_ID jako części nazwy repozytorium.

Do utworzenia repozytorium użyjemy polecenia gcloud artifacts repositories create.

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

Opcjonalnie możesz utworzyć repozytorium za pomocą interfejsu GUI w ten sposób:

1. W konsoli Google Cloud otwórz stronę Artifact Registry.
2. Kliknij przycisk + UTWÓRZ REPOZYTORIUM.
3. Wpisz nazwę repozytorium, np. „service-extension-$PROJECT_ID”.
4. Format – „Docker”, tryb – „Standard”, typ lokalizacji – „Region”, a następnie wybierz „us-central1 (Iowa)”.
5. Kliknij przycisk UTWÓRZ.

Nowo utworzony zasób repozytorium Artifact Registry powinien pojawić się na stronie Repozytoria.

Po utworzeniu zasobu repozytorium uruchom w Cloud Shell to polecenie, aby skonfigurować klienta Dockera w Cloud Shell do wprowadzania i pobierania pakietów przy użyciu tego repozytorium.

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

Dane wyjściowe:

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

8. Konfigurowanie rozszerzeń usług w Media CDN

Teraz pokażemy, jak napisać i skompilować wtyczkę rozszerzenia usługi (Proxy-Wasm), którą można wdrożyć w Media CDN, używając języka programowania Rust.

W tym przykładzie utworzymy wtyczkę Proxy-Wasm, która sprawdza, czy każde żądanie HTTP zawiera nagłówek Authorization o wartości „secret”. Jeśli żądanie nie zawiera tego nagłówka, wtyczka wygeneruje odpowiedź HTTP 403 Forbidden.

Przypomnienie dotyczące rozszerzeń usług: istnieją 3 główne zasoby: WasmAction, WasmPlugin i WasmPluginVersion.

• Zasób WasmAction jest dołączany do usługi Media CDN EdgeCacheService. WasmAction odwołuje się do zasobu WasmPlugin.
• Zasób WasmPlugin ma główną wersję, która odpowiada obecnie aktywnej wersji WasmPluginVersion.
• WasmPluginVersions odwołuje się do obrazu kontenera z Artifact Registry. W miarę wprowadzania zmian w pluginach proxy-wasm tworzysz różne wersje WasmPluginVersion.

Aby lepiej zrozumieć relacje między tymi zasobami, zapoznaj się z poniższym diagramem.

Napisz i skompiluj wtyczkę rozszerzeń usług

1. Zainstaluj łańcuch narzędzi Rust, postępując zgodnie z instrukcjami na stronie https://www.rust-lang.org/tools/install.

Uwaga: postępuj zgodnie z instrukcjami wyświetlanymi w wierszu poleceń, aby zainstalować łańcuch narzędzi Rust.

Jeśli podczas uruchamiania polecenia „rustup” pojawi się błąd „-bash: rustup: command not found”, spróbuj ponownie załadować środowisko PATH w Cloud Shell, wpisując polecenie „source "$HOME/.cargo/env"”.

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

2. Następnie dodaj obsługę Wasm do łańcucha narzędzi Rust, uruchamiając to polecenie:

rustup target add wasm32-wasi

3. Utwórz pakiet Rust o nazwie my-wasm-plugin:

cargo new --lib my-wasm-plugin

Dane wyjściowe:

Created library `my-wasm-plugin` package

4. Otwórz katalog my-wasm-plugin. Powinien się w nim znajdować plik Cargo.toml i katalog src.

cd my-wasm-plugin
ls

Dane wyjściowe:

Cargo.toml  src

5. Następnie skonfiguruj pakiet Rust, edytując plik Cargo.toml. Po wierszu [dependencies] w pliku Cargo.toml dodaj ten kod:

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. Po wprowadzeniu zmian plik Cargo.toml powinien wyglądać mniej więcej tak:

[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. pobierz plik sample_code. Skopiuj całą zawartość pliku sample_code do pliku lib.rs w katalogu src w Cloud Shell.

Uwagi: plik lib.rs to miejsce, w którym znajduje się kod źródłowy. Kod źródłowy powinien być napisany w języku programowania RUST. Więcej przykładów kodu znajdziesz w network-actions-recipes.

W tym ćwiczeniu w Codelabs nasz kod sprawdza, czy każde żądanie HTTP zawiera nagłówek Authorization o wartości „secret”. Jeśli żądanie nie zawiera tego nagłówka, generuje odpowiedź HTTP 403 Forbidden.

8. Po wprowadzeniu zmian plik lib.rs powinien wyglądać mniej więcej tak:

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. Po skonfigurowaniu pliku manifestu Cargo.toml i napisaniu kodu Proxy-Wasm w pliku lib.rs możemy skompilować wtyczkę Proxy-Wasm.

cargo build --release --target wasm32-wasi

Po pomyślnym zakończeniu kompilacji zobaczysz komunikat podobny do tego:

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

Sprawdźmy też katalog target i sprawdźmy, czy pliki zostały utworzone:

ls ./target

Dane wyjściowe będą wyglądać tak:

CACHEDIR.TAG release wasm32-wasi

Publikowanie wtyczki Proxy-Wasm w Artifact Registry

Teraz opublikujemy wtyczkę Proxy-Wasm w utworzonym wcześniej repozytorium Artifact Registry, aby można było ją wdrożyć w Media CDN.

Najpierw pakujemy wtyczki Proxy-Wasm w obraz kontenera.

1. W tym samym katalogu my-wasm-plugin utwórz plik o nazwie Dockerfile z tą zawartością:

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

2. Następnie skompiluj obraz kontenera:

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

Ostrzeżenie: jeśli używasz procesora Apple Silicon (architektura oparta na ARM) lub innego procesora innego niż x86, musisz najpierw włączyć obsługę WASM w Dockerze (https://docs.docker.com/desktop/wasm/#turn-on-wasm-workloads), a następnie uruchomić to polecenie, aby utworzyć obraz kontenera.

(tylko procesory inne niż x86) Następnie utwórz obraz kontenera:

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

Wyniki

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

3. Następnie opublikuj lub „prześlij” wtyczkę Proxy-Wasm do Artifact Registry. Dodamy do obrazu kontenera tag „prod”.

Uwagi: Artifact Registry używa konwencji nazewnictwa do identyfikacji repozytoriów i obrazów.

Pełna nazwa obrazu Dockera w repozytorium ma format:

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

Teraz wypchniemy otagowany obraz kontenera „prod” do repozytorium.

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

Dane wyjściowe:

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

Ostrzeżenie: upewnij się, że gcloud jest skonfigurowany jako asystent danych logowania w domenie Artifact Registry powiązanej z lokalizacją repozytorium.

Jeśli podczas przesyłania kontenera do Artifact Registry wyświetla się błąd „permission denied” (odmowa uprawnień), wróć do sekcji Konfigurowanie Artifact Registry na potrzeby Service Extensions i ponownie uruchom polecenie gcloud auth.

Teraz sprawdźmy, czy obraz kontenera wtyczki Proxy-Wasm został przesłany do Artifact Registry. Powinny wyświetlić się dane wyjściowe podobne do tych:

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

Dane wyjściowe:

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

Powiązywanie wtyczki Proxy-Wasm z wdrożeniem Media CDN

Teraz możemy powiązać wtyczkę Proxy-Wasm z wdrożeniem Media CDN.

Wtyczki Proxy-Wasm są powiązane z trasami Media CDN w zasobie EdgeCacheService.

Ostrzeżenie: tworzenie każdego zasobu Proxy-Wasm może trochę potrwać.

Zanim przejdziesz do kolejnych kroków, poczekaj, aż pojawi się komunikat o zakończeniu.

1. Najpierw tworzymy zasób Wasm-plugin dla naszej wtyczki Proxy-Wasm.

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

2. Następnie tworzymy 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. Następnie określimy główną wersję wtyczki Proxy-Wasm.

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

Teraz sprawdźmy, czy wtyczka Proxy-Wasm została prawidłowo powiązana z obrazem kontenera znajdującym się w repozytorium Artifact Registry. Powinny pojawić się dane wyjściowe podobne do tych:

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

Dane wyjściowe:

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. Następnie tworzymy zasób WasmAction, który odwołuje się do zasobu wtyczki Wasm.

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

Sprawdźmy też, czy zasób WasmAction został prawidłowo powiązany z wtyczką Proxy-Wasm. Powinny pojawić się wyniki podobne do tych:

gcloud alpha service-extensions wasm-actions list

Dane wyjściowe:

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

5. Teraz musimy wyeksportować konfigurację usługi Media CDN EdgeCacheService:

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

6. Następnie otwórz plik my-service.yaml i dodaj element wasmAction do elementu routeAction dla danej trasy, który odwołuje się do utworzonego wcześniej zasobu WasmPlugin.

wasmAction: "my-wasm-action-resource"

7. Po wprowadzeniu zmian plik my-service.yaml powinien wyglądać mniej więcej tak:

...

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. Następnie zapisujemy zaktualizowaną konfigurację z konfiguracją Proxy-Wasm w pliku my-service-with-wasm.yaml.

Ostrzeżenie: jeśli podczas importowania edytowanego pliku YAML do interfejsu edge-cache services API wystąpi błąd weryfikacji konfiguracji, dokładnie sprawdź plik YAML i upewnij się, że w sekcji routeAction dodano wiersz wasmAction. Pamiętaj, aby do wcięć używać tylko spacji. Tabulatory nie są akceptowane w pliku YAML.

9. Na koniec importujemy zaktualizowaną konfigurację środowiska produkcyjnego Media CDN:

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

9. Weryfikowanie wtyczki Service Extensions Proxy-Wasm w Media CDN

Aby sprawdzić, czy usługa jest prawidłowo skonfigurowana do buforowania treści, użyj narzędzia wiersza poleceń curl do wysyłania żądań i sprawdzania odpowiedzi.

Uwagi: rozpowszechnienie zmiany w całej sieci MediaCDN może potrwać do 10 minut. W tym czasie możesz nie widzieć błędu HTTP 403. Ponawiaj próby, aż pojawi się błąd 403.

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

Polecenie powinno wyświetlić dane wyjściowe podobne do tych poniżej:

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

Teraz ponownie wyślij żądanie z nagłówkiem Authorization i jego wartością secret.

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

Polecenie powinno wyświetlić dane wyjściowe podobne do tych poniżej:

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

10. Opcjonalnie: zarządzanie wtyczkami Proxy-Wasm

Aktualizowanie wtyczki Proxy-Wasm

W miarę wprowadzania ulepszeń lub dodawania nowych funkcji do wtyczek Proxy-Wasm musisz wdrażać zaktualizowane wtyczki w Media CDN. Poniżej opisujemy, jak wdrożyć zaktualizowaną wersję wtyczki.

Możesz na przykład zaktualizować przykładowy kod wtyczki, aby w celu uwierzytelniania porównywać nagłówek Authorization z inną wartością. W tym celu zmodyfikuj kod w ten sposób:

Najpierw zaktualizuj plik źródłowy src/lib.rs za pomocą kodu pokazanego poniżej:

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 {}

Następnie skompiluj, spakuj i opublikuj zaktualizowaną wtyczkę:

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

Gdy obraz kontenera zostanie zaktualizowany w Artifact Registry, musimy utworzyć nową wersję WasmPluginVersion, a następnie zaktualizować główną wersję WasmPlugin, aby odwoływała się do nowej wersji.

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

Wersja obrazu kontenera do zaimportowania z Artifact Registry została zaktualizowana i wdrożona w usłudze Media CDN.

Przywracanie poprzedniej wersji

Aby wycofać zmiany do poprzedniej wersji wtyczki, możesz zaktualizować zasób wtyczki Wasm, aby odwoływał się do poprzedniej wersji.

Najpierw wyświetlamy listę dostępnych wersji:

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

Powinny pojawić się te dane wyjściowe:

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

Następnie aktualizujemy zasób wtyczki Wasm, aby odwoływał się do poprzedniej wersji „a2a8ce”:

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

Po pomyślnym zakończeniu operacji powinny się wyświetlić te dane wyjściowe:

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

Media CDN zapisuje skrót obrazu Dockera za każdym razem, gdy tworzony jest nowy zasób wtyczki Wasm, więc wycofanie zmian spowoduje użycie wersji kodu, która była uruchomiona przed ostatnim wdrożeniem.

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

W przypadku wersji „a2a8ce”, czyli wersji z wartością skrótu 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"

Usuwanie WasmAction i WasmPlugin

Aby usunąć WasmAction, WasmPlugin i powiązane WasmPluginVersions, wykonaj te czynności.

Najpierw usuń odwołanie do WasmAction w konfiguracji Media CDN EdgeCacheService.

Linia referencyjna do usunięcia:

wasmAction: "my-wasm-action-resource"

Następnie aktualizujemy zmodyfikowaną konfigurację EdgeCacheService.

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

Następnie zaktualizuj główną wersję WasmPlugin do pustego ciągu znaków „”.

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

""

Na koniec wykonaj poniższe czynności, aby usunąć konto.

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. Zwalnianie miejsca w środowisku modułu

Po ukończeniu ćwiczenia z programowania nie zapomnij zwolnić miejsca w zasobach laboratorium, w przeciwnym razie będą one nadal działać i generować koszty.

Te polecenia usuną usługę Media CDN EdgeCache, konfigurację EdgeCache i wtyczkę Service Extensions. Wykonaj poniższe czynności w podanej kolejności.

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

Każde z powyższych poleceń powinno wyświetlić prośbę o potwierdzenie usunięcia zasobu.

12. Gratulacje!

Gratulacje! Ćwiczenie Service Extensions w Media CDN zostało ukończone.

Omówione zagadnienia

• Konfigurowanie Media CDN z zasobnikiem Cloud Storage ustawionym jako punkt początkowy
• Tworzenie wtyczki rozszerzenia usługi z niestandardowym uwierzytelnianiem HTTP i powiązywanie jej z Media CDN
• Jak sprawdzić, czy wtyczka Service Extension działa prawidłowo
• (opcjonalnie) Jak zarządzać wtyczką rozszerzenia usługi, np. aktualizować, odwoływać się do niej, cofać zmiany i usuwać konkretną wersję wtyczki.

Co dalej?

Sprawdź te ćwiczenia z programowania:

• Dodawanie powiadomień push do aplikacji internetowej
• Tworzenie aplikacji PWA za pomocą Workbox

Więcej informacji

• Szybkie wczytywanie skryptu service worker
• Strategie buforowania w usłudze Service Worker na podstawie typów żądań

Dokumentacja

• Dokumentacja manifestu aplikacji internetowej
• Właściwości pliku manifestu aplikacji internetowej (MDN)
• Zainstaluj i dodaj do ekranu głównego
• Omówienie skryptu service worker
• Cykl życia Service Workera
• Szybkie wczytywanie skryptu service worker
• Offline Cookbook