Anda dapat mengonfigurasi origin untuk Media CDN dengan berbagai cara. Halaman ini menunjukkan cara mengonfigurasi origin.
Mengonfigurasi bucket Cloud Storage sebagai origin
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.
Konsol
Di konsol Google Cloud, buka halaman Origins Media CDN.
Klik Buat asal.
Masukkan nama untuk asal. Misalnya:
cloud-storage-origin.Opsional: Masukkan deskripsi.
Untuk Origin address, pilih Select a Google Cloud Storage bucket.
Buka bucket Cloud Storage Anda, lalu pilih bucket tersebut.
Untuk Cloud Storage, pertahankan setelan protokol dan port default.
Opsional: Agar penggantian header permintaan origin diprioritaskan daripada header yang dikirim oleh klien atau dimanipulasi oleh tindakan header tingkat rute, lakukan hal berikut:
- Pilih Aktifkan penggantian origin.
- Di bagian Headers, tentukan header dengan menambahkan satu atau beberapa pasangan nilai nama.
Opsional: Pilih origin failover yang akan dicoba jika origin ini menjadi tidak dapat dijangkau. Anda dapat memperbarui kolom ini nanti.
Pilih redirect conditions.
Pilih retry conditions.
Untuk Percobaan maksimum, pilih jumlah maksimum percobaan untuk mengisi cache dari origin ini.
Opsional: Tentukan nilai waktu tunggu berikut:
- Untuk Connect timeout, pilih durasi maksimum untuk menunggu koneksi origin dibuat.
- Untuk Waktu tunggu respons, pilih durasi maksimum untuk memungkinkan respons selesai.
- Untuk Waktu tunggu operasi baca, pilih durasi maksimum untuk menunggu di antara pembacaan satu koneksi atau streaming HTTP.
Opsional: Klik Tambahkan label dan tentukan satu atau beberapa pasangan nilai kunci.
Klik Buat asal.
gcloud
Gunakan perintah gcloud edge-cache origins create:
gcloud edge-cache origins create ORIGIN \
--origin-address=ADDRESS
Ganti kode berikut:
ORIGIN: nama origin baruADDRESS: nama bucket—misalnya,gs://my-bucket
Hal ini sama, baik bucket bersifat multi-regional, dual-region, maupun 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 juga 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 cocok dengan parameter jalur, header, atau kueri) ke bucket penyimpanan berbasis Amerika Serikat.
Untuk kasus saat latensi operasi tulis sangat penting, seperti live streaming latensi rendah, Anda dapat mengonfigurasi endpoint Cloud Storage regional sedekat mungkin dengan pengguna.
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 dibagikan ke semua pelanggan, tetapi selalu digunakan oleh resource
EdgeCacheServicesaat terhubung ke origin. - Tambahkan header permintaan kustom dengan nilai token yang Anda validasi di asal (misalnya, nilai acak 16 byte). Origin Anda kemudian dapat menolak permintaan yang tidak menyertakan nilai ini.
Mengonfigurasi protokol origin
Untuk origin yang hanya mendukung HTTPS (HTTP/1.1 melalui TLS) atau HTTP/1.1 (tanpa TLS), tetapkan kolom protocol secara eksplisit dengan melakukan tindakan berikut:
Konsol
Di konsol Google Cloud, buka halaman Origins Media CDN.
Pilih asal Anda, lalu klik Edit.
Untuk protokol, pilih HTTPS atau HTTP. Untuk HTTP, tentukan juga port sebagai
80.Klik Perbarui asal.
gcloud
Gunakan perintah gcloud edge-cache origins update:
gcloud edge-cache origins update LEGACY_ORIGIN \
--protocol=HTTPS
Jika origin Anda mendukung HTTP/2, Anda tidak perlu menetapkan protokol secara eksplisit.
Mengonfigurasi bucket Cloud Storage pribadi
CDN Media dapat mengambil konten dari endpoint HTTP atau HTTPS yang dapat dijangkau internet. Dalam beberapa kasus, Anda mungkin ingin mewajibkan autentikasi, agar hanya mengizinkan Media CDN mengambil konten, dan mencegah akses tanpa izin. Cloud Storage mendukung hal ini melalui izin IAM.
Untuk origin Cloud Storage, lakukan hal berikut:
- Berikan izin IAM
objectViewerke akun layanan Media CDN di bucket Cloud Storage yang Anda gunakan sebagai origin. - Hapus izin
allUsers. - Opsional: Hapus izin
allAuthenticatedUsers.
Untuk mengubah izin bucket Cloud Storage, Anda memerlukan peran IAM Storage Admin.
Akun layanan Media CDN dimiliki oleh project Media CDN, dan tidak akan muncul dalam daftar akun layanan project Anda.
Akun layanan memiliki format berikut, dan hanya memberikan akses ke resource Media CDN di project yang Anda izinkan secara eksplisit.
service-PROJECT_NUM@gcp-sa-mediaedgefill.iam.gserviceaccount.com
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
Gunakan perintah gcloud storage buckets remove-iam-policy-binding
untuk menghapus izin yang diberikan ke peran allUsers untuk bucket tertentu. Misalnya, jika bucket memberikan peran objectViewer kepada allUsers, hapus
pemberian tersebut 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 akun layanan Media CDN di project tersebut ke bucket
penyimpanan.
Untuk melakukannya, pastikan 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 mengulanginya untuk beberapa project, terutama jika beberapa di antaranya
menyimpan 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 yang ditandatangani untuk rute tersebut.
Mengonfigurasi Cloud Storage pribadi tidak mencegah konten yang di-cache Anda diakses langsung dari Media CDN. Untuk mengetahui informasi tentang cara menerbitkan permintaan yang ditandatangani kepada setiap pengguna, lihat permintaan yang ditandatangani.
Mengonfigurasi Load Balancer Aplikasi eksternal sebagai origin
Jika Anda memerlukan pemeriksaan kondisi aktif, round-robin, atau pemilihan rute yang mempertimbangkan beban di seluruh origin Compute Engine, GKE, atau on-premise, Anda dapat mengonfigurasi Load Balancer Aplikasi eksternal sebagai origin.
Hal ini memungkinkan Anda mengonfigurasi (misalnya) paket live streaming di balik 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 VM Compute Engine.
- Grup endpoint jaringan (termasuk VM Compute Engine dan cluster Google Kubernetes Engine).
- Serverless network endpoint group (Cloud Run, App Engine, dan Cloud Run functions).
Arsitektur yang menggabungkan origin Load Balancer Aplikasi eksternal untuk menayangkan manifes video dan origin Cloud Storage untuk penyimpanan segmen menyerupai hal berikut, dengan dua origin yang dipetakan ke rute yang berbeda.
Untuk mengonfigurasi Load Balancer Aplikasi eksternal sebagai origin, Anda perlu membuat resource origin dengan alamat IP atau nama host publik yang mengarah ke aturan penerusan load balancer. Nama host publik (nama domain) lebih disukai, karena diperlukan untuk sertifikat SSL (TLS) dan untuk versi HTTP modern (HTTP/2 dan HTTP/3).
Anda juga harus memastikan hal berikut:
- Load balancer Anda memiliki rute yang cocok dengan nama host yang digunakan untuk resource
EdgeCacheServiceatau Anda telah mengonfigurasiurlRewrite.hostRewriteuntuk rute tempat load balancer dikonfigurasi sebagai origin. - Load balancer Anda memiliki sertifikat SSL (TLS) tepercaya secara publik yang dikonfigurasi untuk nama host ini.
Misalnya, jika nama domain publik yang diarahkan ke aturan penerusan load balancer Anda adalah origin-packager.example.com, Anda harus membuat origin dengan originAddress yang ditetapkan ke nama ini.
Konsol
Di konsol Google Cloud, buka halaman Origins Media CDN.
Klik Buat asal.
Masukkan nama untuk asal. Misalnya:
load-balancer-origin.Opsional: Masukkan deskripsi.
Untuk Origin address, pilih Specify a FQDN or IP address.
Masukkan FQDN atau alamat IP untuk load balancer Google Cloud Anda.
Opsional: Pilih origin failover yang akan dicoba jika origin ini menjadi tidak dapat dijangkau. Anda dapat memperbarui kolom ini nanti.
Pilih retry conditions.
Untuk Percobaan maksimum, pilih jumlah maksimum percobaan untuk mengisi cache dari origin ini.
Opsional: Tentukan nilai waktu tunggu berikut:
- Untuk Connect timeout, pilih durasi maksimum untuk menunggu koneksi origin dibuat.
- Untuk Waktu tunggu respons, pilih durasi maksimum untuk memungkinkan respons selesai.
- Untuk Waktu tunggu operasi baca, pilih durasi maksimum untuk menunggu di antara pembacaan satu koneksi atau streaming HTTP.
Opsional: Klik Tambahkan label dan tentukan satu atau beberapa pasangan nilai kunci.
Klik Buat asal.
gcloud
Gunakan perintah gcloud edge-cache origins create:
gcloud edge-cache origins create LB_ORIGIN \
--origin-address=LB_ADDRESS
Ganti kode berikut:
LB_ORIGIN: nama asalLB_ADDRESS: FQDN atau alamat IP, misalnya,origin-packager.example.com
Jika menggunakan alamat IP aturan penerusan sebagai alamat asal,
atau tidak memiliki sertifikat SSL yang dilampirkan ke load balancer, Anda dapat
menetapkan protokol ke HTTP untuk kembali ke koneksi yang tidak dienkripsi. Sebaiknya
Anda melakukannya hanya untuk pengembangan atau pengujian.
Mengonfigurasi failover origin
Bagian berikut menunjukkan cara mengonfigurasi perilaku failover origin.
Failover origin tanpa mengikuti pengalihan
Berikut adalah konfigurasi EdgeCacheOrigin failover dasar:
name: FAILOVER_ORIGIN
originAddress: FAILOVER_DOMAIN_NAME
CDN Media 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, Media CDN akan menampilkan seluruh respons origin atau, jika tidak ada kode status yang diterima, respons 502 Bad Gateway HTTP.
Latensi pengisian cache meningkat seiring dengan jumlah percobaan ulang dan peristiwa failover.
Meningkatkan nilai waktu tunggu origin (seperti connectTimeout) akan lebih
memengaruhi latensi pengisian cache karena meningkatkan waktu yang dihabiskan untuk menunggu
server origin yang kelebihan beban atau sibuk merespons.
Contoh berikut menunjukkan konfigurasi yang mengirim permintaan pengisian ke
MY_ORIGIN. Konfigurasi ini menyebabkan Media CDN mencoba lagi saat terjadi error koneksi (seperti error DNS, TCP, atau TLS), respons HTTP 5xx dari origin, atau HTTP 404 Not Found. Setelah dua percobaan, tugas akan gagal dan dialihkan ke
FAILOVER_ORIGIN.
Total maksimum empat upaya dilakukan di seluruh origin yang dikonfigurasi: upaya asli ditambah hingga tiga upaya percobaan ulang. Anda dapat mengonfigurasi nilai maxAttempts per origin untuk menentukan jumlah 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 pengalihan berikut
Misalnya, 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 akan membaca konfigurasi PrimaryOrigin dan meresponsnya dengan semestinya.
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 302 Found Redirect HTTP 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.commenampilkan respons yang berhasil, Media CDN akan menggunakan respons tersebut untuk pengisian cache. - Jika
b.example.commenampilkan pengalihan atau respons kegagalan, Media CDN akan beralih keSecondaryOriginyang dikonfigurasi. Hal ini karena, dalam contoh ini,PrimaryOrigindikonfigurasi untuk duamaxAttempts.
Jika Media CDN gagal di-failover ke SecondaryOrigin, Media CDN akan 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.commenampilkan respons yang berhasil, Media CDN akan menggunakan respons tersebut untuk pengisian cache. - Jika
secondary.example.commenampilkan302 Found RedirectHTTP keLocation: c.example.com, Media CDN akan mencoba menghubungic.example.com. Dalam contoh ini, ini adalah upaya #2 untukSecondaryOrigindan upaya #4 secara keseluruhan.
Jika upaya untuk menghubungi c.example.com menampilkan respons yang berhasil, Media CDN akan menggunakan respons tersebut untuk pengisian cache. Jika upaya tersebut menampilkan pengalihan yang dikonfigurasi Media CDN untuk diikuti, Media CDN akan menampilkan error 502 Bad Gateway HTTP karena telah menghabiskan upaya maksimum untuk menghubungi origin.
CDN Media 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 memerlukan health check, round-robin, atau pemilihan rute berbasis beban di seluruh origin, Anda dapat mengonfigurasi Load Balancer Aplikasi eksternal sebagai origin utama.
Mengonfigurasi pengalihan origin berikut
Media CDN mendukung pengalihan berikutnya yang ditampilkan oleh origin Anda secara internal selama pengisian cache, bukan menampilkan respons pengalihan langsung ke klien. Jika Media CDN dikonfigurasi untuk mengikuti pengalihan asal, Media CDN akan mengambil konten dari lokasi pengalihan sebelum menyimpan dalam cache dan menampilkan respons yang dialihkan ke klien. Media CDN mengikuti pengalihan di seluruh domain.
Sebagai praktik terbaik, konfigurasikan pengalihan origin hanya untuk origin yang Anda percaya dan kontrol. Pastikan Anda memercayai setiap origin dalam rantai pengalihan karena
setiap origin menghasilkan konten yang ditayangkan oleh EdgeCacheService Anda.
Untuk mengaktifkan pengalihan asal yang mengikuti, 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. Pastikan semua server yang mungkin diarahkan Media CDN mendukung protokol yang Anda perlukan.
Secara khusus, jika protokol disetel ke HTTPS, HTTP/2, atau HTTP/3, Media CDN tidak akan kembali 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 origin.
| Kondisi | Deskripsi |
|---|---|
| MOVED_PERMANENTLY | Ikuti pengalihan untuk kode respons HTTP 301 |
| DITEMUKAN | Ikuti pengalihan untuk kode respons HTTP 302 |
| SEE_OTHER | Ikuti pengalihan untuk kode respons HTTP 303 |
| TEMPORARY_REDIRECT | Ikuti pengalihan untuk kode respons HTTP 307 |
| PERMANENT_REDIRECT | Ikuti pengalihan untuk kode respons HTTP 308 |
Mengonfigurasi penulisan ulang host atau modifikasi header khusus origin
Jika origin Anda memerlukan penulisan ulang host atau modifikasi header khusus origin,
gunakan contoh konfigurasi originOverrideAction berikut untuk menetapkannya:
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 asal yang diminta oleh
asal tertentu tersebut. Kasus penggunaan umum menambahkan header Authorization statis.
Karena manipulasi header ini dijalankan selama permintaan origin, header
yang ditambahkan per origin akan menggantikan atau menambahkan ke header yang ada dengan nama kolom
yang sama. Secara default, Media CDN ditambahkan 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 berperilaku seperti yang diharapkan, lihat cara memecahkan masalah asal.
Langkah selanjutnya
- Menggunakan bucket pribadi yang kompatibel dengan Amazon S3 sebagai origin
- Mengonfigurasi rute layanan