מעבר ממשימות הדחיפה לתור המשימות של App Engine ל-Cloud Tasks (מודול 8)

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

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

מטרת ה-Codelab הזה היא להראות למפתחים ב-Python 2 App Engine איך לבצע מיגרציה מ-App Engine Task Queue (משימות push) ל-Cloud Tasks. יש גם העברה מרומזת מ-App Engine NDB אל Cloud NDB לגישה אל Datastore (הנושא הזה מכוסה בעיקר במודול 2).

הוספנו את השימוש במשימות push במודול 7, ואת ההעברה של השימוש הזה אל Cloud Tasks במודול 8, ואז המשכנו אל Python 3 ו-Cloud Datastore במודול 9. משתמשים בתורי משימות לביצוע משימות משיכה יבצעו מיגרציה ל-Cloud Pub/Sub, ויצטרכו לעיין במודולים 18-19.

כאן אפשר להבין איך

הדרישות

סקר

איך תשתמשו במדריך הזה?

רק לקרוא לקרוא ולהשלים את התרגילים

איך היית מדרג את חוויית השימוש שלך ב-Python?

מתחילים ביניים מומחים

איזה דירוג מתאים לדעתך לחוויית השימוש שלך בשירותי Google Cloud?

מתחילים ביניים מומחים

2. רקע

תור המשימות של App Engine תומך במשימות מסוג push ומסוג pull. כדי לשפר את הניידות של האפליקציה, צוות Google Cloud ממליץ לבצע מיגרציה משירותים חבילים מדור קודם, כמו Task Queue, לשירותים מקבילים עצמאיים של Cloud או של צד שלישי.

העברת משימות בשיטת Pull מוסברת במודולים 18-19, והעברת משימות בשיטת Push מוסברת במודולים 7-9. כדי להעביר משימות מסוג push מ-App Engine Task Queue, הוספנו את השימוש בהן לאפליקציית הדוגמה הקיימת של Python 2 App Engine, שרושמת כניסות חדשות לדף ומציגה את הכניסות האחרונות. ב-Module 7 codelab נוספת משימת push למחיקת הביקורים הכי ישנים – הם לא יוצגו יותר, אז למה שהם יתפסו נפח אחסון נוסף ב-Datastore? ב-codelab הזה, מודול 8, נשמרת אותה פונקציונליות אבל מועבר מנגנון התורים הבסיסי ממשימות push של Task Queue ל-Cloud Tasks, וגם חוזרים על ההעברה מ-App Engine NDB ל-Cloud NDB לגישה ל-Datastore, כפי שמוסבר במודול 2.

במדריך הזה נסביר איך:

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

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

בקטע הזה נסביר איך:

  1. הגדרת פרויקט בענן
  2. קבלת אפליקציה לדוגמה של ערך בסיס
  3. (Re)Deploy and validate baseline app
  4. הפעלת שירותים או ממשקי API חדשים של Google Cloud

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

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

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

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

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

לא משנה באיזו אפליקציה של מודול 7 אתם משתמשים, התיקייה צריכה להיראות כמו בדוגמה הבאה, ואולי גם לכלול את התיקייה lib:

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

3. (Re)Deploy and validate baseline app

כדי לפרוס את האפליקציה של מודול 7:

  1. אם יש תיקייה בשם lib, מוחקים אותה ומריצים את הפקודה pip install -t lib -r requirements.txt כדי לאכלס מחדש את lib. יכול להיות שתצטרכו להשתמש ב-pip2 במקום זאת אם גם Python 2 וגם Python 3 מותקנים במחשב הפיתוח שלכם.
  2. מוודאים שהתקנתם והפעלתם את כלי שורת הפקודה gcloud, ובדקתם את השימוש בו.
  3. (אופציונלי) מגדירים את פרויקט בענן באמצעות gcloud config set project PROJECT_ID אם לא רוצים להזין את PROJECT_ID בכל פקודת gcloud שמריצים.
  4. פריסת האפליקציה לדוגמה באמצעות gcloud app deploy
  5. מוודאים שהאפליקציה פועלת כמו שצריך ללא בעיות. אם השלמתם את סדנת ה-Codelab בנושא מודול 7, באפליקציה יוצגו המבקרים המובילים יחד עם הביקורים האחרונים (כפי שמוצג בהמשך). בתחתית המסך מופיע סימון של המשימות הישנות יותר שיימחקו.

4aa8a2cb5f527079.png

4. הפעלת שירותים או ממשקי API חדשים של Google Cloud

האפליקציה הישנה השתמשה בשירותים בחבילה של App Engine שלא דורשים הגדרה נוספת, אבל שירותי Cloud עצמאיים כן דורשים הגדרה כזו, והאפליקציה המעודכנת תשתמש גם ב-Cloud Tasks וגם ב-Cloud Datastore (באמצעות ספריית הלקוח Cloud NDB). למספר מוצרים של Cloud יש מכסות של תוכנית בחינם, כולל App Engine,‏ Cloud Datastore ו-Cloud Tasks. אם לא תחרוגו מהמגבלות האלה, לא יחולו עליכם חיובים על השלמת המדריך הזה. אפשר להפעיל את Cloud APIs דרך מסוף Cloud או דרך שורת הפקודה, בהתאם להעדפה שלכם.

מתוך Cloud Console

נכנסים אל דף הספרייה של API Manager (בפרויקט הנכון) ב-Cloud Console, ומחפשים את Cloud Datastore API ואת Cloud Tasks API באמצעות סרגל החיפוש באמצע הדף:

c7a740304e9d35b.png

לוחצים על הלחצן הפעלה לכל API בנפרד. יכול להיות שתתבקשו להזין פרטי חיוב. זו דוגמה שכוללת את הדף Cloud Pub/Sub API Library (אל תפעילו את Pub/Sub API בסדנת הקוד הזו, רק את Cloud Tasks ו-Datastore):

1b6c0a2a73124f6b.jpeg

משורת הפקודה

הפעלת ממשקי API דרך המסוף מספקת מידע חזותי, אבל יש אנשים שמעדיפים את שורת הפקודה. מריצים את הפקודה gcloud services enable cloudtasks.googleapis.com datastore.googleapis.com כדי להפעיל את שני ממשקי ה-API בו-זמנית:

$ gcloud services enable cloudtasks.googleapis.com datastore.googleapis.com
Operation "operations/acat.p2-aaa-bbb-ccc-ddd-eee-ffffff" finished successfully.

יכול להיות שתתבקשו להזין פרטי חיוב. אם רוצים להפעיל ממשקי Cloud API אחרים ורוצים לדעת מהם מזהי ה-URI שלהם, אפשר למצוא אותם בחלק התחתון של כל דף בספריית ה-API. לדוגמה, אפשר לראות את pubsub.googleapis.com כ'שם השירות' בחלק התחתון של הדף Pub/Sub שמופיע למעלה.

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

4. עדכון ההגדרות

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

requirements.txt

במודול 8, במקום להשתמש ב-App Engine NDB וב-Task Queue כמו במודול 1, נעשה שימוש ב-Cloud NDB וב-Cloud Tasks. מוסיפים את google-cloud-ndb ואת google-cloud-tasks ל-requirements.txt כדי להצטרף ל-flask ממודול 7:

flask
google-cloud-ndb
google-cloud-tasks

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

app.yaml

כשמשתמשים בספריות לקוח של Cloud, זמן הריצה של Python 2 App Engine מחייב חבילות ספציפיות של צד שלישי, כלומר grpcio ו-setuptools. משתמשי Python 2 צריכים לציין בספרייה app.yaml ספריות מובנות כמו אלה, לצד גרסה זמינה או 'הגרסה האחרונה'. אם עדיין אין לכם קטע libraries, יוצרים אותו ומוסיפים את שתי הספריות כך:

libraries:
- name: grpcio
  version: latest
- name: setuptools
  version: latest

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

runtime: python27
threadsafe: yes
api_version: 1

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

libraries:
- name: grpcio
  version: latest
- name: setuptools
  version: latest

appengine_config.py

הקריאה google.appengine.ext.vendor.add() ב-appengine_config.py מחברת את ספריות הצד השלישי שהעתקתם (לפעמים נקראות "יצירת עותק מקוד של צד שלישי (vendoring)" או "ספריות עצמאיות") ב-lib לאפליקציה שלכם. למעלה ב-app.yaml, הוספנו ספריות צד שלישי מובנות, ולכן צריך להשתמש ב-setuptools.pkg_resources.working_set.add_entry() כדי לקשר את האפליקציה שלכם לחבילות המובנות האלה ב-lib. בהמשך מוצג מודול 1 המקורי appengine_config.py ואחרי שביצעתם את העדכונים במודול 8:

לפני:

from google.appengine.ext import vendor

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

אחרי:

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)

תיאור דומה מופיע גם במאמרי העזרה בנושא העברה של App Engine.

5. שינוי קוד האפליקציה

בקטע הזה מוצגים עדכונים לקובץ האפליקציה הראשי, main.py, שמחליפים את השימוש בתורי שליחה של App Engine Task Queue ב-Cloud Tasks. לא חלים שינויים בתבנית האינטרנט, templates/index.html—שתי האפליקציות אמורות לפעול באופן זהה ולהציג את אותם נתונים. השינויים באפליקציה הראשית מחולקים לארבעת השלבים הבאים:

  1. עדכון ייבוא והפעלה
  2. עדכון הפונקציונליות של מודל הנתונים (Cloud NDB)
  3. מעבר ל-Cloud Tasks (ול-Cloud NDB)
  4. עדכון (דחיפה) של גורם מטפל במשימות

1. עדכון ייבוא והפעלה

  1. החלפת App Engine NDB ‏ (google.appengine.ext.ndb) ו-Task Queue ‏ (google.appengine.api.taskqueue) ב-Cloud NDB ‏ (google.cloud.ndb) וב-Cloud Tasks ‏ (google.cloud.tasks), בהתאמה.
  2. כדי להשתמש בספריות הלקוח ב-Cloud, צריך לבצע אתחול וליצור 'לקוחות API', ולהקצות אותם ל-ds_client ול-ts_client, בהתאמה.
  3. במסמכי Task Queue מצוין: "App Engine מספק תור דחיפה (push queue) ברירת מחדל, בשם default, שמוגדר ומוכן לשימוש עם הגדרות ברירת מחדל". ב-Cloud Tasks אין תור default (כי זה מוצר Cloud עצמאי שלא תלוי ב-App Engine), ולכן צריך קוד חדש כדי ליצור תור Cloud Tasks בשם default.
  4. לא צריך לציין אזור ב-App Engine Task Queue כי הוא משתמש באזור שבו האפליקציה פועלת. עם זאת, מכיוון ש-Cloud Tasks הוא עכשיו מוצר עצמאי, נדרש אזור, והאזור הזה חייב להיות זהה לאזור שבו האפליקציה פועלת. כדי ליצור 'שם נתיב מלא' כמזהה הייחודי של התור, צריך לציין את שם האזור ואת מזהה הפרויקט בענן.

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

לפני:

from datetime import datetime
import logging
import time
from flask import Flask, render_template, request
from google.appengine.api import taskqueue
from google.appengine.ext import ndb

app = Flask(__name__)

אחרי:

from datetime import datetime
import json
import logging
import time
from flask import Flask, render_template, request
from google.cloud import ndb, tasks

app = Flask(__name__)
ds_client = ndb.Client()
ts_client = tasks.CloudTasksClient()

_, PROJECT_ID = google.auth.default()
REGION_ID = 'REGION_ID'    # replace w/your own
QUEUE_NAME = 'default'     # replace w/your own
QUEUE_PATH = ts_client.queue_path(PROJECT_ID, REGION_ID, QUEUE_NAME)

2. עדכון הפונקציונליות של מודל הנתונים (Cloud NDB)

‫App Engine NDB ו-Cloud NDB פועלים כמעט באופן זהה. אין שינויים משמעותיים במודל הנתונים או בפונקציה store_visit(). ההבדל הבולט היחיד הוא שיצירת הישות Visit ב-store_visit() מוצגת עכשיו בתוך בלוק Python with. ב-Cloud NDB, כל הגישה ל-Datastore נשלטת בתוך מנהל ההקשר שלו, ולכן יש הצהרת with. קטעי הקוד הבאים ממחישים את ההבדל הקטן הזה כשמבצעים מיגרציה ל-Cloud NDB. מטמיעים את השינוי.

לפני:

class Visit(ndb.Model):
    'Visit entity registers visitor IP address & timestamp'
    visitor   = ndb.StringProperty()
    timestamp = ndb.DateTimeProperty(auto_now_add=True)

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

אחרי:

class Visit(ndb.Model):
    'Visit entity registers visitor IP address & timestamp'
    visitor   = ndb.StringProperty()
    timestamp = ndb.DateTimeProperty(auto_now_add=True)

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()

3. מעבר ל-Cloud Tasks (ול-Cloud NDB)

השינוי הכי חשוב בהעברה הזו הוא המעבר לתשתית תורים חדשה. הפעולה הזו מתבצעת בפונקציה fetch_visits() שבה נוצרת משימה (push) למחיקת ביקורים ישנים והיא מתווספת לתור לביצוע. עם זאת, הפונקציונליות המקורית של מודול 7 נשארת ללא שינוי:

  1. שליחת שאילתה לגבי הביקורים האחרונים.
  2. במקום להחזיר את הביקורים האלה באופן מיידי, המערכת שומרת את חותמת הזמן של הביקור האחרון מתוך Visit הביקורים הישנים ביותר שמוצגים – אפשר למחוק בבטחה את כל הביקורים שהתקיימו לפני חותמת הזמן הזו.
  3. אפשר להשתמש בכלי Python סטנדרטיים כדי לחלץ את חותמת הזמן כמספר עשרוני וכמחרוזת, ולהשתמש בשניהם בדרכים שונות, למשל להצגה למשתמש, להוספה ליומנים, להעברה ל-handler וכו'.
  4. יוצרים משימת פוש עם חותמת הזמן הזו כמטען הייעודי (payload) שלה, יחד עם /trim ככתובת ה-URL.
  5. בסופו של דבר, קוראים ל-handler של המשימה באמצעות HTTP POST לכתובת ה-URL הזו.

קטע הקוד 'לפני' ממחיש את תהליך העבודה הזה:

לפני:

def fetch_visits(limit):
    'get most recent visits & add task to delete older visits'
    data = Visit.query().order(-Visit.timestamp).fetch(limit)
    oldest = time.mktime(data[-1].timestamp.timetuple())
    oldest_str = time.ctime(oldest)
    logging.info('Delete entities older than %s' % oldest_str)
    taskqueue.add(url='/trim', params={'oldest': oldest})
    return data, oldest_str

הפונקציונליות נשארת זהה, אבל Cloud Tasks הופכת לפלטפורמת הביצוע. העדכונים שמשפיעים על השינוי הזה כוללים:

  1. עוטפים את השאילתה Visit בתוך בלוק Python with (חוזרים על ההעברה של מודול 2 ל-Cloud NDB)
  2. יצירת מטא-נתונים של Cloud Tasks, כולל מאפיינים צפויים כמו מטען ייעודי (payload) של חותמת זמן וכתובת URL, אבל גם הוספה של סוג MIME וקידוד JSON של המטען הייעודי.
  3. משתמשים בלקוח Cloud Tasks API כדי ליצור את המשימה עם המטא-נתונים והנתיב המלא של התור.

השינויים האלה ב-fetch_visits() מפורטים בהמשך:

אחרי:

def fetch_visits(limit):
    'get most recent visits & add task to delete older visits'
    with ds_client.context():
        data = Visit.query().order(-Visit.timestamp).fetch(limit)
    oldest = time.mktime(data[-1].timestamp.timetuple())
    oldest_str = time.ctime(oldest)
    logging.info('Delete entities older than %s' % oldest_str)
    task = {
        'app_engine_http_request': {
            'relative_uri': '/trim',
            'body': json.dumps({'oldest': oldest}).encode(),
            'headers': {
                'Content-Type': 'application/json',
            },
        }
    }
    ts_client.create_task(parent=QUEUE_PATH, task=task)
    return data, oldest_str

4. עדכון (דחיפה) של גורם מטפל במשימות

פונקציית הטיפול במשימות (push) לא דורשת עדכונים משמעותיים, אלא רק הפעלה. ההגדרה הזו רלוונטית ל-Task Queue או ל-Cloud Tasks. "הקוד הוא הקוד", כמו שאומרים. עם זאת, יש כמה שינויים קלים:

  1. מטען הייעודי (payload) של חותמת הזמן הועבר בדיוק כמו שהוא ל-Task Queue, אבל הוא קודד ב-JSON עבור Cloud Tasks ולכן צריך לנתח אותו ב-JSON כשהוא מגיע.
  2. קריאת ה-HTTP POST אל /trim עם Task Queue כללה MIMEtype משתמע של application/x-www-form-urlencoded, אבל ב-Cloud Tasks היא מוגדרת באופן מפורש כ-application/json, ולכן יש דרך שונה במקצת לחילוץ המטען הייעודי (payload).
  3. שימוש במנהל ההקשר של לקוח Cloud NDB API (העברה של מודול 2 אל Cloud NDB).

בהמשך מופיעים קטעי הקוד לפני ואחרי ביצוע השינויים האלה ב-task handler, ‏ trim():

לפני:

@app.route('/trim', methods=['POST'])
def trim():
    '(push) task queue handler to delete oldest visits'
    oldest = request.form.get('oldest', type=float)
    keys = Visit.query(
            Visit.timestamp < datetime.fromtimestamp(oldest)
    ).fetch(keys_only=True)
    nkeys = len(keys)
    if nkeys:
        logging.info('Deleting %d entities: %s' % (
                nkeys, ', '.join(str(k.id()) for k in keys)))
        ndb.delete_multi(keys)
    else:
        logging.info('No entities older than: %s' % time.ctime(oldest))
    return ''   # need to return SOME string w/200

אחרי:

@app.route('/trim', methods=['POST'])
def trim():
    '(push) task queue handler to delete oldest visits'
    oldest = float(request.get_json().get('oldest'))
    with ds_client.context():
        keys = Visit.query(
                Visit.timestamp < datetime.fromtimestamp(oldest)
        ).fetch(keys_only=True)
        nkeys = len(keys)
        if nkeys:
            logging.info('Deleting %d entities: %s' % (
                    nkeys, ', '.join(str(k.id()) for k in keys)))
            ndb.delete_multi(keys)
        else:
            logging.info(
                    'No entities older than: %s' % time.ctime(oldest))
    return ''   # need to return SOME string w/200

אין עדכונים ל-handler של האפליקציה הראשית root() או לתבנית האינטרנט templates/index.html.

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

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

פריסה ואימות של האפליקציה

פריסת האפליקציה באמצעות gcloud app deploy. הפלט צריך להיות זהה לאפליקציה של מודול 7, אבל צריך להבין שעברתם למוצר תור דחיפה (push queue) שונה לחלוטין, ולכן האפליקציה שלכם ניידת יותר מבעבר.

4aa8a2cb5f527079.png

הסרת המשאבים

כללי

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

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

  • console.cloud.google.com/storage/browser/LOC.artifacts.PROJECT_ID.appspot.com/containers/images
  • console.cloud.google.com/storage/browser/staging.PROJECT_ID.appspot.com
  • הקישורים לאחסון שלמעלה תלויים בPROJECT_ID ובמיקום *LOC*ation, לדוגמה, us אם האפליקציה מאוחסנת בארה"ב.

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

ספציפי ל-Codelab הזה

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

השלבים הבאים

כאן מסתיים תהליך ההעברה ממשימות push של תור משימות ב-App Engine אל Cloud Tasks. אם אתם רוצים להמשיך להעביר את האפליקציה הזו ל-Python 3 ולבצע העברה נוספת ל-Cloud Datastore מ-Cloud NDB, כדאי לעיין במודול 9.

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

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

בנוסף למודולים 3, 8 ו-9, יש מודולים נוספים להעברה שמתמקדים במעבר משירותים קודמים בחבילה של App Engine, שכדאי לשקול להשתמש בהם, כולל:

‫App Engine כבר לא הפלטפורמה היחידה ללא שרת ב-Google Cloud. אם יש לכם אפליקציית App Engine קטנה או אפליקציה עם פונקציונליות מוגבלת ואתם רוצים להפוך אותה למיקרו-שירות עצמאי, או אם אתם רוצים לפצל אפליקציה מונוליטית לכמה רכיבים שאפשר לעשות בהם שימוש חוזר, אלה סיבות טובות לשקול מעבר ל-Cloud Functions. אם יצירת קונטיינרים הפכה לחלק מתהליך העבודה של פיתוח האפליקציה, במיוחד אם היא כוללת צינור CI/CD (אינטגרציה רציפה/פריסה או מסירה רציפה), כדאי לשקול מעבר אל Cloud Run. התרחישים האלה מוסברים במודולים הבאים:

  • מעבר מ-App Engine ל-Cloud Functions: ראו מודול 11
  • מעבר מ-App Engine ל-Cloud Run: אפשר לעיין במודול 4 כדי להעביר את האפליקציה לקונטיינר באמצעות Docker, או במודול 5 כדי לעשות זאת בלי קונטיינרים, בלי ידע ב-Docker או בלי Dockerfiles

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

לא משנה איזה מודול העברה תבחרו, תוכלו לגשת לכל התוכן של Serverless Migration Station (סדנאות קוד, סרטונים, קוד מקור [אם זמין]) במאגר הקוד הפתוח שלו. במאגר README יש גם הנחיות לגבי ההעברות שכדאי לבצע וסדר רלוונטי של מודולי ההעברה.

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

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

בעיות או משוב לגבי Codelabs

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

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

בטבלה שלמטה מופיעים קישורים לתיקיות המאגר של מודול 7 (התחלה) ומודול 8 (סיום).

Codelab

‫Python 2

‫Python 3

מודול 7

קוד

קוד (לא מוצג במדריך הזה)

מודול 8 (ה-Codelab הזה)

קוד

(n/a)

משאבים באינטרנט

בהמשך מופיעים מקורות מידע באינטרנט שעשויים להיות רלוונטיים למדריך הזה:

תור משימות ב-App Engine ו-Cloud Tasks

‫App Engine NDB ו-Cloud NDB‏ (Datastore)

פלטפורמת App Engine

מידע אחר על Cloud

סרטונים

רישיון

עבודה זו מורשית תחת רישיון Creative Commons שמותנה בייחוס 2.0 כללי.