קובץ התצורה app.yaml

קובץ app.yaml מגדיר את הגדרות התצורה של זמן הריצה, וגם הגדרות כלליות של האפליקציה, הרשת ומשאבים אחרים.

אל תוסיפו את app.yaml לקובץ .gcloudignore. יכול להיות שיהיה צורך ב-app.yaml לפריסה, והוספתו ל-.gcloudignore תגרום לכך שהפריסה תיכשל.

תחביר

התחביר של קובץ app.yaml הוא פורמט YAML. פורמט YAML תומך בהערות, שבהן המערכת מתעלמת מכל שורה שמתחילה בתו הסולמית (#), לדוגמה:

# This is a comment.

תבניות של כתובות URL ונתיבי קבצים משתמשות בתחביר של ביטויים רגולריים מורחבים של POSIX, לא כולל רכיבי איסוף ומחלקות איסוף. יש תמיכה בהפניות חוזרות להתאמות מקובצות (למשל \1), וגם בתוספים האלה של Perl: ‏ \w \W \s \S \d \D.

הגדרות כלליות

קובץ app.yaml יכול לכלול את ההגדרות הכלליות האלה. שימו לב שחלק מהם הם חובה:

שם	תיאור
`build_env_variables`	זה שינוי אופציונלי. אם אתם משתמשים בסביבת זמן ריצה שתומכת בחבילות buildpack, אתם יכולים להגדיר משתני סביבה של build בקובץ `app.yaml`. מידע נוסף זמין במאמר שימוש במשתני סביבת build.
`runtime`	חובה. השם של סביבת זמן הריצה שבה האפליקציה משתמשת. לדוגמה, כדי לציין את סביבת זמן הריצה, משתמשים ב: runtime: python ציון `python` בוחר הטמעה מלאה של זמן הריצה של Python 2.7 או 3.7. כדי לציין גרסה נתמכת של Python או להשתמש ב-Python Runtimes החדשים, אפשר לעיין בהגדרה `runtime_config`. סביבות זמן הריצה האלה לא תומכות באף API של App Engine. צריך להשתמש בממשקי ה-API שזמינים לשירות שבו רוצים להשתמש, כמו Google Cloud APIs. מידע נוסף ודוגמה זמינים במאמרים בנושא Python runtime והגדרת האפליקציה באמצעות app.yaml.
`runtime_config`	מציינים את גרסת זמן הריצה של Python. החל מגרסה 3.8 של Python, צריך לציין את גרסת מערכת ההפעלה. runtime_config: operating_system: "ubuntu24" runtime_version: "3.14" ‫`operating_system`: מציינת את הגרסה של מערכת ההפעלה Ubuntu שבה רוצים להשתמש. נדרש ב-Python מגרסה 3.8 ואילך. לא נתמך ב-Python בגרסה 3.7 ובגרסאות קודמות. בדף של Python runtimes אפשר לראות את גרסאות Ubuntu וזמני הריצה הנתמכים. ‫`runtime_version`: אופציונלי לכל גרסאות זמן הריצה. מציינת את הגרסה של זמן הריצה של Python שרוצים להשתמש בה. במאמר בנושא זמני ריצה של Python מפורטות הגרסאות הנתמכות וערכי ברירת המחדל.
`env: flex`	חובה: בוחרים את הסביבה הגמישה.
`entrypoint`	הפקודה להפעלת האפליקציה. נקודת הכניסה מתחילה תהליך שמגיב לבקשות HTTP ביציאה שמוגדרת על ידי משתנה הסביבה `PORT`.
`service: service_name`	חובה אם יוצרים שירות. אופציונלי לשירות ברירת המחדל. לכל שירות ולכל גרסה צריך להיות שם. שם יכול להכיל מספרים, אותיות ומקפים. בסביבה הגמישה, האורך המשולב של `VERSION-dot-SERVICE-dot-PROJECT_ID` (כאשר `VERSION` הוא שם הגרסה, `SERVICE` הוא שם השירות ו-`PROJECT_ID` הוא מזהה הפרויקט) לא יכול להיות ארוך מ-63 תווים, והוא לא יכול להתחיל או להסתיים במקף. אם מבצעים פריסה בלי לציין שם שירות, נוצרת גרסה חדשה של שירות ברירת המחדל. אם מבצעים פריסה עם שם שירות שכבר קיים, נוצרת גרסה חדשה של השירות הזה. אם מבצעים פריסה עם שם שירות חדש שלא קיים, נוצרים שירות וגרסה חדשים. מומלץ להשתמש בשם ייחודי לכל שילוב של שירות וגרסה. הערה: השירותים נקראו בעבר 'מודולים'.
`service_account`	זה שינוי אופציונלי. רכיב `service_account` מאפשר לציין חשבון שירות שמנוהל על ידי משתמש כזהות של הגרסה. חשבון השירות שצוין ישמש לגישה לשירותים אחרים של Google Cloud ולביצוע משימות. צריך לספק את חשבון השירות בפורמט הבא: service_account: [SERVICE_ACCOUNT_NAME]@[PROJECT_ID].iam.gserviceaccount.com
`skip_files`	זה שינוי אופציונלי. רכיב `skip_files` מציין אילו קבצים בספריית האפליקציה לא יועלו ל-App Engine. הערך הוא ביטוי רגולרי או רשימה של ביטויים רגולריים. כל שם קובץ שתואם לאחד מהביטויים הרגולריים מושמט מרשימת הקבצים להעלאה כשהאפליקציה מועלית. לדוגמה, כדי לדלג על קבצים שהשמות שלהם מסתיימים ב-`.bak`, מוסיפים קטע `skip_files` כמו בדוגמה הבאה: skip_files: - ^.*\.bak$

הגדרות ספציפיות לזמן הריצה

מידע נוסף על הגדרת רכיב תרגום של Python באמצעות ההגדרות של runtime_config זמין בדף Python runtime.

הגדרות רשת

אפשר לציין הגדרות רשת בקובץ התצורה app.yaml, למשל:

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

אפשר להשתמש באפשרויות הבאות כשמגדירים את הגדרות הרשת:

אפשרות	תיאור
`name`	לכל מכונת VM בסביבה הגמישה מוקצית רשת של Google Compute Engine כשהיא נוצרת. ההגדרה הזו מאפשרת לציין שם רשת. צריך לציין את השם הקצר, ולא את נתיב המשאב (לדוגמה, `default` ולא `https://www.googleapis.com/compute/v1/projects/my-project/global/networks/default`). אם לא מציינים שם רשת, המופעים משויכים לרשת ברירת המחדל של הפרויקט (ששמה `default`). אם רוצים לציין שם של רשת משנה, צריך לציין שם של רשת.
`instance_ip_mode`	זה שינוי אופציונלי. כדי למנוע ממקרים לקבל כתובת IP חיצונית ארעית, מגדירים את הערך ל-`internal` ומפעילים גישה פרטית ל-Google. אם הפריסה של המכונה שלכם בוצעה בעבר בלי ההגדרה הזו, או שהיא בוצעה כשההגדרה הזו הייתה `external`, פריסה מחדש כשההגדרה הזו היא `internal` תסיר כתובות IP חיצוניות זמניות מהמכונות שלכם. להגדרה `internal` יש מגבלות. ברירת המחדל היא `external`.
`instance_tag`	זה שינוי אופציונלי. תג עם השם הזה מוקצה לכל מופע של השירות כשהוא נוצר. תגים יכולים להיות שימושיים בפקודות `gcloud` כדי לטרגט פעולה לקבוצה של מופעים. לדוגמה, אפשר לראות את השימוש בדגלים `--source-tags` ו-`--target-tags` בפקודה compute firewalls-create. אם לא מציינים תג, המופע מתויג בתג `aef-INSTANCE_ID` כשלא משתמשים ב-VPC משותף. אם משתמשים ב-VPC משותף, המכונה מתויגת גם ב-`aef-INSTANCE_ID and aef-instance.`
`subnetwork_name`	זה שינוי אופציונלי. אתם יכולים לפלח את הרשת ולהשתמש ברשת משנה בהתאמה אישית. מוודאים שצוינה הרשת `name`. צריך לציין את השם הקצר, לא את נתיב המשאב (לדוגמה, `default` ולא `https://www.googleapis.com/compute/v1/projects/my-project/global/networks/default/subnetworks/default`).רשת המשנה צריכה להיות באותו אזור כמו האפליקציה.
`session_affinity`	זה שינוי אופציונלי. ההגדרה `true` מאפשרת להגדיר את App Engine כך שינתב כמה בקשות רצופות של משתמש מסוים לאותו מופע של App Engine, למשל כשמאחסנים נתוני משתמשים באופן מקומי במהלך סשן. זיקה לסשן מאפשרת לבדוק את הערך של קובץ Cookie כדי לזהות כמה בקשות מאותו משתמש, ואז להפנות את כל הבקשות האלה לאותו מופע. אם המופע מופעל מחדש, לא תקין, עמוס מדי או הופך ללא זמין כשמספר המופעים מצטמצם, זיקת הסשן תיפסק ובקשות נוספות ינותבו למופע אחר. שימו לב: הפעלת שיוך סשנים עשויה להשפיע על הגדרת איזון העומסים. הפרמטר הזה מושבת כברירת מחדל.
`forwarded_ports`	זה שינוי אופציונלי. אפשר להעביר יציאות מהמופע (`HOST_PORT`) אל מאגר Docker (`CONTAINER_PORT`). הערך של `HOST_PORT` צריך להיות בין 1024 ל-65535, והוא לא יכול להיות זהה ליציאות הבאות: 22,‏ 8080,‏ 8090,‏ 8443,‏ 10000,‏ 10001,‏ 10400-10500,‏ 11211,‏ 24231. הערך של `CONTAINER_PORT` חייב להיות בין 1 ל-65535, ואסור שהוא יתנגש עם היציאות הבאות: 22,‏ 10001,‏ 10400-10500,‏ 11211. אם מציינים רק `PORT`, מערכת App Engine מניחה שזהו אותו פורט במארח ובקונטיינר. כברירת מחדל, תנועת TCP ו-UDP מועברת. התנועה צריכה להיות מופנית ישירות לכתובת ה-IP של מופע היעד ולא דרך הדומיין appspot.com או הדומיין המותאם אישית שלכם.

הגדרת רשת מתקדמת

אפשר לפלח את הרשת של Compute Engine לרשתות משנה. כך תוכלו להפעיל תרחישי VPN, כמו גישה למסדי נתונים ברשת הארגונית שלכם.

כדי להפעיל רשתות משנה באפליקציית App Engine:

יוצרים רשת משנה בהתאמה אישית.
מוסיפים את שם הרשת ואת שם רשת המשנה לקובץ app.yaml, כמו שמתואר למעלה.
כדי ליצור VPN פשוט שמבוסס על ניתוב סטטי, צריך ליצור שער ומנהרה לרשת משנה בהתאמה אישית. אחרת, אפשר לקרוא איך ליצור סוגים אחרים של VPN.

העברה ליציאה אחרת

העברת פורטים מאפשרת חיבורים ישירים למאגר Docker במופעים שלכם. התעבורה הזו יכולה לעבור בכל פרוטוקול. העברת פורטים נועדה לעזור במצבים שבהם יכול להיות שתצטרכו לצרף כלי לניפוי באגים או כלי ליצירת פרופילים. התנועה צריכה להיות מופנית ישירות לכתובת ה-IP של מופע היעד, ולא דרך הדומיין appspot.com או הדומיין המותאם אישית שלכם.

כברירת מחדל, תעבורת נתונים נכנסת מחוץ לרשת לא מורשית לעבור דרך חומות האש של Google Cloud Platform. אחרי שמציינים את העברת הפורטים בקובץ app.yaml, צריך להוסיף כלל חומת אש שמאפשר תעבורה מהפורטים שרוצים לפתוח.

אפשר לציין כלל חומת אש בדף Networking Firewall Rules במסוףGoogle Cloud או באמצעות פקודות gcloud.

לדוגמה, אם רוצים להעביר תנועת TCP מיציאה 2222:

בהגדרות הרשת של app.yaml, כוללים את:
```
network:
  forwarded_ports:
    - 2222/tcp
```
1. אם משתמשים בסביבת זמן הריצה של Python, צריך לשנות את app.yaml כך שיכלול:
```
entrypoint: gunicorn -b :$PORT -b :2222 main:app
```
מציינים כלל חומת אש בGoogle Cloud מסוף או באמצעות gcloud compute firewall-rules create כדי לאפשר תעבורה מכל מקור (0.0.0.0/0) ומ-tcp:2222.

הגדרות המשאב

ההגדרות האלה קובעות את משאבי המחשוב. ‫App Engine מקצה סוג מכונה על סמך כמות המעבדים והזיכרון שהגדרתם. מובטח שלמכונה יהיו לפחות המשאבים שציינתם, ויכול להיות שיהיו לה יותר.

בהגדרות המשאבים אפשר לציין עד שמונה נפחים של tmpfs. לאחר מכן תוכלו להפעיל עומסי עבודה שדורשים זיכרון משותף באמצעות tmpfs, ולשפר את קלט/פלט של מערכת הקבצים.

לדוגמה:

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

אפשר להשתמש באפשרויות הבאות כשמגדירים את ההגדרות של המשאבים:

אפשרות	תיאור	ברירת מחדל
`cpu`	מספר ליבות המעבד. הערך חייב להיות 1, מספר זוגי בין 2 ל-32 או כפולה של 4 בין 32 ל-80.	ליבה אחת
`memory_gb`	זיכרון RAM ב-GB. הזיכרון הנדרש לאפליקציה, שלא כולל את הזיכרון בנפח ‎0.4 GB שנדרש לתקורה של תהליכים מסוימים. לכל ליבת CPU נדרש זיכרון כולל של ‎1.0 עד ‎6.5 GB. כדי לחשב את הזיכרון הנדרש: `memory_gb` = `cpu` * [1.0 - 6.5] - 0.4 בדוגמה שלמעלה, שבה צוינו 2 ליבות, אפשר לבקש בין 1.6 ל-12.6GB. הסביבה בזמן הריצה מגדירה את כמות הזיכרון הכוללת שזמינה לאפליקציה כמשתנה הסביבה `GAE_MEMORY_MB`.	0.6 GB
`disk_size_gb`	הגודל ב-GB. הגודל המינימלי הוא 10GB והגודל המקסימלי הוא 10,240GB.	‫13GB
`name`	חובה אם משתמשים בכרכים. שם עוצמת הקול. השמות צריכים להיות ייחודיים, ואורכם צריך להיות בין תו אחד ל-63 תווים. התווים יכולים להיות אותיות קטנות, ספרות או מקפים. התו הראשון חייב להיות אות, והתו האחרון לא יכול להיות מקף. הנפח מותקן במאגר האפליקציות בתור `/mnt/NAME`.
`volume_type`	חובה אם משתמשים בכרכים. חייב להיות `tmpfs`.
`size_gb`	חובה אם משתמשים בכרכים. גודל הנפח, ב-GB. המינימום הוא 0.001GB והמקסימום הוא נפח הזיכרון שזמין במאגר האפליקציות ובמכשיר הבסיסי. ‫Google לא מוסיפה RAM למערכת כדי לעמוד בדרישות הדיסק. ‫RAM allocated for tmpfs volumes will be subtracted from memory available to the app container. רמת הדיוק תלויה במערכת.

פיצול בדיקות התקינות

כברירת מחדל, בדיקות תקינות מפוצלות מופעלות. אפשר להשתמש בבקשות תקופתיות לבדיקת תקינות כדי לוודא שמכונה וירטואלית נפרסה בהצלחה, וכדי לבדוק שמכונה וירטואלית שפועלת שומרת על סטטוס תקין. צריך לענות על כל בדיקת תקינות בתוך פרק זמן מוגדר.

מופע נחשב לא תקין אם הוא לא מגיב למספר מסוים של בקשות רצופות לבדיקת תקינות. אם מופע לא פעיל, הוא יופעל מחדש. אם מופע לא מוכן, הוא לא יקבל בקשות מלקוחות. בדיקת תקינות יכולה להיכשל גם אם אין מקום פנוי בדיסק.

יש שני סוגים של בדיקות תקינות שאפשר להשתמש בהן:

בדיקות פעילות מאשרות שהמכונה הווירטואלית והקונטיינר ב-Docker פועלים. ‫App Engine מפעיל מחדש מופעים לא תקינים.
בדיקות מוכנות מאשרות שהמופע שלכם מוכן לקבל בקשות נכנסות. מופעים שנכשלו בבדיקת המוכנות לא נוספים למאגר המופעים הזמינים.

כברירת מחדל, בקשות HTTP מבדיקות תקינות לא מועברות למאגר האפליקציות. אם רוצים להרחיב את בדיקות התקינות לאפליקציה, צריך לציין נתיב לבדיקות פעילות או לבדיקות מוכנות. בדיקת תקינות מותאמת אישית של האפליקציה נחשבת מוצלחת אם היא מחזירה קוד תגובה 200 OK.

בדיקות מצב פעילות (Liveness)

בדיקות מצב פעילות (liveness) מאשרות שהמכונה הווירטואלית והקונטיינר ב-Docker פועלים. מקרים שבהם המכונה נחשבת לא תקינה, המכונה מופעלת מחדש.

אתם יכולים להתאים אישית את הבקשות לבדיקת מצב פעילות (liveness) על ידי הוספת קטע אופציונלי liveness_check לקובץ app.yaml, למשל:

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

ההגדרות הבאות זמינות לבדיקות של מצב פעילות (liveness):

שדה	ברירת מחדל	טווח (מינימום-מקסימום)	תיאור
`path`	ללא		אם רוצים שהבדיקות של מצב פעילות (liveness) יועברו למאגר של האפליקציה, מציינים נתיב כתובת ה-URL, כמו `"/liveness_check"`
`timeout_sec`	‫4 שניות	1-300	מרווח הזמן הקצוב לתפוגה של כל בקשה, בשניות.
`check_interval_sec`	‫30 שניות	1-300	מרווח הזמן בין הבדיקות, בשניות. הערך הזה צריך להיות גדול מהערך של timeout_sec.
`failure_threshold`	‫4 בדיקות	1-10	מופע נחשב לא תקין אחרי שהוא נכשל במספר הזה של בדיקות רצופות.
`success_threshold`	2 בדיקות	1-10	מופע לא תקין הופך שוב לתקין אחרי שהוא מגיב בהצלחה למספר הזה של בדיקות רצופות.
`initial_delay_sec`	‫300 שניות	0-3600	העיכוב, בשניות, אחרי שהמופע מתחיל, שבמהלכו המערכת מתעלמת מתגובות לבדיקת תקינות. ההגדרה הזו חלה על כל מופע חדש שנוצר, ויכולה לאפשר למופע חדש יותר זמן להתחיל לפעול. ההגדרה הזו מעכבת את התיקון האוטומטי כדי למנוע בדיקה של המופע, ואולי יצירה מחדש שלו לפני הזמן אם המופע נמצא בתהליך של הפעלה. הטיימר של ההשהיה הראשונית מתחיל לפעול כשהמופע נמצא במצב RUNNING. לדוגמה, יכול להיות שתרצו להגדיל את העיכוב אם לאפליקציה שלכם יש משימות אתחול שלוקחות הרבה זמן לפני שהיא מוכנה להצגת תנועה.

בדיקות מוכנות

בדיקות מוכנות מאשרות שמופע יכול לקבל בקשות נכנסות. מופעים שלא עוברים את בדיקת המוכנות לא מתווספים למאגר המופעים הזמינים.

אפשר להתאים אישית את בקשות בדיקת תקינות על ידי הוספת קטע אופציונלי readiness_check לקובץ app.yaml, לדוגמה:

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

אלה ההגדרות שזמינות לבדיקות מוכנות:

שדה	ברירת מחדל	טווח (מינימום-מקסימום)	תיאור
`path`	ללא		אם רוצים שהבדיקות של מוכנות ישלחו לקונטיינר של האפליקציה, צריך לציין נתיב כתובת ה-URL, כמו `"/readiness_check"`
`timeout_sec`	‫4 שניות	1-300	מרווח הזמן הקצוב לתפוגה של כל בקשה, בשניות.
`check_interval_sec`	‫5 שניות	1-300	מרווח הזמן בין הבדיקות, בשניות. הערך הזה צריך להיות גדול מהערך של timeout_sec.
`failure_threshold`	2 בדיקות	1-10	מופע נחשב לא תקין אחרי שהוא נכשל במספר הזה של בדיקות רצופות.
`success_threshold`	2 בדיקות	1-10	מופע לא תקין הופך לתקין אחרי שהוא מגיב בהצלחה למספר הזה של בדיקות רצופות.
`app_start_timeout_sec`	‫300 שניות	1-1800	ההגדרה הזו חלה על פריסות חדשות, ולא על מכונות וירטואליות ספציפיות. המדיניות הזו קובעת את משך הזמן המקסימלי בשניות שמוקצה למספר מספיק של מופעים בפריסה כדי לעבור בדיקות תקינות. אם משך הזמן הזה חורג מהמגבלה, הפריסה נכשלת ומתבצעת החזרה למצב הקודם (rollback). הטיימר מתחיל כשמכונות ה-VM של Compute Engine מוקצות וכשנוצר שירות הקצה העורפי של מאזן העומסים. לדוגמה, יכול להיות שתרצו להגדיל את הזמן הקצוב לתפוגה אם אתם רוצים לספק זמני קצוב לתפוגה ארוכים יותר במהלך פריסות, כדי שמספר מספיק של מופעים יהיו תקינים.

תדירות בדיקת התקינות

כדי להבטיח זמינות גבוהה, App Engine יוצר עותקים מיותרים של כל בודק תקינות. אם בדיקת תקינות נכשלת, בדיקה מיותרת יכולה להשתלט ללא דיחוי.

אם בודקים את היומנים של nginx.health_check לגבי האפליקציה, יכול להיות שרואים בדיקות תקינות שמתבצעות בתדירות גבוהה יותר מזו שהוגדרה, כי בודקי התקינות העודפים פועלים גם הם לפי ההגדרות. הבודקים המיותרים האלה נוצרים באופן אוטומטי ואי אפשר להגדיר אותם.

הגדרות של שינוי גודל השירות

המפתחות שמשמשים לשליטה בהתאמת הגודל של שירות תלויים בסוג ההתאמה שאתם מקצים לשירות.

אפשר להשתמש בהתאמה אוטומטית או ידנית של קנה המידה. ברירת המחדל היא התאמה אוטומטית לעומס.

התאמה אוטומטית לעומס

כדי להגדיר התאמה אוטומטית לעומס, מוסיפים קטע automatic_scaling לקובץ app.yaml. לדוגמה:

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

בטבלה הבאה מפורטות ההגדרות שאפשר להשתמש בהן עם התאמה אוטומטית לעומס (automatic scaling):

שם	תיאור
`automatic_scaling`	כברירת מחדל, המערכת מניחה שמתבצעת התאמה אוטומטית לעומס (automatic scaling). כוללים את השורה הזו אם רוצים לציין הגדרות של התאמה אוטומטית לעומס (automatic scaling).
`min_num_instances`	מספר המופעים המינימלי שמוקצה לשירות. כשפורסים שירות, מקצים לו את מספר המופעים הזה והוא משתנה בהתאם לתנועת הנתונים. הערך חייב להיות `1` או יותר, ברירת המחדל היא `2` כדי להפחית את זמן האחזור. הערה: מספר המופעים הפעילים עשוי לרדת מתחת לערך הזה לפרק זמן קצר במהלך אירועים מסוימים. אם האפליקציה שלכם צריכה לפעול באופן רציף במספר מסוים של מופעים, כדאי לשקול הקצאת יתר.
`max_num_instances`	המספר המקסימלי של מופעים שהשירות יכול להתרחב אליהם. מספר המקרים המקסימלי בפרויקט מוגבל על ידי מכסת המשאבים של הפרויקט. ברירת המחדל היא `20`.
`cool_down_period_sec`	מספר השניות שהמידרוג האוטומטי צריך להמתין לפני שהוא מתחיל לאסוף מידע ממופע חדש. כך נמנע מהמידרוג האוטומטי לאסוף מידע בזמן שהמופע עובר אתחול, כי נתוני השימוש שנאספים במהלך האתחול לא מהימנים. תקופת ההמתנה חייבת להיות 60 שניות או יותר. ברירת המחדל היא `120`.
`cpu_utilization`	משתמשים בכותרת הזו אם רוצים לציין את יעד ניצול המעבד.
`target_utilization`	ניצול יעד של יחידת העיבוד המרכזית (CPU). השימוש במעבד מחושב כממוצע בכל המופעים הפועלים, ומשמש לקביעה מתי להקטין או להגדיל את מספר המופעים. שימו לב: המערכת מצמצמת את מספר המופעים 25 שניות אחרי שמופע מקבל את אות הכיבוי, ללא קשר לבקשות שנמצאות בתהליך. ברירת המחדל היא `0.5`.
`target_concurrent_requests`	‫(Beta) מספר היעד של חיבורים בו-זמניים לכל מכונה. אם מציינים ערך לפרמטר הזה, המידרוג האוטומטי משתמש במספר הממוצע של חיבורים בו-זמניים בכל המופעים הפועלים כדי להחליט מתי להקטין או להגדיל את מספר המופעים. מכונה מצטמצמת 25 שניות אחרי שהיא מקבלת את אות הכיבוי, ללא קשר לבקשות שנמצאות בתהליך. אם לא מציינים ערך לפרמטר הזה, המידרוג האוטומטי לא יכוון למספר חיבורים מקבילים לכל מכונה. יש הבדל בין חיבורים לבין בקשות. לקוח יכול להשתמש מחדש בחיבור כדי לשלוח כמה בקשות. הערה: בסביבה גמישה יש מגבלה של 4,096 חיבורי worker ב-Nginx לכל מכונה.

שינוי גודל ידני

כדי להגדיר שינוי גודל ידני, מוסיפים קטע manual_scaling לקובץ app.yaml. לדוגמה:

manual_scaling:
  instances: 5

בטבלה הבאה מפורטות ההגדרות שאפשר להשתמש בהן עם שינוי גודל ידני:

שם	תיאור
`manual_scaling`	נדרש כדי להפעיל שינוי גודל ידני של שירות.
`instances`	מספר המופעים להקצאה לשירות. הערה: מספר המופעים הפעילים עשוי לרדת מתחת לערך הזה לפרק זמן קצר במהלך אירועים מסוימים. אם האפליקציה שלכם צריכה לפעול באופן רציף במספר מסוים של מופעים, כדאי לשקול הקצאת יתר.

הגדרת משתני סביבה

אתם יכולים להגדיר משתני סביבה ב-app.yaml כדי שהם יהיו זמינים לאפליקציה שלכם, למשל:

env_variables:
  MY_VAR: "my value"

כאשר MY_VAR ו-my value הם השם והערך של משתנה הסביבה שרוצים להגדיר, וכל רשומה של משתנה סביבה מוזחת בשני רווחים מתחת לרכיב env_variables.

שימוש במשתני הסביבה

כדי לאחזר את משתנה הסביבה של זמן הריצה של Python, משתמשים ב-os.environ.

תוכלו לעיין גם ברשימה של משתני סביבה של זמן ריצה שלא ניתן להחליף. לדוגמה, כל משתני הסביבה שמתחילים בקידומת GAE שמורים לשימוש המערכת.