יצירת סביבות ריצה בהתאמה אישית

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

כדי ליצור סביבת ריצה בהתאמה אישית, צריך:

צריך להעלות קובץ app.yaml

קובץ התצורה app.yaml צריך לכלול לפחות את ההגדרות הבאות:

runtime: custom
env: flex

מידע נוסף על הגדרות אחרות שאפשר להגדיר לאפליקציה זמין במאמר בנושא הגדרת האפליקציה באמצעות app.yaml.

יצירת קובץ Dockerfile

באתר Docker יש תיעוד מקיף על יצירת קובצי Dockerfile. אם אתם משתמשים בסביבת ריצה בהתאמה אישית, אתם צריכים לספק קובץ Dockerfile, בין אם אתם מספקים תמונת בסיס משלכם או משתמשים באחת מתמונות הבסיס של Google.

ציון תמונת בסיס

הפקודה הראשונה בקובץ Dockerfile היא בדרך כלל פקודה FROM שמציינת תמונת בסיס. קובץ אימג' בסיסי משמש ליצירת הקונטיינר ולפיתוח האפליקציה. אתם יכולים ליצור תמונת בסיס משלכם או לבחור תמונת בסיס ממאגרי קונטיינרים כמו DockerHub.

איתור קובץ Dockerfile

בדרך כלל, שם קובץ ה-Dockerfile הוא תמיד Dockerfile והוא ממוקם באותה ספרייה כמו קובץ app.yaml התואם. עם זאת, במקרים מסוימים, יכול להיות שיהיו דרישות שונות בסביבת כלי הפיתוח. לדוגמה, כלים מבוססי Java של Cloud SDK, כמו הפלאגינים Maven,‏ Gradle,‏ Eclipse ו-IntelliJ, דורשים ש-Dockerfile יהיה ב-src/main/docker/Dockerfile ושהקובץ app.yaml יהיה ב-src/main/appengine/app.yaml. מידע נוסף זמין במאמרי העזרה של סביבת כלי הפיתוח שלכם.

מבנה הקוד

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

האזנה ליציאה 8080

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

טיפול באירועים במחזור החיים

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

כיבוי האפליקציה

כשצריך לכבות מכונה, בקשות חדשות שמגיעות מנותבות למכונות אחרות (אם יש כאלה), ולבקשות שנמצאות כרגע בעיבוד ניתן זמן להשלמה. כשמכבים מופע, הסביבה הגמישה בדרך כלל שולחת אות STOP (SIGTERM) למאגר האפליקציה. האפליקציה לא צריכה להגיב לאירוע הזה, אבל היא יכולה להשתמש בו כדי לבצע פעולות ניקוי נדרשות לפני שהקונטיינר נסגר. בתנאים רגילים, המערכת מחכה עד 30 שניות שהאפליקציה תיסגר ואז שולחת אות KILL (SIGKILL) וסוגרת מיד את המופע.

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

בקשות לבדיקת תקינות

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

יצירה ופריסה של סביבת ריצה בהתאמה אישית

אחרי שמגדירים את הקובץ app.yaml ואת הקובץ DOCKER, אפשר ליצור ולפרוס את קובץ אימג' של קונטיינר ב-App Engine.

לחלופין, אתם יכולים לפרוס קובצי אימג' בקונטיינר של סביבות זמן ריצה מותאמות אישית שכבר נוצרו מראש ואוחסנו ב-Artifact Registry. לדוגמה, אפשר להשתמש ב-Cloud Build כדי ליצור בנפרד את קובצי האימג' ולאחסן אותם ב-Artifact Registry. מידע נוסף זמין במאמר בנושא העלאה והורדה של תמונות.

שילוב האפליקציה עם Google Cloud

אפליקציות שפועלות בסביבות ריצה בהתאמה אישית יכולות להשתמש בספריות הלקוח של Google Cloud כדי לגשת לשירותים Google Cloud . אפליקציות בסביבות זמן ריצה מותאמות אישית יכולות להשתמש גם בכל שירות צד שלישי באמצעות ממשקי API רגילים.

אימות באמצעות Google Cloud שירותים

Application Default Credentials היא הדרך הכי פשוטה לעבור אימות מול Google APIs ולשלוח קריאות לאותם ממשקי API.

אם האפליקציה שלכם משתמשת ב-Cloud Build כדי לקמפל תמונות Docker, המארחים ברשת cloudbuild מארחים את Application Default Credentials (פרטי כניסה שמוגדרים כברירת מחדל לאפליקציה), וכך השירותים המשויכים Google Cloud יכולים למצוא את פרטי הכניסה שלכם באופן אוטומטי.

למידע נוסף על אימות, ראו אימות ב-Google.

רישום ביומן

כשבקשה נשלחת לאפליקציה שפועלת ב-App Engine, פרטי הבקשה והתגובה נרשמים ביומן באופן אוטומטי. אפשר לראות אותם ב Google Cloud מסוף Logs Explorer.

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

אפשר גם לכתוב יומנים בהתאמה אישית ל-/var/log/app_engine/custom_logs באמצעות קובץ שמסתיים ב-.log או ב-.json.

אם כוללים סוכנים של צד שלישי במאגר האפליקציות, צריך לוודא שהסוכנים מוגדרים לרישום ביומן ב-stdout וב-stderr, או ביומן מותאם אישית. כך אפשר לוודא שכל השגיאות שנוצרות על ידי הסוכנים האלה יהיו גלויות ב-Cloud Logging.

יומני הבקשות והאפליקציות של האפליקציה נאספים על ידי סוכן של Cloud Logging ונשמרים למשך 90 ימים לכל היותר, עד לגודל מקסימלי של 1GB. אם רוצים לאחסן את היומנים לתקופה ארוכה יותר או לאחסן נפח גדול יותר מ-1GB, אפשר לייצא את היומנים ל-Cloud Storage. אפשר גם לייצא את היומנים ל-BigQuery ול-Pub/Sub כדי להמשיך לעבד אותם.

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

שם יומן הביקורת סוג המטען הייעודי (Payload) מטרה
crash.log טקסט מידע שנרשם ביומן כשההגדרה נכשלת. אם האפליקציה לא פועלת, כדאי לבדוק את היומן הזה.
monitoring.* טקסט מידע מקונטיינר Docker שמפרסם נתונים ב-Cloud Monitoring.
shutdown.log טקסט המידע שנרשם ביומן בזמן כיבוי המחשב.
stdout טקסט פלט רגיל מהאפליקציה.
stderr טקסט שגיאה רגילה מהמאגר.
syslog טקסט יומן syslog של מכונה וירטואלית, מחוץ למאגר Docker.