Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

קובץ התצורה 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 שבה רוצים להשתמש. נדרש לגרסה 3.8 של Python ואילך. לא נתמך בגרסה 3.7 של Python ובגרסאות קודמות. אפשר לעיין בגרסאות הנתמכות של Ubuntu ובזמני הריצה בדף זמני ריצה של Python. ‫`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 מקצה סוג מכונה על סמך כמות המעבדים והזיכרון שהגדרתם. מובטח שלמכונה יהיו לפחות המשאבים שציינתם, ויכול להיות שיהיו לה יותר.

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

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

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

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

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

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