הרחבת התמיכה בשירותים בחבילה של App Engine: חלק 1 (מודול 17)

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

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

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

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

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

למה תזדקק?

סקר

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

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

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

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

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

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

2. רקע

שירות App Engine המקורי הושק ב-2008 וכללו קבוצה של ממשקי API מדור קודם (שנקראים כיום שירותים ארוזים) כדי להקל על מפתחים ליצור ולפרוס אפליקציות ברחבי העולם. השירותים האלה כוללים את Datastore, Memcache ו- Task Queue. כשהדבר נוח, המשתמשים החלו לחשוש מהניידות של האפליקציות שלהם במהלך השימוש בממשקי API קנייניים שמחברים אותם ל-App Engine. הם רצו שהאפליקציות שלהם יהיו ניידות יותר. העובדה הזו, יחד עם העובדה שרבים מהשירותים הכלולים בחבילה הפכו למוצרי ענן עצמאיים, הובילה את צוות App Engine להשיק ב-2018 את פלטפורמת הדור הבא בלעדיהם.

קדימה, מפתחים את Python 2 שרוצים לשדרג ל-Python 3. אפליקציה בגודל פי 2.0 שנעשה בה שימוש בשירותים בחבילה חייבת לבצע מיגרציה מהשירותים האלה לפני שאפשר היה לנייד את האפליקציות שלה אל 3.x. מצב כזה מייצג שתי העברות כפויות אחת אחרי השנייה, מה שעלול להיות מאתגרות. כדי לסייע במעבר, צוות App Engine הציג בסתיו 2021 "חור תולעת" בעבר, כדי לאפשר לאפליקציות שפועלות בסביבות זמן ריצה של הדור הבא לגשת לרבים מהשירותים הכלולים בחבילה. הגרסה הזו לא כוללת את כל השירותים שזמינים בסביבות זמני הריצה המקוריות, אבל יש נגנים מובילים כמו Datastore, Task Queue ו-Memcache.

ה-Codelab הזה מדגים את השינויים הנדרשים כדי לשדרג את האפליקציה ל-Python 3 תוך המשך השימוש בשירותים הכלולים בחבילה. המטרה היא שהאפליקציות שלכם יפעלו בסביבות זמני הריצה האחרונות, כך שתוכלו לעבור משירותים בחבילה לשירותים עצמאיים ב-Cloud או לחלופות של צד שלישי בלוחות הזמנים שלכם, במקום לחסום את האפשרות לשדרוג של 3.x. המעבר משירותים בחבילה אינו נדרש יותר, אך הדבר מספק יותר ניידות וגמישות מבחינת המקומות שבהם האפליקציות יכולות להתארח, כולל מעבר לפלטפורמות שעשויות לשרת טוב יותר את עומסי העבודה שלכם, או פשוט להישאר ב-App Engine במהלך השדרוג לגרסה מודרנית יותר של שפה, כפי שמתואר בהמשך.

האפליקציה לדוגמה של מודול 1 ב-Python 2 משתמשת בשירות בחבילה Datastore דרך App Engine NDB. האפליקציה כבר העבירה frameworks מ-webapp2 ל-Flask – הפעולה הושלמה ב-Codelab של מודול 1 – אבל השימוש ב-Datastore נשאר ללא שינוי.

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

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

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

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

  1. הגדרת פרויקט ב-Cloud
  2. אחזור של אפליקציה בסיסית לדוגמה
  3. (מחדש) פריסה ואימות של אפליקציה בסיסית

השלבים האלה יעזרו לכם לוודא שאתם מתחילים עם קוד תקין.

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

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

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

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

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

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

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

מבצעים את השלבים הבאים כדי לפרוס מחדש את אפליקציית מודול 1:

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

a7a9d2b80d706a2b.png

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

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

צריך להוסיף SDK לקובץ הדרישות.txt

זמן הריצה ל-Python 3 של App Engine מפחית משמעותית את התקורה על השימוש בספריות של צד שלישי. כל מה שצריך הוא לרשום אותם בrequirements.txt. כדי להשתמש בשירותים הכלולים ב-Python 3, צריך להוסיף אליה את חבילת App Engine SDK, appengine-python-standard. חבילת ה-SDK מאחדת את Flask ממודול 1:

flask
appengine-python-standard

עדכון app.yaml

כדי להחיל שינויי הגדרות על קובץ app.yaml:

  1. מחליפים את ההוראה runtime בגרסת Python 3 הנתמכת. לדוגמה, מציינים את python310 עבור Python 3.10.
  2. מוחקים את ההוראות threadsafe וגם את api_version כי לא נעשה בהן שימוש ב-Python 3.
  3. למחוק לגמרי את הקטע handlers כי באפליקציה הזו יש רק רכיבי handler של סקריפטים. אם לאפליקציה יש רכיבי handler של קבצים סטטיים, צריך להשאיר אותם ללא שינוי ב-handlers.
  4. זמן הריצה של Python 3 לא תומך בספריות מובנות של צד שלישי כמו בסביבת זמן הריצה של Python 2. אם באפליקציה שלך יש קטע libraries ב-app.yaml, צריך למחוק את הקטע כולו. (חבילות נדרשות רק ב-requirements.txt, כמו ספריות לא מובנות). באפליקציה לדוגמה שלנו אין קטע בשם libraries, לכן כדאי לעבור לשלב הבא.
  5. צריך ליצור הוראת app_engine_apis שמוגדרת ל-true כדי להשתמש בה – היא תואמת להוספת חבילת App Engine SDK ל-requirements.txt שלמעלה.

סיכום של השינויים הנדרשים במסגרת app.yaml:

לפני:

runtime: python27
threadsafe: yes
api_version: 1

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

אחרי:

runtime: python310
app_engine_apis: true

קובצי תצורה אחרים

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

  • מחיקת קובץ אחד (appengine_config.py)
  • מחיקת התיקייה lib

הגענו לסוף של כל השינויים הנחוצים בהגדרות.

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

כדי לגשת לרוב השירותים החבילות הזמינים בסביבת זמן הריצה של Python 3, נדרש קטע קוד קצר שעוטף את אובייקט האפליקציה Web Server Gateway Interface (WSGI) ב-main.py. פונקציית wrapper היא google.appengine.api.wrap_wsgi_app(), ומשתמשים בה על ידי ייבוא שלה ועטיפת אובייקט WSGI איתה. צריך לבצע את השינויים הבאים כדי לשקף את העדכון הנדרש ל-Flask ב-main.py:

לפני:

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 wrap_wsgi_app
from google.appengine.ext import ndb

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

במסמכי העזרה אפשר למצוא דוגמאות לאריפת WSGI של frameworks אחרות של Python.

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

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

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

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

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

פורסים את אפליקציית Python 3 עם gcloud app deploy ומוודאים שהאפליקציה פועלת כמו ב-Python 2. הפונקציונליות לא משתנה, לכן הפלט אמור להיות זהה לאפליקציית מודול 1:

a7a9d2b80d706a2b.png

הערות סופיות

מזל טוב, עשית את הצעד הראשון להעברת אפליקציות 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 הזה. אפשר לקרוא מידע נוסף במסמכי התיעוד של כל מוצר:

השלבים הבאים

ניתן להמשיך מכאן בכמה הנחיות:

  1. עדכון הקוד באמצעות שירותים בחבילה שמחייבים שינויים נוספים בקוד
  2. מעבר משירותים בחבילה למוצרים עצמאיים ב-Cloud
  3. מעבר מ-App Engine לפלטפורמה אחרת ללא שרת ענן

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

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

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

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

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

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

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

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

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

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

בטבלה למטה מופיעים הקישורים לתיקיות המאגר של מודול 1 (START) ומודול 1ב (FINISH). אפשר לגשת אליהם גם מהמאגר לכל העברות Codelab ב-App Engine.

Codelab

ֶPython 2

ֶPython 3

יחידת לימוד 1

קוד

לא רלוונטי

יחידת לימוד 17 (Codelab זה)

לא רלוונטי

code (mod1b-flask)

מקורות מידע אונליין

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

שירותים בחבילה של App Engine

מסמכים כלליים של App Engine

מידע אחר בענן

סרטונים

רישיון

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