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

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

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

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

מה תלמדו

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

מה תצטרכו

סקר

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

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

2. רקע

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

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

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

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

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

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

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

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

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

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

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

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

$ ls
app.yaml        index.html      main.py

3. (Re)Familiarize yourself w/gcloud commands

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

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

הפקודה האחרונה (#5), ‏ gcloud app deploy, היא לפריסת האפליקציה ב-App Engine. מכיוון שאנחנו רק מתחילים, הפעלת הקוד עכשיו היא אופציונלית, אבל אנחנו בהחלט לא ממליצים לפרוס את הקוד של מודול 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, צריך להגדיר בקובץ התצורה appengine_config.py את התיקייה lib שבה App Engine צריך לחפש אותן. קובץ התצורה 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. אחרי הייבוא של מסגרת webapp2, מתבצע ייבוא של ספריית Datastore, ולבסוף של התוסף App Engine שמעבד תבניות בסגנון Django.ndb אתם אמורים לראות את הנתונים הבאים:

  • לפני:
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) שמפרט את כל המסלולים והמטפלים בכל קובץ Python (יכולים להיות קבצים אחרים):

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

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

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

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

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

ה-Codelab הזה לא כולל הדרכה על Flask, לכן מומלץ לעיין במדריך ל-Flask ובמאמרי העזרה של Flask כדי להכיר טוב יותר את המסגרת.

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

אין שינויים כאן. הנושא של ה-codelab הבא יהיה Datastore.

4. Handlers

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

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

ב-framework‏ webapp2 נעשה שימוש במודל ביצוע מבוסס-מחלקות, שבו נוצרים רכיבי handler לכל שיטת 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, כותבים פונקציות ומקשטים אותן במסלול שצריך לקרוא להן. המשתמשים יכולים לציין שיטות HTTP שמטופלות בקריאה ל-decorator, כלומר, @app.route('/app/', methods=['GET', 'POST']). מכיוון שברירת המחדל היא רק GET (ובאופן משתמע HEAD), אפשר להשאיר את ההגדרה הזו כלא פעילה.

במעבר ל-Flask, מחליפים את המחלקה MainHandler ואת השיטה 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 שמבצעות קריאות (callables) כמו 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 בכל שאר סדנאות הקוד שקשורות להעברה.

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

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

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

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

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

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

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

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

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

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

השלבים הבאים

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

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

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

App Engine migration module codelabs issues/feedback

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

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

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

Codelab

‫Python 2

‫Python 3

יחידת לימוד 0

קוד

(n/a)

מודול 1

קוד

(n/a)

משאבי App Engine

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