פריסת ההגדרה של נקודות הקצה

אחרי שמגדירים את קובץ .proto ואת קובץ ההגדרות של gRPC API, פורסים אותם כדי שמערכת Cloud Endpoints תקבל את המידע שהיא צריכה כדי לנהל את ה-API. כדי לפרוס את הגדרת Endpoints, משתמשים בפקודה gcloud endpoints services deploy. הפקודה הזו משתמשת ב-Service Infrastructure, פלטפורמת השירותים הבסיסית של Google, שמשמשת את Endpoints ושירותים אחרים ליצירה ולניהול של ממשקי API ושירותים. בדף הזה מוסבר איך לפרוס את קובצי ההגדרות ב-Endpoints.

דרישות מוקדמות

כנקודת התחלה, בדף הזה מניחים שיש לכם:

הכנה של Google Cloud CLI לפריסה

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

כדי להתכונן לפריסה:

  1. מתקינים ומפעילים את ה-CLI של gcloud.
  2. מעדכנים את ה-CLI של gcloud: 
    gcloud components update
  3. מוודאים של-CLI של gcloud יש הרשאה לגשת לנתונים ולשירותים שלכם: 
    gcloud auth login

    תיפתח כרטיסייה חדשה בדפדפן ותתבקשו לבחור חשבון.

  4. מגדירים את פרויקט ברירת המחדל. מחליפים את [YOUR-PROJECT-ID] במזהה הפרויקט ב-GCP. 
    gcloud config set project [YOUR-PROJECT-ID]
  5. אם אתם מתכוונים לפרוס את ה-backend של ה-API ב-Kubernetes או ב-Kubernetes Engine, מריצים את הפקודה הבאה כדי לקבל פרטי כניסה חדשים של משתמש שאפשר להשתמש בהם בפרטי כניסה שמוגדרים כברירת מחדל לאפליקציה. צריך את פרטי הכניסה של המשתמש כדי לתת הרשאה ל-kubectl. 
    gcloud auth application-default login
     נפתחת כרטיסייה חדשה בדפדפן ומוצגת בקשה לבחור חשבון.

פריסת קובצי התצורה

  1. חשוב לוודא שאתם נמצאים בספרייה שבה נמצאים הקבצים api_descriptor.pb ו-api_config.yaml.
  2. מוודאים שפרויקט ברירת המחדל שבו כלי שורת הפקודה gcloud משתמש כרגע הוא הפרויקט Google Cloud שבו רוצים לפרוס את ההגדרה של Endpoints. כדי לוודא שהשירות לא נוצר בפרויקט הלא נכון, מאמתים את מזהה הפרויקט שמוחזר מהפקודה הבאה: 
    gcloud config list project

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

    gcloud config set project YOUR_PROJECT_ID
  3. פורסים את הקובץ proto descriptor ואת קובץ ההגדרות באמצעות Google Cloud CLI: 
    gcloud endpoints services deploy api_descriptor.pb api_config.yaml

    במהלך היצירה וההגדרה של השירות, Service Management מציג מידע במסוף. בסיום הפריסה, תוצג הודעה שדומה לזו:

    Service Configuration [CONFIG_ID] uploaded for service [bookstore.endpoints.example-project.cloud.goog]

    ‫CONFIG_ID הוא המזהה הייחודי של הגדרת שירות Endpoints שנוצר על ידי הפריסה. לדוגמה:

    Service Configuration [2017-02-13r0] uploaded for service [bookstore.endpoints.example-project.cloud.goog]

    בדוגמה הקודמת, 2017-02-13r0 הוא מזהה הגדרות השירות ו-bookstore.endpoints.example-project.cloud.goog הוא שם השירות. מזהה הגדרות השירות מורכב מחותמת זמן ואחריה מספר הגרסה. אם תפרסו את ההגדרה של Endpoints שוב באותו יום, מספר הגרסה יוגדל במזהה הגדרת השירות.

אם ההגדרות של השירות נמצאות בכמה קובצי YAML, אפשר להעביר את כולם לפקודה deploy. לדוגמה, ההגדרה הבסיסית של חנות הספרים נמצאת ב-api_config.yaml, אבל אפשר להפעיל קידוד מחדש של HTTP בשירות על ידי פריסה גם של api_config_http.yaml, שכולל הגדרה נוספת לתכונה הזו:

‫
gcloud endpoints services deploy api_descriptor.pb api_config.yaml api_config_http.yaml

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

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

פריסה מחדש

בכל פעם שמשנים משהו בקובץ .proto או בקובץ ה-YAML של הגדרת השירות, צריך לפרוס את הקבצים מחדש כדי ש-Extensible Service Proxy ‏ (ESP) יקבל את הגרסה העדכנית ביותר של הגדרת השירות של ה-API. אם פרסתם בעבר את ESP עם האפשרות rollout שהוגדרה לערך managed, לא צריך להפעיל מחדש את ESP או לפרוס אותו מחדש. האפשרות rollout=managed מגדירה את ESP כך שישתמש בהגדרת השירות העדכנית ביותר שפריסתה הושלמה. אם תבחרו באפשרות הזו, עד 5 דקות אחרי שתפרסו הגדרת שירות חדשה, ESP יזהה את השינוי ויתחיל להשתמש בה באופן אוטומטי. אנחנו ממליצים לציין את האפשרות הזו במקום מזהה תצורה ספציפי לשימוש ב-ESP.

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

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