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

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

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

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

הערה: אחד האתגרים ב-Docker הוא יצירת Dockerfile יעיל. קובצי אימג' של קונטיינרים שלא עברו אופטימיזציה לוקח יותר זמן לבנות, לפרוס, להפעיל ולהריץ. ‫Cloud Buildpacks הם אלטרנטיבה ל-Docker. הם תואמים למפרט הפתוח של Buildpacks Cloud Native, משתמשים באינטרוספקציה כדי לקבוע את התלות של האפליקציה ויוצרים את קובצי האימג' של הקונטיינרים היעילים ביותר שאפשר. אם אתם חדשים בתחום הקונטיינרים או שאתם רוצים להימנע מלימוד של עוד מערכת אקולוגית, אתם יכולים לדלג על המדריך הזה וללמוד איך להפוך את האפליקציה שלכם לקונטיינר באמצעות Cloud Buildpacks, בעזרת מודול 5 של ה-codelab: מעבר מ-Google App Engine ל-Cloud Run באמצעות Cloud Buildpacks.

מה תלמדו

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

מה תצטרכו

• פרויקט ב-Google Cloud Platform עם:
  • חשבון לחיוב פעיל ב-GCP
  • App Engine מופעל
• מיומנויות בסיסיות ב-Python
• ידע מעשי בפקודות נפוצות של Linux
• ידע בסיסי בפיתוח ופריסה של אפליקציות App Engine
• מומלץ: להשלים את ה-Codelab של מודול 2 או את ה-Codelab של מודול 3
• אפליקציית App Engine פעילה שמוכנה להעברה לקונטיינר
  • ‫Python 2: דוגמה ל-Cloud NDB ביחידת לימוד 2
  • ‫Python 3: Module 3 Cloud Datastore sample

סקר

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

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

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

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

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

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

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

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

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

בין אם משתמשים בקוד שלכם או בקוד שלנו, הקוד של מודול 2 הוא המקום שבו נתחיל בגרסת Python 2 של המדריך הזה, ובאופן דומה, הקוד של מודול 3 הוא המקום שבו נתחיל בגרסת Python 3. ב-codelab של מודול 4 מוסבר כל שלב, ובסיום התהליך אמור להתקבל קוד שדומה לאחת מתיקיות המאגר של מודול 4 (FINISH), בהתאם לאפשרויות שתבחרו.

• ‫Python 2 (אפליקציית Cloud NDB)
  • התחלה: קוד מודול 2
  • סיום: קוד מודול 4
• ‫Python 3 (אפליקציית Cloud Datastore)
  • התחלה: קוד מודול 3
  • סיום: קוד מודול 4
• כל המאגר (לשיבוט או להורדה של קובץ ZIP)

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

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

אם אתם משתמשים בקוד משלכם של מודול 2 (2.x), תהיה לכם גם תיקייה בשם lib. לא משתמשים ב-lib או ב-appengine_config.py ב-Python 3, והקוד ההתחלתי של מודול 3 (3.x) צריך להיראות כך:

$ 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. אפשר גם לעבור על ה-codelab של מודול 5 (זהה לזה אבל עם Cloud Buildpacks) אחרי כן. אפליקציית הדוגמה הבסיסית שלנו קלה מספיק כדי למנוע חלק מהבעיות שצוינו למעלה בנושא Dockerfile.

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

תיאור	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 פירושה החלפת app.yaml ב-Dockerfile שמפרט איך לבנות ולהפעיל את הקונטיינר. ב-App Engine, האפליקציה מופעלת אוטומטית, אבל ב-Cloud Run היא לא מופעלת אוטומטית. לשם כך נועדו הפקודות Dockerfile ENTRYPOINT ו-CMD. מידע נוסף על Dockerfile זמין בדף הזה במסמכי התיעוד של Cloud Run. אפשר גם לראות דוגמה לשימוש ב-Dockerfile כדי ליצור gunicorn.

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

מחיקה של app.yaml ויצירה של Dockerfile

לא נעשה שימוש ב-app.yaml בקונטיינרים, לכן צריך למחוק אותו עכשיו. קובץ התצורה של מאגר התגים הוא Dockerfile, ובאפליקציה לדוגמה שלנו נדרש רק קובץ מינימלי. יוצרים את Dockerfile עם התוכן הזה, ומחליפים את NNN ב-2 או ב-3, בהתאם לגרסת Python שבה אתם משתמשים:

FROM python:NNN-slim
WORKDIR /app
COPY . .
RUN pip install -r requirements.txt
ENTRYPOINT ["python", "main.py"]

רוב הקוד Dockerfile מציין איך ליצור את מאגר התגים חוץ מENTRYPOINT שמציין איך להפעיל את מאגר התגים. במקרה הזה, הקוד קורא ל-python main.py כדי להפעיל את שרת הפיתוח של Flask. אם אתם חדשים ב-Docker, ההנחיה FROM מציינת את תמונת הבסיס שממנה מתחילים, והמילה slim מתייחסת להפצה מינימלית של Python. מידע נוסף זמין בדף Docker Python images.

קבוצת הפקודות האמצעית יוצרת את ספריית העבודה (/app), מעתיקה את קובצי האפליקציה ואז מריצה את הפקודה pip install כדי להוסיף לספרייה ספריות של צד שלישי. ‫WORKDIR משלב את הפקודות mkdir ו-cd של Linux. אפשר לקרוא מידע נוסף על כך במאמרי העזרה של WORKDIR . ההנחיות COPY ו-RUN הן ברורות מאליהן.

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

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

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

מפתחי Python 2 App Engine יודעים שספריות של צד שלישי מועתקות לתיקייה lib, מוזכרות ב-requirements.txt, מפורטות ב-app.yaml ונתמכות על ידי appengine_config.py. קונטיינרים, כמו אפליקציות Python 3 App Engine, משתמשים רק ב-requirements.txt, כך שאפשר להסיר את כל השאר. כלומר, אם יש לכם אפליקציית App Engine בגרסה 2.x, עכשיו אפשר למחוק את appengine_config.py ואת כל תיקיית lib.

הפעלה

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

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

runtime: python38
entrypoint: python main.py

ההנחיה entrypoint מציינת ל-App Engine איך להפעיל את השרת. אפשר להעביר אותו כמעט ישירות אל Dockerfile (או אל Procfile אם משתמשים ב-Buildpacks [ראו מודול 5] כדי להפוך את האפליקציה לקונטיינר). סיכום של המקום שבו מכניסים את ההנחיה entrypoint בשתי הפלטפורמות:

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

אפשר להשתמש בשרת הפיתוח של Flask לצורך בדיקות, אבל אם משתמשים בשרת ייצור כמו gunicorn עבור האפליקציה, צריך להפנות אליו את ההנחיה ENTRYPOINT או CMD כמו בדוגמה Cloud Run Quickstart.

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

מומלץ ליצור קובץ .dockerignore כדי לצמצם את הגודל של קובץ אימג' של קונטיינר ולא להעמיס על קובץ אימג' של קונטיינר קבצים מיותרים כמו:

*.md
*.pyc
*.pyo
.git/
.gitignore
__pycache__

קבצים של אפליקציות

כל האפליקציות של מודול 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. פיתוח ופריסה

אחרי שמשלימים את העדכונים של קובץ המקור וההגדרה של Docker, אפשר להפעיל אותו ב-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 beta 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 Dockerfile and deploying container to Cloud Run service [SVC_NAME] in project [PROJECT_ID] region [REGION]
✓ Building and deploying new service... Done.
  ✓ Uploading sources...
  ✓ Building Container... Logs are available at [https://console.cloud.google.com/cloud-build/builds/BUILD-HASH?project=PROJECT_NUM].
  ✓ Creating Revision... Deploying Revision.
  ✓ Routing traffic...
  ✓ Setting IAM Policy...
Done.
Service [SVC_NAME] revision [SVC_NAME-00001-vos] 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. אם התחלתם את סדרת המאמרים הזו בלי לבצע את כל המעבדות הקודמות, האפליקציה עצמה לא משתנה. היא רושמת את כל הביקורים בדף האינטרנט הראשי (/) ונראית כך אחרי שביקרתם באתר מספיק פעמים:

הקוד שלכם צריך להיות זהה לקוד בתיקיית המאגר של מודול 4, בין אם מדובר בגרסה 2.x או בגרסה 3.x. כל הכבוד, סיימתם את Codelab מודול 4.

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

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

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

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

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

השלבים הבאים

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

• אם עדיין לא עשיתם זאת, עוברים ל-Python 3. אפליקציית הדוגמה כבר תואמת לגרסאות 2.x ו-3.x, כך שהשינוי היחיד הוא שמשתמשי Docker צריכים לעדכן את Dockerfile כדי להשתמש בתמונה של Python 3.
• ‫מודול 5: מעבר ל-Cloud Run באמצעות Cloud Buildpacks
  • יצירת קונטיינר לאפליקציה כדי להפעיל אותה ב-Cloud Run באמצעות Cloud Buildpacks
  • לא צריך לדעת שום דבר על Docker, על מאגרי מידע או על Dockerfiles
  • נדרש שכבר העברתם את האפליקציה ל-Python 3
• ‫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 הזה, כדאי לחפש את הבעיה לפני ששולחים דיווח. קישורים לחיפוש וליצירה של בעיות חדשות:

• כלי למעקב אחר בעיות ב-Codelabs בנושא מיגרציה של App Engine
  • חיפוש בעיות
  • דיווח על בעיה חדשה או משוב

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

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

Codelab	‫Python 2	‫Python 3
מודול 2	קוד	(קוד)
Module 3	(קוד)	קוד
Module 4	קוד	קוד

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

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

• קונטיינרים
  • Google Cloud Run
  • Google Cloud Build
  • Google Cloud Container Registry
  • Docker
  • פוסט על השקת Cloud Buildpacks
  • Cloud Buildpacks deploy post
  • מאגר Cloud Buildpacks
  • מפרט Buildpacks של CNCF
  • כלי להעברה מ-App Engine ל-Cloud Run – כדי ליצור service.yaml
• כללי
  • ‫Python ב-Google Cloud Platform
  • ספריות לקוח Python של Google Cloud