יחידת לימוד 2: מעבר מ-App Engine ndb ל-Cloud NDB

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

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

במדריך הזה נסביר איך להעביר את ספריית הלקוח המובנית ndb (Next Database) של App Engine אל ספריית הלקוח של Cloud NDB.

הערה: אם האפליקציה שלכם לא משתמשת ב-ndb או ב-Datastore, אתם יכולים לעבור על ה-Codelab הזה כתרגיל כדי להכיר את ההעברה הזו.

מה תלמדו

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

מה תצטרכו

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

סקר

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

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

2. רקע

במודול 1, העברנו את ה-frameworks של האתר מ-webapp2 המובנה של App Engine אל Flask. ב-codelab הזה אנחנו ממשיכים להפסיק להשתמש בשירותים המובנים של App Engine, ועוברים מהספרייה ndb של App Engine אל Cloud NDB של Google.

אחרי שתשלימו את המיגרציה, תוכלו:

1. מעבר ל-Python 3 ולזמן הריצה של הדור הבא של App Engine
2. העברה אל Cloud Datastore (ספריית לקוח לאפליקציות שאינן App Engine)
3. העברת אפליקציית Python 2 (או 3) לקונטיינר והעברה ל-Cloud Run
4. הוספה של שימוש בתורי משימות (push) של App Engine ואז מעבר ל-Cloud Tasks

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

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

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

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

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

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

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

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

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

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

תיקיית הקוד של מודול 1 של STARTing צריכה להכיל את התוכן הבא:

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

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

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

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

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

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

4. עדכון קובצי התצורה (הוספת ספריית Cloud NDB)

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

נעדכן את קובצי האישור כדי להחליף את App Engine ndb ב-Cloud NDB, ואז נשנה את האפליקציה.

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

במודול 1, התלות החיצונית היחידה של האפליקציה שלנו הייתה Flask. עכשיו נוסיף את Cloud NDB. כך נראה קובץ requirements.txt בסוף מודול 1:

• לפני:

Flask==1.1.2

כדי להעביר נתונים מ-App Engine ndb, צריך להשתמש בספריית Cloud NDB ‏ (google-cloud-ndb), לכן מוסיפים את החבילה שלה אל requirements.txt.

• אחרי:

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

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

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

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

2. עדכון של app.yaml

יש כמה דרישות להוספת ספריות לקוח של Google Cloud כמו google-cloud-ndb, וכולן קשורות להכללה של ספריות 'מוכללות', חבילות של צד שלישי שכבר זמינות בשרתים של Google. אתם לא מפרטים אותם ב-requirements.txt וגם לא מעתיקים אותם באמצעות pip install. הדרישות היחידות:

1. ציון ספריות מובנות ב-app.yaml
2. הפניה לספריות של צד שלישי שהועתקו והם עשויים לעבוד איתן (ב-lib)

הנה ההתחלה של app.yaml מתוך מודול 1:

• לפני:

runtime: python27
threadsafe: yes
api_version: 1

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

עכשיו מוסיפים את השורות הבאות אל app.yaml כדי להפנות לצמד חבילות צד שלישי: grpcio ו-setuptools בקטע libraries חדש:

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

למה כדאי להשתמש בספריות המובנות האלה? ‏gRPC הוא פריימוורק RPC בקוד פתוח שמשמש את כל ספריות הלקוח של Google Cloud, כולל google-cloud-ndb. הספרייה grpcio היא מתאם Python gRPC ולכן היא נדרשת. ההסבר למה כוללים את setuptools יופיע בהמשך.

• אחרי:

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

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

3. עדכון של appengine_config.py

הכלי pkg_resources, שהוא חלק מהספרייה setuptools, משמש כדי לאפשר לספריות צד שלישי מוכללות לגשת לספריות מצורפות. צריך לעדכן את appengine_config.py כדי להשתמש ב-pkg_resources כדי להפנות אותם לספריות בחבילה ב-lib. אחרי שמבצעים את השינוי הזה, הקובץ כולו צריך להיראות כך:

import pkg_resources
from google.appengine.ext import vendor

# Set PATH to your libraries folder.
PATH = 'lib'
# Add libraries installed in the PATH folder.
vendor.add(PATH)
# Add libraries to pkg_resources working set to find the distribution.
pkg_resources.working_set.add_entry(PATH)

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

אחרי שסיימתם את הפורמליות של קובץ התצורה, אתם יכולים להעביר מ-ndb ל-Cloud NDB. כדי להשלים את המיגרציה, צריך לעדכן את הספריות המיובאות ולהוסיף שימוש בניהול הקשר ב-main.py.

1. יבוא

מבצעים את החלפת הייבוא הבאה ב-main.py:

• לפני

from google.appengine.ext import ndb

• אחרי:

from google.cloud import ndb

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

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

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

באופן דומה, כדי להשתמש ב-Cloud NDB, צריך לקבל את ההקשר של לקוח כדי לתקשר עם Datastore לפני שניתן להפעיל פקודות של Datastore. קודם יוצרים לקוח (ndb.Client()) על ידי הוספת ds_client = ndb.Client() ב-main.py right after Flask initialization:

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

הפקודה Pythonwith משמשת רק כדי לקבל את ההקשר של אובייקט. מקיפים כל בלוק קוד שמאפשר גישה ל-Datastore בהצהרות with.

בהמשך מופיעות אותן פונקציות מתוך מודול 1 לכתיבת ישות חדשה ב-Datastore ולקריאה כדי להציג את הישויות שנוספו לאחרונה:

• לפני:

הנה הקוד המקורי בלי ניהול הקשר:

def store_visit(remote_addr, user_agent):
    'create new Visit entity in Datastore'
    Visit(visitor='{}: {}'.format(remote_addr, user_agent)).put()

def fetch_visits(limit):
    'get most recent visits'
    return (v.to_dict() for v in Visit.query().order(
            -Visit.timestamp).fetch(limit))

• אחרי:

עכשיו מוסיפים את with ds_client.context(): ומעבירים את קוד הגישה למאגר הנתונים לבלוק with:

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

def fetch_visits(limit):
    'get most recent visits'
    with ds_client.context():
        return (v.to_dict() for v in Visit.query().order(
                -Visit.timestamp).fetch(limit))

אזהרה: בניגוד ל-ndb, כשעובדים עם טרנזקציות ו-Cloud NDB, תורי המשימות פועלים באופן עצמאי. לדוגמה, בקוד של העסקה, קריאות לתור המשימות לא מבוטלות אם העסקה נכשלת, רק פעולות Datastore. אין לנו תיעוד לגבי המגבלה הזו, אבל היא מופיעה בדף "not available" with Cloud Tasks.

אפליקציית ה-driver הראשית נשארת זהה למה שהיה לנו ממודול 1, כי אין כאן קוד ndb (וגם לא Cloud NDB):

@app.route('/')
def root():
    'main application (GET) handler'
    store_visit(request.remote_addr, request.user_agent)
    visits = fetch_visits(10)
    return render_template('index.html', visits=visits)

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

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

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

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

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

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

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

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

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

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

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

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

השלבים הבאים

מכאן יש לך גמישות לגבי הפעולה הבאה. אפשר לבחור אחת מהאפשרויות האלה:

• בונוס למודול 2: כדי ללמוד על העברה ל-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
• מודול 3:
  • מודרניזציה של הגישה ל-Datastore מ-Cloud NDB ל-Cloud Datastore
  • זוהי הספרייה שמשמשת לאפליקציות Python 3 App Engine ולא לאפליקציות App Engine

7. בונוס: מעבר ל-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 NDB תואם ל-Python 2-3, אין צורך להעביר קוד אפליקציה באופן מפורש ל-3.x. האפליקציה פועלת ב-2.x וב-3.x ללא שינוי, כלומר השינויים הנדרשים הם רק בהגדרות במקרה הזה:

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

בנוסף לקובץ main.py, הקבצים requirements.txt ו-templates/index.html לא משתנים.

פישוט app.yaml

לפני:

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

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 זמין בדף התיעוד שלו.

הסרת ההוראה 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 Engine Standard וגם במסמכי ההפעלה של App Engine Flexible.

מחיקה של 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 במודול 2. כדי להמחיש את ההבדלים באמצעות Python 2, משווים את הקוד לגרסת Python 2 שלו.

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

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

כשמגיע הזמן להעביר את האפליקציה שלכם, תצטרכו להעביר את 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 הזה, כדאי לחפש את הבעיה לפני ששולחים דיווח. קישורים לחיפוש וליצירה של בעיות חדשות:

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

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

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

Codelab	‫Python 2	‫Python 3
מודול 1	קוד	(n/a)
מודול 2	קוד	קוד

משאבי App Engine

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

• הפניות ל-Python NDB
  • מסמכי ndb App Engine
  • מאגר ndb App Engine
  • מסמכי התיעוד של Google Cloud NDB
  • מאגר Google Cloud NDB
• ‫(OLD) העברה מ-Python 2.5 ומ-webapp ל-2.7 ומ-webapp2
  • ‫Python 2.5 הוצא משימוש בשנת 2013 והושבת בשנת 2017 לטובת גרסה 2.7
  • מסמכי Python בגרסאות 2.5 עד 2.7
  • ‫Python 2.5 db library
  • העברה מ-Python 2.5 db ל-2.7 ndb
• מעבר ל-Python 3 ולסביבת זמן ריצה מהדור הבא של GAE
  • העברה מ-GAE ndb ל-Cloud NDB
  • מאגר לדוגמא של מסמכי תיעוד של GAE ndb ל-Cloud NDB
  • אופציונלי: רכיבי handler של סקריפטים
  • הפניה entrypoint
  • דוגמאות ושיטות מומלצותapp.yaml
  • דוגמאות נוספות ושיטות מומלצות
  • העברת קובצי תצורה של App Engine
  • דף הבית של מרכז ההעברה
• כללי
  • ‫Python ב-Google Cloud Platform
  • ספריות לקוח Python של Google Cloud