File Konfigurasi app.yaml

File app.yaml menentukan setelan konfigurasi untuk runtime serta setelan aplikasi, jaringan, dan resource umum lainnya.

Jangan tambahkan app.yaml ke file .gcloudignore. app.yaml mungkin diperlukan untuk deployment, dan menambahkannya ke .gcloudignore akan menyebabkan deployment gagal.

Sintaksis

Sintaksis file app.yaml adalah format YAML. Format YAML mendukung komentar, di mana setiap baris yang dimulai dengan karakter simbol hash (#) akan diabaikan, misalnya:

# This is a comment.

Pola jalur file dan URL menggunakan sintaksis ekspresi reguler POSIX yang diperluas, kecuali elemen pengkolasi dan class kolasi. Referensi balik ke pencocokan yang dikelompokkan (misalnya \1) didukung, begitu juga ekstensi Perl berikut: \w \W \s \S \d \D.

Setelan umum

File app.yaml dapat menyertakan setelan umum berikut. Perhatikan bahwa beberapa di antaranya bersifat wajib:

NamaDeskripsi
build_env_variables

Opsional. Jika menggunakan runtime yang mendukung buildpack, Anda dapat menentukan variabel lingkungan build dalam file app.yaml.

Untuk mempelajari lebih lanjut, lihat Menggunakan variabel lingkungan build.

runtime

Wajib. Nama lingkungan runtime yang digunakan aplikasi Anda. Misalnya, untuk menentukan lingkungan runtime, gunakan:

env: flex Wajib: Pilih lingkungan fleksibel.
service: service_name Wajib jika membuat layanan. Opsional untuk layanan default. Setiap layanan dan setiap versi harus memiliki nama. Nama dapat berisi angka, huruf, dan tanda hubung. Di lingkungan fleksibel, panjang gabungan dari VERSION-dot-SERVICE-dot-PROJECT_ID (di mana VERSION adalah nama versi Anda, SERVICE adalah nama layanan, dan PROJECT_ID adalah project ID Anda) tidak boleh lebih dari 63 karakter dan tidak boleh diawali atau diakhiri dengan tanda hubung.

Jika Anda men-deploy tanpa menentukan nama layanan, versi baru layanan default akan dibuat. Jika Anda men-deploy dengan nama layanan yang sudah ada, versi baru layanan tersebut akan dibuat. Jika Anda men-deploy dengan nama layanan baru yang tidak ada, layanan dan versi baru akan dibuat. Sebaiknya gunakan nama unik untuk setiap kombinasi versi layanan.

Catatan: Sebelumnya, layanan disebut "modul".

service_account

Opsional. Elemen service_account memungkinkan Anda menentukan akun layanan yang dikelola pengguna sebagai identitas versi. Akun layanan yang ditentukan akan digunakan saat mengakses layanan Google Cloud lainnya dan menjalankan tugas.

Akun layanan harus diisikan dalam format berikut:

service_account: [SERVICE_ACCOUNT_NAME]@[PROJECT_ID].
skip_files

Opsional. Elemen skip_files menentukan file mana saja dalam direktori aplikasi yang tidak akan diupload ke App Engine. Nilai ini dapat berupa sebuah ekspresi reguler, atau daftar ekspresi reguler. Semua nama file yang cocok dengan ekspresi reguler akan dihapus dari daftar file yang akan diupload saat aplikasi diupload.

Misalnya, untuk melewati file yang namanya diakhiri dengan .bak, tambahkan bagian skip_files seperti berikut:

skip_files:
- ^.*\.bak$

Setelan jaringan

Anda dapat menentukan setelan jaringan di file konfigurasi app.yaml, misalnya:

network:
  name: NETWORK_NAME
  instance_ip_mode: INSTANCE_IP_MODE
  instance_tag: TAG_NAME
  subnetwork_name: SUBNETWORK_NAME
  session_affinity: true
  forwarded_ports:
    - PORT
    - HOST_PORT:CONTAINER_PORT
    - PORT/tcp
    - HOST_PORT:CONTAINER_PORT/udp

Anda dapat menggunakan opsi berikut saat mengonfigurasi setelan jaringan:

Opsi Deskripsi
name Setiap instance VM di lingkungan fleksibel ditetapkan ke jaringan Google Compute Engine saat dibuat. Gunakan setelan ini untuk menentukan nama jaringan. Berikan nama pendek, bukan jalur resource (misalnya default, bukan https://www.googleapis.com/compute/v1/projects/my-project/global/networks/default). Jika nama jaringan tidak ditentukan, instance akan ditetapkan ke jaringan default project (yang memiliki nama default). Jika ingin menentukan nama subnetwork, Anda harus menentukan nama jaringan.
instance_ip_mode Opsional. Agar instance tidak menerima alamat IP eksternal sementara, tetapkan opsi ini ke internal dan aktifkan Akses Google Pribadi. Jika instance Anda sebelumnya di-deploy tanpa setelan ini, atau di-deploy saat opsi ini ditetapkan ke external, men-deploy ulang instance saat opsi ini ditetapkan ke internal akan menghapus alamat IP eksternal sementara dari instance Anda. Setelan internal memiliki batasan. Default-nya adalah external.
instance_tag Opsional. Tag dengan nama tersebut ditetapkan ke setiap instance layanan saat dibuat. Tag dapat berguna dalam perintah gcloud untuk menargetkan tindakan ke sekumpulan instance. Misalnya, lihat penggunaan flag --source-tags dan --target-tags dalam perintah compute firewalls-create.

Jika tidak ditentukan, instance akan diberi tag aef-INSTANCE_ID saat VPC Bersama tidak digunakan. Jika VPC Bersama digunakan, instance akan diberi tag aef-INSTANCE_ID and aef-instance.
subnetwork_name Opsional. Anda dapat menyegmentasikan jaringan dan menggunakan subnetwork kustom. Pastikan name jaringan sudah ditentukan. Berikan nama pendek, bukan jalur resource (misalnya default, bukan https://www.googleapis.com/compute/v1/projects/my-project/global/networks/default/subnetworks/default).Subnetwork harus berada di region yang sama dengan aplikasi.
session_affinity Opsional. Tetapkan opsi ini ke true untuk mengonfigurasi App Engine agar merutekan beberapa permintaan berurutan untuk pengguna tertentu ke instance App Engine yang sama, misalnya saat menyimpan data pengguna secara lokal selama sesi. Afinitas sesi memungkinkan pemeriksaan nilai cookie untuk mengidentifikasi beberapa permintaan oleh pengguna yang sama, lalu mengarahkan semua permintaan tersebut ke instance yang sama. Jika instance dimulai ulang, tidak responsif, kelebihan beban, atau menjadi tidak tersedia saat jumlah instance telah diperkecil, afinitas sesi akan rusak dan permintaan selanjutnya akan dirutekan ke instance berbeda. Perlu diperhatikan bahwa mengaktifkan afinitas sesi dapat memengaruhi konfigurasi load balancing Anda. Parameter ini dinonaktifkan secara default.
forwarded_ports Opsional. Anda dapat meneruskan port dari instance Anda (HOST_PORT) ke container Docker (CONTAINER_PORT). HOST_PORT harus antara 1024 dan 65535 serta tidak boleh bertentangan dengan port berikut: 22, 8080, 8090, 8443, 10000, 10001, 10400-10500, 11211, 24231. CONTAINER_PORT harus antara 1 dan 65535 serta tidak boleh bertentangan dengan port berikut: 22, 10001, 10400-10500, 11211. Jika Anda hanya menentukan PORT, App Engine akan menganggap bahwa port tersebut adalah port yang sama di host dan container. Secara default, traffic TCP dan UDP diteruskan. Traffic harus diarahkan langsung ke alamat IP instance target, bukan melalui domain appspot.com atau domain kustom Anda.

Konfigurasi jaringan lanjutan

Anda dapat menyegmentasikan jaringan Compute Engine menjadi beberapa subnetwork. Dengan begitu, Anda dapat mengaktifkan skenario VPN, seperti mengakses database dalam jaringan perusahaan.

Untuk mengaktifkan subnetwork untuk aplikasi App Engine Anda:

  1. Buat jaringan subnet kustom.

  2. Tambahkan nama jaringan dan nama subnetwork ke file app.yaml Anda, seperti yang ditentukan di atas.

  3. Untuk membuat VPN sederhana berdasarkan perutean statis, buat gateway dan tunnel untuk jaringan subnet kustom. Jika tidak, lihat cara membuat jenis VPN lain.

Penerusan port

Penerusan port memungkinkan koneksi langsung ke container Docker di instance Anda. Traffic ini dapat mengalir melalui protokol apa pun. Penerusan port dimaksudkan untuk membantu dalam situasi ketika Anda mungkin perlu memasang debugger atau profiler. Traffic harus diarahkan langsung ke alamat IP instance target, bukan melalui domain appspot.com atau domain kustom Anda.

Secara default, traffic masuk dari luar jaringan Anda tidak diizinkan melalui firewall Google Cloud Platform. Setelah menetapkan penerusan port dalam file app.yaml, Anda harus menambahkan aturan firewall yang mengizinkan traffic dari port yang ingin dibuka.

Anda dapat menentukan aturan firewall di halaman Networking Firewall Rules pada Konsol Google Cloud atau menggunakan perintah gcloud.

Misalnya, jika Anda ingin meneruskan traffic TCP dari port 2222:

  1. Di setelan jaringan app.yaml, sertakan:

    network:
      forwarded_ports:
        - 2222/tcp
    
    1. Jika Anda menggunakan runtime Python, ubah app.yaml untuk menyertakan:

      entrypoint: gunicorn -b :$PORT -b :2222 main:app
      
  2. Tentukan aturan firewall di Konsol Google Cloud atau gunakan gcloud compute firewall-rules create untuk mengizinkan traffic dari sumber mana pun (0.0.0.0/0) dan dari tcp:2222.

Setelan resource

Setelan ini mengontrol resource komputasi. App Engine menetapkan jenis mesin berdasarkan jumlah CPU dan memori yang Anda tentukan. Mesin dijamin memiliki resource setidaknya sebanyak yang Anda tentukan, bahkan mungkin lebih.

Anda dapat menentukan hingga delapan volume tmpfs di setelan resource. Selanjutnya, Anda dapat mendukung workload yang memerlukan memori bersama melalui tmpfs dan dapat meningkatkan I/O sistem file.

Contoh:

resources:
  cpu: 2
  memory_gb: 2.3
  disk_size_gb: 10
  volumes:
  - name: ramdisk1
    volume_type: tmpfs
    size_gb: 0.5

Anda dapat menggunakan opsi berikut saat mengonfigurasi setelan resource:

Opsi Deskripsi Default
cpu Jumlah core; harus satu, bilangan genap antara 2 dan 32, atau kelipatan 4 antara 32 dan 80. 1 core
memory_gb

RAM dalam GB. Memori yang diminta untuk aplikasi Anda, yang tidak mencakup memori ~0,4 GB yang diperlukan untuk overhead beberapa proses. Setiap core CPU memerlukan total memori antara 1,0 dan 6,5 GB.

Untuk menghitung memori yang diminta:

memory_gb = cpu * [1,0 - 6,5] - 0,4

Untuk contoh di atas, di mana Anda telah menentukan 2 core, Anda dapat meminta memori antara 1,6 dan 12,6 GB. Jumlah total memori yang tersedia untuk aplikasi ditetapkan oleh lingkungan runtime sebagai variabel lingkungan GAE_MEMORY_MB.

0,6 GB
disk_size_gb Ukuran dalam GB. Ukuran minimum adalah 10 GB dan maksimum adalah 10.240 GB. 13 GB
name Wajib, jika menggunakan volume. Nama volume. Nama harus unik dan terdiri atas 1 hingga 63 karakter. Karakter dapat berupa huruf kecil, angka, atau tanda hubung. Karakter pertama harus berupa huruf, dan karakter terakhir tidak boleh berupa tanda hubung. Volume dipasang di container aplikasi sebagai /mnt/NAME.
volume_type Wajib, jika menggunakan volume. Harus berupa tmpfs.
size_gb Wajib, jika menggunakan volume. Ukuran volume, dalam GB. Nilai minimumnya adalah 0,001 GB dan maksimumnya adalah jumlah memori yang tersedia di container aplikasi dan di perangkat dasar. Google tidak menambahkan RAM tambahan ke sistem Anda untuk memenuhi persyaratan disk. RAM yang dialokasikan untuk volume tmpfs akan dikurangkan dari memori yang tersedia untuk container aplikasi. Presisinya bergantung pada sistem.

Health check terpisah

Secara default, health check terpisah diaktifkan. Anda dapat menggunakan permintaan health check berkala untuk mengonfirmasi bahwa instance VM telah berhasil di-deploy, dan untuk memastikan bahwa instance yang berjalan selalu berstatus responsif. Setiap health check harus dijawab dalam interval waktu yang ditentukan.

Instance dianggap tidak responsif jika gagal merespons sejumlah permintaan health check berturut-turut. Jika instance tidak aktif, instance akan dimulai ulang. Jika belum siap, instance tidak akan menerima permintaan klien. Health check juga dapat gagal jika tidak ada kapasitas disk yang kosong.

Ada dua jenis health check yang dapat Anda gunakan:

  • Pemeriksaan keaktifan mengonfirmasi bahwa VM dan container Docker sedang berjalan. App Engine memulai ulang instance yang tidak responsif.
  • Pemeriksaan kesiapan mengonfirmasi bahwa instance Anda siap menerima permintaan masuk. Instance yang gagal dalam pemeriksaan kesiapan tidak akan ditambahkan ke kumpulan instance yang tersedia.

Secara default, permintaan HTTP dari health check tidak diteruskan ke container aplikasi Anda. Jika Anda ingin memperluas health check ke aplikasi, tentukan jalur untuk pemeriksaan keaktifan atau pemeriksaan kesiapan. Health check yang disesuaikan untuk aplikasi Anda dianggap berhasil jika menampilkan kode respons 200 OK.

Pemeriksaan keaktifan

Pemeriksaan keaktifan mengonfirmasi bahwa VM dan container Docker sedang berjalan. Instance yang dianggap tidak responsif akan dimulai ulang.

Anda dapat menyesuaikan permintaan pemeriksaan keaktifan dengan menambahkan bagian liveness_check opsional ke file app.yaml, misalnya:

liveness_check:
  path: "/liveness_check"
  check_interval_sec: 30
  timeout_sec: 4
  failure_threshold: 2
  success_threshold: 2

Setelan berikut tersedia untuk pemeriksaan keaktifan:

Kolom Default Rentang (Minimum-Maksimum) Deskripsi
path Tidak ada Jika Anda ingin pemeriksaan keaktifan diteruskan ke container aplikasi, tentukan jalur URL, seperti "/liveness_check"
timeout_sec 4 detik 1-300 Interval waktu tunggu untuk setiap permintaan, dalam detik.
check_interval_sec 30 seconds 1-300 Interval waktu antara pemeriksaan, dalam detik. Perhatikan bahwa nilai ini harus lebih besar daripada timeout_sec.
failure_threshold 4 pemeriksaan 1-10 Instance menjadi tidak responsif setelah gagal dalam pemeriksaan berturut-turut sebanyak ini.
success_threshold 2 pemeriksaan 1-10 Instance yang tidak responsif akan kembali menjadi responsif setelah berhasil merespons pemeriksaan berturut-turut sebanyak ini.
initial_delay_sec 300 detik 0-3600 Penundaan, dalam detik, setelah instance dimulai, yang selama rentang waktu tersebut respons health check diabaikan. Setelan ini berlaku untuk setiap instance yang baru dibuat dan dapat memberi instance baru lebih banyak waktu untuk aktif dan berjalan. Setelan ini menunda pemeriksaan autohealing dan berpotensi membuat ulang instance secara prematur jika instance sedang dalam proses dimulai. Timer penundaan awal dimulai saat instance berada dalam mode RUNNING. Misalnya, Anda dapat meningkatkan waktu tunda jika aplikasi memiliki tugas inisialisasi yang membutuhkan waktu lama sebelum siap menyalurkan traffic.

Pemeriksaan kesiapan

Pemeriksaan kesiapan mengonfirmasi bahwa instance dapat menerima permintaan masuk. Instance yang tidak lulus pemeriksaan kesiapan tidak akan ditambahkan ke kumpulan instance yang tersedia.

Anda dapat menyesuaikan permintaan health check dengan menambahkan bagian readiness_check opsional ke file app.yaml, misalnya:

readiness_check:
  path: "/readiness_check"
  check_interval_sec: 5
  timeout_sec: 4
  failure_threshold: 2
  success_threshold: 2
  app_start_timeout_sec: 300

Setelan berikut tersedia untuk pemeriksaan kesiapan:

Kolom Default Rentang (Minimum-Maksimum) Deskripsi
path Tidak ada Jika Anda ingin pemeriksaan kesiapan diteruskan ke container aplikasi, tentukan jalur URL, seperti "/readiness_check"
timeout_sec 4 detik 1-300 Interval waktu tunggu untuk setiap permintaan, dalam detik.
check_interval_sec 5 detik 1-300 Interval waktu antara pemeriksaan, dalam detik. Perhatikan bahwa nilai ini harus lebih besar daripada timeout_sec.
failure_threshold 2 pemeriksaan 1-10 Instance menjadi tidak responsif setelah gagal dalam pemeriksaan berturut-turut sebanyak ini.
success_threshold 2 pemeriksaan 1-10 Instance yang tidak responsif akan menjadi responsif kembali setelah berhasil merespons pemeriksaan berturut-turut sebanyak ini.
app_start_timeout_sec 300 detik 1-1800 Setelan ini berlaku untuk deployment baru, bukan untuk VM individual. Setelan ini menentukan waktu maksimum (dalam detik) yang diberikan agar instance dalam jumlah yang cukup di suatu deployment dapat lulus health check. Jika durasi ini terlampaui, deployment akan gagal dan di-roll back. Timer dimulai saat instance Compute Engine telah disediakan dan layanan backend Load Balancer dibuat. Misalnya, Anda dapat meningkatkan waktu tunggu jika ingin memberikan waktu lebih lama selama deployment agar instance dalam jumlah yang cukup menjadi responsif.

Frekuensi health check

Untuk memastikan ketersediaan tinggi, App Engine membuat salinan redundan setiap health checker. Jika health checker gagal, health checker redundan dapat mengambil alih tanpa penundaan.

Saat memeriksa log nginx.health_check aplikasi, Anda mungkin mendapati bahwa polling health check terjadi lebih sering daripada yang telah dikonfigurasi. Hal ini karena health checker redundan juga mengikuti setelan Anda. Health checker redundan ini dibuat secara otomatis dan Anda tidak dapat mengonfigurasinya.

Setelan penskalaan layanan

Kunci yang digunakan untuk mengontrol penskalaan layanan bergantung pada jenis penskalaan yang Anda tetapkan ke layanan.

Anda dapat menggunakan penskalaan otomatis atau manual. Default-nya adalah penskalaan otomatis.

Penskalaan otomatis

Anda dapat mengonfigurasi penskalaan otomatis dengan menambahkan bagian automatic_scaling ke file app.yaml. Contoh:

automatic_scaling:
  min_num_instances: 1
  max_num_instances: 15
  cool_down_period_sec: 180
  cpu_utilization:
    target_utilization: 0.6
  target_concurrent_requests: 100

Tabel berikut mencantumkan setelan yang dapat Anda gunakan dengan penskalaan otomatis:

Nama Deskripsi
automatic_scaling Penskalaan otomatis diasumsikan secara default. Sertakan baris ini jika Anda ingin menentukan salah satu setelan penskalaan otomatis.
min_num_instances Jumlah minimum instance yang diberikan ke layanan Anda. Saat di-deploy, layanan akan diberi instance sebanyak ini dan diskalakan sesuai dengan traffic. Harus 1 atau lebih besar, default-nya adalah 2 untuk mengurangi latensi.
max_num_instances Jumlah maksimum instance yang dapat ditingkatkan skalanya oleh layanan Anda. Jumlah maksimum instance dalam project dibatasi oleh kuota resource project. Default-nya adalah 20.
cool_down_period_sec Jumlah detik autoscaler harus menunggu sebelum mulai mengumpulkan informasi dari instance baru. Setelan ini mencegah autoscaler mengumpulkan informasi saat instance sedang dimulai, karena selama waktu tersebut penggunaan yang terkumpul tidak dapat diandalkan. Periode tunggu ini harus lebih besar daripada atau sama dengan 60 detik. Default-nya adalah 120.
cpu_utilization Gunakan header ini jika Anda ingin menentukan target pemakaian CPU.
target_utilization Target pemakaian CPU Penggunaan CPU di semua instance yang berjalan dirata-rata dan digunakan untuk memutuskan kapan harus mengurangi atau meningkatkan jumlah instance. Perhatikan bahwa jumlah instance akan dikurangi 25 detik setelah sinyal penonaktifan diterima, meskipun ada permintaan yang sedang diproses. Default-nya adalah 0.5.
target_concurrent_requests

(Beta) Jumlah target koneksi serentak per instance. Jika Anda menentukan nilai untuk parameter ini, autoscaler akan menggunakan jumlah rata-rata koneksi serentak di semua instance yang berjalan untuk memutuskan kapan harus mengurangi atau meningkatkan jumlah instance. Jumlah instance akan dikurangi 25 detik setelah sinyal penonaktifan diterima, meskipun ada permintaan yang sedang diproses.

Jika Anda tidak menentukan nilai untuk parameter ini, autoscaler tidak akan menargetkan jumlah koneksi serentak per instance.

Koneksi tidak sama dengan permintaan. Koneksi dapat digunakan kembali oleh klien untuk mengirim beberapa permintaan.

Penskalaan manual

Anda dapat mengonfigurasi penskalaan manual dengan menambahkan bagian manual_scaling ke file app.yaml. Contoh:

manual_scaling:
  instances: 5

Tabel berikut mencantumkan setelan yang dapat Anda gunakan dengan penskalaan manual:

NamaDeskripsi
manual_scaling Harus ada untuk mengaktifkan penskalaan manual pada layanan.
instances Jumlah instance yang akan ditetapkan ke layanan.

Menentukan variabel lingkungan

Anda dapat menentukan variabel lingkungan di app.yaml untuk disediakan bagi aplikasi Anda, misalnya:

env_variables:
  MY_VAR: "my value"

di mana MY_VAR dan my value adalah nama dan nilai variabel lingkungan yang ingin Anda tentukan, dan setiap entri variabel lingkungan diindentasi dua spasi di bawah elemen env_variables.

Menggunakan variabel lingkungan