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

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

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

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

כאן מוסבר איך

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

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

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

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

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

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

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

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

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

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

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

$ 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) פריסת אפליקציות בסיסיות

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

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

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

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

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

הגעתם למקום הנכון אם אתם כבר מכירים קונטיינרים ו-Docker, ואתם רוצים לקבל מידע נוסף על יצירת קונטיינרים לאפליקציית App Engine עבור Cloud Run. אפשר להתחיל גם את Module 5 Codelab לאחר מכן (זה זהה לזה אבל ב-Cloud Buildpacks). האפליקציה שלנו לדוגמית ברייל (barebones) היא קלה מספיק כדי למנוע חלק מהבעיות 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-בלבד])

(לא רלוונטי)

(לא רלוונטי)

הפעלה

(לא רלוונטי) או 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.

קבוצת הפקודות האמצעית יוצרת את ספריית העבודה (/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.

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

מפתחי App Engine Python 2 יודעים שספריות של צד שלישי מועתקות לתיקייה 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] כדי ליצור קונטיינרים לאפליקציה). סיכום המיקום שבו תבוצע הוראה של נקודת כניסה בין שתי הפלטפורמות:

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

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

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

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

אפליקציית visitme

הקוד אמור עכשיו להתאים למה שמופיע בתיקיית המאגר של מודול 4 – 2.x או 3.x. מזל טוב, השלמת את שיעור ה-Codelab במודול 4 הזה.

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

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

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

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

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

השלבים הבאים

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

  • עוברים ל-Python 3 אם עדיין לא עשיתם זאת. האפליקציה לדוגמה כבר תואמת ל- 2.x ול- 3.x, לכן השינוי היחיד הוא שמשתמשי Docker יעדכנו את Dockerfile שלהם לשימוש בתמונת Python 3.
  • מודול 5: מעבר ל-Cloud Run עם Cloud Buildpacks
    • יצירת קונטיינרים לאפליקציה כדי לרוץ ב-Cloud Run באמצעות Cloud Buildpacks
    • לא צריך לדעת שום דבר על Docker, על קונטיינרים או על Dockerfile
    • צריך להעביר כבר את האפליקציה ל-Python 3
  • מודול 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) ומודול 4 (FINISH). אפשר לגשת אליהן גם דרך המאגר לכל העברות Codelab ב-App Engine, שאותו ניתן לשכפל או להוריד בקובץ ZIP.

Codelab

ֶPython 2

ֶPython 3

יחידת לימוד 2

קוד

(קוד)

יחידת לימוד 3

(קוד)

קוד

יחידת לימוד 4

קוד

קוד

משאבי App Engine ו-Cloud Run

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