מעבר מ-Python 2.7 ל-Python 3 Runtime העדכני

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

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

המעבר ל-Python 3 runtime מאפשר לכם להשתמש בתכונות שפה עדכניות ולבנות אפליקציות ניידות יותר עם קוד אידיומטי. ‫Python 3 runtime משתמש בגרסה העדכנית ביותר של רכיב התרגום של Python בקוד פתוח, שמסופקת על ידי Python Software Foundation. אפליקציות שנוצרו בסביבת זמן הריצה של Python 3 יכולות להשתמש במערכת האקולוגית העשירה של חבילות ומסגרות של Python באפליקציה, כולל אלה שמשתמשות בקוד C, על ידי הצהרה על תלות בקובץ requirements.txt.

סקירה כללית של תהליך ההעברה של סביבת זמן הריצה

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

1. משדרגים את האפליקציה כדי שתהיה תואמת ל-Python 3.

   יש כמה פתרונות שיעזרו לכם לבצע את השדרוג. לדוגמה, אפשר להשתמש ב-Six,‏ Python-Future או Python-Modernize.

   מידע נוסף על השלב הזה בתהליך העברת נתוני זמן הריצה זמין במאמר העברת קוד Python 2 ל-Python 3 באתר התיעוד של Python Software Foundation.

2. בוחרים אחת משיטות ההטמעה האלה לכל שירות בחבילה של App Engine שהאפליקציה משתמשת בו:

   1. מעבירים את השירותים מהדור הקודם שכלולים באפליקציית Python 2 לשירותים Google Cloud לא כלולים, לשירותים של צד שלישי או לחלופות מומלצות אחרות.

   2. להמשיך להשתמש בשירותים מדור קודם שצורפו לאפליקציות Python 3. הגישה הזו מאפשרת לכם לעבור לשירותים לא מצורפים בשלב מאוחר יותר בתהליך ההעברה.

      הערה: לא לכל השירותים הקודמים שכלולים בחבילה שזמינים ל-Python 2 יש שירות מקביל ב-Python 3, ולכן צריך להעביר אותם לשירות Google Cloud או לשירות של צד שלישי לפני ההעברה ל-Python 3.

   חשוב לבדוק את האפליקציה אחרי העברת כל שירות.

3. הכנת קובצי ההגדרות של App Engine לסביבת זמן הריצה של Python 3. כמה שינויים חשובים משפיעים על הגדרות התצורה בקובץ app.yaml, כולל:

   • אם אתם משתמשים בשירותים מדור קודם שכלולים בחבילה באפליקציות Python 3, מוסיפים את ההגדרה app_engine_bundled_services לקובץ app.yaml כדי להפעיל גישה לשירותים ספציפיים שכלולים בחבילה.
   • ההנחה היא עכשיו שהאפליקציות בטוחות לשימוש בריבוי תהליכים. אם האפליקציה שלכם לא בטוחה לשימוש בריבוי תהליכים, צריך להגדיר את max_concurrent_requests ב-app.yaml לערך 1. ההגדרה הזו עלולה לגרום ליצירה של יותר מופעים ממה שצריך לאפליקציה בטוחה לשימוש בריבוי תהליכים, ולעלות מיותרת.

   • קובץ app.yaml כבר לא מעביר בקשות לסקריפטים שלכם. במקום זאת, אתם צריכים להשתמש במסגרת אינטרנט עם ניתוב בתוך האפליקציה, ולעדכן או להסיר את כל רכיבי ה-handler של script ב-app.yaml. דוגמה לאופן הביצוע של הפעולה הזו באמצעות מסגרת Flask מופיעה בדוגמת הקוד במדריך להעברה של App Engine ב-GitHub.

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

4. בזמני הריצה מהדור השני, יומני האפליקציה כבר לא מוטמעים ביומני הבקשות. כדי להציג את התצוגה המקוננת של בקשות ויומני אפליקציות ב-Logs Explorer, צריך לבצע שלבים נוספים. מידע נוסף מופיע במאמר בנושא מעבר ל-Cloud Logging.

5. בודקים ומפעילים את האפליקציה המשודרגת בסביבת Python 3.

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

דוגמאות להמרת אפליקציות Python 2 ל-Python 3 מופיעות במקורות המידע הנוספים האלה.

ההבדלים העיקריים בין סביבות זמן הריצה של Python 2 ו-Python 3

רוב השינויים שצריך לבצע במהלך ההעברה בזמן הריצה נובעים מההבדלים הבאים בין סביבות זמן הריצה של Python 2 ו-Python 3:

• הבדלים בשימוש בזיכרון
• ההבדלים בשימוש ב-CPU
• הבדלים בכותרות הבקשה
• ההבדלים בין תהליכי העבודה של Gunicorn
• בעיות תאימות בין Python 2 ל-Python 3
• שירותים בחבילה של App Engine בסביבת זמן הריצה של Python 3
• הבדלים בין קובצי תצורה
• נדרשת מסגרת אינטרנט כדי להפנות בקשות לתוכן דינמי
• אפליקציות עם תוכן סטטי בלבד
• הבדלים בבדיקות
• הבדלים בפריסה

הבדלים בשימוש בזיכרון

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

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

הבדלים בשימוש במעבד

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

הבדלים בכותרות הבקשה

סביבות זמן ריצה מהדור הראשון מאפשרות להעביר לאפליקציה כותרות של בקשות עם קווים תחתונים (למשל X-Test-Foo_bar). בסביבות זמן ריצה מהדור השני,‏ Nginx מוצגת בארכיטקטורת המארח. כתוצאה מהשינוי הזה, סביבות זמן ריצה מהדור השני מוגדרות להסרה אוטומטית של כותרות עם קווים תחתונים (_). כדי למנוע בעיות באפליקציה, מומלץ להימנע משימוש בקווים תחתונים בכותרות של בקשות לאפליקציה.

הבדלים בין תהליכי עבודה של Gunicorn

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

בעיות תאימות בין Python 2 ל-Python 3

כש-Python 3 הושקה לראשונה בשנת 2008, נוספו לשפה כמה שינויים שלא תואמים לאחור. חלק מהשינויים האלה דורשים רק עדכונים קלים בקוד, כמו שינוי של הצהרת print לפונקציה print(). שינויים אחרים עשויים לדרוש עדכונים משמעותיים בקוד, כמו עדכון האופן שבו מטפלים בנתונים בינאריים, בטקסט ובמחרוזות.

גם הרבה ספריות פופולריות של קוד פתוח, כולל הספריות הרגילות של Python, השתנו כשעברו מ-Python 2 ל-Python 3.

שירותים בחבילה של App Engine בסביבת זמן הריצה של Python 3

כדי לצמצם את המאמץ והמורכבות של ההעברה, סביבת App Engine standard מאפשרת לכם לגשת להרבה ממשקי API ולשירותים מדור קודם שצורפו לזמן הריצה של Python 3, כמו Memcache. אפליקציית Python 3 יכולה להפעיל את ממשקי ה-API של השירותים שכלולים בחבילה באמצעות ספריות אידיומטיות של השפה, ולקבל גישה לאותה פונקציונליות כמו בסביבת זמן הריצה של Python 2.

הערה: רשימה מלאה של ממשקי API של שירותים מקובצים מדור קודם שזמינים ל-Python 3 מופיעה במאמר ממשקי API זמינים של שירותים מקובצים מדור קודם.

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

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

קובצי תצורה

לפני שמריצים את האפליקציה בסביבת זמן הריצה של Python 3 בסביבה הרגילה של App Engine, יכול להיות שתצטרכו לשנות חלק מקובצי ההגדרות שבהם נעשה שימוש ב-App Engine:

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

• ‫requirements.txt. יוצרים את הקובץ הזה כדי להתקין רכיבים תלויים של צד שלישי, כולל חבילות Python שדורשות תוספי C מקוריים. ‫App Engine מתקין באופן אוטומטי את התלויות האלה במהלך פריסת האפליקציה בסביבת זמן הריצה של Python 3. בעבר, כדי להתקין תלות בסביבת זמן הריצה של Python 2, היה צריך לפרט את הספריות שהועתקו או את הספריות שצורפו לקובץ הזה ואז להריץ פקודה של pip install -t lib -r requirements.txt.

• ‫appengine_config.py. הקובץ הזה לא נמצא בשימוש בסביבת זמן הריצה של Python 3, והמערכת מתעלמת ממנו אם הוא נפרס. בעבר, בסביבת זמן הריצה של Python 2, הקובץ הזה שימש להגדרת מודולי Python ולהפניית האפליקציה לספריות של צד שלישי שהועתקו או נארזו בעצמן.

נדרש פריימוורק לאינטרנט כדי לנתב בקשות לתוכן דינמי

בזמן הריצה של Python 2, אפשר ליצור מטפלים בכתובות URL בקובץ app.yaml כדי לציין איזו אפליקציה להפעיל כשמתקבלת בקשה לכתובת URL ספציפית או לתבנית כתובת URL ספציפית.

בזמן הריצה של Python 3, האפליקציה צריכה להשתמש ב-framework לאינטרנט כמו Flask או Django כדי לנתב בקשות לתוכן דינמי, במקום להשתמש ב-handlers של כתובות URL בקובץ app.yaml. לגבי תוכן סטטי, אפשר להמשיך ליצור handlers של כתובות URL בקובץ app.yaml של האפליקציה.

אפליקציות עם תוכן סטטי בלבד

כשמארחים אפליקציית אינטרנט סטטית ב-App Engine, צריך לציין מטפלים בקובץ app.yaml כדי למפות כתובות URL לקבצים סטטיים.

ב-Python 2, אם בקשה לא תואמת לאף אחד מהמטפלים שצוינו בקובץ app.yaml, ‏ App Engine מחזיר קוד שגיאה 404.

ב-Python 3, אם בקשה לא תואמת לאף אחד מהמטפלים, App Engine מחפש קובץ main.py ומחזיר שגיאת 5xx אם לא נמצא קובץ main.py. מכיוון שאפליקציות App Engine עם תוכן סטטי בלבד לא דורשות קובץ main.py, רוב המשתמשים רואים את השגיאה הזו, בנוסף לשגיאות בהפעלת מופעים ביומני האפליקציה.

כדי לשמור על אותה התנהגות של החזרת שגיאה 404 כשאין התאמה לאף אחד מהמטפלים הסטטיים, וכדי להימנע משגיאות ביומנים, אפשר:

• מוסיפים handler סטטי catch-all שמפנה לספרייה ריקה בקובץ app.yaml
• הוספת אפליקציה דינמית פשוטה בקובץ main.py כדי להחזיר שגיאה 404

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

app.yaml

יוצרים ספרייה ריקה בספריית השורש של האפליקציה, כמו empty/. בקטע handler בקובץ app.yaml, יוצרים handler חדש בסוף הקובץ כדי לטפל בכל דפוסי כתובות ה-URL האחרים, ומציינים את הספרייה empty ברכיבים static_files ו-upload:

  handlers:
  - url:
    .
    .
    .
  - url: /(.*)$
    static_files: empty/\1
    upload: empty/.*$

main.py

יוצרים קובץ main.py ומוסיפים את הקוד הבא כדי להחזיר שגיאה 404:

  def app(env, start_response):
    start_response('404 Not Found', [('Content-Type','text/html')])
    return [b"Not Found"]

בדיקה

מומלץ להשתמש בגישת בדיקה שמתאימה ל-Python ולא תלויה ב-dev_appserver. לדוגמה, אפשר להשתמש ב-venv כדי ליצור סביבת Python 3 מקומית ומבודדת. אפשר להשתמש בכל מסגרת בדיקה סטנדרטית של Python כדי לכתוב את בדיקות היחידה, האינטגרציה והמערכת. אפשר גם להגדיר גרסאות פיתוח של השירותים או להשתמש באמולטורים המקומיים שזמינים למוצרים רבים של Google Cloud.

אפשר גם להשתמש בגרסת התצוגה המקדימה של dev_appserver שתומכת ב-Python 3. מידע נוסף על תכונת הבדיקה הזו זמין במאמר שימוש בשרת פיתוח מקומי.

פריסה

פריסות דרך appcfg.py לא נתמכות ב-Python 3. במקום זאת, משתמשים בgcloud שורת הפקודה כדי לפרוס את האפליקציה.

רישום ביומן

הרישום בזמן הריצה של Python 3 מתבצע לפי תקן הרישום ב-Cloud Logging. בזמן הריצה של Python 3, יומני האפליקציה כבר לא נכללים ביומני הבקשות, אלא מופרדים לרשומות שונות. מידע נוסף על קריאה וכתיבה של יומנים בסביבת זמן הריצה של Python 3 זמין במדריך לרישום ביומן.

מקורות מידע נוספים על העברת נתונים

מידע נוסף על העברת אפליקציות App Engine לשירותי Cloud עצמאיים או לסביבת זמן ריצה של Python 3 זמין במקורות המידע הבאים של App Engine:

• סרטונים ו-Codelabs בנושא העברת אפליקציות בלי שרת (serverless)
• דוגמאות להעברת אפליקציות מ-Python 2 ל-Python 3 שנוצרו על ידי הקהילה