אחרי שמגדירים את קובץ .proto ואת קובץ ההגדרות של gRPC API, פורסים אותם כדי שמערכת Cloud Endpoints תקבל את המידע שהיא צריכה כדי לנהל את ה-API. כדי לפרוס את הגדרת Endpoints, משתמשים בפקודה gcloud
endpoints services deploy. הפקודה הזו משתמשת ב-Service Infrastructure, פלטפורמת השירותים הבסיסית של Google, שמשמשת את Endpoints ושירותים אחרים ליצירה ולניהול של ממשקי API ושירותים. בדף הזה מוסבר איך לפרוס את קובצי ההגדרות ב-Endpoints.
דרישות מוקדמות
כנקודת התחלה, בדף הזה מניחים שיש לכם:
יצרתם Google Cloud פרויקט שבו יש לכם את התפקיד Editor או Owner. אחרי הפריסה הראשונית, אפשר לתת את התפקיד המגביל יותר עריכת הגדרות שירות. מידע נוסף זמין במאמר בנושא מתן גישה ל-API וביטול הגישה.
נקודות קצה שהוגדרו, כולל:
אם משתמשים בשם דומיין בהתאמה אישית (למשל,
example.com), צריך לאמת את שם הדומיין לפני שפורסים את קובצי ההגדרות של gRPC.
הכנה של Google Cloud CLI לפריסה
משתמשים בכלי gcloud של שורת הפקודה כדי לפרוס את ההגדרה. מידע נוסף על הפקודות מופיע ב
מדריך העזר ל-gcloud.
כדי להתכונן לפריסה:
- מתקינים ומפעילים את ה-CLI של gcloud.
- מעדכנים את ה-CLI של gcloud:
gcloud components update
- מוודאים של-CLI של gcloud יש הרשאה לגשת לנתונים ולשירותים שלכם:
gcloud auth login
תיפתח כרטיסייה חדשה בדפדפן ותתבקשו לבחור חשבון.
- מגדירים את פרויקט ברירת המחדל. מחליפים את
[YOUR-PROJECT-ID]במזהה הפרויקט ב-GCP.gcloud config set project [YOUR-PROJECT-ID]
- אם אתם מתכוונים לפרוס את ה-backend של ה-API ב-Kubernetes או ב-Kubernetes Engine, מריצים את הפקודה הבאה כדי לקבל פרטי כניסה חדשים של משתמש שאפשר להשתמש בהם בפרטי כניסה שמוגדרים כברירת מחדל לאפליקציה. צריך את פרטי הכניסה של המשתמש כדי לתת הרשאה ל-
kubectl. נפתחת כרטיסייה חדשה בדפדפן ומוצגת בקשה לבחור חשבון.gcloud auth application-default login
פריסת קובצי התצורה
- Make sure you are in the directory where the
api_descriptor.pbandapi_config.yamlfiles are located. - Confirm that the default project that the
gcloudcommand-line tool is currently using is the Google Cloud project that you want to deploy the Endpoints configuration to. Validate the project ID returned from the following command to make sure that the service doesn't get created in the wrong project.gcloud config list project
If you need to change the default project, run the following command:
gcloud config set project YOUR_PROJECT_ID
- Deploy the
proto descriptorfile and the configuration file by using the Google Cloud CLI:gcloud endpoints services deploy api_descriptor.pb api_config.yaml
As it is creating and configuring the service, Service Management outputs information to the terminal. When the deployment completes, a message similar to the following is displayed:
Service Configuration [CONFIG_ID] uploaded for service [bookstore.endpoints.example-project.cloud.goog]
CONFIG_ID is the unique Endpoints service configuration ID created by the deployment. For example:
Service Configuration [2017-02-13r0] uploaded for service [bookstore.endpoints.example-project.cloud.goog]
In the previous example,
2017-02-13r0is the service configuration ID andbookstore.endpoints.example-project.cloud.googis the service name. The service configuration ID consists of a date stamp followed by a revision number. If you deploy the Endpoints configuration again on the same day, the revision number is incremented in the service configuration ID.
אם ההגדרות של השירות נמצאות בכמה קובצי 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 וביטול הגישה.
המאמרים הבאים
- פריסת העורף של ה-API
- הפעלת ESP באופן מקומי או בפלטפורמה אחרת
- איך מוצאים את שם השירות ואת מזהה ההגדרה