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 בספריות לקוח של Cloud Datastore
- עדכון האפליקציה
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
שאר השלבים לפני העבודה שצריך לבצע עכשיו:
- כדאי להכיר מחדש את כלי שורת הפקודה
gcloud
(אם רלוונטי) - (אם צריך לפרוס מחדש את הקוד של מודול 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 הזה.
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:
אם עברתם לסדרה הזו בלי לבצע אף אחת מההדרכות הקודמות של הקוד, האפליקציה עצמה לא משתנה. הוא רושם את כל הביקורים בדף האינטרנט הראשי (/
) ונראה כך לאחר שביקרת באתר מספיק פעמים:
מזל טוב, השלמת את ה-Codelab של יחידת הלימוד הזו. עכשיו אתם יודעים שאפשר להשתמש גם בספריות הלקוח Cloud NDB וגם ב-Cloud Datastore כדי לגשת ל-Datastore. אם תעברו לגרסה השנייה, עכשיו תוכלו ליהנות מההטבות: ספריות משותפות, שימוש חוזר בקוד וקוד עקבי כדי לשמור על עקביות ולהוזיל את עלות התחזוקה.
אופציונלי: הסרת המשאבים
מה לעשות כדי שלא נחייב אתכם עד שתהיו מוכנים לעבור ל-Codelab הבא של ההעברה? כמפתחים קיימים, סביר להניח שאתם כבר מעודכנים לגבי נתוני התמחור של App Engine.
אופציונלי: השבתת האפליקציה
אם אתם עדיין לא מוכנים לעבור למדריך הבא, כדאי להשבית את האפליקציה כדי לא לצבור חיובים. כשתהיו מוכנים לעבור ל-Codelab הבא, תוכלו להפעיל אותו מחדש. בזמן שהאפליקציה מושבתת, תנועת הגולשים לא תצברו חיובים. עם זאת, חיוב נוסף הוא השימוש שלכם במאגר הנתונים אם הוא חורג מהמכסה בחינם. לכן כדאי למחוק מספיק נתונים כדי לא לחרוג מהמגבלה הזו.
מצד שני, אם אתם לא מתכוונים להמשיך בהעברות ואתם רוצים למחוק הכול לגמרי, תוכלו להשבית את הפרויקט.
השלבים הבאים
לאחר מכן, תוכלו להתנסות במודולים הבאים להעברה:
- בונוס על יחידת לימוד 3: המשיכו לקטע הבונוס כדי ללמוד איך לנייד אל Python 3 ואל סביבת זמן הריצה של App Engine מהדור הבא.
- מודול 7: תורים של משימות דחיפה ב-App Engine (נדרש אם משתמשים ב[push] תורי משימות)
- הוספת משימות דחיפה ל-App Engine
taskqueue
לאפליקציית מודול 1 - הכנת המשתמשים למעבר אל Cloud Tasks במודול 8
- הוספת משימות דחיפה ל-App Engine
- מודול 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
כדי לקבל גישה לתכונות ולזמן הריצה העדכניים ביותר של 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 ללא שינויים, כלומר השינויים הנדרשים היחידים הם בהגדרות במקרה הזה:
- צריך לפשט את
app.yaml
כדי להפנות ל-Python 3 ולהסיר את ההפניה לספריות בחבילה של צד שלישי. - מוחקים את
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, סיכום של השינויים העיקריים הוא:
- אין קיבוץ של ספריות של צד שלישי שהועתקו (רשומות ב-
requirements.txt
) - לא
pip install
בתוך תיקייה מסוגlib
, כלומר אין תקופה שלlib
תיקייה - אין רישום של ספריות מובְנות של צד שלישי ב-
app.yaml
- אין צורך להפנות לאפליקציה לספריות של צד שלישי, לכן אין צורך בקובץ
appengine_config.py
אם צריך, מפרסמים את כל הספריות הנדרשות של צד שלישי ב-requirements.txt
.
פריסת אפליקציה
צריך לפרוס מחדש את האפליקציה כדי לוודא שהיא פועלת. אתם יכולים גם לבדוק עד כמה הפתרון שלכם קרוב לקוד Python 3 לדוגמה של מודול 3. כדי להמחיש את ההבדלים לעומת Python 2, משווים בין הקוד לגרסת Python 2 שלו.
מזל טוב, סיימת את שלב הבונוס במודול 3! למסמכי העזרה בנושא הכנת קובצי תצורה לסביבת זמן הריצה של Python 3 לסיום, יש לעיין בסיכום הקודם שלמעלה כדי לקבל הנחיות לשלבים הבאים ולהסרת המשאבים.
הבקשה שלך בהכנה.
כשמגיע הזמן להעביר את האפליקציה שלכם, תצטרכו לנייד את הקובץ main.py
וקובצי אפליקציות אחרים ל- 3.x, כך ששיטה מומלצת היא להגדיר את האפליקציה מסוג 2.x כ'תואם להעברה'. ככל האפשר.
יש המון מקורות מידע באינטרנט שיכולים לעזור לכם לעשות זאת, אבל ריכזנו כאן כמה טיפים חשובים:
- מוודאים שכל יחסי התלות של אפליקציות תואמים באופן מלא ל- 3.x
- מוודאים שהאפליקציה פועלת בגרסה 2.6 לפחות (עדיף 2.7)
- חשוב לוודא שהאפליקציה עוברת את כל חבילת הבדיקות (וכיסוי מינימלי של 80%)
- שימוש בספריות תאימות כמו
six
, Future ו/או Modernize - הסברים לגבי ההבדלים בין מפתחות 2.x ל-3.x שאינם תואמים לאחור
- כל קלט/פלט (I/O) יוביל ככל הנראה לאי-תאימות במחרוזות של Unicode לעומת בייטים
האפליקציה לדוגמה תוכננה מתוך מחשבה על כל זה, ולכן היא פועלת ב-2.x וב-3.x ישירות מהאריזה, כדי שנוכל להתמקד בלהראות לך מה צריך לשנות כדי להשתמש בפלטפורמה של הדור הבא.
8. מקורות מידע נוספים
בעיות/משוב על Codelabs עם מודול ההעברה של App Engine
אם נתקלתם בבעיות ב-Codelab הזה, צריך קודם לחפש את הבעיה לפני השליחה. קישורים לחיפוש וליצירת בעיות חדשות:
משאבים להעברה
בטבלה למטה מופיעים הקישורים לתיקיות המאגר של מודול 2 (START) ומודול 3 (FINISH). אפשר לגשת אליהן גם דרך המאגר לכל ההעברות של App Engine, שאותו אפשר לשכפל או להוריד בקובץ ZIP.
Codelab | ֶPython 2 | ֶPython 3 |
יחידת לימוד 3 |
משאבי App Engine
בהמשך מופיעים מקורות מידע נוספים בנוגע להעברה הספציפית הזו:
- מסמכי עזר של Python Cloud NDB ו-Cloud Datastore
- מעבר לשימוש ב-Python 3 וב-GAE מהדור הבא של סביבת זמן ריצה
- כללי