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

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

מטרת הסדרה הזו של מדריכים מעשיים ללימוד עצמי היא לעזור למפתחים ב-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, אבל זו לא הדרך היחידה לגשת ל-Datastore. כש-Datastore של App Engine הפך למוצר עצמאי ב-2013, Google Cloud Datastore, נוצרה ספריית לקוח חדשה כדי שכל המשתמשים יוכלו להשתמש ב-Datastore.

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

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

• הפיצ'ר מאפשר למפתחים להתמקד בבסיס קוד יחיד כדי לקבל גישה ל-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 שלכם או שלנו, הקוד של מודול 2 הוא המקום שבו נתחיל. ה-Codelab במודול 3 הזה ינחה אותך לאורך כל שלב, ובסיום התהליך הוא אמור להיות דומה לקוד בנקודת FINISH. המדריך הזה כולל Python 2 ו-3 גרסאות, וצריך להשתמש במאגר הקוד המתאים בהמשך.

Python 2

• התחלה: קוד מודול 2
• FINISH: קוד מודול 3
• כל המאגר (לשכפול או הורדה של קובץ ZIP)

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

$ 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 וגם 3 מותקנים, אנחנו ממליצים להשתמש ב-pip2 במקום ב-pip כדי למנוע בלבול עם Python 3.

Python 3

• START: מאגר מודול 2
• FINISH: מאגר מודול 3
• כל המאגר (לשכפול או הורדה של קובץ ZIP)

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

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

ב-Python 3 לא נעשה שימוש ב-lib וב-appengine_config.py.

3. (מחדש) פריסה של אפליקציית מודול 2

שאר השלבים לפני העבודה שצריך לבצע עכשיו:

1. כדאי להכיר מחדש את כלי שורת הפקודה gcloud (אם רלוונטי)
2. (אם צריך לפרוס מחדש את הקוד של מודול 1 ב-App Engine)

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

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:

• אחרי (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 בקובץ אחד של 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. גישה ל-Datastore

כדי לעבור ל-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 (dict Python) של צמדי מפתח/ערך, ואז כותבים אותה ב-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() כפי שלמעלה, והחתימות שלהם זהות לגרסה הקודמת. אין שינויים בכלל ב-handler הראשי root(). לאחר השלמת השינויים האלה, האפליקציה שלך מותאמת לשימוש ב-Cloud Datastore ומוכנה לבדיקה.

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

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

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

• ֶPython 2
• ֶPython 3

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

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

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

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

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

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

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

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

השלבים הבאים

לאחר מכן, תוכלו להתנסות במודולים הבאים להעברה:

• בונוס על יחידת לימוד 3: המשיכו לקטע הבונוס כדי ללמוד איך לנייד אל Python 3 ואל סביבת זמן הריצה של App Engine מהדור הבא.
• מודול 7: תורים של משימות דחיפה ב-App Engine (נדרש אם משתמשים ב[push] תורי משימות)
  • הוספת משימות דחיפה ל-App Engine taskqueue לאפליקציית מודול 1
  • הכנת המשתמשים למעבר אל Cloud Tasks במודול 8
• מודול 4: מעבר ל-Cloud Run באמצעות Docker
  • יצירת קונטיינרים לאפליקציה להרצה ב-Cloud Run באמצעות Docker
  • מאפשרת להמשיך להשתמש ב-Python 2
• מודול 5: מעבר ל-Cloud Run עם Cloud Buildpacks
  • יצירת קונטיינרים לאפליקציה כדי לרוץ ב-Cloud Run באמצעות Cloud Buildpacks
  • לא צריך לדעת שום דבר על Docker, קונטיינרים או Dockerfile
  • צריך להעביר כבר את האפליקציה ל-Python 3
• מודול 6: מעבר ל-Cloud Firestore
  • כדי לקבל גישה לתכונות של Firebase צריך לעבור ל-Cloud Firestore
  • אומנם 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 הוצאו משימוש. כל האפליקציות נחשבות ל-threadsafe ולא נעשה שימוש ב-api_version ב-Python 3. כבר אין חבילות מובנות של צד שלישי המותקנות מראש בשירותי App Engine, ולכן גם libraries הוצא משימוש. מידע נוסף על השינויים האלה זמין במסמכי התיעוד בנושא שינויים ב-app.yaml. לכן, צריך למחוק את כל השלושה מ-app.yaml ולעדכן לגרסת Python 3 נתמכת (ראו בהמשך).

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

בנוסף, הוצאה משימוש גם ההוראה handlers שמפנה את תעבורת הנתונים לאפליקציות של App Engine. הדור הבא של סביבת זמן הריצה, מצפה שמסגרות אינטרנט ינהלו את ניתוב האפליקציות, ולכן כל 'הסקריפטים של ה-handler' ל-"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. מקורות מידע נוספים

בעיות/משוב על Codelabs עם מודול ההעברה של App Engine

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

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

משאבים להעברה

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

Codelab	ֶPython 2	ֶPython 3
יחידת לימוד 2	קוד	קוד
יחידת לימוד 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
  • ספריות הלקוח של Google Cloud Python