Membuat Runtime Kustom

Runtime kustom memungkinkan Anda menggunakan implementasi alternatif dari bahasa lingkungan fleksibel yang didukung, atau untuk menyesuaikan yang disediakan Google. Selain itu, Anda juga dapat menulis kode dalam bahasa lain yang dapat menangani permintaan HTTP yang masuk (contoh). Dengan runtime kustom, lingkungan fleksibel menyediakan dan mengelola infrastruktur penskalaan, pemantauan, dan load balancing untuk Anda, sehingga Anda dapat fokus membuat aplikasi.

Untuk membuat runtime kustom, Anda harus:

Menyediakan file app.yaml

File konfigurasi app.yaml Anda harus berisi setidaknya setelan berikut:

runtime: custom
env: flex

Untuk mengetahui informasi tentang hal lain yang dapat Anda setel untuk aplikasi, lihat Mengonfigurasi Aplikasi dengan app.yaml.

Membuat Dockerfile

Dokumentasi lengkap tentang pembuatan Dockerfile tersedia di situs Docker. Jika menggunakan runtime kustom, Anda harus menyediakan Dockerfile, baik untuk menyediakan image dasar sendiri maupun menggunakan salah satu image dasar Google.

Menentukan image dasar

Perintah pertama dalam Dockerfile biasanya adalah perintah FROM yang menentukan image dasar. Image dasar digunakan untuk membuat container dan membangun aplikasi Anda. Anda dapat menulis image dasar Anda sendiri atau memilih image dasar dari container registry seperti DockerHub.

Memberi nama dan mencari Dockerfile

Secara umum, Dockerfile selalu diberi nama Dockerfile dan ditempatkan di direktori yang sama dengan file app.yaml yang terkait. Namun, dalam beberapa kasus, lingkungan alat mungkin memiliki persyaratan yang berbeda. Misalnya, alat Java berbasis Cloud SDK seperti plugin Maven, Gradle, Eclipse, dan IntelliJ mengharuskan Dockerfile berada dalam src/main/docker/Dockerfile dan file app.yaml berada di src/main/appengine/app.yaml. Lihat dokumentasi untuk lingkungan alat Anda untuk informasi selengkapnya.

Struktur kode yang diperlukan

Bagian ini menjelaskan perilaku yang harus diterapkan kode Anda, baik menggunakan image dasar yang disediakan Google atau image dasar Anda sendiri.

Memproses port 8080

Frontend App Engine akan mengarahkan permintaan masuk ke modul yang sesuai pada port 8080. Anda harus memastikan bahwa kode aplikasi memproses 8080.

Menangani peristiwa siklus proses

Lingkungan fleksibel secara berkala mengirimkan peristiwa siklus proses tertentu ke aplikasi Anda.

Penonaktifan Aplikasi

Saat instance perlu dinonaktifkan, permintaan masuk baru akan dirutekan ke instance lain (jika ada) dan permintaan yang saat ini sedang diproses akan diberi waktu untuk menyelesaikannya. Saat mematikan instance, lingkungan fleksibel biasanya mengirimkan sinyal STOP (SIGTERM) ke container aplikasi. Aplikasi Anda tidak perlu merespons peristiwa ini, tetapi dapat menggunakan tindakan ini untuk melakukan tindakan pembersihan yang diperlukan sebelum container dinonaktifkan. Dalam kondisi normal, sistem menunggu hingga 30 detik sampai aplikasi berhenti, lalu mengirimkan sinyal KILL (SIGKILL), yang segera menonaktifkan instance.

Dalam kasus yang jarang terjadi, pemadaman layanan dapat mencegah App Engine menyediakan waktu penonaktifan selama 30 detik. Artinya, sinyal STOP dan KILL mungkin tidak dikirim sebelum instance dihentikan. Untuk menangani kemungkinan ini, Anda harus memeriksa status instance secara berkala, terutama menggunakannya sebagai cache dalam memori, bukan penyimpanan data yang dapat diandalkan.

Permintaan health check

Anda dapat menggunakan permintaan health check berkala untuk mengonfirmasi bahwa instance VM telah berhasil di-deploy, dan untuk memeriksa apakah instance yang berjalan mempertahankan status yang responsif.

Membangun dan men-deploy runtime kustom

Setelah mengonfigurasi file app.yaml dan DOCKER, Anda dapat membangun dan men-deploy image container tersebut ke App Engine.

Atau, Anda dapat men-deploy image container bawaan dari runtime kustom Anda yang disimpan di container registry. Misalnya, Anda dapat menggunakan Cloud Build untuk membangun image secara terpisah, lalu menyimpan gambar tersebut di Artifact Registry.

Mengintegrasikan aplikasi Anda dengan Google Cloud Platform

Aplikasi yang berjalan di runtime kustom dapat menggunakan Library Klien Google Cloud untuk mengakses layanan Google Cloud Platform. Aplikasi dalam runtime kustom juga dapat menggunakan layanan pihak ketiga melalui API standar.

Mengautentikasi dengan layanan Google Cloud Platform

Kredensial Default Aplikasi menyediakan cara paling sederhana untuk melakukan autentikasi dan memanggil Google API.

Jika aplikasi Anda menggunakan Cloud Build untuk mengompilasi image Docker, jaringan cloudbuild akan menghosting Kredensial Default Aplikasi yang memungkinkan layanan Google Cloud terkait menemukan kredensial Anda secara otomatis.

Untuk informasi selengkapnya tentang autentikasi, lihat Autentikasi di Google.

Logging

Saat permintaan dikirim ke aplikasi Anda yang berjalan di App Engine, detail permintaan dan respons akan otomatis dicatat ke dalam log. Log tersebut dapat dilihat di Logs Explorer pada konsol Google Cloud.

Saat menangani permintaan, aplikasi Anda juga dapat menulis pesan logging-nya sendiri ke stdout dan stderr. File ini dikumpulkan secara otomatis dan dapat dilihat di Logs Explorer. Hanya entri terbaru ke stdout dan stderr yang dipertahankan, untuk membatasi ukurannya.

Anda juga dapat menulis log kustom ke /var/log/app_engine/custom_logs, menggunakan file yang diakhiri dengan .log atau .json.

Jika Anda menyertakan agen pihak ketiga dalam penampung aplikasi, pastikan Anda mengonfigurasi agen tersebut untuk mencatat log ke stdout dan stderr, atau ke log kustom. Tindakan ini akan memastikan setiap error yang dihasilkan oleh agen ini terlihat di Cloud Logging.

Log permintaan dan aplikasi untuk aplikasi Anda dikumpulkan oleh agen Cloud Logging dan disimpan selama maksimum 90 hari, hingga ukuran maksimum sebesar 1 GB. Jika ingin menyimpan log untuk jangka waktu yang lebih lama atau menyimpan log dengan ukuran lebih besar dari 1 GB, Anda dapat mengekspor log ke Cloud Storage. Anda juga dapat mengekspor log ke BigQuery dan Pub/Sub untuk diproses lebih lanjut.

Log lainnya juga tersedia untuk Anda gunakan. Berikut ini adalah beberapa log yang dikonfigurasi secara default:

Nama log Jenis payload Tujuan
crash.log text Informasi yang dicatat saat penyiapan gagal. Jika aplikasi Anda gagal dijalankan, periksa log ini.
monitoring.* text Informasi dari container Docker yang memublikasikan data ke Cloud Monitoring.
shutdown.log text Informasi yang dicatat saat dimatikan.
stdout text Output standar dari aplikasi Anda.
stderr text Error standar dari container Anda.
syslog text Syslog VM, di luar container Docker.