רוב הפונקציונליות שסופקה על ידי חבילת השירותים מדור קודם מסופקת עכשיו על ידי ספריות הלקוח של Cloud. מידע נוסף זמין בחלופות המומלצות שרשומות בהמשך.
אם העברה לפתרון לא משולב היא לא אפשרות עבור הפרויקט שלכם, יכול להיות שתוכלו להמשיך להשתמש בשירותים משולבים מדור קודם באפליקציותPython 3, כפתרון חלופי. הגישה הזו מאפשרת לכם גמישות לעבור לשירותים לא מקובצים בהמשך מחזור המיגרציה.
אחרי שתעברו משירותים בחבילה מדור קודם, תוכלו להמשיך להשתמש ב-App Engine או לעבור ל-Cloud Run. Cloud Run נועד לשפר את חוויית השימוש ב-App Engine, ומשלב הרבה מהתכונות הטובות ביותר של הסביבה הרגילה ושל הסביבה הגמישה. כדי להשוות בין התכונות ולהבין איך לבצע העברה, אפשר לעיין במדריך ההשוואה בין App Engine לבין Cloud Run.
Google Cloud מספקת מוצרים עצמאיים שמציעים פונקציונליות דומה לחלק מהשירותים המצורפים מדור קודם בסביבת זמן הריצה של Python. לגבי חבילות שירותים מדור קודם שלא זמינות כמוצרים נפרדים ב- Google Cloud, כמו אימייל והודעות, במדריך הזה מומלץ להשתמש בספקי צד שלישי או בפתרונות עקיפים אחרים.
בדף הזה מוסבר על נתיב ההעברה של חבילת השירותים מדור קודם.
הסבר על ההרשאות ב- Google Cloud
האפליקציה שהועברה והשירותים שבהם היא משתמשת לא פועלים באותו סביבת ארגז חול, והאפליקציה דורשת הרשאה כדי לגשת לכל שירות. Google Cloud לדוגמה, כדי ליצור אינטראקציה עם Firestore במצב Datastore (Datastore) או עם Cloud Tasks, האפליקציה צריכה לספק את פרטי הכניסה לחשבון שיש לו הרשאה לגשת לשירותים האלה.
כברירת מחדל, אפליקציות שפועלות בסביבה הרגילה של App Engine מספקות את פרטי הכניסה של חשבון השירות שמוגדר כברירת מחדל ב-App Engine, שיש לו הרשאה לגשת למסדי נתונים באותו פרויקט שבו נמצאת האפליקציה.
אם אחד מהתנאים הבאים מתקיים, צריך להשתמש בשיטת אימות חלופית שכוללת פרטי כניסה:
האפליקציה ומסד הנתונים של Memorystore נמצאים בפרויקטים שונים.Google Cloud
שיניתם את התפקידים שהוקצו לחשבון השירות שמוגדר כברירת מחדל ב-App Engine.
מידע על שיטות אימות חלופיות זמין במאמר הגדרת אימות לאפליקציות ייצור מסוג Server-to-Server.
אימות לפיתוח מקומי
כדי לפתח או לבדוק את האפליקציה באופן מקומי, צריך ליצור חשבון שירות ולהשתמש בו. לא מומלץ להשתמש בחשבון השירות שמוגדר כברירת מחדל ב-App Engine כי יש לו הרשאות רחבות בפרויקט. במקום זאת, כדאי ליצור חשבון שירות עם ההרשאות המינימליות שנדרשות למשימות הפיתוח והבדיקה הספציפיות שלכם, ולהשתמש בו.
כדי להגדיר חשבון שירות ולחבר אותו לאפליקציה, אפשר לעיין במאמר קבלת פרטי כניסה לחשבון שירות וציון שלהם באופן ידני.
התקנה של ספריות לקוח
כדי להשתמש בשירותים מאפליקציית Python, צריך להתקין את ספריית הלקוח של Python עבור השירות.שירותים גם מספקים ממשקי REST API וממשקים אחרים. Google Cloud Google Cloud
כדי להתקין ספריית לקוח לזמן הריצה של Python 3:
מוסיפים את שם הספרייה לקובץ
requirements.txtשל האפליקציה. לדוגמה:google-cloud-ndb
App Engine מעלה באופן אוטומטי את כל הספריות שמפורטות בקובץ requirements.txt לזמן הריצה של Python 3.
נתיבי העברה לשירותים בחבילה של App Engine
Blobstore
כדי לאחסן ולאחזר נתונים, משתמשים ב-Cloud Storage דרך ספריות הלקוח של Cloud. כדי להתחיל, אפשר לעיין במאמר בנושא שימוש ב-Cloud Storage ובמדריך בנושא העברה מ-Blobstore ל-Cloud Storage. כדי לדמות את ההעברה הזו, מוסיפים שימוש ב-Blobstore לאפליקציה לדוגמה ומעבירים אותה ל-Cloud Storage.
Datastore
אם אפליקציית Python 2 שלכם משתמשת ב-NDB כדי ליצור אינטראקציה עם Datastore, אתם צריכים לעבור לספריית Cloud NDB. Cloud NDB מיועד בעיקר ככלי מעבר להעברת אפליקציות Python 2. מומלץ להשתמש בספריית הלקוח של מצב Datastore באפליקציות Python 3.
פרטים נוספים זמינים במאמר מעבר ל-Cloud NDB. כדי לדמות את ההעברה הזו באמצעות אפליקציה לדוגמה, אפשר לעיין במאמר מעבר מ-ndb ב-App Engine ל-Cloud NDB.
תמונות
אתם יכולים להציג תמונות מ-Cloud Storage, להציג אותן ישירות או להשתמש ברשת של צד שלישי להעברת תוכן (CDN).
כדי לשנות את הגודל של תמונות, להמיר אותן ולבצע בהן מניפולציות, אפשר להשתמש בספרייה לעיבוד תמונות כמו Pillow או ממשק Python ל-ImageMagick.
כדי להשתמש באחת מהספריות האלה של צד שלישי, צריך להוסיף את הספרייה כתלות ולעדכן את הקוד כדי לקרוא ל-APIs של הספרייה.
שירות התמונות של App Engine סיפק גם פונקציונליות למניעת בקשות דינמיות לאפליקציה על ידי טיפול בשינוי גודל התמונה באמצעות כתובת URL להצגת התמונה. אם אתם רוצים פונקציונליות דומה, אתם יכולים ליצור את התמונות המוקטנות מראש ולהעלות אותן ל-Cloud Storage כדי להציג אותן. אפשרות אחרת היא להשתמש בשירות של רשת להעברת תוכן (CDN) של צד שלישי שמציע שינוי גודל של תמונות.
רישום ביומן
מומלץ לעדכן את האפליקציה כדי להשתמש ב-Cloud Logging, שתומך בתכונות כמו צפייה ביומנים בכלי Logs Explorer, הורדת יומנים, סינון הודעות לפי חומרה וקישור בין הודעות באפליקציה לבין בקשות ספציפיות. לחלופין, אם אתם מעדיפים פשטות על פני דיוק נתונים, אתם יכולים לכתוב יומנים מובְנים אל stdout או אל stderr.
מידע נוסף זמין במאמרים כתיבה של יומנים וצפייה בהם ומעבר ל-Cloud Logging.
שליחת אימייל
כדי לשפר את אבטחת האימייל ולהבטיח מסירה אמינה של אימיילים בכמויות גדולות, מומלץ לעבור מ-Mail API מדור קודם לשירות אימייל מבוסס SMTP, כמו SendGrid, Mailgun או Mailjet.Memcache
כדי לשמור נתונים של אפליקציות במטמון, משתמשים ב-Memorystore for Redis.
פרטים נוספים זמינים במאמר בנושא העברת Memcache ל-Memorystore. כדי לדמות את ההעברה הזו, מוסיפים שימוש ב-Memcache לאפליקציה לדוגמה ומעבירים ל-Memorystore for Redis.
באפליקציות שמשתמשות ב-Memcache רק כדי לצמצם את זמן האחזור של בקשות NDB (או Cloud NDB), מומלץ להשתמש בתמיכה המובנית של Cloud NDB ב-Redis במקום ב-Memcache או ב-Memorystore for Redis.
מודולים
כדי לקבל מידע ולשנות את השירותים הפועלים באפליקציה, משתמשים בשילוב של משתני סביבה ו-App Engine Admin API:
| פרטי השירות | איך ניגשים |
|---|---|
| מזהה האפליקציה הנוכחית | משתנה הסביבה GAE_APPLICATION |
| מזהה הפרויקט הנוכחי | משתנה הסביבה GOOGLE_CLOUD_PROJECT |
| שם השירות הנוכחי | משתנה הסביבה GAE_SERVICE |
| גרסת השירות הנוכחית | משתנה הסביבה GAE_VERSION |
| מזהה המופע הנוכחי | משתנה הסביבה GAE_INSTANCE |
| שם מארח שמוגדר כברירת מחדל | שיטת Admin API apps.get |
| רשימת השירותים | שיטת Admin API apps.services.list |
| רשימת הגרסאות של שירות | שיטת Admin API apps.services.versions.list |
| גרסת ברירת המחדל של שירות, כולל חלוקת תנועה | שיטת Admin API apps.services.get |
| רשימה של מופעים פעילים של גרסה | שיטת Admin API apps.services.versions.instances.list |
מידע נוסף על הנתונים שזמינים לגבי שירותים שפועלים באפליקציה מופיע במאמר בנושא סביבת זמן הריצה שלPython 3,.
מרחבי שמות
Namespaces API מאפשר לאפליקציות מרובות דיירים לחלק את הנתונים בין הדיירים פשוט על ידי ציון מחרוזת ייחודית של מרחב שמות לכל דייר.
Datastore תומך ישירות בשימוש במספר דיירים, אבל שירותים אחרים Google Cloudלא. אם האפליקציה הרב-דיירית שלכם משתמשת בשירותים אחרים של Google Cloud, תצטרכו לנהל את הרב-דיירות באופן ידני. כדי לקבל מופעים מבודדים לחלוטין של שירותים, אתם יכולים ליצור פרויקטים חדשים באופן פרוגרמטי באמצעות Cloud Resource Manager API ולגשת למשאבים בפרויקטים שונים.
OAuth
במקום להשתמש בשירות OAuth של App Engine כדי לאמת אסימוני OAuth 2.0, צריך להשתמש בשיטה oauth2.tokeninfo של OAuth 2.0 API.
חיפוש
אירוח של מסד נתונים לחיפוש טקסט מלא כמו Elasticsearch ב-Compute Engine וגישה אליו מהשירות.
תור משימות
שירות תור המשימות של App Engine זמין בשני מצבים שונים. המעבר מכל אחת מהנקודות האלה מצביע על שני מוצרי Cloud נפרדים.
העברת משימות
במקום להשתמש בשירות של משימות דחיפה בתור המשימות של App Engine לביצוע אסינכרוני של קוד, משתמשים בספריות לקוח של Cloud Tasks עם נקודת קצה של סביבה רגילה של Python 3 כיעד. מידע נוסף זמין במאמר העברת תורים של הודעות בדחיפה ל-Cloud Tasks.
כדי לדמות את המעבר הזה באמצעות אפליקציה לדוגמה, אפשר לעיין במאמרים איך משתמשים בתורי דחיפה של App Engine באפליקציות Flask ומעבר ל-Cloud Tasks.
שליפת משימות
אם אתם משתמשים בשירות של משימות שליפת הודעות בתור המשימות, למשל, כדי להוסיף משימות או הודעות לתור לעיבוד על ידי עובדים נפרדים, Cloud Pub/Sub יכול להיות חלופה טובה. היא מציעה פונקציונליות דומה והתחייבויות מסירה. בדומה לשירותי ענן אחרים, Pub/Sub מספק ספריות לקוח נוחות לגישה לשירות. מידע נוסף זמין במאמרים כתיבה של הודעות Pub/Sub ותגובה להן ובמדריך להעברה של משימות שליפה בתור המשימות ל-Pub/Sub.
כדי לדמות את ההעברה הזו באמצעות אפליקציה לדוגמה, אפשר לעיין במאמר איך משתמשים במשימות משיכה של App Engine באפליקציה לדוגמה ובמאמר העברה ל-Pub/Sub.
URL Fetch
כברירת מחדל, סביבת זמן הריצה של Python 2.7 משתמשת בשירות אחזור של כתובות אתרים כדי לטפל בבקשות HTTP(S) יוצאות, גם אם אתם משתמשים בספריות Python רגילות כדי להנפיק את הבקשות האלה.
אם האפליקציה שלכם משתמשת ישירות ב-URL Fetch APIs, למשל כדי לשלוח בקשות אסינכרוניות, מומלץ לעבור לספריית Python רגילה, כמו Requests library.
מידע נוסף זמין במאמר בנושא העברת בקשות יוצאות.
אימות משתמשים
כחלופה ל-Users API, אפשר להשתמש בכל אחד ממנגנוני האימות שמבוססים על HTTP שמתוארים בדף אימות משתמשים.