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

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

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

העלאת קובץ app.yaml

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

runtime: custom
env: flex

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

יצירת קובץ Dockerfile

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

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

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

איתור קובץ Dockerfile

בדרך כלל, שם קובץ ה-Dockerfile הוא תמיד Dockerfile והוא ממוקם באותה תיקייה כמו קובץ app.yaml התואם. עם זאת, במקרים מסוימים, יכול להיות שיהיו דרישות שונות בסביבת כלי הפיתוח. לדוגמה, כלים מבוססי Cloud SDK ב-Java, כמו הפלאגינים 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 ולבצע קריאות ל-Google APIs.

אם האפליקציה שלכם משתמשת ב-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.