יחידת לימוד 5: מעבר מ-Google App Engine ל-Cloud Run באמצעות Cloud Buildpacks

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

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

במדריך הזה תלמדו איך ליצור קונטיינרים לאפליקציות של App Engine לפריסה בשירות מנוהל של Cloud Run באמצעות Cloud Buildpacks, חלופה ל-Docker. Cloud Buildpacks יוצר קונטיינרים לאפליקציות בלי לנהל קובצי Dockerfile ואפילו לא לדעת דבר על Docker.

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

כאן מוסבר איך

  • יצירת קונטיינרים לאפליקציה באמצעות Cloud Buildpacks
  • פריסת קובצי אימג' של קונטיינרים ב-Cloud Run

מה צריך להכין

סקר

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

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

2. רקע

מערכות PaaS כמו App Engine ו-Cloud Functions מספקות לצוות ולאפליקציה שלכם אפשרויות נוחות רבות. לדוגמה, פלטפורמות ללא שרת (serverless) מאפשרות ל-SysAdmin/Devops להתמקד בפיתוח פתרונות. האפליקציה יכולה להתאים לעומס (auto-scaling) לפי הצורך, ולהקטין אותה לאפס באמצעות חיוב בתשלום לפי שימוש כדי לשלוט בעלויות, והיא משתמשת במגוון שפות פיתוח נפוצות.

עם זאת, הגמישות של קונטיינרים מעניינת גם את היכולת לבחור בכל שפה, בכל ספרייה ובכל תוכנה בינארית. Google Cloud Run מספק למשתמשים את המיטב משני העולמות, נוחות של שרת ללא שרת (serverless) והגמישות של קונטיינרים.

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

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

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

ההעברה כוללת את השלבים הבאים:

  1. הגדרה/עבודה מוקדמת
  2. יצירת קונטיינרים של האפליקציה
    • החלפת קובצי תצורה
    • שינוי קובצי אפליקציה

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

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

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

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

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

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

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

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

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

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

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

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

אחרי שתבצעו את השלבים האלה בהצלחה, תוכלו ליצור את הקונטיינרים.

4. יצירת קונטיינרים של האפליקציה

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

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

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

תיאור

App Engine

Docker

Buildpacks

הגדרות כלליות

app.yaml

Dockerfile

(service.yaml)

ספריות של צד שלישי

requirements.txt

requirements.txt

requirements.txt

הגדרות של צד שלישי

app.yaml (וגם appengine_config.py ו-lib [2.x-בלבד])

(לא רלוונטי)

(לא רלוונטי)

הפעלה

(לא רלוונטי) או app.yaml (אם נעשה שימוש ב-entrypoint)

Dockerfile

Procfile

התעלמות מקבצים

.gcloudignore וגם .gitignore

‫.gcloudignore, .gitignore וגם .dockerignore

.gcloudignore וגם .gitignore

לאחר שהאפליקציה שלכם בקונטיינרים, אפשר לפרוס אותה ל-Cloud Run. אפשרויות אחרות של פלטפורמות קונטיינרים ב-Google Cloud כוללות את Compute Engine, GKE ו-Anthos.

הגדרות כלליות

App Engine מפעיל את האפליקציה באופן אוטומטי, אבל Cloud Run לא מפעיל אותו. ל-Procfile יש תפקיד דומה לזה של ההוראה app.yaml entrypoint. באפליקציה לדוגמה שלנו, Procfile יריץ את הפקודה python main.py כדי להפעיל את שרת הפיתוח של Flask. אם רוצים, אפשר גם להשתמש בשרת אינטרנט בסביבת ייצור כמו gunicorn. אם רוצים, מוסיפים אותו ל-requirements.txt. מידע נוסף על פריסה מקוד מקור באמצעות Buildpacks זמין בדף המסמכים הזה ב-Cloud Run.

צריך רק להעביר את ההוראה app.yaml entrypoint אל Procfile. אם אין לך אפליקציה כזו, אפשר בינתיים להשתמש בשרת הפיתוח של Flask כי זו רק אפליקציית בדיקה לדוגמה כדי להכיר למשתמשים את ההעברה הזו. האפליקציה תהיה פקודת הפעלה ספציפית שאתם מכירים הכי טוב. בכיסוי, שירות Cloud Run יוצר service.yaml שנראה או פועל יותר כמו app.yaml. כדי לראות את service.yaml שנוצר באופן אוטומטי, צריך להיכנס לקישור כמו זה, אבל לשירות SVC_NAME ולשירות REGION: https://console.cloud.google.com/run/detail/REGION/SVC_NAME/yaml/view.

ספריות של צד שלישי

אין צורך לשנות את הקובץ requirements.txt. ה-Flask צריך להיות שם יחד עם ספריית הלקוח של Datastore (Cloud Datastore או Cloud NDB). אם ברצונך להשתמש בשרת HTTP אחר שתואם ל-WSGI, כמו Gunicorn — הגרסה הנוכחית בזמן הכתיבה היא 20.0.4 — אז צריך להוסיף את gunicorn==20.0.4 ל-requirements.txt.

הגדרות של צד שלישי

ב-buildpacks אין תמיכה ב-Python 2 ולכן אנחנו לא דנים בנושא הזה כאן. אפליקציות Python 3 שפועלות בקונטיינרים ב-Cloud Run דומות לאפליקציות Python 3 App Engine שבהן צריך לציין ספריות של צד שלישי ב-requirements.txt.

הפעלה

למשתמשי Python 3 יש אפשרות להמיר את קובצי ה-app.yaml שלהם כך שיכללו הוראות entrypoint במקום script: auto בקטע handlers. אם אתם משתמשים ב-entrypoint ב-Python 3 שלכם app.yaml, הוא ייראה בערך כך:

runtime: python38
entrypoint: python main.py

ההוראה entrypoint מנחה את App Engine איך להפעיל את השרת. אפשר להעביר אותו כמעט ישירות אל Procfile. סיכום המיקום שבו תבוצע הוראה של נקודת כניסה בין שתי הפלטפורמות: תרגום ישיר לנתונים שבהמשך; מציג גם את המקבילה ל-Docker לידיעה:

  • Buildpacks: שורה ב-Procfile: web: python main.py
  • Docker: שורה ב-Dockerfile: ENTRYPOINT ["python", "main.py"]

לביצוע בדיקות ו-staging, קל להריץ את שרת הפיתוח של Flask מ-Python כמו שלמעלה, אבל המפתחים יכולים לבחור להשתמש ביכולות מתקדמות יותר לצורכי ייצור, כמו דוגמה של Cloud Run Quickstart שמשתמשת ב-gunicorn.

קובצי האפליקציה

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

if __name__ == '__main__':
    import os
    app.run(debug=True, threaded=True, host='0.0.0.0',
            port=int(os.environ.get('PORT', 8080)))

5. פיתוח ופריסה

כשההגדרות של App Engine הוחלפו ב-Buildpacks ובעדכונים של קובצי המקור, אתם מוכנים להתחיל לעבוד ב-Cloud Run. לפני זה נדון בקצרה על שירותים.

שירותים לעומת אפליקציות

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

אלא אם אפליקציית App Engine הורכבה מכמה שירותים, באמת לא צריך לתת שמות כלשהם בעת פריסת האפליקציות. זה משתנה ב-Cloud Run, כשצריך להמציא את שם השירות. ואילו הדומיין appspot.com של App Engine כולל את מזהה הפרויקט שלו, למשל, https://PROJECT_ID.appspot.com, ואולי זהו קיצור של מזהה אזור, למשל http://PROJECT_ID.REGION_ID.r.appspot.com

עם זאת, הדומיין של שירות Cloud Run כולל את שם השירות, קיצור המזהה של האזור וגיבוב (hash), אבל לא את מזהה הפרויקט, למשל, https://SVC_NAME-HASH-REG_ABBR.a.run.app. השורה התחתונה, התחל לחשוב על שם השירות!

פריסת השירות

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

$ gcloud run deploy SVC_NAME --source .
Please choose a target platform:
 [1] Cloud Run (fully managed)
 [2] Cloud Run for Anthos deployed on Google Cloud
 [3] Cloud Run for Anthos deployed on VMware
 [4] cancel
Please enter your numeric choice:  1

To specify the platform yourself, pass `--platform managed`. Or, to make this the default target platform, run `gcloud config set run/platform managed`.

Please specify a region:
 [1] asia-east1
 [2] asia-east2
 [3] asia-northeast1
 [4] asia-northeast2
 [5] asia-northeast3
 [6] asia-south1
 [7] asia-southeast1
 [8] asia-southeast2
 [9] australia-southeast1
 [10] europe-north1
 [11] europe-west1
 [12] europe-west2
 [13] europe-west3
 [14] europe-west4
 [15] europe-west6
 [16] northamerica-northeast1
 [17] southamerica-east1
 [18] us-central1
 [19] us-east1
 [20] us-east4
 [21] us-west1
 [22] us-west2
 [23] us-west3
 [24] us-west4
 [25] cancel
Please enter your numeric choice: <select your numeric region choice>

To make this the default region, run `gcloud config set run/region REGION`.

Allow unauthenticated invocations to [SVC_NAME] (y/N)?  y

Building using Buildpacks and deploying container to Cloud Run service [SVC_NAME] in project [PROJECT_ID] region [REGION]
✓ Building and deploying... Done.
  ✓ Uploading sources...
  ✓ Building Container... Logs are available at [https://console.cloud.google.com/cloud-build/builds/BUILD-HASH?project=PROJECT_NUM].
  ✓ Creating Revision...
  ✓ Routing traffic...
Done.
Service [SVC_NAME] revision [SVC_NAME-00014-soc] has been deployed and is serving 100 percent of traffic.
Service URL: https://SVC_NAME-HASH-REG_ABBR.a.run.app

צריך להיכנס לכתובת ה-URL שצוינה בדפדפן כדי לאשר שהפריסה הצליחה!

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

$ gcloud beta run deploy SVC_NAME --source . --platform managed --region REGION --allow-unauthenticated

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

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

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

אפליקציית visitme

הקוד אמור עכשיו להתאים למה שמופיע בתיקיית המאגר של מודול 5. מזל טוב, השלמת את שיעור ה-Codelab של יחידת הלימוד הזו.

אופציונלי: הסרת המשאבים

מה לעשות כדי שלא נחייב אתכם עד שתהיו מוכנים לעבור ל-Codelab הבא של ההעברה? מכיוון שאתם משתמשים עכשיו במוצר אחר, הקפידו לעיין במדריך התמחור של Cloud Run.

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

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

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

השלבים הבאים

מעולה! הוספת את האפליקציה לקונטיינרים, וזהו סיכום של המדריך הזה. לאחר מכן, השלב הבא הוא ללמוד איך לבצע את אותו הדבר עם Docker ב-Codelab של מודול 4 (קישור למטה) או לבצע העברה אחרת של App Engine:

  • מודול 4: מעבר ל-Cloud Run באמצעות Docker
    • יצירת קונטיינרים לאפליקציה להרצה ב-Cloud Run באמצעות Docker
    • מאפשרת להמשיך להשתמש ב-Python 2
  • מודול 7: תורים של משימות דחיפה ב-App Engine (נדרש אם משתמשים ב[push] תורי משימות)
    • הוספת משימות דחיפה ל-App Engine taskqueue לאפליקציית מודול 1
    • הכנת המשתמשים למעבר אל Cloud Tasks במודול 8
  • מודול 3:
    • מודרניזציה של הגישה ל-Datastore מ-Cloud NDB ל-Cloud Datastore
    • הספרייה הזו משמשת לאפליקציות של Python 3 App Engine ולאפליקציות שאינן של App Engine.
  • מודול 6: מעבר ל-Cloud Firestore
    • כדי לקבל גישה לתכונות של Firebase צריך לעבור ל-Cloud Firestore
    • אומנם Cloud Firestore תומך ב-Python 2, אבל ה-Codelab הזה זמין רק ב-Python 3.

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

בעיות/משוב על Codelabs עם מודול ההעברה של App Engine

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

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

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

Codelab

ֶPython 2

Python 3

יחידת לימוד 2

קוד

(קוד)

יחידת לימוד 3

(קוד)

קוד

יחידת לימוד 5

(לא רלוונטי)

קוד

משאבי App Engine ו-Cloud Run

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