בדיקה מקומית

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

הפעלה באמולטור של Knative serving

הפלאגין Cloud Code ל-VS Code ול-IDE של JetBrains מאפשר לכם להריץ ולנפות באגים בקובץ אימג' של קונטיינר באופן מקומי באמולטור של Knative serving בתוך סביבת הפיתוח המשולבת (IDE). האמולטור מאפשר לכם להגדיר סביבה שמייצגת את השירות שלכם שפועל ב-Knative serving.

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

1. מתקינים את Cloud Code ל-VS Code או ל-JetBrains IDE.
2. פועלים לפי ההוראות לפיתוח ולניפוי באגים באופן מקומי בסביבת הפיתוח המשולבת.
   • ‫VS Code: פיתוח וניפוי באגים באופן מקומי
   • ‫IntelliJ: פיתוח וניפוי באגים באופן מקומי

הרצה מקומית באמצעות Docker

כדי לבדוק את קובץ האימג' של הקונטיינר באופן מקומי באמצעות Docker:

1. משתמשים בפקודת Docker:

   PORT=8080 && docker run -p 9090:${PORT} -e PORT=${PORT} IMAGE_URL

   מחליפים את IMAGE_URL בהפניה לקובץ אימג' של קונטיינר, לדוגמה, gcr.io/cloudrun/hello.

   משתנה הסביבה PORT מציין את היציאה שבה האפליקציה תקשיב לבקשות HTTP או HTTPS. זוהי דרישה של הסכם Container Runtime. בדוגמה הזו, אנחנו משתמשים ביציאה 8080.

2. פותחים את http://localhost:9090 בדפדפן.

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

הרצה מקומית באמצעות Docker עם גישה לשירותים Google Cloud

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

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

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

כדי להריץ באופן מקומי:

1. למידע נוסף על הגדרת פרטי הכניסה, אפשר לעיין במאמר מפתח של חשבון שירות.

2. הדגלים הבאים של Docker run מזריקים את פרטי הכניסה וההגדרות מהמערכת המקומית לקונטיינר המקומי:

   1. משתמשים בדגל --volume (-v) כדי להחדיר את קובץ פרטי הכניסה למאגר (בהנחה שכבר הגדרתם את משתנה הסביבה GOOGLE_APPLICATION_CREDENTIALS במחשב):

      -v $GOOGLE_APPLICATION_CREDENTIALS:/tmp/keys/FILE_NAME.json:ro

   2. משתמשים בדגל --environment (-e) כדי להגדיר את המשתנה GOOGLE_APPLICATION_CREDENTIALS בתוך מאגר התגים:

      -e GOOGLE_APPLICATION_CREDENTIALS=/tmp/keys/FILE_NAME.json

3. אפשר גם להשתמש בפקודה המוגדרת במלואה של Docker run:

   PORT=8080 && docker run \
   -p 9090:${PORT} \
   -e PORT=${PORT} \
   -e K_SERVICE=dev \
   -e K_CONFIGURATION=dev \
   -e K_REVISION=dev-00001 \
   -e GOOGLE_APPLICATION_CREDENTIALS=/tmp/keys/FILE_NAME.json \
   -v $GOOGLE_APPLICATION_CREDENTIALS:/tmp/keys/FILE_NAME.json:ro \
   IMAGE_URL

   שימו לב שהנתיב

   המיקום

   /tmp/keys/FILE_NAME.json

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

   אבל אפשר להשתמש גם במיקומים אחרים בספרייה. הדרישה החשובה ביותר היא שמשתנה הסביבה GOOGLE_APPLICATION_CREDENTIALS יהיה זהה למיקום הטעינה של bind mount בתוך הקונטיינר.

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

המאמרים הבאים

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