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

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

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

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

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

מה תלמדו

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

מה תצטרכו

סקר

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

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

2. רקע

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

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

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

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

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

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

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

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

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

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

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

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

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

במדריך הזה נסביר איך להתחיל להשתמש ב-Google Workspace, בין אם אתם משתמשים בגרסה שלכם או בגרסה שלנו. ב-codelab הזה מוסבר איך לבצע את ההעברה, ובסיום התהליך, התוצאה צריכה להיות דומה למה שמופיע בתיקיית המאגר FINISH של מודול 5.

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

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

3. (Re)Deploy baseline app

השלבים הנותרים שצריך לבצע עכשיו:

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

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

4. העברת אפליקציה לקונטיינר

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

אם אתם רוצים לדלג על לימוד Docker ולהפוך את אפליקציית App Engine שלכם לקונטיינר כדי להריץ אותה ב-Cloud Run או בכל פלטפורמה אחרת לאירוח קונטיינרים, הגעתם למקום הנכון. אם אתם רוצים ללמוד איך להשתמש ב-Docker כדי ליצור קונטיינרים לאפליקציות, תוכלו לעבור אל מודול 4 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 בלבד])

(n/a)

(n/a)

הפעלה

‫(n/a) או 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. בדף הזה במסמכי Cloud Run יש מידע נוסף על פריסה מקוד מקור באמצעות Buildpacks.

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

  • חבילות Buildpack: שורה ב-Procfile: web: python main.py
  • ‫Docker: שורה ב-Dockerfile: ENTRYPOINT ["python", "main.py"]

לצורך בדיקות והעלאה לסביבת Staging, אפשר פשוט להריץ את שרת הפיתוח של Flask מ-Python כמו בדוגמה שלמעלה, אבל מפתחים יכולים לבחור משהו חזק יותר בשביל Production, כמו דוגמת ההפעלה המהירה של Cloud Run שמשתמשת ב-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, לעומת זאת, צריך להגדיר שם שירות. לעומת זאת, בדומיין של App Engine‏ appspot.com מופיע מזהה הפרויקט, למשל https://PROJECT_ID.appspot.com, ואולי גם קיצור של מזהה האזור, למשל http://PROJECT_ID.REGION_ID.r.appspot.com.

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

אופציונלי: ניקוי

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

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

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

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

השלבים הבאים

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

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

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

App Engine migration module codelabs issues/feedback

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

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

בטבלה שלמטה מופיעים קישורים לתיקיות המאגר של מודול 2 ומודול 3 (התחלה) ומודול 5 (סיום). אפשר גם לגשת אליהם ממאגר המידע של כל ההעברות של App Engine codelab, שאפשר לשכפל או להוריד כקובץ ZIP.

Codelab

‫Python 2

‫Python 3

מודול 2

קוד

(קוד)

Module 3

(קוד)

קוד

מודול 5

(n/a)

קוד

משאבים של App Engine ו-Cloud Run

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