Halaman ini berisi daftar persyaratan dan perilaku utama container di Cloud Run. Halaman ini juga menjelaskan perbedaan antara layanan Cloud Run, tugas Cloud Run, dan kumpulan pekerja Cloud Run jika diperlukan.
Bahasa dan gambar yang didukung
Image container Anda dapat menjalankan kode yang ditulis dalam bahasa pemrograman pilihan Anda dan menggunakan image dasar apa pun, asalkan image tersebut mematuhi batasan yang tercantum di halaman ini.
File yang dapat dieksekusi di image container harus dikompilasi untuk Linux 64-bit. Cloud Run secara khusus mendukung format ABI x86_64 Linux.
Cloud Run menerima image container di format gambar Docker Image Manifest V2, Schema 1, Schema 2, dan OCI. Cloud Run juga menerima image container yang dikompresi Zstd.
Jika men-deploy image multiarsitektur,
daftar manifes
harus menyertakan linux/amd64.
Untuk fungsi yang di-deploy dengan Cloud Run, Anda dapat menggunakan salah satu image dasar runtime Cloud Run yang dipublikasikan oleh buildpack Google Cloud untuk menerima update keamanan dan pemeliharaan otomatis. Lihat Jadwal dukungan runtime untuk mengetahui runtime yang didukung.
Memproses permintaan pada port yang benar (layanan)
Layanan Cloud Run memulai instance Cloud Run untuk menangani permintaan yang masuk. Instance Cloud Run selalu memiliki satu container masuk yang memproses permintaan, dan secara opsional satu atau beberapa container file bantuan. Detail konfigurasi port berikut hanya berlaku untuk container masuk, bukan untuk file bantuan.
Container ingress dalam sebuah instance harus memproses permintaan pada
0.0.0.0 di port tujuan pengiriman permintaan.
Khususnya, container ingress tidak boleh memproses 127.0.0.1.
Secara default, permintaan akan dikirim ke 8080, tetapi Anda dapat mengonfigurasi Cloud Run
untuk mengirim permintaan ke port pilihan Anda. Cloud Run memasukkan
variabel lingkungan PORT ke dalam container masuk.
Container yang berjalan dalam eksekusi tugas harus keluar setelah selesai
Untuk tugas Cloud Run, container harus keluar dengan kode keluar 0 saat tugas berhasil diselesaikan, dan keluar dengan kode keluar bukan nol saat tugas gagal.
Karena tugas tidak boleh melayani permintaan, container tidak boleh memproses port atau memulai server web.
Enkripsi lapisan transpor (TLS)
Container tidak boleh menerapkan keamanan lapisan transport secara langsung. TLS dihentikan oleh Cloud Run untuk HTTPS dan gRPC, lalu permintaan akan di-proxy-kan sebagai HTTP/1 atau gRPC ke container tanpa TLS.
Jika Anda mengonfigurasi layanan Cloud Run untuk menggunakan HTTP/2 secara menyeluruh, container Anda harus menangani permintaan dalam format cleartext (h2c) HTTP/2, karena TLS masih dihentikan secara otomatis oleh Cloud Run.
Respons (layanan)
Untuk layanan Cloud Run, container Anda harus mengirim respons dalam waktu yang ditentukan di setelan waktu tunggu permintaan setelah menerima permintaan, termasuk waktu startup container. Jika tidak, permintaan akan berakhir dan error 504 akan ditampilkan.
Penyimpanan dalam cache respons dan cookie
Jika respons layanan Cloud Run Anda berisi header Set-Cookie, Cloud Run akan menetapkan header Cache-Control ke private sehingga respons tidak di-cache. Tindakan ini mencegah pengguna lain mengambil cookie.
Variabel lingkungan
Berbagai variabel lingkungan tersedia untuk layanan dan tugas Cloud Run.
Variabel lingkungan untuk layanan
Variabel lingkungan berikut akan otomatis ditambahkan ke semua
container yang berjalan, kecuali PORT. Variabel PORT hanya ditambahkan ke container masuk:
| Nama | Deskripsi | Contoh |
|---|---|---|
PORT |
Port yang akan diproses oleh server HTTP Anda. | 8080 |
K_SERVICE |
Nama layanan Cloud Run yang sedang dijalankan. | hello-world |
K_REVISION |
Nama revisi Cloud Run yang sedang dijalankan. | hello-world.1 |
K_CONFIGURATION |
Nama konfigurasi Cloud Run yang membuat revisi. | hello-world |
Variabel lingkungan untuk tugas
Untuk tugas Cloud Run, variabel lingkungan berikut telah ditetapkan:
| Nama | Deskripsi | Contoh |
|---|---|---|
CLOUD_RUN_JOB |
Nama tugas Cloud Run yang sedang dijalankan. | hello-world |
CLOUD_RUN_EXECUTION |
Nama eksekusi Cloud Run yang sedang dijalankan. | hello-world-abc |
CLOUD_RUN_TASK_INDEX |
Indeks tugas ini. Dimulai dari 0 untuk tugas pertama dan bertambah 1 untuk setiap tugas yang berurutan, hingga jumlah maksimum tugas minus 1. Jika Anda menetapkan --parallelism ke lebih besar dari 1, tugas mungkin tidak mengikuti urutan indeks. Misalnya, tugas 2 dapat dimulai sebelum tugas 1. |
0 |
CLOUD_RUN_TASK_ATTEMPT |
Frekuensi percobaan ulang tugas ini. Dimulai dari 0 untuk percobaan pertama dan akan bertambah 1 untuk setiap percobaan ulang berturut-turut, hingga nilai percobaan ulang mencapai batas maksimum. | 0 |
CLOUD_RUN_TASK_COUNT |
Jumlah tugas yang ditentukan dalam parameter --tasks. |
1 |
Variabel lingkungan untuk kumpulan pekerja
Cloud Run menetapkan variabel lingkungan berikut untuk kumpulan pekerja:
| Nama | Deskripsi | Contoh |
|---|---|---|
CLOUD_RUN_WORKER_POOL |
Nama kumpulan pekerja Cloud Run yang sedang berjalan. | hello-world |
CLOUD_RUN_WORKER_POOL_REVISION |
Nama revisi kumpulan pekerja Cloud Run yang sedang berjalan. | hello-world.1 |
Persyaratan header respons dan permintaan (layanan)
Untuk layanan, Cloud Run membatasi nama header ke ASCII non-spasi yang dapat dicetak, dan tidak boleh berisi titik dua. Cloud Run membatasi nilai header untuk karakter ASCII yang terlihat, ditambah spasi dan tab horizontal, sesuai dengan IETF RFC 7230.
Akses sistem file
Sistem file setiap container dapat ditulis dan tunduk pada perilaku berikut:
- Ini adalah sistem file dalam memori, sehingga penulisan ke file ini akan menggunakan memori instance.
- Data yang ditulis ke sistem file tidak akan bertahan saat instance berhenti.
Anda tidak dapat menentukan batas ukuran untuk sistem file ini, sehingga Anda berpotensi menggunakan semua memori yang dialokasikan untuk instance dengan menulis ke sistem file dalam memori, yang akan menyebabkan instance mengalami error. Anda dapat menghindari masalah ini jika menggunakan volume dalam memori khusus dengan batas ukuran.
Siklus proses instance
Karakteristik siklus proses berbeda untuk tugas dan layanan Cloud Run, sehingga nanti akan dijelaskan secara terpisah di subbagian berikut.
Untuk layanan
Karakteristik berikut hanya berlaku untuk layanan.
Penskalaan layanan
Secara default, layanan Cloud Run diskalakan secara otomatis ke jumlah instance yang diperlukan untuk menangani semua permintaan, peristiwa, atau penggunaan CPU yang masuk. Anda dapat secara opsional menggunakan penskalaan manual jika Anda memerlukan kontrol lebih besar atas perilaku penskalaan.
Setiap instance menjalankan sejumlah container tetap – satu container masuk dan secara opsional satu atau beberapa container file bantuan.
Jika revisi tidak menerima traffic apa pun, revisi tersebut akan diskalakan ke jumlah minimum instance yang dikonfigurasi (nol secara default).
Startup
Untuk layanan Cloud Run, instance Anda harus memproses permintaan dalam waktu 4 menit setelah dimulai dan semua container dalam instance harus responsif. Selama waktu startup ini, instance diberi alokasi CPU. Anda dapat mengaktifkan peningkatan CPU startup untuk meningkatkan alokasi CPU sementara selama startup instance guna mengurangi latensi pengaktifan.
Permintaan akan dikirim ke container masuk segera setelah memproses port yang dikonfigurasi.
Permintaan yang menunggu instance akan tetap tertunda dalam antrean sebagai berikut:
Permintaan akan ditunda hingga 3,5 kali waktu mulai rata-rata instance penampung layanan ini, atau 10 detik, mana saja yang lebih besar.
Anda dapat mengonfigurasi pemeriksaan startup untuk menentukan apakah container telah dimulai dan siap menyalurkan permintaan.
Untuk layanan Cloud Run yang terdiri dari instance multi-container, Anda dapat menentukan urutan dimulainya container dalam instance dengan mengonfigurasi urutan startup container.
Memproses permintaan
Untuk layanan Cloud Run, CPU selalu dialokasikan ke semua container, termasuk file bantuan dalam instance selama revisi Cloud Run memproses setidaknya satu permintaan.
Tidak ada aktivitas
Untuk layanan Cloud Run, instance yang tidak ada aktivitas adalah instance yang tidak memproses permintaan apa pun.
CPU yang dialokasikan ke semua container dalam instance yang tidak ada aktivitas bergantung pada setelan penagihan yang dikonfigurasi.
Kecuali jika instance harus dibiarkan tidak beraktivitas karena setelan konfigurasi jumlah minimum instance, maka instance tidak akan dibiarkan menganggur selama lebih dari 15 menit.
Nonaktif
Untuk layanan Cloud Run, instance yang tidak ada aktivitas dapat dihentikan kapan saja, termasuk instance yang tetap aktif karena jumlah minimum instance yang dikonfigurasi. Jika instance yang memproses permintaan perlu dinonaktifkan, permintaan yang sedang diproses akan diberi waktu untuk menyelesaikannya, dan permintaan masuk baru akan dirutekan ke instance lain. Dalam kasus yang jarang terjadi, Cloud Run mungkin memulai penonaktifan dan mengirim sinyal SIGTERM ke container yang masih memproses permintaan.
Sebelum mematikan instance, Cloud Run mengirimkan sinyal SIGTERM ke semua container dalam instance,
yang menunjukkan dimulainya periode 10 detik
sebelum penonaktifan yang sebenarnya terjadi. Pada saat itu Cloud Run mengirimkan permintaan sinyal SIGKILL.
Selama periode ini, instance mendapatkan alokasi CPU dan akan dikenai biaya.
Pada layanan yang menggunakan lingkungan eksekusi generasi pertama, jika
instance tidak menangkap sinyal SIGTERM, instance
akan segera dimatikan. Di layanan yang menggunakan lingkungan eksekusi generasi kedua, sebaiknya instal handler SIGTERM di container Anda untuk menerima peringatan saat Cloud Run akan mematikan instance.
Penghentian paksa
Jika satu atau beberapa container Cloud Run melebihi
batas total memori container,
maka instance akan dihentikan. Semua permintaan yang masih diproses di instance
diakhiri dengan error HTTP 500.
Untuk tugas
Untuk tugas Cloud Run, instance container akan berjalan hingga instance container keluar, atau hingga waktu tunggu tugas tercapai, atau sampai container mengalami error.
Exit code
Anda dapat menggunakan kode keluar tugas untuk melihat apakah tugas berhasil diselesaikan atau apakah tugas mengalami error. Kode keluar adalah nilai numerik yang dipetakan ke penyelesaian yang berhasil atau jenis error tertentu.
Tabel berikut menentukan kode keluar umum dan definisinya:
| Exit code | Sinyal | Deskripsi |
|---|---|---|
| 0 | Tugas berhasil diselesaikan. | |
| 4 | SIGILL |
Tugas mencoba mengakses memori di alamat yang salah. |
| 7 | SIGBUS |
Tugas mencoba mengakses memori di luar batas yang dialokasikan. |
| 9 | SIGKILL |
Tugas dihentikan secara paksa, baik oleh tindakan pengguna atau intervensi manual. |
| 11 | SIGSEGV |
Tugas mencoba mengakses memori yang tidak sah. |
| 15 | SIGTERM |
Jika waktu tunggu tugas yang dikonfigurasi terlampaui, tugas akan menerima sinyal SIGTERM. Server aplikasi mengirimkan sinyal SIGTERM agar instance container dimatikan. Jika instance tidak dinonaktifkan sendiri dalam beberapa detik setelah menerima SIGTERM, Cloud Run akan mengirimkan sinyal SIGKILL untuk penghentian paksa. Jika instance keluar dengan benar dengan SIGTERM, instance tersebut mungkin melaporkan kode error yang berbeda; jika tidak, instance tersebut akan menampilkan SIGTERM. |
Penghentian paksa
Instance container Cloud Run yang melebihi
batas memori yang diizinkan
akan dihentikan. Semua permintaan yang masih diproses pada instance container
berakhir dengan error HTTP 500.
Jika tugas melebihi waktu tunggu tugas,
Cloud Run akan mengirimkan sinyal 'SIGTERM' yang menunjukkan dimulainya
periode 10 detik sebelum penonaktifan sebenarnya terjadi.
Di sini Cloud Run mengirimkan
sinyal SIGKILL, yang akan menonaktifkan instance container.
Selama periode ini, instance container mendapatkan alokasi CPU untuk seluruh siklus prosesnya dan dikenai biaya.
Baca contoh kode SIGTERM
untuk mempelajari cara menangkap sinyal SIGTERM.
Untuk kumpulan pekerja
Karakteristik berikut hanya berlaku untuk gabungan worker.
Penskalaan
Kumpulan pekerja tidak diskalakan secara otomatis. Menskalakan
secara manual jumlah instance
yang diperlukan oleh worker pool Cloud Run untuk menangani beban kerjanya. Secara
default, Cloud Run menetapkan jumlah instance ke 1. Anda dapat mengubah
angka ini menjadi lebih tinggi atau lebih rendah, atau Anda dapat menonaktifkan penskalaan dengan menyetel
angka menjadi 0. Agar dapat dimulai dan tetap aktif, beban kerja Anda harus memiliki setidaknya satu instance. Jika Anda menyetel instance minimum ke 0, instance pekerja tidak akan
dimulai, meskipun deployment berhasil.
Memulai
Instance worker pool Cloud Run memulai container dengan entrypoint yang Anda tentukan dalam image container atau dalam konfigurasi worker pool. Semua penampung dalam instance harus responsif.
Secara default, instance container Cloud Run menggunakan satu CPU. Anda dapat menaikkan atau menurunkan nilai ini berdasarkan persyaratan Anda.
Anda dapat mengonfigurasi pemeriksaan startup untuk menentukan apakah container dimulai. Pemeriksaan startup memungkinkan Cloud Run memeriksa kondisi container dependen, sehingga memastikan container berhasil lulus sebelum memulai container berikutnya. Jika Anda tidak menggunakan health check, Cloud Run akan memulai container dalam urutan yang ditentukan, meskipun container yang menjadi dependensinya gagal dimulai.
Alokasi resource
Kumpulan pekerja tidak dalam kondisi tidak ada aktivitas. Terlepas dari statusnya, Cloud Run selalu mengalokasikan CPU ke semua container, termasuk file bantuan dalam instance kumpulan pekerja. Selama berjalan, instance dianggap aktif dan ditagih sesuai dengan itu.
Nonaktif
Cloud Run tidak menurunkan skala instance kumpulan pekerja berdasarkan instance
yang tidak digunakan. Jika instance pemrosesan beban kerja harus dinonaktifkan,
Cloud Run memberi waktu kepada tugas yang sedang diproses untuk menyelesaikan tugasnya dan
merutekan beban kerja baru ke instance lain. Cloud Run
juga dapat memulai penonaktifan dan mengirim sinyal SIGTERM ke container yang masih
memproses beban kerja.
Sebelum mematikan instance, Cloud Run mengirimkan sinyal SIGTERM
ke semua container dalam instance. Sinyal ini menunjukkan dimulainya periode 10 detik sebelum penonaktifan yang sebenarnya terjadi. Pada saat itu, Cloud Run mengirimkan sinyal SIGKILL.
Selama periode penonaktifan ini, instance mendapatkan alokasi CPU dan akan dikenai biaya.
Sebaiknya instal handler
SIGTERM di
penampung Anda untuk menerima peringatan saat Cloud Run akan menonaktifkan
instance.
Penghentian paksa
Jika satu atau beberapa container Cloud Run melebihi
batas total memori container,
Cloud Run akan menghentikan instance. Semua permintaan yang masih diproses di instance diakhiri dengan error HTTP 500.
Resource instance container
Bagian berikut menjelaskan resource untuk instance penampung Anda:
CPU
Setiap container Cloud Run dalam instance secara default mendapatkan alokasi vCPU yang telah dikonfigurasi (1 secara default). Anda dapat mengonfigurasi batas CPU pada setiap container secara terpisah.
vCPU diimplementasikan sebagai abstraksi hardware dasar untuk memberikan perkiraan waktu CPU yang setara untuk hardware hyper-thread tunggal pada platform CPU variabel. Semua platform CPU yang digunakan oleh Cloud Run mendukung kumpulan petunjuk AVX2. Perhatikan bahwa kontrak container tidak berisi detail platform CPU tambahan.
Container mungkin dijalankan di beberapa core secara bersamaan.
Untuk layanan Cloud Run, alokasi CPU bergantung pada penagihan yang dipilih.
Jika Anda memilih penagihan berbasis instance, CPU akan dialokasikan selama masa aktif instance. Jika Anda memilih penagihan berbasis permintaan (default), CPU akan dialokasikan saat instance memproses permintaan. Lihat setelan penagihan untuk mengetahui detailnya.
Jika Anda telah mengonfigurasi sejumlah instance minimum, Anda harus menggunakan penagihan berbasis instance agar CPU dialokasikan di luar permintaan.
Anda dapat mengaktifkan peningkatan CPU startup untuk meningkatkan alokasi CPU untuk sementara waktu selama startup instance guna mengurangi latensi startup.
Memori
Setiap container Cloud Run secara default mendapatkan alokasi memori yang telah dikonfigurasi, (512 MiB secara default). Anda dapat mengonfigurasi batas memori pada setiap container secara terpisah.
Penggunaan umum memori meliputi:
- Kode yang dimuat ke dalam memori untuk menjalankan layanan
- Menulis ke sistem file
- Proses tambahan yang berjalan dalam container seperti server nginx
- Sistem caching dalam memori seperti OpCache PHP
- Penggunaan memori per permintaan
- Volume dalam memori bersama
GPU
Anda dapat mengonfigurasi container di instance Cloud Run untuk mengakses GPU. Jika layanan Cloud Run di-deploy dengan container pendamping, hanya satu container dalam deployment yang dapat mengakses GPU. Lihat Mengonfigurasi GPU untuk mengetahui persyaratan dan detailnya.
Library NVIDIA
Secara default, semua library driver NVIDIA L4 di-mount di bawah
/usr/local/nvidia/lib64. Cloud Run secara otomatis menambahkan jalur ini ke
variabel lingkungan LD_LIBRARY_PATH (yaitu ${LD_LIBRARY_PATH}:/usr/local/nvidia/lib64)
dari container dengan GPU. Hal ini memungkinkan linker dinamis menemukan library driver NVIDIA. Linker menelusuri dan menyelesaikan jalur
dalam urutan yang Anda cantumkan dalam variabel lingkungan LD_LIBRARY_PATH. Nilai
yang Anda tentukan dalam variabel ini diprioritaskan daripada jalur library driver Cloud Run
default /usr/local/nvidia/lib64.
Jika Anda ingin menggunakan versi CUDA yang lebih tinggi dari 12.2,
cara termudah adalah dengan mengandalkan image dasar NVIDIA yang lebih baru
dengan paket kompatibilitas ke depan yang sudah diinstal. Opsi lainnya adalah menginstal paket kompatibilitas ke depan NVIDIA secara manual dan menambahkannya ke LD_LIBRARY_PATH. Lihat matriks kompatibilitas NVIDIA
untuk menentukan versi CUDA mana yang kompatibel ke depan dengan versi driver NVIDIA yang diberikan (535.216.03).
Konkurensi (layanan)
Untuk layanan Cloud Run, setiap instance Cloud Run secara default ditetapkan ke beberapa serentak, dengan container masuk dapat menerima lebih dari satu permintaan secara bersamaan. Anda dapat mengubahnya dengan menyetel konkurensi.
Sandbox container
Jika Anda menggunakan lingkungan eksekusi generasi pertama, container Cloud Run akan di-sandbox menggunakan sandbox runtime container gVisor. Seperti yang tercantum dalam referensi kompatibilitas syscall gVisor, beberapa panggilan sistem mungkin tidak didukung oleh sandbox container ini.
Jika Anda menggunakan lingkungan eksekusi generasi kedua,
Anda memiliki kompatibilitas penuh dengan Linux.
Tugas Cloud Run selalu menggunakan lingkungan eksekusi generasi kedua.
Dalam lingkungan eksekusi generasi kedua,
/sys/class/dmi/id/product_name disetel ke Google Compute Engine.
Lingkungan eksekusi generasi kedua menjalankan kode layanan Anda dalam namespace proses terpisah, sehingga dimulai sebagai proses init container yang memiliki semantik proses khusus. Di lingkungan eksekusi generasi pertama, kode layanan Anda tidak dijalankan sebagai proses init container.
Batas deskriptor file
Lingkungan generasi pertama dan kedua Cloud Run menetapkan batas jumlah deskriptor file yang dapat dibuka oleh proses hingga 25.000. Hal ini berlaku untuk penampung dan proses turunannya yang dibuatnya (fork). Ini adalah batas yang tidak bisa dilewati. Jika Anda melampaui batas, instance Anda mungkin kehabisan deskriptor file/soket.
Batas di lingkungan generasi kedua
Kecuali untuk batas deskriptor file yang dijelaskan sebelumnya, batas di lingkungan generasi kedua adalah batas Linux standar.
Misalnya, batas jumlah deskriptor file yang dapat dibuka (seperti yang tercantum dalam: /proc/sys/fs/file-max) menggunakan nilai default sekitar 10% memori. Lihat file-max dan file-nr
dalam dokumentasi kernel untuk mengetahui detailnya.
Demikian pula, max_map_count (seperti yang tercantum dalam /proc/sys/vm/max_map_count),
yang menetapkan jumlah area memori yang dapat dimiliki suatu proses, menggunakan nilai default
65535. Lihat max-map-count
dalam dokumentasi kernel untuk mengetahui detailnya.
Container dengan hak istimewa dan biner setuid
Cloud Run tidak mendukung container istimewa. Oleh karena itu, Cloud Run tidak mendukung biner yang menggunakan
flag setuid untuk pengguna non-root, seperti gcsfuse
atau sudo, dan mungkin gagal karena izin yang tidak memadai.
Salah satu alternatifnya adalah menjalankan biner ini sebagai pengguna root, lalu menggunakan perintah su untuk beralih ke pengguna lain saat runtime.
Misalnya, di Dockerfile, hapus petunjuk USER, dan di skrip
entrypoint, gunakan urutan berikut:
gcsfuse ... # Run gcsfuse as root
su myuser -c "/yourapp.sh" # Switch to 'myuser' and run 'yourapp.sh'
Mengeksekusi pengguna
Jika nama pengguna tidak ada, Cloud Run akan menjalankan container sebagai pengguna root (uid=0).
Server metadata instance
Instance Cloud Run menampilkan server metadata yang dapat Anda gunakan untuk mengambil detail tentang container, seperti project ID, region, ID instance, atau akun layanan. Anda juga dapat menggunakan server metadata untuk membuat token untuk identitas layanan.
Untuk mengakses data server metadata, gunakan permintaan HTTP ke endpoint http://metadata.google.internal/ dengan header Metadata-Flavor: Google: library klien tidak diperlukan. Untuk mengetahui informasi selengkapnya, baca
Mendapatkan metadata.
Tabel berikut mencantumkan beberapa informasi server metadata yang tersedia:
| Jalur | Deskripsi |
|---|---|
/computeMetadata/v1/project/project-id |
Project ID untuk layanan atau tugas Cloud Run yang berada di dalamnya |
/computeMetadata/v1/project/numeric-project-id |
Nomor project tempat layanan atau tugas Cloud Run berada |
/computeMetadata/v1/instance/region |
Region layanan atau tugas Cloud Run ini, menampilkan projects/PROJECT-NUMBER/regions/REGION |
/computeMetadata/v1/instance/id |
ID unik instance (juga tersedia di log). |
/computeMetadata/v1/instance/service-accounts/default/email |
Email untuk identitas layanan dari layanan atau tugas Cloud Run ini. |
/computeMetadata/v1/instance/service-accounts/default/token |
Membuat token akses OAuth2 untuk akun layanan dari layanan atau tugas Cloud Run ini. Agen layanan Cloud Run digunakan untuk mengambil token. Endpoint ini akan menampilkan respons JSON dengan atribut access_token. Baca selengkapnya tentang cara mengekstrak dan menggunakan token akses ini. |
Perhatikan bahwa Cloud Run tidak memberikan detail tentang
Google Cloud zona tempat
instance dijalankan. Akibatnya, atribut metadata /computeMetadata/v1/instance/zone
selalu menampilkan projects/PROJECT-NUMBER/zones/REGION-1.
Nama file
Nama file yang Anda gunakan dalam container harus kompatibel dengan UTF-8, baik UTF-8 atau yang dapat dikonversi otomatis secara aman ke UTF-8. Jika nama file Anda menggunakan encoding yang berbeda, jalankan build Docker di komputer dengan nama file yang kompatibel dengan UTF-8 dan hindari menyalin file ke container yang berisi nama UTF-8 yang tidak kompatibel.
Deployment container akan gagal jika nama file tidak kompatibel dengan UTF-8. Perhatikan bahwa tidak ada batasan encoding karakter yang Anda gunakan dalam file.
Waktu tunggu permintaan keluar
Untuk layanan dan tugas Cloud Run, ada waktu tunggu setelah 10 menit waktu tidak ada aktivitas untuk permintaan dari container Anda ke VPC. Untuk permintaan dari container ke internet, diberikan waktu tunggu setelah 20 menit tidak beraktivitas.
Koneksi keluar direset
Streaming koneksi dari container Anda ke VPC dan internet terkadang dapat dihentikan dan diganti ketika infrastruktur dasar dimulai ulang atau diperbarui. Jika aplikasi Anda menggunakan kembali koneksi yang memakan waktu lama, sebaiknya konfigurasikan aplikasi Anda agar menghubungkan koneksi kembali guna menghindari penggunaan ulang koneksi yang tidak aktif.