מודול 1: מעבר מ-webapp2 ל-Flask

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

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

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

כאן מוסבר איך

  • שימוש בספריות של צד שלישי (מובְנות או אחרות)
  • עדכון קובצי תצורה
  • העברת אפליקציה פשוטה מ-webapp2 ל-Flask

מה צריך להכין

סקר

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

לקריאה בלבד לקרוא אותו ולבצע את התרגילים

2. רקע

המסגרת webapp צורפה כש-App Engine הושק לראשונה ב-Python 2.5 בשנת 2008. בשנים מאוחר יותר, הוא הוחלף על ידי webapp2 כך שסביבת זמן הריצה של 2.7 הוצאה משימוש ב-2.5 ב-2013.

webapp2 (ראו מסמכים) עדיין קיים ואפשר להשתמש בו מחוץ ל-App Engine כמסגרת אינטרנט תואמת ל-WSGI, אבל הוא לא מבצע ניתוב משלו של בקשות משתמשים לקוד המתאים באפליקציה. במקום זאת, היא מסתמך על App Engine, על קובצי תצורה ועל המפתח כדי לבצע את הניתוב של תנועת האינטרנט בהתאם ל"handlers" המתאימים. בנוסף, היתרונות העיקריים של webapp2 קשורים באופן בלתי תלוי לשירותים בחבילה של App Engine, ולכן אנחנו מוציאים משימוש את השירות אפילו אם הוא פועל ב-Python 3 (אפשר לעיין גם בבעיה קשורה).

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

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

  1. הגדרה/עבודה מוקדמת
  2. הוספת ספריית צד שלישי של Flask
  3. עדכון קובצי אפליקציה
  4. עדכון קובץ של תבנית HTML

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

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

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

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

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

מאגר ההעברה של GAE כולל את כל הקוד שדרוש. משכפלים או מורידים את קובץ ה-ZIP שלו. עבור מדריך זה, תתחילו עם הקוד בתיקיית מודול 0 (START), ולאחר השלמת המדריך, הקוד אמור להתאים לתיקייה של מודול 1 (FINISH). אם לא, בדקו את ההבדלים כדי שתוכלו לעבור לשיעור ה-Lab הבא.

התיקייה של מודול 0 צריכה להכיל קבצים שנראים כך, כפי שמוצג באמצעות הפקודה ls של POSIX:

$ ls
app.yaml        index.html      main.py

3. (חשוב) להכיר את הפקודות של gcloud

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

  1. gcloud components update — עדכון Google Cloud SDK
  2. gcloud auth login – צריך להתחבר לחשבון בעל פרטי הכניסה שלך
  3. gcloud config list — הצגת רשימה של הגדרות הפרויקט ב-GCP
  4. gcloud config set project PROJECT_ID – הגדרת מזהה פרויקט ב-GCP
  5. gcloud app deploy — פורסים את אפליקציית App Engine

אם לא ביצעתם לאחרונה פיתוח של App Engine עם gcloud, עליכם להריץ את ארבע הפקודות הראשונות (#1-#4) כדי לבצע את ההגדרה לפני המעבר לשלבים הבאים. עכשיו נציג סקירה כללית קצרה של הפקודות האלה.

קודם כל, gcloud components update מוודאים שהגרסה העדכנית ביותר של Cloud SDK מותקנת במכשיר. הרצת הפקודה הזו אמורה לספק פלט כזה:

$ gcloud components update

Your current Cloud SDK version is: 317.0.0
You will be upgraded to version: 318.0.0

┌──────────────────────────────────────────────────┐
│        These components will be updated.         │
├──────────────────────────┬────────────┬──────────┤
│           Name           │  Version   │   Size   │
├──────────────────────────┼────────────┼──────────┤
│ Cloud SDK Core Libraries │ 2020.11.06 │ 15.5 MiB │
│ gcloud cli dependencies  │ 2020.11.06 │ 10.6 MiB │
└──────────────────────────┴────────────┴──────────┘

The following release notes are new in this upgrade.
Please read carefully for information about new features, breaking changes,
and bugs fixed.  The latest full release notes can be viewed at:
  https://cloud.google.com/sdk/release_notes

318.0.0 (2020-11-10)

      . . .
      (release notes)
      . . .

    Subscribe to these release notes at
    https://groups.google.com/forum/#!forum/google-cloud-sdk-announce.

Do you want to continue (Y/n)?

╔════════════════════════════════════════════════════════════╗
╠═ Creating update staging area                             ═╣
╠════════════════════════════════════════════════════════════╣
╠═ Uninstalling: Cloud SDK Core Libraries                   ═╣
╠════════════════════════════════════════════════════════════╣
╠═ Uninstalling: gcloud cli dependencies                    ═╣
╠════════════════════════════════════════════════════════════╣
╠═ Installing: Cloud SDK Core Libraries                     ═╣
╠════════════════════════════════════════════════════════════╣
╠═ Installing: gcloud cli dependencies                      ═╣
╠════════════════════════════════════════════════════════════╣
╠═ Creating backup and activating new installation          ═╣
╚════════════════════════════════════════════════════════════╝

Performing post processing steps...done.

Update done!

To revert your SDK to the previously installed version, you may run:
  $ gcloud components update --version 317.0.0

בשלב הבא, עליך להשתמש ב-gcloud auth login כדי לאמת את עצמך באמצעות פקודות gcloud שייושמו בעתיד:

$ gcloud auth login
Your browser has been opened to visit:

    https://accounts.google.com/o/oauth2/auth?response_type=code&client_id= . . .

You are now logged in as [YOUR_EMAIL].
Your current project is [PROJECT_ID].  You can change this setting by running:
  $ gcloud config set project PROJECT_ID

אפשר להשתמש ב-gcloud config list כדי לראות את הגדרות הפרויקט הנוכחיות:

$ gcloud config list
[core]
account = YOUR_EMAIL
disable_usage_reporting = False
project = PROJECT_ID

Your active configuration is: [default]

הפקודה שלמעלה אמורה להנחות אתכם ביצירת פרויקט חדש או בבחירת פרויקט קיים. אם הפלט של gcloud config list לא תואם לפרויקט שנבחר שבו מתכוונים להשתמש במדריך הזה, מריצים את הפקודה gcloud config set project PROJECT_ID כדי להגדיר את מזהה הפרויקט. לאחר מכן, כדי לוודא שמזהה הפרויקט הנכון מוגדר, מריצים שוב את gcloud config list.

$ gcloud config set project PROJECT_ID
Updated property [core/project].

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

כרטיסיית מידע של פרויקט

הפקודה האחרונה (מס' 5), gcloud app deploy, מיועדת לפריסה של האפליקציה ב-App Engine. מכיוון שזו רק ההתחלה, ההרצה שלו עכשיו היא אופציונלית, אבל אנחנו בהחלט לא לא מעודדים לפרוס את הקוד של Module 0 כדי לוודא שהוא פועל. לאחר הביצוע, בוחרים את האזור הגיאוגרפי שבו רוצים שהאפליקציה תפעל (בדרך כלל המיקום שלכם). עם זאת, לא ניתן לשנות את ההגדרה הזו לאחר הגדרתה. לאחר מכן מומלץ לצפות בשאר פרטי הפריסה. בסיום התהליך, תישלח אליך הודעה לגבי כתובת ה-URL שבה האפליקציה תוצג. הנה גרסה מקוצרת של מה שאתם עשויים לראות:

$ gcloud app deploy
Services to deploy:

descriptor:      [/private/tmp/mod0-baseline/app.yaml]
source:          [/private/tmp/mod0-baseline]
target project:  [PROJECT_ID]
target service:  [default]
target version:  [20201116t220827]
target url:      [https://PROJECT_ID.REG_ABBR.r.appspot.com]


Do you want to continue (Y/n)?

Beginning deployment of service [default]...
╔════════════════════════════════════════════════════════════╗
╠═ Uploading 1 file to Google Cloud Storage                 ═╣
╚════════════════════════════════════════════════════════════╝
File upload done.
Updating service [default]...done.
Setting traffic split for service [default]...done.
Deployed service [default] to [https://PROJECT_ID.REG_ABBR.r.appspot.com]

You can stream logs from the command line by running:
  $ gcloud app logs tail -s default

To view your application in the web browser run:
  $ gcloud app browse

אם לא משתמשים ב-App Engine במשך זמן מה, יכול להיות שתבחינו שפקודת appcfg.py update המקורית של הפריסה הוחלפה על ידי gcloud app deploy. למידע נוסף על gcloud app deploy, אפשר להיכנס לדף התיעוד שלו.

שינוי נוסף שבוצע לאחרונה הוא כתובת URL, שונה מ-http://PROJECT_ID.appspot.com ל-http://PROJECT_ID.REG_ABBR.r.appspot.com. רוב האפליקציות יומרו בסופו של דבר לפורמט החדש. מידע נוסף על הפורמט של כתובת URL זמין במסמכי התיעוד בנושא בקשות וניתוב.

לאחר פריסת האפליקציה, צריך לרענן את הדפדפן (לפעמים כמה פעמים) כדי לראות את הביקורים האחרונים:

אפליקציית visitme

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

4. הוספת ספריית צד שלישי של Flask

זמן הריצה של Python 2 App Engine מספק קבוצה של פעולות מובנות" ספריות של צד שלישי שבהן כל מה שצריך לעשות הוא לציין אותן בקובץ app.yaml לשימוש. ההעברה לא מחייבת את המשתמשים האלה, אבל הם יופיעו במדריך הבא בנושא ההעברה (למודול 2).

ספריות של צד שלישי שאינן מובנות צריך לציין בקובץ בשם requirements.txt ולהתקין אותן באופן מקומי בתיקייה lib, באותה ספרייה שבה נמצא קוד האפליקציה שבה כל התוכן מועלה אל App Engine. במסמכי התיעוד בנושא צירוף ספריות של צד שלישי יש מידע נוסף.

ספריות שהועתקו כמו Flask מחייבות אותך להנחות את App Engine לחפש אותן בתיקייה lib באמצעות קובץ התצורה appengine_config.py. קובץ התצורה appengine_config.py ממוקם באותה תיקיית אפליקציות ברמה העליונה שבה נמצאים requirements.txt ו-lib. בחלק זה של המדריך תלמדו:

  • יצירת requirements.txt (יש לציין ספריות של צד שלישי [לא מובנות] שהועתקו)
  • יצירת appengine_config.py (זיהוי ספריות של צד שלישי)
  • התקנה של חבילות ויחסי תלות של צד שלישי

1. יצירה של requirements.txt

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

Flask==1.1.2

מידע נוסף על פורמטים קבילים זמין במסמכי התיעוד בנושא requirements.txt.

2. יצירה של appengine_config.py

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

from google.appengine.ext import vendor

# Set PATH to your libraries folder.
PATH = 'lib'
# Add libraries installed in the PATH folder.
vendor.add(PATH)

הקוד הזה מבצע בדיוק את מה שציינו קודם, כלומר מפנה את App Engine אל התיקייה lib כדי למצוא ספריות שהועתקו.

3. התקנה של חבילות ויחסי תלות

עכשיו מריצים את הפקודה pip install כדי ליצור את התיקייה lib ולהתקין בה את Flask ואת יחסי התלות שלה:

$ pip install -t lib -r requirements.txt

בין אם השתמשתם ב-pip או ב-pip2, אחרי שהתקנת החבילה הסתיימה, צריכה להיות לכם תיקייה lib עם תוכן דומה ל:

$ ls lib
bin/
click/
click-7.1.2.dist-info/
flask/
Flask-1.1.2.dist-info/
itsdangerous/
itsdangerous-1.1.0.dist-info/
jinja2/
Jinja2-2.11.2.dist-info/
markupsafe/
MarkupSafe-1.1.1.dist-info/
werkzeug/
Werkzeug-1.0.1.dist-info/

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

עכשיו נעדכן את קובץ האפליקציה, main.py.

1. יבוא

הייבוא מתחיל כמו בכל קובצי Python. אחרי הייבוא של framework של webapp2 מופיעה ספריית Datastore ndb, ולבסוף, תוסף App Engine שמעבד תבניות בטעם Django. אתם אמורים לראות את הנתונים הבאים:

  • לפני:
import webapp2
from google.appengine.ext import ndb
from google.appengine.ext.webapp import template

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

  • אחרי:
from flask import Flask, render_template, request
from google.appengine.ext import ndb

2. הפעלה

באפליקציות שמשתמשות ב-webapp2 נדרש מערך יחיד (רשימת Python) שמפרט את כל הנתיבים וה-handlers בכל קובץ Python (יכולים להיות גם אחרים):

  • לפני:
app = webapp2.WSGIApplication([
    ('/', MainHandler),
], debug=True)

חשוב לזכור שהמערכת app.yaml מבצעת ניתוב ברמה גבוהה יותר ועשויה להפעיל handlers שונים. האפליקציה לדוגמה פשוטה מספיק כך שכל המסלולים מגיעים ל-handler של main.py.

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

  • אחרי:
app = Flask(__name__)

ב-Flask, מאתחלים את ה-framework ואז משתמשים בקישוטים כדי להגדיר את המסלולים. בנוסף, מסלולים מותאמים לפונקציות, לא למחלקות או לשיטות.

ב-Codelab הזה לא נכלל המדריך הזה של Flask, אז כדאי להקדיש זמן לעבודה על המדריך של Felask ולקרוא את מסמכי התיעוד של Flask כדי להתרגל ל-framework.

3. מודל נתונים

אין כאן שינויים. Datastore יהיה המוקד ב-Codelab הבא.

4. מטפלים

האפליקציה, ללא קשר ל-framework שבו אתם משתמשים (webapp2 או Flask), מבצעת 3 פעולות:

  1. טיפול בנתיב הבסיס (/) של בקשות אחזור
  2. רישום "ביקור" בדף אינטרנט (יצירה/אחסון של אובייקט Visit)
  3. הצגת 10 הביקורים האחרונים המובילים (עם תבנית מוגדרת מראש, index.html)

ה-framework של webapp2 משתמש במודל הפעלה מבוסס-מחלקה שבו נוצרים handlers לכל method נתמכת של HTTP. במקרה הפשוט שלנו יש לנו רק GET, כך שהשיטה get() מוגדרת:

  • לפני:
class MainHandler(webapp2.RequestHandler):
    def get(self):
        store_visit(self.request.remote_addr, self.request.user_agent)
        visits = fetch_visits(10) or ()  # empty sequence if None
        tmpl = os.path.join(os.path.dirname(__file__), 'index.html')
        self.response.out.write(template.render(tmpl, {'visits': visits}))

כפי שצוין למעלה, Flask משתמשת בתכנון מסלול משלה. במקום מחלקה של handler, כותבים פונקציות וקשטים אותן במסלול שרוצים להגדיר להן את ה-handler. המשתמשים יכולים לציין methods של HTTP שמטופלות בקריאה למשתמש לעיצוב, כלומר, @app.route('/app/', methods=['GET', 'POST']). מכיוון שברירת המחדל היא רק GET (ובאופן מרומז HEAD), אפשר להפסיק אותה.

בהעברה ל-Flask, צריך להחליף את המחלקה MainHandler ואת ה-method שלה ב-get() בפונקציית הניתוב הבאה של Flask:

  • אחרי:
@app.route('/')
def root():
    store_visit(request.remote_addr, request.user_agent)
    visits = fetch_visits(10) or ()  # empty sequence if None
    return render_template('index.html', visits=visits)

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

5. קובצי עזר

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

.gcloudignore
.git
.gitignore
.hgignore
.hg/
*.pyc
*.pyo
__pycache__/
/setup.cfg
README.md

6. עדכון קובץ של תבנית HTML

1. העברת קובץ תבנית

בתיקיית המאגר הבסיסית (מודול 0), קובץ התבנית index.html נמצא באותה תיקייה שבה נמצאים קובצי האפליקציה. כדי להשתמש ב-Flask צריך להציב קובצי HTML בתיקייה templates, לכן צריך ליצור את התיקייה הזו (mkdir templates) ולהעביר אליה את index.html. במערכת שתואמת ל-POSIX, כמו Linux או Mac OS X, הפקודות הן:

mkdir templates
mv index.html templates

2. עדכון קובץ תבנית

אחרי ההעברה של index.html אל templates, אפשר לבצע שינוי קטן אבל נדרש. בואו נסתכל על קובץ התבנית המקורי בשלמותו:

<!doctype html>
<html>
<head>
<title>VisitMe Example</title>
<body>

<h1>VisitMe example</h1>
<h3>Last 10 visits</h3>
<ul>
{% for visit in visits %}
    <li>{{ visit.timestamp.ctime }} from {{ visit.visitor }}</li>
{% endfor %}
</ul>

</body>
</html>

webapp2 משתמש בתבניות Django שמבצע קריאה לפעולה כמו visit.timestamp.ctime בלי סוגריים עגולים ( ), אבל ב-Jinja2 צריך להשתמש בהן באופן מפורש. זה נשמע כמו שינוי קטן, אבל תבניות Jinja הן יותר חזקות, ישירות מתוך ההגדרות, כי ניתן להעביר ארגומנטים בשיחות.

ב-Django, צריך ליצור 'תג תבנית' או לכתוב מסנן. לאחר הבנת המידע הזה, עליך לעדכן את index.html על ידי הוספת זוג סוגריים מרובעים להפעלה של visit.timestamp.ctime:

  • לפני:
<li>{{ visit.timestamp.ctime }} from {{ visit.visitor }}</li>
  • אחרי:
<li>{{ visit.timestamp.ctime() }} from {{ visit.visitor }}</li>

זהו השינוי היחיד שנדרש; לא נדרשים שינויים נוספים ב-index.html בכל שאר ה-codelabs להעברה.

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

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

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

משתמשים בפקודה gcloud app deploy כפי שעשינו קודם לכן כשפרסנו את קוד המודול המקורי 0. גישה לאפליקציה ב-PROJECT_ID.appspot.com, מדפדפן אינטרנט או באמצעות פקודת curl או wget כדי לאשר שהיא פועלת כצפוי.

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

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

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

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

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

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

השלבים הבאים

יש שני מודולים של העברה שמתחילים בקוד של מודול 1 שהושלם, מודולים 2 ו-7:

  • מודול 2 (חובה אם משתמשים ב-Datastore)
    • מעבר מ-App Engine ndb ל-Cloud NDB
    • אחרי המעבר ל-Cloud NDB, יש עוד הרבה אפשרויות זמינות
      • יצירת קונטיינרים לאפליקציה כדי שתפעל ב-Cloud Run
      • העברה נוספת של האפליקציה לספריית הלקוח של Cloud Datastore
      • העברת האפליקציה שלך ל-Cloud Firestore כדי לקבל גישה לתכונות של Firebase
  • מודול 7 (חובה אם משתמשים בתורי משימות [push])
    • הוספת שימוש ב-App Engine (התראות) taskqueue
    • הכנה של אפליקציית מודול 1 להעברה אל Cloud Tasks במודול 8

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

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

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

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

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

Codelab

ֶPython 2

ֶPython 3

יחידת לימוד 0

קוד

(לא רלוונטי)

יחידת לימוד 1

קוד

(לא רלוונטי)

משאבי App Engine

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