יחידת לימוד 3: מעבר מ-Google Cloud NDB ל-Cloud Datastore

1. סקירה כללית

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

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

מה תלמדו

• שימוש ב-Cloud NDB (אם אתם לא מכירים אותו)
• העברה מ-Cloud NDB ל-Cloud Datastore
• העברה נוספת של האפליקציה ל-Python 3

מה תצטרכו

• פרויקט ב-Google Cloud Platform עם חשבון חיוב פעיל ב-GCP
• מיומנויות בסיסיות ב-Python
• ידע מעשי בפקודות בסיסיות של Linux
• ידע בסיסי בפיתוח ובפריסה של אפליקציות App Engine
• אפליקציית App Engine 2.x או 3.x תקינה של מודול 2.

סקר

איך תשתמשו ב-Codelab הזה?

רק קוראים את הטקסט קוראים את הטקסט ומבצעים את התרגילים

2. רקע

‫Cloud NDB הוא פתרון מצוין ל-Datastore למפתחי App Engine ותיקים, והוא עוזר להם לעבור ל-Python 3. עם זאת, זו לא הדרך היחידה שבה מפתחי App Engine יכולים לגשת ל-Datastore. כש-Datastore של App Engine הפך למוצר עצמאי בשנת 2013, נוצרה ספריית לקוח חדשה, Google Cloud Datastore, כדי שכל המשתמשים יוכלו להשתמש ב-Datastore.

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

העברה מ-Cloud NDB ל-Cloud Datastore

• מאפשר למפתחים להתמקד ב-codebase יחיד לגישה ל-Datastore
• אין צורך לתחזק קוד מסוים באמצעות Cloud NDB וקוד אחר באמצעות Cloud Datastore
• הכלי מספק עקביות רבה יותר ב-codebase ושימוש חוזר טוב יותר בקוד
• מאפשר שימוש בספריות משותפות, שמסייעות להפחתת עלויות התחזוקה הכוללות

הערה:‏ Cloud NDB נועד לגשר בין סביבות זמן ריצה מקוריות וסביבות זמן ריצה מהדור הבא של App Engine, וגם לעזור למשתמשי Python 2 לעבור ל-Python 3. אם אתם לא משתמשים ב-Cloud Datastore, לא מתכוונים להשתמש בו ואין לכם אפליקציות אחרות שמשתמשות בו, אתם יכולים לדלג על המדריך הזה ולהמשיך להשתמש ב-Cloud NDB.

ההעברה הזו כוללת את השלבים העיקריים הבאים:

1. הגדרה/עבודה מקדימה
2. החלפת Cloud NDB בספריות לקוח של Cloud Datastore
3. עדכון האפליקציה

3. הגדרה/עבודה מקדימה

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

1. הגדרת פרויקט

אם השלמתם את ה-Codelab של מודול 2, מומלץ להשתמש מחדש באותו פרויקט (ובאותו קוד). אפשר גם ליצור פרויקט חדש לגמרי או להשתמש בפרויקט קיים אחר. מוודאים שלפרויקט יש חשבון פעיל לחיוב ושהשירות App Engine (אפליקציה) מופעל.

2. קבלת אפליקציה לדוגמה של ערך בסיס

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

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

Python 2

• התחלה: קוד מודול 2
• סיום: קוד מודול 3
• כל המאגר (לשיבוט או להורדה של קובץ ZIP)

הספרייה של קובצי ההתחלה של מודול 2 של Python 2 (שלכם או שלנו) צריכה להיראות כך:

$ ls
README.md               appengine_config.py     requirements.txt
app.yaml                main.py                 templates

אם השלמתם את הדרכה בנושא מודול 2, תהיה לכם גם תיקייה בשם lib עם Flask והתלות שלה. אם אין לכם תיקייה בשם lib, צריך ליצור אותה באמצעות הפקודה pip install -t lib -r requirements.txt כדי שנוכל לפרוס את אפליקציית הבסיס הזו בשלב הבא. אם מותקנות אצלכם גם Python 2 וגם Python 3, מומלץ להשתמש ב-pip2 במקום ב-pip כדי למנוע בלבול עם Python 3.

Python 3

• התחלה: מאגר Module 2
• סיום: מאגר Module 3
• כל המאגר (לשיבוט או להורדה של קובץ ZIP)

הספרייה של קובצי ההתחלה של מודול 2 של Python 3 (שלכם או שלנו) צריכה להיראות כך:

$ ls
README.md               main.py                 templates
app.yaml                requirements.txt

אי אפשר להשתמש ב-lib או ב-appengine_config.py ב-Python 3.

3. (Re)Deploy Module 2 app

השלבים הנותרים שצריך לבצע עכשיו:

1. כדאי לעיין שוב בכלי gcloud של שורת הפקודה (אם צריך).
2. (Re)deploy the Module 1 code to App Engine (if nec.)

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

4. החלפת Cloud NDB בספריות לקוח של Cloud Datastore

השינוי היחיד בהגדרות הוא החלפה קלה של חבילה בקובץ requirements.txt.

1. עדכון של requirements.txt

אחרי שמסיימים את מודול 2, קובץ requirements.txt נראה כך:

• לפני (Python 2 ו-3):

Flask==1.1.2
google-cloud-ndb==1.7.1

מעדכנים את requirements.txt על ידי החלפת ספריית Cloud NDB ‏ (google-cloud-ndb) בגרסה העדכנית של ספריית Cloud Datastore ‏ (google-cloud-datastore), בלי לשנות את הערך של Flask. חשוב לזכור שהגרסה האחרונה של Cloud Datastore שתואמת ל-Python 2 היא 1.15.3:

• ‫AFTER (Python 2):

Flask==1.1.2
google-cloud-datastore==1.15.3

• אחרי (Python 3):

Flask==1.1.2
google-cloud-datastore==2.1.0

חשוב לזכור שהמאגר מתעדכן באופן קבוע יותר מאשר המדריך הזה, ולכן יכול להיות שהקובץ requirements.txt ישקף גרסאות חדשות יותר. מומלץ להשתמש בגרסאות העדכניות של כל ספרייה, אבל אם הן לא פועלות, אפשר לחזור לגרסה קודמת. מספרי הגרסאות שמופיעים למעלה הם העדכניים ביותר בזמן העדכון האחרון של ה-codelab הזה.

הערה למשתמשי Python 2: אם יש לכם תיקייה בשם lib ולא יצרתם אותה עכשיו, מחקו אותה. עכשיו (מחדש) מתקינים את הספריות המעודכנות באמצעות הפקודה pip install -t lib -r requirements.txt, ומשתמשים ב-pip2 במקום ב-pip לפי הצורך.

פתרון בעיות ב-Python 2: אם מופיעה השגיאה ImportError: cannot import name collections_abc באפליקציה, צריך לוודא שתלות Cloud NDB‏, google-cloud-core, היא לפחות בגרסה 1.4.4 ב-lib. בעיית הליבה שגורמת לשגיאה הזו קיימת רק בגרסאות 1.4.2 ו-1.4.3. (עבר זמן רב מאז הפרסומים האלה, לכן האזהרה הזו תוסר בגרסאות עתידיות של המדריך הזה).

2. קבצים אחרים של הגדרות

קבצי ההגדרות האחרים, app.yaml ו-appengine_config.py, צריכים להישאר ללא שינוי מהשלב הקודם של ההעברה:

• האפליקציה app.yaml צריכה (עדיין) להתייחס לחבילות הצד השלישי grpcio וsetuptools.
• הערכים של appengine_config.py ושל pkg_resources (עדיין) צריכים להפנות google.appengine.ext.vendor למקורות של צד שלישי ב-lib.

עכשיו נעבור לקבצי האפליקציה.

5. עדכון קובצי אפליקציות

אין שינויים ב-template/index.html, אבל יש כמה עדכונים ב-main.py.

1. יבוא

הקוד ההתחלתי של קטע הייבוא צריך להיראות כך:

• לפני:

from flask import Flask, render_template, request
from google.cloud import ndb

מחליפים את השורה google.cloud.ndb import בשורה של Cloud Datastore: google.cloud.datastore. ספריית הלקוח של Datastore לא תומכת ביצירה אוטומטית של שדה חותמת זמן בישות, ולכן צריך גם לייבא את מודול הספרייה הרגיל datetime כדי ליצור אותו באופן ידני. לפי המוסכמה, ייבוא של ספריות רגילות מופיע מעל ייבוא של חבילות צד שלישי. אחרי שמסיימים לבצע את השינויים האלה, זה אמור להיראות כך:

• אחרי:

from datetime import datetime
from flask import Flask, render_template, request
from google.cloud import datastore

2. אתחול ומודל נתונים

אחרי שמפעילים את Flask, אפליקציית הדוגמה של מודול 2 שיוצרת מחלקת מודל נתונים של NDB והשדות שלה נראית כך:

• לפני:

app = Flask(__name__)
ds_client = ndb.Client()

class Visit(ndb.Model):
    visitor   = ndb.StringProperty()
    timestamp = ndb.DateTimeProperty(auto_now_add=True)

בספריית Cloud Datastore אין מחלקה כזו, לכן צריך למחוק את ההצהרה על המחלקה Visit. עדיין צריך לקוח כדי לתקשר עם Datastore, לכן צריך לשנות את ndb.Client() ל-datastore.Client(). הספרייה Datastore היא יותר "גמישה", ומאפשרת לכם ליצור ישויות בלי "להצהיר מראש" על המבנה שלהן כמו ב-NDB. אחרי העדכון הזה, החלק הזה של main.py אמור להיראות כך:

• אחרי:

app = Flask(__name__)
ds_client = datastore.Client()

3. גישה למאגר הנתונים

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

• לפני:

def store_visit(remote_addr, user_agent):
    with ds_client.context():
        Visit(visitor='{}: {}'.format(remote_addr, user_agent)).put()

def fetch_visits(limit):
    with ds_client.context():
        return (v.to_dict() for v in Visit.query().order(
                -Visit.timestamp).fetch_page(limit)[0])

בעזרת Cloud Datastore, יוצרים ישות כללית ומזהים אובייקטים מקובצים בישות באמצעות 'מפתח'. יוצרים את רשומת הנתונים עם אובייקט JSON (Python dict) של צמדי מפתח-ערך, ואז כותבים אותה ל-Datastore עם put() הצפוי. השאילתות דומות אבל פשוטות יותר ב-Datastore. כאן אפשר לראות את ההבדלים בקוד המקביל של Datastore:

• אחרי:

def store_visit(remote_addr, user_agent):
    entity = datastore.Entity(key=ds_client.key('Visit'))
    entity.update({
        'timestamp': datetime.now(),
        'visitor': '{}: {}'.format(remote_addr, user_agent),
    })
    ds_client.put(entity)

def fetch_visits(limit):
    query = ds_client.query(kind='Visit')
    query.order = ['-timestamp']
    return query.fetch(limit=limit)

מעדכנים את גופי הפונקציות של store_visit() ושל fetch_visits() כמו שמופיע למעלה, ומוודאים שהחתימות שלהן זהות לגרסה הקודמת. לא חלים שינויים בכלל במטפל הראשי root(). אחרי שתבצעו את השינויים האלה, האפליקציה תהיה מוכנה לשימוש ב-Cloud Datastore ולבדיקה.

6. סיכום/ניקוי

פריסת אפליקציה

מבצעים פריסה מחדש של האפליקציה באמצעות gcloud app deploy ומאשרים שהאפליקציה פועלת. הקוד שלכם צריך להיות זהה למה שמופיע בתיקיות של מאגר מודול 3:

• ‫Python 2
• ‫Python 3

אם התחלתם את סדרת המאמרים הזו בלי לבצע את כל המעבדות הקודמות, האפליקציה עצמה לא משתנה. היא רושמת את כל הביקורים בדף האינטרנט הראשי (/) ונראית כך אחרי שביקרתם באתר מספיק פעמים:

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

אופציונלי: ניקוי

מה לגבי ניקוי כדי להימנע מחיוב עד שתהיו מוכנים לעבור אל סדנת ה-codelab הבאה בנושא העברה? אם אתם מפתחים קיימים, סביר להניח שכבר קראתם את פרטי התמחור של App Engine.

חשוב: בסביבות זמן הריצה המקוריות של App Engine לא נדרש חשבון חיוב פעיל, אבל זה כבר לא המצב (החל מנובמבר 2019, נאכף החל מאפריל 2020). עם זאת, אפשר להיות רגועים כי ל-App Engine עדיין יש רמת גישה ללא תשלום, שבה לא תחויבו אלא אם תחרגו מהמגבלות האלה.

אופציונלי: השבתת האפליקציה

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

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

השלבים הבאים

מכאן אפשר לעבור למודולים הבאים בנושא העברה:

• בונוס למודול 3: ממשיכים לקטע הבונוס כדי ללמוד איך לבצע המרה ל-Python 3 ולזמן הריצה של הדור הבא של App Engine.
• ‫Module 7: App Engine Push Task Queues (required if you use [push] Task Queues)
  • הוספת משימות push של App Engine לאפליקציה Module 1taskqueue
  • הכנת המשתמשים להעברה אל Cloud Tasks במודול 8
• מודול 4: מעבר ל-Cloud Run באמצעות Docker
  • העברת האפליקציה לקונטיינר להפעלה ב-Cloud Run באמצעות Docker
  • מאפשרת לכם להמשיך להשתמש ב-Python 2
• ‫מודול 5: מעבר ל-Cloud Run באמצעות Cloud Buildpacks
  • יצירת קונטיינר לאפליקציה כדי להפעיל אותה ב-Cloud Run באמצעות Cloud Buildpacks
  • לא צריך לדעת כלום על Docker, על קונטיינרים או על Dockerfiles
  • נדרש שכבר העברתם את האפליקציה ל-Python 3
• ‫מודול 6: מעבר ל-Cloud Firestore
  • מעבר ל-Cloud Firestore כדי לגשת לתכונות של Firebase
  • ‫Cloud Firestore תומך ב-Python 2, אבל ה-codelab הזה זמין רק ב-Python 3.

7. בונוס: מעבר ל-Python 3

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

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

סקירה כללית

העברה ל-Python 3 לא נכללת בהיקף של הדרכה ב-Google Cloud, אבל החלק הזה של ה-codelab נותן למפתחים מושג לגבי ההבדלים בין זמן הריצה של Python 3 App Engine. אחת התכונות הבולטות של סביבת זמן הריצה מהדור הבא היא גישה פשוטה לחבילות של צד שלישי: אין צורך לציין חבילות מובנות ב-app.yaml ואין צורך להעתיק או להעלות ספריות לא מובנות. הן מותקנות באופן מרומז מתוך הרשימה ב-requirements.txt.

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

1. פשוט משתמשים ב-app.yaml כדי להפנות אל Python 3 ומסירים את ההפניה לספריות צד שלישי שצורפו.
2. מוחקים את appengine_config.py ואת התיקייה lib כי הם כבר לא נחוצים.

קבצי האפליקציה main.py ו-templates/index.html לא משתנים.

עדכון של requirements.txt

הגרסה האחרונה של Cloud Datastore שתומכת ב-Python 2 היא 1.15.3. מעדכנים את requirements.txt לגרסה האחרונה של Python 3 (יכול להיות שיש גרסה חדשה יותר עכשיו). בזמן כתיבת המדריך הזה, הגרסה האחרונה הייתה 2.1.0, לכן צריך לערוך את השורה כך שתיראה כמו השורה הבאה (או כמו הגרסה העדכנית):

google-cloud-datastore==2.1.0

פישוט app.yaml

לפני:

השינוי האמיתי היחיד באפליקציה לדוגמה הזו הוא קיצור משמעותי של app.yaml. תזכורת: אלה הנתונים שהיו לנו ב-app.yaml בסיום מודול 3:

runtime: python27
threadsafe: yes
api_version: 1

handlers:
- url: /.*
  script: main.app

libraries:
- name: grpcio
  version: 1.0.0
- name: setuptools
  version: 36.6.0

אחרי:

ב-Python 3, כל ההנחיות threadsafe, api_version ו-libraries הוצאו משימוש. כל האפליקציות נחשבות בטוחות לשימוש עם שרשורים, וההנחיה api_version לא נמצאת בשימוש ב-Python 3. חבילות צד שלישי מובנות כבר לא מותקנות מראש בשירותי App Engine, ולכן גם libraries הוצא משימוש. מידע נוסף על השינויים האלה זמין במאמר בנושא שינויים ב-app.yaml. לכן, צריך למחוק את שלושתם מ-app.yaml ולעדכן לגרסה נתמכת של Python 3 (ראו בהמשך).

אופציונלי: שימוש בהנחיית handlers

בנוסף, הוצאנו משימוש את ההנחיה handlers, שמפנה תנועה לאפליקציות ב-App Engine. מכיוון שסביבת זמן הריצה מהדור הבא מצפה ממסגרות אינטרנט לנהל את הניתוב של האפליקציה, צריך לשנות את כל ה-handler scripts ל-auto. אחרי שמשלבים את השינויים שלמעלה, מקבלים את app.yaml:

runtime: python38

handlers:
- url: /.*
  script: auto

מידע נוסף על script: auto זמין app.yamlבדף העזר.

הסרת ההוראה handlers

מאחר שהתג handlers הוצא משימוש, אפשר גם להסיר את כל הקטע ולהשאיר רק את התג app.yaml בשורה אחת:

runtime: python38

כברירת מחדל, יופעל שרת האינטרנט Gunicorn WSGI שזמין לכל האפליקציות. אם אתם מכירים את gunicorn, זו הפקודה שמופעלת כשהיא מופעלת כברירת מחדל עם app.yaml:

gunicorn main:app --workers 2 -c /config/gunicorn.py

אופציונלי: שימוש בהנחיית entrypoint

עם זאת, אם האפליקציה שלכם דורשת פקודת הפעלה ספציפית, אפשר לציין אותה באמצעות הוראה entrypoint, וכך ליצור קובץ app.yaml שנראה כך:

runtime: python38
entrypoint: python main.py

בדוגמה הזו יש בקשה ספציפית להשתמש בשרת הפיתוח של Flask במקום ב-gunicorn. צריך גם להוסיף לאפליקציה קוד שמפעיל את שרת הפיתוח כדי להפעיל אותה בממשק 0.0.0.0 ביציאה 8080. לשם כך, מוסיפים את הקטע הקטן הזה לתחתית של main.py:

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=8080, debug=True)

מידע נוסף על entrypoint זמין app.yamlבדף העזר. דוגמאות נוספות ושיטות מומלצות מופיעות במסמכי ההפעלה של הסביבה הרגילה של App Engine וגם במסמכי ההפעלה של הסביבה הגמישה של App Engine.

מחיקה של appengine_config.py ושל lib

מוחקים את הקובץ appengine_config.py ואת התיקייה lib. במהלך המעבר ל-Python 3, ‏ App Engine מאחזר ומתקין חבילות שמופיעות בקובץ requirements.txt.

קובץ התצורה appengine_config.py משמש לזיהוי ספריות או חבילות של צד שלישי, בין אם העתקתם אותן בעצמכם או השתמשתם בספריות או בחבילות שכבר זמינות בשרתי App Engine (מובנות). כשעוברים ל-Python 3, סיכום השינויים העיקריים הוא:

1. לא מתבצעת חבילה של ספריות צד שלישי שהועתקו (רשימה ב-requirements.txt)
2. אין pip install בתיקייה lib, כלומר אין תיקייה lib בכלל
3. אין ספריות מובנות של צד שלישי ב-app.yaml
4. אין צורך להפנות את האפליקציה לספריות של צד שלישי, ולכן אין קובץ appengine_config.py

כל מה שצריך לעשות הוא לפרט את כל הספריות הנדרשות של צד שלישי ב-requirements.txt.

פריסת אפליקציה

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

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

הכנת הבקשה שלך

כשמגיע הזמן להעביר את האפליקציה שלכם, תצטרכו להעביר את main.py ואת שאר קובצי האפליקציה לגרסה 3.x. לכן מומלץ מאוד לנסות להפוך את האפליקציה בגרסה 2.x ל "תואמת קדימה" ככל האפשר.

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

1. מוודאים שכל התלות של האפליקציה תואמת באופן מלא לגרסה 3.x
2. מוודאים שהאפליקציה פועלת בגרסה 2.6 לפחות (רצוי 2.7)
3. מוודאים שהאפליקציה עוברת את כל חבילת הבדיקות (וכיסוי של 80% לפחות)
4. שימוש בספריות תאימות כמו six,‏ Future ו/או Modernize
5. מידע על ההבדלים העיקריים בין גרסה 2.x לגרסה 3.x שלא תואמות לאחור
6. כל קלט/פלט (I/O) כנראה יוביל לחוסר תאימות בין Unicode לבין מחרוזת בייטים

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

8. מקורות מידע נוספים

App Engine migration module codelabs issues/feedback

אם נתקלתם בבעיות ב-codelab הזה, כדאי לחפש את הבעיה לפני ששולחים דיווח. קישורים לחיפוש וליצירה של בעיות חדשות:

• חיפוש בעיות
• דיווח על בעיה חדשה או משוב

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

בטבלה שלמטה מופיעים קישורים לתיקיות המאגר של מודול 2 (התחלה) ומודול 3 (סיום). אפשר גם לגשת אליהם ממאגר המידע של כל ההעברות של App Engine, שאפשר לשכפל או להוריד כקובץ ZIP.

Codelab	‫Python 2	‫Python 3
מודול 2	קוד	קוד
Module 3	קוד	קוד

משאבי App Engine

למטה מופיעים מקורות מידע נוספים לגבי ההעברה הספציפית הזו:

• מסמכי עזר של Python Cloud NDB ו-Cloud Datastore
  • מסמכי התיעוד של ספריית הלקוחות של Google Cloud NDB
  • מאגר של ספריית הלקוח Google Cloud NDB
  • מסמכי עזרה של ספריית הלקוחות של Google Cloud Datastore
  • מאגר ספריות לקוח של Google Cloud Datastore
• מעבר ל-Python 3 ולסביבת זמן ריצה מהדור הבא של GAE
  • אופציונלי: רכיבי handler של סקריפטים
  • הפניה entrypoint
  • דוגמאות ושיטות מומלצותapp.yaml
  • דוגמאות נוספות ושיטות מומלצות
  • העברת קובצי תצורה של App Engine
  • דף הבית של מרכז ההעברה
• כללי
  • ‫Python ב-Google Cloud Platform
  • ספריות לקוח Python של Google Cloud