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

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

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

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

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

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

הדרישות

סקר

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

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

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

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

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

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

2. רקע

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. (Re)Deploy baseline app

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

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

a7a9d2b80d706a2b.png

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

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

הוספת SDK לקובץ requirements.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 לגמרי כי לאפליקציה הזו יש רק script handlers. אם לאפליקציה יש handlers סטטיים לקבצים, אל תשנו אותם ב-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, אין צורך להעתיק אותן או לבצע יצירת עותק מקוד של צד שלישי (vendoring), ולכן אין יותר פקודה pip install או תיקייה lib, אז אפשר למחוק אותה. סיכום:

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

כאן מסתיימים כל השינויים הנדרשים בהגדרות.

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

כדי לגשת לרוב השירותים הזמינים בחבילה בסביבת זמן הריצה של Python 3, צריך להשתמש בקטע קוד קצר שעוטף את אובייקט האפליקציה של ממשק כניסה לשרתי אינטרנט (WSGI) ב-main.py. פונקציית העטיפה היא 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-wrapping עבור מסגרות Python אחרות מופיעות במסמכי התיעוד.

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

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

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

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

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

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

a7a9d2b80d706a2b.png

הערות סופיות

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

הסרת המשאבים

כללי

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

השלבים הבאים

יש כמה אפשרויות מכאן:

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

כדי לגשת לשירותים אחרים בחבילה כמו Blobstore, ‏ Mail ו-Deferred, צריך לבצע שינויים נוספים בקוד. מודולים להעברה שמתמקדים במעבר משירותים קודמים בחבילה של 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. מקורות מידע נוספים

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

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

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

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

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

Codelab

‫Python 2

‫Python 3

מודול 1

קוד

לא רלוונטי

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

לא רלוונטי

‫code (mod1b-flask)

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

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

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

מסמכים כלליים בנושא App Engine

מידע אחר על Cloud

סרטונים

רישיון

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