דף זה תורגם על ידי Cloud Translation API.

איך משתמשים ב-Memcache של App Engine באפליקציות Flask (מודול 12)

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

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

ב-Codelab הזה מוסבר איך לכלול את App Engine Memcache ואיך להשתמש בו באפליקציה לדוגמה מ-Module 1 codelab. אנחנו מוסיפים שימוש ב-Memcache במדריך מודול 12 ואז עוברים ל-Cloud Memorystore בהמשך במודול 13.

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

שימוש בספרייה/בממשק ה-API של Memcache של App Engine
הוספת שמירה במטמון לאפליקציית NDB בסיסית של Python 2 Flask App Engine NDB

למה תזדקק?

פרויקט ב-Google Cloud Platform עם חשבון פעיל לחיוב ב-GCP
מיומנויות בסיסיות ב-Python
ידע בעבודה עם פקודות Linux נפוצות
ידע בסיסי פיתוח ופריסה של אפליקציות App Engine
אפליקציית App Engine של מודול פעיל 1 (צריך להשלים את ה-codelab שלה [מומלץ] או להעתיק את האפליקציה מהמאגר)

סקר

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

לקריאה בלבד

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

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

מתחילים

בינונית

בקיאים

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

מתחילים

בינונית

בקיאים

2. רקע

כדי לבצע העברה מ-Memcache של App Engine, צריך להוסיף את השימוש שלו לאפליקציית Flask ו-App Engine NDB הקיימת שנוצרת באמצעות Codelab של מודול 1. האפליקציה לדוגמה מציגה את עשרת הביקורים האחרונים של המשתמש. אם אותו משתמש מרענן את הדפדפן שלו, לא מומלץ ליצור באופן קבוע ישויות ביקור חדשות ולאחזר את הביקורים האחרונים מ-Datastore, לכן נשמור את הביקורים האחרונים האלה במטמון.

אם אותו מבקר מגיע לדף, הביקורים האלה מוחזרים מהמטמון. אם משתמש חדש מבקר באתר או חולף שעה, המטמון מתרוקן ומוחלף ברשומות האחרונות (כמו ביקור חדש שנרשם). באמצעות השילוב של Memcache ב-App Engine, נוכל להעביר אותו אל Cloud Memorystore ב-codelab הבא (מודול 13).

המדריך הזה כולל את השלבים הבאים:

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

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

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

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

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

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

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

בין אם אתם משתמשים בקוד של יחידת הלימוד שלכם או שלנו, קוד המודול 1 הוא המקום שבו נתחיל. ה-Codelab הזה ינחה אותך לאורך כל השלבים, ויסתיים עם קוד שדומה למה שמופיע בתיקיית המאגר של מודול 11 (FINISH).

START: תיקיית מודול 1 (Python 2)
FINISH: תיקיית מודול 12 (Python 2)
כל המאגר (לשכפול או הורדה של קובץ ZIP)

הספרייה של קובצי Module 1 STARTing (שלכם או שלנו) אמורה להיראות כך:

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

3. (Re) פריסת אפליקציות בסיסיות

שאר השלבים לפני העבודה שצריך לבצע עכשיו:

כדאי להכיר מחדש את כלי שורת הפקודה gcloud
פורסים מחדש את האפליקציה לדוגמה באמצעות gcloud app deploy
אישור שהאפליקציה פועלת ב-App Engine ללא בעיות

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

4. עדכון ההגדרות האישיות

אין צורך לבצע שינויים בקובצי התצורה הרגילים של App Engine (app.yaml, requirements.txt, appengine_config.py).

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

מאחר שאנחנו מוסיפים רק API של App Engine, לא נעשה שימוש בחבילות חיצוניות. כלומר, אין צורך לעדכן קובצי תצורה (app.yaml, requirements.txt, appengine_config.py). יש רק קובץ אפליקציה אחד, main.py, כך שכל השינויים בקטע הזה ישפיעו רק על הקובץ הזה.

יבוא

השלב החשוב ביותר הוא ייבוא ספריית ה-Memcache, google.appengine.api.memcache. מכיוון שנשמור במטמון את הביקורים האחרונים למשך שעה, נוסיף גם קבוע למספר השניות בשעה. בהמשך תוכלו לראות איך הקוד נראה לפני השינוי הזה:

לפני:

from flask import Flask, render_template, request
from google.appengine.ext import ndb

app = Flask(__name__)

אחרי:

from flask import Flask, render_template, request
from google.appengine.api import memcache
from google.appengine.ext import ndb

app = Flask(__name__)
HOUR = 3600

הוספת שמירה במטמון באמצעות התמיכה ב-Memcache

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

הגדרת הביקור הנוכחי והתקשרות אליו visitor
ניסיון לאחזר מהמטמון את visits העדכני ביותר
אם המטמון ריק או אם המבקר האחרון (visits[0]['visitor']) שונה מ-visitor הנוכחי: אחסן את הביקור החדש ביותר הזה, אחזר את הביקורים האחרונים ושמור אותם במטמון למשך שעה.
הצגת visits למשתמש באמצעות תבנית האינטרנט

ריכזנו כאן את לפני ואחרי העדכונים:

לפני:

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

אחרי:

@app.route('/')
def root():
    'main application (GET) handler'
    # check for (hour-)cached visits
    ip_addr, usr_agt = request.remote_addr, request.user_agent
    visitor = '{}: {}'.format(ip_addr, usr_agt)
    visits = memcache.get('visits')

    # register visit & run DB query if cache empty or new visitor
    if not visits or visits[0]['visitor'] != visitor:
        store_visit(ip_addr, usr_agt)
        visits = list(fetch_visits(10))
        memcache.set('visits', visits, HOUR)  # set() not add()

    return render_template('index.html', visits=visits)

לפניכם ייצוג גרפי של השינויים שבוצעו:

הושלמו כל השינויים הנדרשים להוספת השימוש ב-App Engine memcache לאפליקציה לדוגמה של מודול 1. בואו נבנה ונפרוס את האפליקציה הזו כדי לראות שהיא עובדת!

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

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

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

פורסים מחדש את האפליקציה באמצעות gcloud app deploy ומוודאים שהאפליקציה פועלת. הקוד אמור עכשיו להתאים למידע שמופיע ב-FINISH, בתיקיית המודול 12. הפלט אמור להיות זהה לאפליקציית מודול 1 שפרסתם קודם:

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

מזל טוב על השלמת השימוש ב-Codelab במודול 12 על הוספת השימוש בשירות memcache של App Engine לאפליקציה לדוגמה שלנו. עכשיו יש אפשרות לנייד את אפליקציית Python 2 הזו ל-Python 3 בשלב הבונוס.

הסרת המשאבים

כללי

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

גילוי נאות מלא, פריסה בפלטפורמת מחשוב ללא שרת (serverless) של Google Cloud, כמו App Engine, כרוכה בעלויות נמוכות של build ואחסון. ל-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*שלך, לדוגמה, "us" אם האפליקציה מתארחת בארה"ב.

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

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

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

שירות ה-Memcache של App Engine זמין בשתי טעמים שונים, כל אחת עם מבנה תמחור משלה, כך שצריך לעקוב אחרי השימוש הזה בקשר לחיוב.
שירות App Engine Datastore ניתן על ידי Cloud Datastore (Cloud Firestore במצב Datastore), שגם לו יש תוכנית ללא תשלום; בדף התמחור שלו יש מידע נוסף.

השלבים הבאים

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

Cloud Memorystore אינו ללא שרת (serverless). המשמעות היא שצריך להקצות שרת למטמון. גם ל-Cloud Memorystore אין תוכנית ללא תשלום. שני הגורמים האלה יכולים להשפיע באופן משמעותי על העלות.
Cloud Memorystore תומך בצמד של מנגנוני אחסון בסיסיים שונים (מנועי שמירה במטמון), Redis ו-Memcached.
ב-Cloud Memorystore (ל-Redis) יש תכונות עשירות ומעמיקות יותר בהשוואה ל-Memcache של App Engine.
כדי להשתמש ב-Cloud Memorystore, צריך להגדיר שרת Cloud Memorystore, להוסיף אותו לרשת Google Cloud VPC ולאחר מכן לבקש מאפליקציית App Engine להשתמש ברשת הזו כדי לתקשר עם שרת Memorystore.

אם אינך רוצה להשתמש בכל התכונות שזמינות ב-Cloud Memorystore או שיש לך חשש לגבי ההשפעות שלהן על העלות, אפשר להישאר ב-App Engine Memcache.

מעבר למודול 13 כולל מגוון רחב של העברות אפשריות אחרות כמו Cloud NDB ו-Cloud Datastore, או Cloud Tasks. יש גם העברות בין מוצרים ל-Cloud Run ול-Cloud Functions. אפשר למצוא את כולם במאגר ההעברה.

שלב אפשרי נוסף הוא מעבר ל-Python 3, שאותו אפשר למצוא בקטע הבא כשלב אופציונלי.

7. בונוס: העברה ל-Python 3

סקירה כללית

החלק הזה מורכב מתוכן בונוס אופציונלי שמעביר את אפליקציית מודול 12 ל-Python 3 שסיימנו עכשיו. אנחנו מתחילים בהגדרה ואחריה האפליקציה.

מפשטים את app.yaml

אחד היתרונות של סביבת זמן הריצה של Python 3 הוא שאפשר לפשט משמעותית את app.yaml.

לפני:

בהמשך מופיע פירוט של app.yaml בסיכום יחידת לימוד 12:

runtime: python27
threadsafe: yes
api_version: 1

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

בגלל שסביבת זמן הריצה של Python 3 מחייבת ש-frameworks של אינטרנט יעשו ניתוב משלהן, צריך לשנות את כל הגורמים המטפלים בנתיבים ב-app.yaml ל-auto. אם לא מוצגים קבצים סטטיים, המשתמשים יכולים פשוט להסיר את כל הקטע של handlers:. בנוסף, ההוצאה משימוש של threadsafe וגם של api_version הוצאו משימוש.

אחרי:

עם השינויים הנדרשים שמתוארים עכשיו, זהו ה-app.yaml החלופי ל-Python 3:

runtime: python39
app_engine_apis: true

השורה היחידה שדורשת הסבר היא app_engine_apis: true. כשהשירותים מהדור הקודם של App Engine הפכו לזמינים עבור זמני ריצה מדור שני ב-2021, סביבות מסוימות, כולל Python 3, מחייבות אתחול אתחול נוסף כדי לגשת לממשקי ה-API האלה כמו ndb, taskqueue ו-memcache. השורה הזו בהגדרות האישיות משרתת את המטרה הזו.

עדכון הדרישות.txt

נדרשת אתחול נוסף של ממשקי ה-API המקוריים ב-requirements.txt: יש לכלול גישה ל-SDK החדש של App Engine.

לפני:

בהמשך מופיע פירוט של app.yaml בסיכום יחידת לימוד 12:

flask

אחרי:

פשוט מוסיפים את App Engine Python SDK ומקבלים את הדברים הבאים:

flask
appengine-python-standard

מחיקת appengine_config.py ו-lib

סביבות זמן ריצה של App Engine מהדור הבא חידשו את השימוש בחבילות של צד שלישי:

ספריות מובנות הן ספריות שנבדקו על ידי Google וזמינות בשרתי App Engine, כנראה כי הן מכילות קוד C/C++ שהמפתחים לא מורשים לפרוס בענן – הן כבר לא זמינות בסביבות זמני הריצה של הדור השני.
אין יותר צורך להעתיק ספריות לא מובנות (שנקראות לפעמים 'ספק' או 'קיבוץ עצמי') בסביבות זמני הריצה של הדור השני. במקום זאת, הם צריכים להופיע ב-requirements.txt, שם מערכת ה-build מתקינה אותם באופן אוטומטי בזמן הפריסה.

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

לא לכלול ספריות של צד שלישי באריזה עצמית או בהעתקה. צריך לרשום אותם ב-requirements.txt
לא pip install בתוך תיקייה מסוג lib, כלומר אין תקופה של lib תיקייה
אין רישום של ספריות מובְנות של צד שלישי (כלומר, לא בקטע libraries) ב-app.yaml; צריך לרשום אותם ב-requirements.txt
אין ספריות של צד שלישי להפניה מהאפליקציה שלך. פירוש הדבר שאין קובץ appengine_config.py

הדרישה היחידה למפתחים היא להציג את כל הספריות הרצויות של צד שלישי ב-requirements.txt.

צריך לעדכן את האפליקציה כדי להשתמש ב-SDK של App Engine

כפי שצוין למעלה, צריך לבצע שינויים מסוימים באפליקציות Python 3 כדי לגשת לשירותים בחבילה של App Engine:

מקבץ App Engine SDK (ב-requirements.txt)
הפעלת App Engine SDK (ב-app.yaml)
גלישת אובייקט WSGI (ב-main.py)

הצמד הראשון הושלם למעלה, לכן הדרישה האחרונה היא לעדכן את main.py.

לפני:

בהמשך מופיע קוד Python 2 main.py בסיכום יחידת לימוד 12:

from flask import Flask, render_template, request
from google.appengine.api import memcache
from google.appengine.ext import ndb

app = Flask(__name__)
HOUR = 3600

אחרי:

ליציאת Python 3, מייבאים את ה-SDK ועוטפים את האובייקט של אפליקציית Flask (ה-SDK wrapper), והתוצאה שמתקבלת היא:

from flask import Flask, render_template, request
from google.appengine.api import memcache, wrap_wsgi_app
from google.appengine.ext import ndb

app = Flask(__name__)
app.wsgi_app = wrap_wsgi_app(app.wsgi_app)
HOUR = 3600

המפתחים צריכים לבצע את השינויים האלה באפליקציות Python שלהם כשמעבירים מ-2.x ל- 3.x כדי לגשת לשירותים הכלולים. אם אתם לא משתמשים ב-Flask, יש גם דוגמאות של ג'נגו ופירמידה ב-Docs. אם קוד Python 2 שלכם הוא לא אפליקציית אינטרנט, רק הוספה של חבילת ה-SDK אמורה להספיק בזמן ההעברה ל-Python 3. קוד האפליקציה שלנו תוכנן במקור לפעול בגרסאות 2 ו-3 של Python, כך שאין צורך בשינויי תאימות נוספים.

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

לאחר השלמת השינויים שלמעלה, תוכלו לפרוס את האפליקציה המעודכנת לדוגמה. (אין בעיה כשפורסים גרסת Python 3 של האפליקציה במקום גרסת Python 2 המקורית באותו פרויקט ב-GCP). התנהגות האפליקציה צריכה להישאר ללא שינוי. אם אתם צריכים להשוות את האפליקציה המעודכנת שלכם לאפליקציה שלנו, תוכלו לעיין בתיקיית מודול 12b במאגר ההעברה. למידע נוסף על התמיכה בשירותים בחבילה של App Engine בסביבות זמני הריצה האחרונות, כמו Python 3, אפשר לעיין בהודעה על השקת התכונות וגם בקוד Lab של מודול 17.

מזל טוב, סיימת את שלב הבונוס במודול 12! קראו גם את המסמכי העזרה בנושא הכנת קובצי תצורה לסביבת זמן הריצה של Python 3. מעיינים בקטע 'סיכום/ניקוי' שלמעלה כדי לראות את השלבים הבאים ואת הניקוי.

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

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

משוב או בעיות ב-Codelab

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

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

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

Codelab	ֶPython 2	ֶPython 3
יחידת לימוד 1	קוד	code (לא מוצג במדריך הזה)
יחידת לימוד 12 (Codelab זה)	קוד	קוד

הפניות אונליין

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

App Engine

Cloud Memorystore ו-Cloud Datastore

מידע אחר בענן

Python ב-Google Cloud Platform
ספריות הלקוח של Google Cloud Python
"חינם תמיד" ב-Google Cloud שכבה
Google Cloud SDK (כלי שורת הפקודה gcloud)
כל משאבי העזרה של Google Cloud

סרטונים

רישיון

היצירה הזו בשימוש ברישיון Creative Commons Attribution 2.0 גנרי.