‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

קובץ התצורה 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 Google ולביצוע משימות. צריך לספק את חשבון השירות בפורמט הבא: 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, למשל כשמאחסנים נתוני משתמשים באופן מקומי במהלך סשן. זיקה לסשן (session affinity) מאפשרת לבדוק את הערך של קובץ Cookie כדי לזהות כמה בקשות מאותו משתמש, ואז להפנות את כל הבקשות האלה לאותו מופע. אם המופע מופעל מחדש, לא תקין, עמוס מדי או הופך ללא זמין כשמספר המופעים מצטמצם, תופסק הזיקה לסשן (session affinity) והבקשות הבאות ינותבו למופע אחר. שימו לב: הפעלת שיוך סשנים עשויה להשפיע על הגדרת איזון העומסים. הפרמטר הזה מושבת כברירת מחדל.
`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 מקצה סוג מכונה על סמך כמות ה-CPU והזיכרון שהגדרתם. מובטח שלמכונה יהיו לפחות המשאבים שציינתם, ויכול להיות שיהיו לה יותר.

בהגדרות המשאבים אפשר לציין עד שמונה נפחים של 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 GB עד ‎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`	חובה אם משתמשים בכרכים. שם הכרך. השמות צריכים להיות ייחודיים, באורך של 1 עד 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)

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

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

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

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

שדה	ברירת מחדל	טווח (מינימום-מקסימום)	תיאור
`path`	ללא		אם רוצים שהבדיקות של הפעילות יועברו למאגר של האפליקציה, מציינים נתיב של כתובת 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	העיכוב, בשניות, אחרי שהמופע מתחיל, שבמהלכו מתעלמים מתגובות של בדיקת תקינות. ההגדרה הזו חלה על כל מופע חדש שנוצר, ויכולה לאפשר למופע חדש יותר זמן להתחיל לפעול. ההגדרה הזו מעכבת את הבדיקה של תיקון תוכנה אוטומטי (autohealing), ואת האפשרות ליצור מחדש את המכונה לפני הזמן אם המכונה נמצאת בתהליך של הפעלה. הטיימר של ההשהיה הראשונית מתחיל כשהמופע נמצא במצב 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).
`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`	‫(בטא) מספר היעד של חיבורים בו-זמניים לכל מכונה. אם מציינים ערך לפרמטר הזה, המערכת להרחבת הקיבולת האוטומטית משתמשת במספר הממוצע של חיבורים בו-זמניים בכל המופעים הפועלים כדי להחליט מתי להקטין או להגדיל את מספר המופעים. מכונה מצטמצמת 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 שמורים לשימוש המערכת.