Mengonfigurasi origin

Anda dapat mengonfigurasi origin untuk Media CDN dengan berbagai cara. Halaman ini menunjukkan cara mengonfigurasi origin.

Mengonfigurasi bucket Cloud Storage sebagai asal

Media CDN mendukung bucket Cloud Storage sebagai backend untuk konten. Setiap layanan dapat mereferensikan beberapa bucket dengan mengonfigurasi rute untuk host, jalur, dan atribut permintaan lainnya.

Bucket Cloud Storage dikonfigurasi menggunakan URL bucket, seperti gs://my-bucket, sebagai alamat asal saat membuat resource asal.

gcloud edge-cache origins create ORIGIN \
    --origin-address=ADDRESS

Hal ini sama, baik bucket bersifat multi-regional, dual-region, atau regional.

Saat mengonfigurasi layanan, Anda dapat merutekan konten video on demand ke satu bucket dan konten live streaming ke bucket kedua. Hal ini berguna jika Anda memiliki tim yang berbeda untuk mengelola setiap alur kerja. Untuk mengurangi latensi pengisian cache, Anda dapat merutekan region eu-media.example.com ke bucket Cloud Storage multi-regional yang berlokasi di Uni Eropa dan region us-media.example.com (atau mencocokkan jalur, header, atau parameter kueri) ke bucket penyimpanan berbasis di AS dengan cara yang sama.

Untuk kasus yang latensi penulisan sangat penting, seperti live streaming latensi rendah, Anda dapat mengonfigurasi endpoint Cloud Storage regional sedekat mungkin dengan pengguna Anda.

Mengautentikasi permintaan

Untuk mengonfirmasi bahwa permintaan berasal dari Media CDN, gunakan salah satu pendekatan yang didukung berikut:

• Validasi bahwa alamat IP yang terhubung berasal dari rentang pengisian cache Media CDN. Rentang ini digunakan bersama oleh semua pelanggan, tetapi selalu digunakan oleh resource EdgeCacheService saat terhubung ke origin.
• Tambahkan header permintaan kustom dengan nilai token yang Anda validasi di origin (misalnya, nilai 16 byte acak). Origin Anda kemudian dapat menolak permintaan yang tidak menyertakan nilai ini.

Mengonfigurasi protokol origin

Jika origin Anda mendukung HTTP/2, Anda tidak perlu menetapkan protokol secara eksplisit. Untuk asal yang hanya mendukung HTTPS (HTTP/1.1 melalui TLS) atau HTTP/1.1 (tanpa TLS), tetapkan kolom protocol secara eksplisit dengan melakukan hal berikut:

gcloud edge-cache origins update LEGACY_ORIGIN \
    --protocol=HTTPS

Mengonfigurasi bucket Cloud Storage pribadi

Media CDN dapat menarik konten dari endpoint HTTP atau HTTPS yang dapat dijangkau internet. Dalam beberapa kasus, Anda mungkin ingin mewajibkan autentikasi, agar hanya mengizinkan Media CDN menarik konten, dan mencegah akses yang tidak sah. Cloud Storage mendukung hal ini melalui izin IAM.

Untuk origin Cloud Storage, lakukan hal berikut:

• Berikan izin IAM objectViewer akun layanan Media CDN di bucket Cloud Storage yang Anda gunakan sebagai asal.
• Hapus izin allUsers.
• Opsional: Hapus izin allAuthenticatedUsers.

Untuk mengubah izin bucket Cloud Storage, Anda memerlukan peran Storage Admin (roles/storage.admin).

Akun layanan Media CDN dimiliki oleh project Media CDN, dan tidak akan muncul dalam daftar akun layanan project Anda. Akun layanan hanya memberikan akses ke resource Media CDN di project yang Anda izinkan secara eksplisit.

Anda harus membuat setidaknya satu resource Media CDN untuk memicu pembuatan akun layanan. Dalam sebagian besar kasus, ini adalah resource EdgeCacheOrigin yang terhubung ke bucket Cloud Storage Anda.

Untuk memberikan akses Media CDN ke bucket, berikan peran objectViewer ke akun layanan:

gcloud storage buckets add-iam-policy-binding gs://BUCKET \
    --member=serviceAccount:service-PROJECT_NUM@gcp-sa-mediaedgefill.iam.gserviceaccount.com \
    --role=roles/storage.objectViewer

Ganti PROJECT_NUMBER dengan nomor project.

Sebelum menghapus akses publik ke bucket penyimpanan yang ada dan digunakan sebagai origin produksi, tunggu setidaknya 10 menit agar konfigurasi diterapkan.

Gunakan perintah gcloud storage buckets remove-iam-policy-binding untuk menghapus izin yang diberikan kepada peran allUsers untuk bucket tertentu. Misalnya, jika bucket memberikan peran objectViewer kepada allUsers, hapus pemberian akses menggunakan perintah berikut:

gcloud storage buckets remove-iam-policy-binding gs://BUCKET \
    --member=allUsers --role=roles/storage.objectViewer

Untuk memvalidasi bahwa akses publik telah dihapus, buka jendela browser samaran dan coba akses objek bucket menggunakan https://storage.googleapis.com/BUCKET/object.ext.

Untuk mengizinkan resource EdgeCacheService dalam satu project mengakses bucket Cloud Storage di project lain, Anda dapat memberikan akses ke bucket penyimpanan kepada akun layanan Media CDN di project tersebut.

Untuk melakukannya, pastikan bahwa PROJECT_NUM di service-PROJECT_NUM@gcp-sa-mediaedgefill.iam.gserviceaccount.com adalah nomor project dari project dengan resource EdgeCacheService yang memerlukan akses. Anda dapat mengulangi langkah ini untuk beberapa project, terutama jika beberapa project tersebut menampung lingkungan Media CDN yang berbeda (seperti pengembangan, staging, atau produksi) dan project terpisah berisi aset video atau media Anda.

Anda dapat melindungi akses ke origin Cloud Storage tanpa mengaktifkan permintaan bertanda tangan untuk rute tersebut.

Mengonfigurasi Cloud Storage pribadi tidak mencegah konten yang di-cache diakses langsung dari Media CDN. Untuk mengetahui informasi tentang cara Anda dapat mengeluarkan permintaan bertanda tangan kepada setiap pengguna, lihat permintaan bertanda tangan.

Mengonfigurasi Load Balancer Aplikasi eksternal sebagai origin

Jika Anda memerlukan pemeriksaan kondisi aktif, round-robin, atau pengarahan yang sadar beban di seluruh asal Compute Engine, GKE, atau lokal, Anda dapat mengonfigurasi Load Balancer Aplikasi eksternal sebagai asal.

Dengan begitu, Anda dapat mengonfigurasi (misalnya) pengemas live streaming di belakang Media CDN atau grup proxy Envoy yang dikelola oleh Cloud Service Mesh untuk terhubung kembali ke infrastruktur lokal Anda.

Load balancer memungkinkan Anda mengonfigurasi backend untuk hal berikut:

• Grup instance virtual machine (VM) Compute Engine.
• Grup endpoint jaringan (termasuk VM Compute Engine dan cluster Google Kubernetes Engine).
• Grup endpoint jaringan serverless (Cloud Run, App Engine, dan Cloud Run functions).

Arsitektur yang menggabungkan asal Load Balancer Aplikasi eksternal untuk menyajikan manifes video dan asal Cloud Storage untuk penyimpanan segmen menyerupai berikut, dengan dua asal dipetakan ke rute yang berbeda.

Untuk mengonfigurasi Load Balancer Aplikasi eksternal sebagai asal, Anda perlu membuat resource asal dengan alamat IP atau nama host publik yang mengarah ke aturan penerusan load balancer. Nama host publik (nama domain) lebih disarankan karena diperlukan untuk sertifikat SSL (TLS) dan untuk versi HTTP modern (HTTP/2 dan HTTP/3).

Anda juga harus mengonfirmasi hal berikut:

• Load balancer Anda memiliki rute yang cocok dengan nama host yang digunakan untuk resource EdgeCacheService atau Anda telah mengonfigurasi urlRewrite.hostRewrite untuk rute tempat load balancer Anda dikonfigurasi sebagai origin.
• Load balancer Anda telah mengonfigurasi sertifikat SSL (TLS) yang dipercaya secara publik untuk nama host ini.

Misalnya, jika nama domain publik yang mengarah ke aturan penerusan load balancer Anda adalah origin-packager.example.com, Anda harus membuat asal dengan originAddress yang ditetapkan ke nama ini.

gcloud edge-cache origins create LB_ORIGIN \
    --origin-address=LB_ADDRESS

Jika Anda menggunakan alamat IP aturan penerusan sebagai alamat asal, atau Anda tidak memiliki sertifikat SSL yang terlampir pada load balancer, Anda dapat menetapkan protokol ke HTTP untuk melakukan penggantian ke koneksi yang tidak terenkripsi. Sebaiknya Anda hanya melakukannya untuk pengembangan atau pengujian.

Mengonfigurasi region untuk perisai fleksibel

Anda dapat mengonfigurasi region untuk perisai fleksibel saat membuat atau memperbarui asal.

gcloud edge-cache origins update ORIGIN \
    --origin-address=ADDRESS \
    --flex-shielding=REGION

name: ORIGIN
originAddress: ADDRESS
# ... Other fields
flexShielding:
  flexShieldingRegions:
    - REGION
# ... Other fields

Mengonfigurasi failover origin

Bagian berikut menunjukkan cara mengonfigurasi perilaku failover asal.

Failover asal tanpa mengikuti pengalihan

Berikut adalah konfigurasi EdgeCacheOrigin failover dasar:

name: FAILOVER_ORIGIN
originAddress: FAILOVER_DOMAIN_NAME

Media CDN mencoba ulang origin utama rute maksimal tiga kali sebelum mencoba origin failover. Dalam konfigurasi ini, setelah mencoba origin utama tiga kali, Media CDN akan mencoba satu permintaan terhadap FAILOVER_ORIGIN. Jika origin failover juga gagal merespons dengan berhasil, maka Media CDN akan menampilkan seluruh respons origin atau, jika tidak ada kode status yang diterima, respons HTTP 502 Bad Gateway.

Latensi pengisian cache meningkat seiring dengan jumlah percobaan ulang dan peristiwa failover. Meningkatkan nilai waktu tunggu server asal (seperti connectTimeout) akan semakin memengaruhi latensi pengisian cache karena akan meningkatkan waktu yang dihabiskan untuk menunggu server asal yang kelebihan beban atau sibuk merespons.

Contoh berikut menunjukkan konfigurasi yang mengirim permintaan pengisian ke MY_ORIGIN. Konfigurasi ini menyebabkan Media CDN mencoba lagi jika terjadi error koneksi (seperti error DNS, TCP, atau TLS), respons HTTP 5xx dari origin, atau HTTP 404 Not Found. Setelah dua kali percobaan, koneksi akan dialihkan ke FAILOVER_ORIGIN.

Total maksimum empat upaya dilakukan di seluruh origin yang Anda konfigurasi: upaya asli ditambah hingga tiga upaya percobaan ulang. Anda dapat mengonfigurasi nilai maxAttempts per asal untuk menentukan berapa banyak percobaan ulang yang dilakukan sebelum mencoba melakukan failover.

name: MY_ORIGIN
originAddress: DOMAIN_NAME
maxAttempts: 2 # the number of attempts to make before trying the failoverOrigin
failoverOrigin: FAILOVER_ORIGIN
# what conditions trigger a retry or failover
retryConditions:
- CONNECT_FAILURE
- HTTP_5xx # any HTTP 5xx response
- NOT_FOUND # retry on a HTTP 404
timeout:
  maxAttemptsTimeout: 10s # set a deadline for all retries and failover

Failover origin dengan mengikuti pengalihan

Misalnya, anggaplah Anda telah mengonfigurasi resource EdgeCacheOrigin berikut dan rute resource EdgeCacheService Anda dikonfigurasi untuk menggunakan PrimaryOrigin untuk pengisian cache:

name: PrimaryOrigin
originAddress: "primary.example.com"
maxAttempts: 2
failoverOrigin: "SecondaryOrigin"
retryConditions: [CONNECT_FAILURE]
originRedirect:
  redirectConditions: [FOUND, TEMPORARY_REDIRECT]

name: SecondaryOrigin
originAddress: "secondary.example.com"
maxAttempts: 3
originRedirect:
  redirectConditions: [FOUND, TEMPORARY_REDIRECT]

Dalam contoh ini, saat Media CDN melakukan pengisian cache, Media CDN membaca konfigurasi PrimaryOrigin dan meresponsnya dengan tepat.

Misalkan Media CDN terhubung ke primary.example.com sebagai upaya #1 untuk menghubungi origin. Jika primary.example.com menampilkan respons yang berhasil, Media CDN akan menggunakan respons tersebut untuk pengisian cache.

Sekarang misalkan primary.example.com menampilkan HTTP 302 Found Redirect ke Location: b.example.com. Kemudian, sebagai upaya #2 untuk menghubungi origin, Media CDN mengikuti pengalihan ke b.example.com. Dalam hal ini, Media CDN melakukan hal berikut:

• Jika b.example.com menampilkan respons yang berhasil, Media CDN akan menggunakan respons tersebut untuk pengisian cache.
• Jika b.example.com menampilkan pengalihan atau respons kegagalan, Media CDN akan melakukan failover ke SecondaryOrigin yang dikonfigurasi. Hal ini karena, dalam contoh ini, PrimaryOrigin dikonfigurasi untuk dua maxAttempts.

Jika Media CDN melakukan failover ke SecondaryOrigin, Media CDN menggunakan konfigurasi SecondaryOrigin dan mencoba terhubung ke secondary.example.com. Ini adalah upaya #1 untuk menghubungi asal, dan upaya #3 secara keseluruhan.

Dalam hal ini, Media CDN melakukan hal berikut:

• Jika secondary.example.com menampilkan respons yang berhasil, Media CDN menggunakan respons tersebut untuk pengisian cache.
• Jika secondary.example.com menampilkan HTTP 302 Found Redirect ke Location: c.example.com, Media CDN akan mencoba menghubungi c.example.com. Dalam contoh ini, ini adalah percobaan #2 untuk SecondaryOrigin dan percobaan #4 secara keseluruhan.

Jika upaya untuk menghubungi c.example.com menampilkan respons yang berhasil, Media CDN menggunakan respons tersebut untuk pengisian cache. Jika upaya menampilkan pengalihan yang dikonfigurasi untuk diikuti Media CDN, Media CDN menampilkan kode status HTTP 502 Bad Gateway karena telah mencapai upaya maksimum untuk menghubungi origin. Media CDN melakukan maksimal empat upaya di semua origin, terlepas dari konfigurasi EdgeCacheOrigin. Terakhir, jika Media CDN gagal menghubungi c.example.com, Media CDN akan menampilkan respons 504 Gateway Timeout atau respons 502 Bad Gateway.

Jika Anda memerlukan health check, round-robin, atau pengarahan yang sadar beban di seluruh origin, Anda dapat mengonfigurasi Load Balancer Aplikasi eksternal sebagai origin utama.

Mengonfigurasi pengalihan origin berikut

Media CDN mendukung pengalihan yang ditampilkan oleh origin Anda secara internal selama pengisian cache, bukan menampilkan respons pengalihan langsung ke klien. Jika dikonfigurasi untuk mengikuti pengalihan asal, Media CDN mengambil konten dari lokasi pengalihan sebelum melakukan caching dan menampilkan respons yang dialihkan ke klien. Media CDN mengikuti pengalihan di seluruh domain.

Sebagai praktik terbaik, konfigurasi pengalihan origin hanya untuk origin yang Anda percayai dan kontrol. Pastikan Anda memercayai setiap asal dalam rantai pengalihan karena setiap asal menghasilkan konten yang ditayangkan oleh EdgeCacheService Anda.

Untuk mengaktifkan pengalihan origin berikut, tambahkan konfigurasi berikut ke resource EdgeCacheOrigin Anda:

name: MY_ORIGIN
originAddress: DOMAIN_NAME
maxAttempts: 2
originRedirect:
  redirectConditions: [FOUND, TEMPORARY_REDIRECT]

CDN Media menggunakan protokol yang ditentukan dalam pengalihan untuk menjangkau semua server. Konfirmasi bahwa semua server yang mungkin dialihkan oleh Media CDN menyediakan dukungan untuk protokol yang Anda perlukan. Khususnya, jika protokol disetel ke HTTPS, HTTP/2, atau HTTP/3, Media CDN tidak melakukan penggantian ke koneksi HTTP/1.1 untuk mengikuti pengalihan yang tidak aman. Header host yang dikirim ke origin yang dialihkan cocok dengan URL yang dialihkan. CDN media mengikuti satu pengalihan per upaya EdgeCacheOrigin sebelum menampilkan respons akhir atau mengevaluasi kondisi percobaan ulang atau failover.

Setelan redirectConditions menentukan kode respons HTTP yang menyebabkan Media CDN mengikuti pengalihan untuk setiap asal.

Mengonfigurasi penulisan ulang host atau modifikasi header khusus asal

Jika asal Anda memerlukan penulisan ulang host atau modifikasi header khusus asal, gunakan contoh konfigurasi originOverrideAction berikut untuk menyetelnya:

name: FAILOVER_ORIGIN
originAddress: FAILOVER_ORIGIN_HOST"
originOverrideAction:
  urlRewrite:
    hostRewrite: FAILOVER_ORIGIN_HOST"
  headerAction:
    requestHeadersToAdd:
    - headerName: "Authorization"
      headerValue: "AUTH-KEY"
      replace: true

Setelan originOverrideAction.hostRewrite lebih diutamakan daripada penulisan ulang header yang ada yang dikonfigurasi pada rute yang mengarah ke origin ini.

Anda dapat menggunakan requestHeadersToAdd header unik per origin yang diminta oleh origin tertentu tersebut. Kasus penggunaan umum menambahkan header Authorization statis. Karena manipulasi header ini dijalankan selama permintaan asal, header yang ditambahkan per asal akan menggantikan atau ditambahkan ke header yang ada dengan nama kolom yang sama. Secara default, Media CDN menambahkan ke header yang ada. Untuk mengganti header yang ada, tetapkan headerAction.replace ke true.

Untuk mengetahui informasi tentang cara menetapkan header permintaan per rute, lihat Menetapkan header kustom.

Memecahkan masalah origin

Jika asal tidak berfungsi seperti yang diharapkan, lihat cara memecahkan masalah asal.

Langkah berikutnya

• Menggunakan bucket pribadi yang kompatibel dengan Amazon S3 sebagai origin
• Mengonfigurasi rute layanan