מידע על פעולות ותצורות עבור Edge Microgateway

אתה צופה בתיעוד של Apigee Edge.
הצג תיעוד של Apigee X.

Edge Microgateway v. 2.5.x

הנושא הזה עוסק בניהול ובהגדרה של Edge Microgateway.

שדרוג Microgateway של Edge אם יש לך חיבור לאינטרנט

  1. מריצים את הפקודה npm ומשדרגים לגרסה האחרונה של Edge Microgateway: 
    npm upgrade edgemicro -g

    כדי לשדרג לגרסה ספציפית של Edge Microgateway, יש לציין את מספר הגרסה בפקודת השדרוג. אם לא יצוין מספר גרסה, תותקן הגרסה האחרונה. לדוגמה, כדי לשדרג לגרסה 2.5.26, השתמשו בפקודה הבאה:

    npm upgrade edgemicro@2.5.26 -g
  2. בודקים את מספר הגרסה. לדוגמה, אם התקנתם את גרסה 2.5.26: 
    edgemicro --version
current nodejs version is v8.9.0
current edgemicro version is 2.5.26
  3. לסיום, משדרגים לגרסה האחרונה של שרת ה-proxy של edgemicro-auth: 
    edgemicro upgradeauth -o org_name -e env_name -u username

ביצוע שינויים בהגדרה

קובצי התצורה שצריך לדעת:

  • קובץ ברירת המחדל של תצורת המערכת
  • קובץ תצורה המוגדר כברירת מחדל למכונה של Microgateway Edge שפעילה לאחרונה
  • קובץ תצורה דינמית למכונות פועלות

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

קובץ ברירת המחדל של הגדרות המערכת

כשמתקינים את Edge Microgateway, קובץ ברירת המחדל של הגדרות המערכת מוצב כאן:

prefix/lib/node_modules/edgemicro/config/default.yaml

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

אם משנים את קובץ התצורה של המערכת, צריך לבצע אתחול, הגדרה מחדש והפעלה מחדש של Edge Microgateway:

edgemicro init
edgemicro configure [params]
edgemicro start [params]

קובץ תצורה המוגדר כברירת מחדל למכונות מיקרו-שער של Edge באתחול

כאשר מריצים את edgemicro init, קובץ התצורה של המערכת (כפי שמתואר למעלה) default.yaml נמצא בספרייה ~/.edgemicro.

אם משנים את קובץ התצורה ב-~/.edgemicro, צריך להגדיר אותו מחדש ולהפעיל את Edge Microgateway:

edgemicro stop
edgemicro configure [params]
edgemicro start [params]

קובץ תצורה דינמי למכונות פועלות

כשמריצים את edgemicro configure [params], קובץ תצורה דינמי נוצר ב-~/.edgemicro. הקובץ נקרא על סמך התבנית הבאה: org-env-config.yaml, כאשר org ו-env הם שמות הארגון והסביבה שלך ב-Apigee Edge. אפשר להשתמש בקובץ הזה כדי לבצע שינויים בהגדרות, ואז לטעון אותן מחדש עם זמן השבתה. לדוגמה, אם מוסיפים ומגדירים פלאגין, ניתן לטעון מחדש את התצורה מבלי לצבור זמן השבתה, כפי שמוסבר בהמשך.

אם Edge Edge Microgateway פועל (אפשרות של זמן השבתה):

  1. טוענים מחדש את ההגדרה של Edge Microgateway: 
    edgemicro reload -o org_name -e env_name -k key -s secret

    כאשר:

    • org_name הוא שם הארגון שלך ב-Edge (עליך להיות אדמין ארגוני).
    • env_name היא סביבה בארגון שלך (כגון "test" או "prod").
    • key הוא המפתח שהוחזר בעבר על ידי פקודת ה-config.
    • secret הוא המפתח שהוחזר בעבר באמצעות פקודת ה-config.

    לדוגמה

    edgemicro reload -o docs -e test -k 701e70ee718ce6dc188...78b6181d000723 \
  -s 05c14356e42ed1...4e34ab0cc824

אם מתבצעת השבתה של Microgateway Edge:

  1. מפעילים מחדש את ה-Microgateway של Edge: 
    edgemicro start -o org_name -e env_name -k key -s secret

    כאשר:

    • org_name הוא שם הארגון שלך ב-Edge (עליך להיות אדמין בארגון).
    • env_name היא סביבה בארגון שלך (למשל "test" או "prod").
    • key הוא המפתח שהוחזר בעבר באמצעות פקודת ה-config.
    • secret הוא המפתח שהוחזר בעבר באמצעות פקודת ה-config.

    לדוגמה:

    edgemicro start -o docs -e test -k 701e70ee718ce...b6181d000723 \
  -s 05c1435...e34ab0cc824

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

edge_config:
  bootstrap: >-
    https://edgemicroservices-us-east-1.apigee.net/edgemicro/bootstrap/organization/docs/environment/test
  jwt_public_key: 'https://docs-test.apigee.net/edgemicro-auth/publicKey'
  managementUri: 'https://api.enterprise.apigee.com'
  vaultName: microgateway
  authUri: 'https://%s-%s.apigee.net/edgemicro-auth'
  baseUri: >-
    https://edgemicroservices.apigee.net/edgemicro/%s/organization/%s/environment/%s
  bootstrapMessage: Please copy the following property to the edge micro agent config
  keySecretMessage: The following credentials are required to start edge micro
  products: 'https://docs-test.apigee.net/edgemicro-auth/products'
edgemicro:
  port: 8000
  max_connections: 1000
  max_connections_hard: 5000
  config_change_poll_interval: 600
  logging:
    level: error
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24
  plugins:
    sequence:
      - oauth
headers:
  x-forwarded-for: true
  x-forwarded-host: true
  x-request-id: true
  x-response-time: true
  via: true
oauth:
  allowNoAuthorization: false
  allowInvalidAuthorization: false
  verify_api_key_url: 'https://docs-test.apigee.net/edgemicro-auth/verifyApiKey'
analytics:
  uri: >-
    https://edgemicroservices-us-east-1.apigee.net/edgemicro/axpublisher/organization/docs/environment/test

הגדרת משתני סביבה

את הפקודות של ממשק שורת הפקודה שדורשות ערכים עבור הארגון והסביבה של Edge, והמפתח והסוד הנדרשים להפעלה של Edge Microgateway, אפשר לאחסן במשתני הסביבה האלה:

  • EDGEMICRO_ORG
  • EDGEMICRO_ENV
  • EDGEMICRO_KEY
  • EDGEMICRO_SECRET

הגדרת המשתנים האלה היא אופציונלית. אם מגדירים אותם, אין צורך לציין את הערכים שלהם כשמשתמשים בממשק Command-Line (CLI) כדי להגדיר ולהפעיל את Edge Microgateway.

הגדרת SSL בשרת Microgateway Edge

ניתן להגדיר את שרת Microgateway לשימוש ב-SSL. לדוגמה, כשמגדירים SSL, אפשר להפעיל ממשקי API דרך Edge Microgateway עם הפרוטוקול "https":

https://localhost:8000/myapi

כדי להגדיר SSL בשרת Microgateway, פועלים לפי השלבים הבאים:

  1. יוצרים או משיגים אישור SSL ומפתח באמצעות כלי השירות openssl או השיטה המועדפת.
  2. מוסיפים את המאפיין edgemicro:ssl לקובץ התצורה של Edge Microgateway. כדי לראות את רשימת האפשרויות המלאה, אפשר לעיין בטבלה שלמטה. לדוגמה:
    edgemicro:
  ssl:
   key: <absolute path to the SSL key file>
   cert: <absolute path to the SSL cert file>
   passphrase: admin123 #option added in v2.2.2
   rejectUnauthorized: true #option added in v2.2.2
   requestCert: true
  3. מפעילים מחדש את Edge Microgateway. פועלים לפי השלבים המפורטים בקטע ביצוע שינויים בהגדרות, בהתאם לקובץ התצורה שערכתם: קובץ ברירת המחדל או קובץ התצורה של זמן הריצה.

דוגמה לקטע edgemicro בקובץ התצורה עם הגדרה של SSL:

edgemicro:
  port: 8000
  max_connections: 1000
  max_connections_hard: 5000
  logging:
    level: error
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24
  plugins:
    sequence:
      - oauth
  ssl:
    key: /MyHome/SSL/em-ssl-keys/server.key
    cert: /MyHome/SSL/em-ssl-keys/server.crt
    passphrase: admin123 #option added in v2.2.2
    rejectUnauthorized: true #option added in v2.2.2

הנה רשימה של כל אפשרויות השרת הנתמכות:

אפשרות תיאור
key נתיב לקובץ ca.key (בפורמט PEM).
cert נתיב לקובץ ca.cert (בפורמט PEM).
pfx נתיב לקובץ pfx שמכיל את המפתח הפרטי, האישור ואישורי ה-CA של הלקוח בפורמט PFX.
passphrase מחרוזת שמכילה את ביטוי הסיסמה למפתח הפרטי או ל-PFX.
ca נתיב לקובץ המכיל רשימה של אישורים מהימנים בפורמט PEM.
ciphers מחרוזת שמתארת את הצפנים לשימוש, כשהם מופרדים באמצעות התו ":".
rejectUnauthorized אם True, אישור השרת מאומת מול רשימת רשויות האישורים שסופקו. אם האימות ייכשל, תוחזר שגיאה.
secureProtocol שיטת ה-SSL שבה יש להשתמש. לדוגמה, SSLv3_method כדי לאלץ SSL להשתמש בגרסה 3.
servername שם השרת של תוסף ה-TLS של ה-SNI (שרת השמות).
requestCert True ל-כיווני

שימוש באפשרויות SSL/TLS של לקוח

ניתן להגדיר את Edge Microgateway כלקוח TLS או SSL כשמתחברים לנקודות קצה (endpoint). בקובץ התצורה של Microgateway, ניתן להשתמש ברכיב היעדים כדי להגדיר אפשרויות SSL/TLS.

בדוגמה הזו מוצגות ההגדרות שיחולו על כל המארחים:

edgemicro:
...
targets:
  ssl:
    client:
      key: /Users/jdoe/nodecellar/twowayssl/ssl/client.key
      cert: /Users/jdoe/nodecellar/twowayssl/ssl/ca.crt
      passphrase: admin123
      rejectUnauthorized: true

בדוגמה הזו, ההגדרות חלות רק על המארח שצוין:

edgemicro:
...
targets:
  - host: 'myserver.example.com'
    ssl:
      client:
        key: /Users/myname/twowayssl/ssl/client.key
        cert: /Users/myname/twowayssl/ssl/ca.crt
        passphrase: admin123
        rejectUnauthorized: true

דוגמה ל-TLS:

edgemicro:
...
targets:
  - host: 'myserver.example.com'
    tls:
      client:
        pfx: /Users/myname/twowayssl/ssl/client.pfx
        passphrase: admin123
        rejectUnauthorized: true

יצרנו רשימה של כל אפשרויות הלקוח הנתמכות:

אפשרות תיאור
pfx נתיב לקובץ pfx שמכיל את המפתח הפרטי, האישור ואישורי ה-CA של הלקוח בפורמט PFX.
key נתיב לקובץ ca.key (בפורמט PEM).
passphrase מחרוזת שמכילה את ביטוי הסיסמה למפתח הפרטי או ל-PFX.
cert נתיב לקובץ ca.cert (בפורמט PEM).
ca נתיב לקובץ המכיל רשימה של אישורים מהימנים בפורמט PEM.
ciphers מחרוזת שמתארת את הצפנים לשימוש, כשהם מופרדים באמצעות התו ":".
rejectUnauthorized אם True, אישור השרת מאומת מול רשימת רשויות האישורים שסופקו. אם האימות ייכשל, תוחזר שגיאה.
secureProtocol שיטת ה-SSL שבה יש להשתמש. לדוגמה, SSLv3_method כדי לאלץ SSL להשתמש בגרסה 3.
servername שם השרת של תוסף ה-TLS של ה-SNI (שרת השמות).

התאמה אישית של שרת proxy ב-edgemicro-auth

כברירת מחדל, Edge Microgateway משתמש בשרת proxy שנפרס ב-Apigee Edge לאימות OAuth2. שרת ה-proxy הזה נפרס כשמריצים את edgemicro configure. תוכלו לשנות את הגדרות ברירת המחדל של שרת ה-proxy הזה כדי להוסיף תמיכה לתלונות בהתאמה אישית לאסימון אינטרנט מסוג JSON ( JWT), להגדיר תפוגה של אסימון וליצור אסימוני רענון. לפרטים, עיינו בדף edgemicro-auth ב-GitHub.

שימוש בשירות אימות מותאם אישית

כברירת מחדל, Edge Microgateway משתמש בשרת proxy שנפרס ב-Apigee Edge לאימות OAuth2. שרת ה-proxy הזה נפרס כשמריצים את edgemicro configure. כברירת מחדל, כתובת ה-URL של שרת ה-proxy הזה מצוינת בקובץ התצורה של Edge Microgateway:

authUri: https://myorg-myenv.apigee.net/edgemicro-auth

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

ניהול קובצי יומן

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

איפה מאוחסנים קובצי היומן

כברירת מחדל, קובצי יומן מאוחסנים ב-/var/tmp.

איך משנים את ספריית ברירת המחדל של קובצי יומן

הספרייה שבה מאוחסנים קובצי היומן מצוינת בקובץ התצורה של Edge Microgateway. למידע נוסף, ראו שינויים בהגדרות.

edgemicro:
  home: ../gateway
  port: 8000
  max_connections: -1
  max_connections_hard: -1
  logging:
    level: info
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24

משנים את הערך של dir כדי לציין ספרייה אחרת של קובץ יומן.

שליחת יומנים למסוף

אפשר להגדיר את הרישום ביומן כך שפרטי היומן יישלחו לפלט רגיל במקום לקובץ יומן. מגדירים את הדגל to_console לערך true:

edgemicro:
  logging:
    to_console: true

באמצעות ההגדרה הזו, היומנים יישלחו לרמת Standard. בשלב זה לא ניתן לשלוח יומנים לקובץ stdout וגם לקובץ יומן.

הגדרה של רמת הרישום ביומן

אפשר להגדיר את הרמות הבאות ביומן: info, אזהרה ו-error. מומלץ להעלות את רמת המידע. היא מתעדת את כל הבקשות והתשובות של ה-API – וזו ברירת המחדל.

איך משנים את מרווחי הזמן ביומן

ניתן להגדיר את מרווחי הזמן האלה בקובץ התצורה של Edge Microgateway. כדאי גם לעיין בעריכת שינויים בהגדרה.

המאפיינים שניתנים להגדרה הם:

  • stats_log_interval: (ברירת המחדל: 60) מרווח, בשניות, כאשר רשומת הנתונים הסטטיסטיים נכתבת בקובץ היומן של ה-API.
  • round_interval: (ברירת המחדל: 24) מרווח (בשעות) כאשר מתבצעת רוטציה של קובצי היומן. לדוגמה:
edgemicro:
  home: ../gateway
  port: 8000
  max_connections: -1
  max_connections_hard: -1
  logging:
    level: info
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24

שיטות מומלצות לתחזוקת קובצי יומן

כאשר הנתונים בקובץ היומן נצברים לאורך זמן, ההמלצה של Apigee היא לאמץ את השיטות הבאות:

מוסכמה למתן שמות לקובצי יומן

כל מופע של Microgateway Edge מייצר שלושה סוגים של קובצי יומן:

  • api – רישום של כל הבקשות והתגובות שנזרקות דרך Edge Microgateway. גם מונהי API (שגיאות) ושגיאות נרשמים בקובץ הזה.
  • err - מתעד כל מה שנשלח אל stderr.
  • out – רושם כל פריט שנשלח ל-stdout.

זוהי המוסכמה למתן שמות:

edgemicro-<Host Name>-<Instance ID>-<Log Type>.log

לדוגמה:

edgemicro-mymachine-local-MTQzNTgNDMxODAyMQ-api.log
edgemicro-mymachine-local-MTQzNTg1NDMODAyMQ-err.log
edgemicro-mymachine-local-mtqzntgndmxodaymq-out.log

מידע על התוכן של קובץ היומן

תאריך הוספה: v2.3.3

כברירת מחדל, שירות הרישום משמיט את קובץ ה-JSON של שרתי proxy שהורדו, את המוצרים ואת אסימון האינטרנט JSON (JWT). כדי לייצר אובייקטים כאלה לקובצי היומן, צריך להגדיר את DEBUG=* כש-Microsoft Edgeway מופעל. לדוגמה:

DEBUG=* edgemicro start -o docs -e test -k abc123 -s xyz456

התוכן של קובץ היומן מסוג "API"

קובץ היומן של ה-"API" מכיל מידע מפורט על זרימת הבקשות והתגובות דרך Edge Microgateway. קובצי היומן של ה-"API" נקראים כך:

edgemicro-mymachine-local-MTQzNjIxOTk0NzY0Nw-api.log

בכל בקשה שנשלחה ל-Microgateway Edge, 4 אירועים מתועדים בקובץ היומן של ה-API:

  • בקשה נכנסת מהלקוח
  • בקשה יוצאת אל היעד
  • תגובה נכנסת מהיעד
  • תגובה יוצאת ללקוח

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

(1) 1436403888651 info req m=GET, u=/, h=localhost:8000, r=::1:59715, i=0
(2) 1436403888665 info treq m=GET, u=/, h=127.0.0.18080, i=0
(3) 1436403888672 info tres s=200, d=7, i=0
(4) 1436403888676 info res s=200, d=11, i=0

בואו נבחן אותם אחד אחרי השני:

1. דוגמה לבקשה נכנסת מהלקוח:

1436403888651 info req m=GET, u=/, h=localhost:8000, r=::1:59715, i=0
  • 1436403888651 - חותמת תאריך של Unix
  • info – בהתאם להקשר. יכול להיות מידע, אזהרה או שגיאה, בהתאם לרמת היומן. הנתונים הסטטיסטיים יכולים להיות של רשומת סטטיסטיקה, להציג אזהרות או שגיאה של שגיאות.
  • req – מזהה את האירוע. במקרה כזה, יש לבקש מהלקוח.
  • m - פועל ה-HTTP של הבקשה.
  • u – החלק בכתובת ה-URL שמופיע אחרי נתיב הבסיס.
  • h – מספר המארח והיציאה שבהם מתבצעת ההאזנה ל-Edge Microgateway.
  • r – המארח והיציאה המרוחקים שמהם הגיעה בקשת הלקוח.
  • i – מזהה הבקשה. כל ארבע הרשומות של האירוע ישתפו את המזהה הזה. לכל בקשה מוקצה מזהה בקשה ייחודי. קישור בין רשומות היומן לפי מזהה הבקשה יכול לספק תובנות חשובות לגבי זמן האחזור של היעד.
  • d – משך הזמן באלפיות השנייה מאז שהבקשה התקבלה על ידי Edge Microgateway. בדוגמה שלמעלה, תגובת היעד לבקשה 0 התקבלה אחרי 7 אלפיות השנייה (שורה 3), והתגובה נשלחה ללקוח אחרי 4 אלפיות השנייה (שורה 4). במילים אחרות, זמן האחזור הכולל של הבקשה היה 11 אלפיות השנייה, שמתוכם 7 אלפיות השנייה נלקחו על-ידי היעד ו-4 אלפיות השנייה על ידי Edge Microgateway עצמו.

2. דוגמה לבקשה יוצאת שנשלחה ליעד:

1436403888665 info treq m=GET, u=/, h=127.0.0.1:8080, i=0
  • 1436403888651 - חותמת תאריך של Unix
  • info – בהתאם להקשר. יכול להיות מידע, אזהרה או שגיאה, בהתאם לרמת היומן. הנתונים הסטטיסטיים יכולים להיות של רשומת סטטיסטיקה, להציג אזהרות או שגיאה של שגיאות.
  • treq – מזהה את האירוע. במקרה הזה, כדאי לטרגט את הבקשה.
  • m – פועל ה-HTTP המשמש בבקשת היעד.
  • u – החלק בכתובת ה-URL שמופיע אחרי נתיב הבסיס.
  • h - מספר המארח והיציאה של היעד לקצה העורפי.
  • i – המזהה של הרשומה ביומן. המזהה הזה ייכלל בכל ארבע רשומות האירועים.

3. דגימה של תגובה נכנסת מהיעד

1436403888672 info tres s=200, d=7, i=0

1436403888651 - חותמת תאריך של Unix

  • info – בהתאם להקשר. יכול להיות מידע, אזהרה או שגיאה, בהתאם לרמת היומן. הנתונים הסטטיסטיים יכולים להיות של רשומת סטטיסטיקה, להציג אזהרות או שגיאה של שגיאות.
  • tres – זיהוי האירוע. במקרה כזה, כדאי לטרגט את התשובה.
  • s – הסטטוס של תגובת ה-HTTP.
  • d – משך הזמן באלפיות שנייה. הזמן שנדרש לקריאת ה-API על ידי היעד.
  • i – המזהה של הרשומה ביומן. המזהה הזה ייכלל בכל ארבע רשומות האירועים.

4. דגימה של תגובה יוצאת ללקוח

1436403888676 info res s=200, d=11, i=0

1436403888651 - חותמת תאריך של Unix

  • מידע - תלוי בהקשר. יכול להיות מידע, אזהרה או שגיאה, בהתאם לרמת היומן. הנתונים הסטטיסטיים יכולים להיות של רשומת סטטיסטיקה, להציג אזהרות או שגיאה של שגיאות.
  • res – מזהה את האירוע. במקרה כזה, צריך להשיב ללקוח.
  • s – הסטטוס של תגובת ה-HTTP.
  • d – משך הזמן באלפיות שנייה. זהו הזמן הכולל שנוצר על ידי הקריאה ל-API, כולל הזמן שנמדד על ידי ה-API לטירגוט והזמן שהוצא באמצעות Edge Microgateway עצמו.
  • i – המזהה של הרשומה ביומן. המזהה הזה ייכלל בכל ארבע רשומות האירועים.

יומן של קובצי יומן

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

הודעות שגיאה

רשומות מסוימות ביומן יכילו הודעות שגיאה. כדי לזהות איפה השגיאות מתרחשות ומדוע, יש לעיין בחומר העזר לשגיאות ב-Edge Microgateway.

הפניה להגדרה של Microgateway Edge

המיקום של קובץ התצורה

מאפייני התצורה המתוארים בקטע הזה נמצאים בקובץ התצורה של Edge Microgateway. למידע נוסף, ראו שינויים בהגדרות.

מאפייני edge_config

ההגדרות האלה משמשות ליצירת אינטראקציה בין המכונה של Edge Microgateway לבין Apigee Edge.

  • shoestrap: (ברירת מחדל: none) כתובת URL שמפנה לשירות ספציפי של Edge במיקרו-שער שפועל ב-Apigee Edge. Edge Microgateway משתמש בשירות הזה כדי לתקשר עם Apigee Edge. כתובת ה-URL הזו מוחזרת כשמריצים את הפקודה כדי ליצור את זוג המפתחות הציבורי/הפרטי: edgemicro genkeys. לפרטים נוספים, אפשר לעיין בהגדרה והגדרה של Microgateway Edge.
  • jwt_public_key: (ברירת מחדל: none) כתובת URL שמצביעה על שרת ה-proxy של Edge Microgateway שנפרס ב-Apigee Edge. שרת ה-proxy הזה משמש כנקודת קצה לאימות לצורך הנפקת אסימונים של גישה חתומה ללקוחות. כתובת ה-URL הזו מוחזרת כשמריצים את הפקודה לפריסה של שרת ה-proxy: edgemicro configuration. לפרטים נוספים, אפשר לעיין בהגדרה והגדרה של Microgateway Edge.

מאפייני edgemicro

ההגדרות האלה קובעות את תהליך ה-Microgateway Edge.

  • port: (ברירת מחדל: 8000) מספר היציאה שבה תהליך ה-Microgateway של Edge מאזינים.
  • max_connects: (ברירת מחדל: 1-) מציין את המספר המקסימלי של חיבורים בו-זמניים ש-Edge Microgateway יכול לקבל. במקרה של חריגה מהמספר הזה, יוחזר הסטטוס הבא:

    res.statusCode = 429; // Too many requests
  • max_connections_hard: (ברירת מחדל: -1) המספר המקסימלי של בקשות בו-זמניות ש-Edge Microgateway יכול לקבל לפני סגירת החיבור. ההגדרה הזו נועדה לסכל התקפות מניעת שירות (DoS). בדרך כלל, מגדירים את המספר למספר גדול יותר מ-max_connections.
  • רישום ביומן:
    • level: (ברירת המחדל: שגיאה)
      • info – רישום כל הבקשות והתשובות שמועברות במכונה של Edge Microgateway.
      • אזהרה – הודעות אזהרה לגבי יומנים בלבד.
      • error - הודעות שגיאה ביומן.
    • dir: (ברירת מחדל: /var/tmp) הספרייה שבה מאוחסנים קובצי היומן.
    • stats_log_interval: (ברירת המחדל: 60) מרווח, בשניות, כאשר רשומת הנתונים הסטטיסטיים נכתבת בקובץ יומן ה-API.
    • סובב_interval: (ברירת מחדל: 24) מרווח, בשעות, בעת רוטציה של קובצי יומן.
  • dir: נתיב יחסי מספריית ./gateway לספריית ./plugins או לנתיב מוחלט.
  • sequency: רשימה של מודולים של יישומי פלאגין, שיש להוסיף למכונה של Edge Microgateway. המודולים יפעלו לפי הסדר שבו הם מפורטים כאן.
  • ניפוי באגים: הוספה של ניפוי באגים מרחוק לתהליך Edge Microgateway.
    • port: מספר היציאה להאזנה. לדוגמה, צריך להגדיר את הכלי לניפוי באגים של IDE כדי להאזין ביציאה הזו.
    • args: ארגומנטים לניפוי באגים. למשל: args --nolazy
  • config_change_poll_interval: (ברירת המחדל: 600 שניות) Edge Microgateway טוען הגדרה חדשה מדי פעם ומבצע טעינה מחדש אם משהו משתנה. כשמשתמשים בסקרים, המערכת קולטת את השינויים שנערכו ב-Edge (שינויים במוצרים, שרתי proxy בעלי מיקרו-שער וכו') ואת השינויים שבוצעו בקובץ התצורה המקומי.
  • disable_config_poll_interval: (ברירת המחדל: false) מגדירים את הערך true כדי להשבית את הסקרים האוטומטיים.
  • request_timeout: קביעת זמן קצוב לתפוגה עבור בקשות יעד. הזמן הקצוב לתפוגה מוגדר בשניות. אם הזמן הקצוב לתפוגה פג, Edge Microgateway מגיב לקוד סטטוס 504. (נוסף גרסה 2.4.x)

מאפייני כותרות

ההגדרות האלה מתייחסות לאופן הטיפול בכותרות מסוימות של HTTP.

  • x-forwarded-for: (ברירת המחדל: true) צריך להגדיר את הערך false כדי למנוע העברה של כותרות X-Forwarded-for ליעד. שימו לב שאם בקשה מסוג X-Forwarded-for תופיע בבקשה, הערך שלה יוגדר לערך client-ip ב-Edge Analytics.
  • x-forwarded-host: (ברירת המחדל: true) צריך להגדיר את הערך false כדי למנוע העברה של כותרות X-Forwarded-host ליעד.
  • x-request-id: (ברירת מחדל: true) צריך להגדיר את הערך false כדי למנוע העברה של כותרות X-request-id ליעד.
  • x-response-time: (ברירת המחדל: true) צריך להגדיר את הערך false כדי למנוע העברה של כותרות מסוג x-response-time ליעד.
  • via: (ברירת מחדל: true) ניתן להגדיר את הערך false כדי למנוע העברה של כותרות אל היעד.

מאפייני oauth

ההגדרות האלה קובעות איך נאכפת אימות הלקוחות על ידי Edge Microgateway.

  • allowNoAuthorization: (ברירת המחדל: FALSE) אם המדיניות מוגדרת כ-TRUE, קריאות ל-API יכולות לעבור דרך Edge Microgateway ללא כותרת הרשאה בכלל. יש להגדיר את הערך כ-false כדי לדרוש כותרת הרשאה (ברירת מחדל).
  • allowinvalidAuthorization: (ברירת המחדל: False), אם הערך הוא True, קריאות ל-API עשויות לעבור אם האסימון שהועבר בכותרת ההרשאה לא תקין או שתוקפו פג. הערך מוגדר כ-false כדי לדרוש אסימונים תקפים (ברירת מחדל).
  • authorization-header: (ברירת המחדל: הרשאה: נושא) הכותרת שמשמשת לשליחת אסימון הגישה אל Edge Microgateway. מומלץ לשנות את ברירת המחדל במקרים שבהם היעד צריך להשתמש בכותרת ההרשאה למטרות אחרות.
  • api-key-header: (ברירת המחדל: x-api-key) השם של הפרמטר או הכותרת של השאילתה שמשמשים להעברת מפתח API ל-Edge Microgateway. למידע נוסף, ראו שימוש במפתח API.
  • keep-authorization-header: (ברירת המחדל: false) אם המדיניות מוגדרת כ-True, כותרת ההרשאה שנשלחת בבקשה מועברת ליעד (היא נשמרת).
  • allowOAuthOnly – אם המדיניות מוגדרת כ-True, כל ממשק API צריך לכלול כותרת הרשאה עם אסימון גישה לדובים. המדיניות מאפשרת לאשר רק את מודל האבטחה של OAuth (עם שמירה על תאימות לאחור). (נוספה 2.4.x)
  • allowAPIKeyOnly – אם המדיניות מוגדרת כ-True, כל API צריך לכלול כותרת x-api-key (או מיקום מותאם אישית) עם מפתח API.מאפשר להשתמש רק במודל האבטחה של מפתח API (אבל תוך שמירה על התאימות לאחור). (נוסף 2.4.x)
  • gracePeriod – הפרמטר הזה עוזר למנוע שגיאות שנגרמו עקב אי-התאמות קלות בין שעון המערכת לבין זמני not before (nbf) או זמני הנפקת הודעות (iat) שצוינו באסימון ההרשאה JWT. מגדירים את הפרמטר הזה למספר השניות כדי לאפשר את אי-ההתאמות. (נוסף 2.5.7)

מאפיינים ספציפיים לפלאגין

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

סינון שרתי proxy

אפשר לסנן אילו שרתי proxy בעלי מיקרו-שערים מעבדים מופע של מיקרו-גייטוויי אדג'. כשאפליקציית Edge Microgateway מתחילה לפעול, היא מורידה את כל שרתי ה-proxy המודעים למיקרו-שירותים בארגון שאליו הוא משויך. שימוש בהגדרה הבאה כדי להגביל את שרתי ה-proxy לעיבוד המיקרו-שער. לדוגמה, ההגדרה הזו מגבילה את שרתי ה-proxy של המיקרו-שער שיעובדו לשלושה: edgemicro_proxy-1, edgemicro_proxy-2 ו-edgemicro_proxy-3:

proxies:
  - edgemicro_proxy-1
  - edgemicro_proxy-2
  - edgemicro_proxy-3

הגדרה של תדירות דחיפת ניתוח הנתונים

תוכלו להשתמש בפרמטרים הבאים של הגדרות כדי לקבוע את התדירות שבה Edge Microgateway שולח נתוני ניתוח ל-Apigee:

  • bufferSize (אופציונלי): המספר המקסימלי של רשומות ניתוח הנתונים שהמאגר יכול לשמור לפני שמתחילים למחוק את הרשומות הישנות ביותר. ברירת מחדל: 10000
  • batchSize (אופציונלי): הגודל המקסימלי של קבוצה של רשומות Analytics שנשלחות אל Apigee. ברירת מחדל: 500
  • flushInterval (אופציונלי): מספר אלפיות השנייה בין כל תעבורה של קבוצה של רשומות ניתוחיות שנשלחו אל Apigee. ברירת מחדל: 5000

לדוגמה:

analytics:
  bufferSize: 15000
  batchSize: 1000
  flushInterval: 6000

אנונימיזציה של נתונים

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

analytics:
  mask_request_uri: 'string_to_mask'
  mask_request_path: 'string_to_mask'

הפרדה בין קריאות ל-API ב-Edge Analytics

אפשר להגדיר את הפלאגין של Analytics להפרדה בין נתיב API ספציפי כך שיופיע כשרת proxy נפרד במרכזי הבקרה של Edge Analytics. לדוגמה, אפשר להפריד את API של בדיקת התקינות במרכז הבקרה כדי למנוע בלבול עם קריאות לשרת proxy של API בפועל. בשרתי proxy של Analytics, שרתי proxy מופרדים פועלים לפי תבנית השמות הזו:

edgemicro_proxyname-health

בתמונה הבאה מוצגים שני שרתי proxy מופרדים בלוח הבקרה של Analytics: edgemicro_hello-health ו-edgemicro_mock-health:

תוכלו להשתמש בפרמטרים הבאים כדי להפריד בין נתיבים יחסיים ובמוחלים במרכז הבקרה של Analytics, דרך שרתי proxy נפרדים:

  • לידPath (אופציונלי): ציון נתיב יחסי להפרדה במרכז הבקרה של Analytics. לדוגמה, אם בוחרים את השדה /healthcheck, כל קריאות ה-API שמכילות את הנתיב /healthcheck יופיעו במרכז הבקרה עם הערך edgemicro_proxyname-health. הערה: הדגל הזה מתעלם מנתיב הבסיס של שרת ה-proxy. כדי להפריד על סמך נתיב מלא, כולל basepath, משתמשים בסימון proxyPath.
  • proxyPath (אופציונלי): מציין נתיב מלא לשרת proxy של API, כולל הנתיב הבסיסי של שרת ה-proxy, להפרדה במרכז הבקרה של Analytics. לדוגמה, אם מציינים את השדה /mocktarget/healthcheck כאשר /mocktarget הוא נתיב הבסיס של שרת ה-proxy, כל הקריאות ל-API עם הנתיב /mocktarget/healthcheck יופיעו במרכז השליטה כ-edgemicro_proxyname-health.

לדוגמה, בהגדרה הבאה, כל נתיב API שמכיל /healthcheck יופרד באמצעות הפלאגין של Analytics. המשמעות היא ש-/foo/healthcheck ו-/foo/bar/healthcheck יופרדו כשרת proxy נפרד בשם edgemicro_proxyname-health במרכז הבקרה של Analytics.

analytics:
  uri: >-
    https://xx/edgemicro/ax/org/docs/environment/test
  bufferSize: 100
  batchSize: 50
  flushInterval: 500
  relativePath: /healthcheck

בהגדרה הבאה, כל ממשק API עם נתיב שרת ה-proxy /mocktarget/healthcheck יופרד בתור שרת proxy נפרד בשם edgemicro_proxyname-health במרכז הבקרה של Analytics.

analytics:
  uri: >-
    https://xx/edgemicro/ax/org/docs/environment/test
  bufferSize: 100
  batchSize: 50
  flushInterval: 500
  proxyPath: /mocktarget/healthcheck

הגדרת מיקרו-שער של Edge מאחורי חומת אש של החברה

גרסה 2.4.x נתמכת

אם Edge Microgateway מותקן מאחורי חומת אש, ייתכן שהשער לא יוכל לתקשר עם Apigee Edge. במקרה כזה, יש שתי אפשרויות שכדאי לשקול:

אפשרות 1:

האפשרות הראשונה היא להגדיר את האפשרות edgemicro: proxy_tunnel כ-true בקובץ ה-config של microgateway:

edge_config:

    proxy: http://10.224.16.85:3128
    proxy_tunnel: true

כאשר proxy_tunnl הוא true, Edge Microgateway משתמש בשיטת HTTP CONNECT כדי להעביר בקשות HTTP בחיבור TCP יחיד. (כך גם אם משתני הסביבה להגדרת שרת ה-proxy מופעלים באמצעות TLS).

אפשרות 2:

האפשרות השנייה היא לציין שרת proxy והגדיר את proxy_tunnel ל-false בקובץ התצורה של microgateway. לדוגמה:

edge_config:
     proxy: http://10.224.16.85:3128
     proxy_tunnel: false

במקרה כזה, ניתן להגדיר את המשתנים הבאים כדי לשלוט במארחים של כל שרת proxy ל-HTTP שבו אתם רוצים להשתמש, או לקבוע אילו מארחים לא יטפלו בשרתי proxy של Edge Microgateway: HTTP_PROXY, HTTPS_PROXY ו-NO_PROXY.

אפשר להגדיר את NO_PROXY כרשימה של דומיינים המופרדים בפסיקים, שלא מומלץ לשרת proxy ב-Edge. לדוגמה:

export NO_PROXY='localhost,localhost:8080'

מגדירים את HTTP_PROXY ואת HTTPS_PROXY לנקודת הקצה של HTTP Edge Microgateway, שיכולים לשלוח אליו הודעות. לדוגמה:

export HTTP_PROXY='http://localhost:3786'

export HTTPS_PROXY='https://localhost:3786'

מידע נוסף על המשתנים האלה זמין בכתובת https://www.npmjs.com/package/request#controlling-proxy-behaviour-using-environment-variables

כדאי לעיין גם בפרטים הבאים

איך מגדירים את Microgateway Edge מאחורי חומת אש של חברה בקהילת Apigee.

שימוש בתווים כלליים לחיפוש בשרתי proxy ב-Microgateway

אפשר להשתמש בתווים כלליים לחיפוש "*" או יותר בנתיב הבסיס של שרת proxy מסוג edgemicro_* (Microgateway-מודרני). לדוגמה, נתיב בסיס של /team/*/members מאפשר ללקוחות להתקשר אל https://[host]/team/blue/members ו- https://[host]/team/green/members בלי שתצטרכו ליצור שרתי proxy חדשים כדי לתמוך בצוותים חדשים. לתשומת ליבך: /**/ לא נתמך.

חשוב: אי אפשר להשתמש בתו כללי לחיפוש "*" כרכיב הראשון של הנתיב הבסיסי. לדוגמה, תכונה זו אינה נתמכת: חיפוש /*/.

שימוש במפתחות JWT מסתובבים

בשלב מסוים אחרי יצירת JWT, יכול להיות שתצטרכו לשנות את זוג המפתחות הציבורי/פרטי ששמור ב-KVM המוצפן של Edge. התהליך הזה של יצירת זוג מפתחות חדש נקרא רוטציית מפתחות.

איך Edge Microgateway משתמש ב-JWT

אסימון אינטרנט מסוג JSON (JWT) הוא תקן אסימון שמתואר ב-RFC7519. JWT מספק דרך לחתימה על קבוצה של תלונות, שניתן לאמת אותן באופן מהימן על ידי הנמען של JWT.

Edge Microgateway משתמש ב-JWT כאסימונים נושאים לאבטחת OAuth. כשיוצרים אסימון OAuth עבור Edge Microgateway, מקבלים JWT בחזרה. לאחר מכן אפשר להשתמש ב-JWT בכותרת ההרשאה של קריאות ל-API. לדוגמה:

curl -i http://localhost:8000/hello -H "Authorization: Bearer eyJhbGciOiJ..dXDefZEA"

יצירת JWT חדש

אפשר ליצור JWT ל-Edge של Microgateway באמצעות הפקודה edgemicro token או ה-API. לדוגמה:

edgemicro token get -o docs -e test -i G0IAeU864EtBo99NvUbn6Z4CBwVcS2 -s uzHTbwNWvoSmOy

הפקודה מבקשת מ-Apigee Edge ליצור JWT שיכול לשמש לאימות קריאות ל-API. הפרמטרים -i ו--s הם מזהה הצרכן והערכים הסודיים של מפתח האפליקציה בארגון שלך ב-Apigee Edge.

לחלופין, אפשר ליצור JWT באמצעות API לניהול:

curl -i -X POST "http://org-env.apigee.net/edgemicro-auth/token" \
  -H "Content-Type: application/json" \
  -d '{
    "client_id": "your consumer key",
    "client_secret": "your consumer secret",
    "grant_type": "client_credentials"
  }'

כאשר:

  • org הוא שם הארגון שלך ב-Edge (עליך להיות מנהל מערכת בארגון).
  • env היא סביבה בארגון שלך (כגון "test" או "prod").
  • client_id הוא מזהה הצרכן באפליקציה למפתחים שיצרת בעבר.
  • client_secret הוא סוד הצרכן באפליקציה למפתחים שיצרתם קודם.

מהו סבב מפתחות?

בשלב מסוים אחרי יצירת JWT, יכול להיות שתצטרכו לשנות את זוג המפתחות הציבורי/פרטי ששמור ב-KVM המוצפן של Edge. התהליך הזה של יצירת זוג מפתחות חדש נקרא רוטציית מפתחות. כשאתם מבצעים רוטציה למפתחות, זוג מפתחות פרטיים/ציבוריים חדשים נוצר ונשמר ב-KVM של "מיקרו-שער" בארגון/בסביבה של Apigee Edge. בנוסף, המפתח הציבורי הקודם נשמר יחד עם ערך המפתח המקורי שלו.

כדי ליצור JWT, ב-Edge נעשה שימוש במידע שמאוחסן ב-KVM המוצפן. KVM בשם microgateway נוצר ומאוכלס באמצעות מפתחות כשהגדרתם (הוגדר) Edge Microgateway. המפתחות ב-KVM משמשים לחתימה על JWT ולהצפנתו.

מפתחות ה-KVM כוללים:

  • private_key – המפתח הפרטי האחרון (שנוצר לאחרונה) מסוג RSA המשמש לחתימה על JWTs.

  • public_key – האישור האחרון (שנוצר לאחרונה) המשמש לאימות JWTs שנחתם באמצעות key_key.

  • private_key_kid – המזהה של המפתח הפרטי האחרון (שנוצר לאחרונה). מזהה המפתח הזה משויך לערך private_key, והוא משמש לתמיכה ברוטציית המפתחות.

  • public_key1_kid – מזהה המפתח הציבורי האחרון (שנוצר לאחרונה). המפתח הזה משויך לערך public_key1 והוא משמש לתמיכה ברוטציית המפתחות. הערך הזה זהה לצאצא של המפתח הפרטי.

  • public_key1 – המפתח הציבורי האחרון (שנוצר לאחרונה).

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

  • public_key2_kid – מזהה המפתח הציבורי הישן. המפתח הזה משויך לערך public_key2 והוא משמש לתמיכה ברוטציית המפתחות.

  • public_key2 – המפתח הציבורי הישן.

מספרי JWT שנשלחים לאימות יאומתו באמצעות המפתח הציבורי החדש. אם האימות ייכשל, ייעשה שימוש במפתח הציבורי הישן, עד שתוקפו יפוג (לאחר 30 דקות). כך ניתן "לסובב" את המפתחות בלי להפריע לתנועה של ה-API באופן מיידי.

איך מבצעים רוטציית מפתחות

בקטע הזה מוסבר איך מבצעים רוטציית מפתחות.

אם הגדרת את המופע של Edge Microgateway לפני גרסה 2.5.2

אם הגדרת את מכונת Edge Edge Microgateway לפני גרסה 2.5.2, צריך להריץ את שתי הפקודות הבאות כדי לשדרג את ה-KVM ואת מדיניות האימות:

upgradekvm -o org -e env -u username

מידע נוסף על הפקודה הזו זמין במאמר שדרוג של ה-KVM.

הפקודה הבאה משדרגת את שרת ה-proxy של edgemicro-oauth שנפרס לארגון Apigee שלך כשהגדרת את Edge Microgateway. שרת ה-proxy הזה מספק שירותים הנדרשים ליצירת אסימונים. 

upgradeauth -o org -e env -u username

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

ביצוע רוטציה למפתחות

מוסיפים את השורה הבאה לקובץ ~/.edgemicro/org-env-config.yaml, שבו צריך לציין את אותו ארגון ואותה סביבה שבהם הגדרתם את המיקרו-שער לשימוש:

jwk_public_keys: 'https://org-env.apigee.net/edgemicro-auth/jwkPublicKeys'

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

edgemicro rotatekey -o org -e env -u username -k kid_value

לדוגמה:

edgemicro rotatekey -o jdoe -e test -u jdoe@google.com -k 2
current nodejs version is v6.9.1
current edgemicro version is 2.5.7
password:
Checking if private key exists in the KVM...
Checking for certificate...
Found Certificate
Generating New key/cert pair...
Extract new public key
Key Rotation successfully completed!

הפרמטר -k מציין מזהה מפתח (ילד). המזהה הזה משמש להתאמה למפתח מסוים. Edge Microgateway משתמש בערך הזה כדי לבחור מתוך קבוצה של מפתחות במהלך סיבוב המפתחות. למידע נוסף, ראו סעיף 4.5 במפרט של מפתח האינטרנט JSON.

לאחר סיבוב המפתחות, Edge מחזיר מספר מפתחות ל-Edge Microgateway. הערה בדוגמה הבאה, לכל מפתח יש ערך "kid" (מזהה מפתח) ייחודי. המיקרו-שער משתמש במפתחות האלה כדי לאמת את אסימוני ההרשאה. אם אימות האסימון נכשל, המיקרו-שער בודק אם יש מפתח ישן יותר בקבוצת המפתחות ומנסה להפעיל אותו. הפורמט של המפתחות שהוחזרו הוא JSON Web Key (JWK). אפשר לקרוא על הפורמט הזה ב-RFC 7517.

{
  "keys": [
    {
      "kty": "RSA",
      "n": "nSl7R_0wKLiWi6cO3n8aOJwYGBtinq723Jgg8i7KKWTSTYoszOjgGsJf_MX4JEW1YCScwpE5o4o8ccQN09iHVTlIhk8CNiMZNPipClmRVjaL_8IWvMQp1iN66qy4ldWXzXnHfivUZZogCkBNqCz7VSC5rw2Jf57pdViULVvVDGwTgf46sYveW_6h8CAGaD0KLd3vZffxIkoJubh0yMy0mQP3aDOeIGf_akeZeZ6GzF7ltbKGd954iNTiKmdm8IKhz6Y3gLpC9iwQ-kex_j0CnO_daHl1coYxUSCIdv4ziWIeM3dmjQ5_2dEvUDIGG6_Az9hTpNgPE5J1tvrOHAmunQ",
      "e": "AQAB",
      "kid": "2"
    },
    {
      "kty": "RSA",
      "n": "8BKwzx34BMUcHwTuQtmp8LFRCMxbkKg_zsWD6eOMIUTAsORexTGJsTy7z-4aH0wJ3fT-3luAAUPLBQwGcuHo0P1JnbtPrpuYjaJKSZOeIMOnlryJCspmv-1xG4qAqQ9XaZ9C97oecuj7MMoNwuaZno5MvsY-oi5B_gqED3vIHUjaWCErd4reONyFSWn047dvpE6mwRhZbcOTkAHT8ZyKkHISzopkFg8CD-Mij12unxA3ldcTV7yaviXgxd3eFSD1_Z4L7ZRsDUukCJkJ-8qY2-GWjewzoxl-mAW9D1tLK6qAdc89yFem3JHRW6L1le3YK37-bs6b2a_AqJKsKm5bWw",
      "e": "AQAB",
      "kid": "1"
    }
  ]
}

מתבצע סינון של שרתי proxy שהורדו

כברירת מחדל, אפליקציית Edge Microgateway מורידה את כל שרתי ה-proxy בארגון Edge שלך, שמתחילה בקידומת 'edgemicro_'. ניתן לשנות את ברירת המחדל הזו כדי להוריד שרתי proxy שהשמות שלהם תואמים לתבנית.

  1. פותחים את קובץ התצורה של Edge Micro: ~/.edgemicro/org-env-config.yaml
  2. צריך להוסיף את הרכיב proxyPattern בקטע edge_config. לדוגמה, הדפוס הבא יוריד שרתי proxy כמו edgemicro_foo, edgemicro_speed ו-edgemicro_first. 
    edge_config:
…
proxyPattern: edgemicro_f*

ציון מוצרים ללא שרתי proxy של API

ב-Apigee Edge אפשר ליצור מוצר API שלא מכיל שרתי proxy של API. ההגדרה האישית של המוצר מאפשרת למפתח API המשויך למוצר הזה לעבוד עם כל שרת proxy שנפרס בארגון שלך. החל מגרסה 2.5.4, Edge Microgateway תומך בהגדרת המוצר הזו.

ניפוי באגים ופתרון בעיות

מתחבר לכלי לניפוי באגים

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

  1. יש להפעיל מחדש את Edge Microgateway במצב ניפוי באגים. כדי לעשות את זה, מוסיפים DEBUG=* בתחילת הפקודה start. לדוגמה: 
    DEBUG=* edgemicro start -o  myorg -e test -k
      db4e9e8a95aa7fabfdeacbb1169d0a8cbe42bec19c6b98129e02 -s
      6e56af7c1b26dfe93dae78a735c8afc9796b077d105ae5618ce7ed
  2. מפעילים את הכלי לניפוי באגים ומגדירים אותו להאזנה במספר היציאה של התהליך לניפוי באגים.
  3. עכשיו אפשר להתקדם עם הקוד של Microgateway Edge, להגדיר נקודות עצירה, ביטויים לצפייה ועוד.

אפשר לציין סימונים רגילים של Node.js שקשורים למצב ניפוי באגים. לדוגמה, --nolazy מסייע לניפוי באגים בקוד אסינכרוני.

קובצי יומן בבדיקה

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

שימוש במפתחות אבטחה ל-API

מפתחות API מספקים מנגנון פשוט לאימות לקוחות ששולחים בקשות ל-Microsoft Edgeway. כדי לקבל מפתח API, מעתיקים את הערך של מפתח הצרכן (שנקרא גם Client ID) ממוצר Apigee Edge שכולל את שרת ה-proxy של Edge Microgateway.

שמירת מפתחות במטמון

אסימוני ה-API מוחלפים באסימונים של דובים, ששמורים במטמון. אפשר להשבית את השמירה במטמון על ידי הגדרת הכותרת Cache-Control: no-cache בבקשות נכנסות ל-Microsoft Edgeway.

שימוש במפתח API

אתם יכולים להעביר את מפתח ה-API בבקשת API כפרמטר של שאילתה או ככותרת. כברירת מחדל, הכותרת ושם הפרמטר של השאילתה הם x-api-key.

דוגמה לפרמטר שאילתה:

curl http://localhost:8000/foobar?x-api-key=JG616Gjz7xs4t0dvpvVsGdI49G34xGsz

דוגמה לכותרת:

curl http://localhost:8000/foobar -H "x-api-key:JG616Gjz7xs4t0dvpvVsGdI49G34xGsz"

הגדרת השם של מפתח ה-API

כברירת מחדל, x-api-key הוא השם המשמש לכותרת של מפתח ה-API ולפרמטר השאילתה. תוכלו לשנות את ברירת המחדל הזו בקובץ התצורה, כפי שמוסבר בעריכת ההגדרות. לדוגמה, כדי לשנות את השם ל-apiKey:

oauth:
  allowNoAuthorization: false
  allowInvalidAuthorization: false
  api-key-header: apiKey

בדוגמה הזו, פרמטר השאילתה ושם הכותרת משתנים ל-apiKey. השם x-api-key לא יפעל יותר באף אחד מהמקרים. למידע נוסף, ראו שינויים בהגדרות.

לדוגמה:

curl http://localhost:8000/foobar -H "apiKey:JG616Gjz7xs4t0dvpvVsGdI49G34xGsz"

מידע נוסף על השימוש במפתחות API בבקשות של שרתי proxy זמין במאמר Secure Edge Microgateway.

שימוש באבטחת אסימון OAuth2

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

איך לקבל אסימון גישה

בקטע הזה מוסבר איך להשתמש בשרת proxy של edgemicro-auth כדי לקבל אסימון גישה.

אפשר לקבל אסימון גישה גם באמצעות הפקודה CLI של edgemicro token. לפרטים נוספים על ה-CLI, אפשר לעיין במאמר ניהול אסימונים.

API 1

מחליפים את שמות הארגון והסביבה בכתובת ה-URL ומחליפים את ערכי מזהה הצרכן והצרכן הסודיים שמקורם באפליקציה למפתחים ב-Apigee Edge בפרמטרים client_id ו-client_secret:

curl -i -X POST "http://<org>-<test>.apigee.net/edgemicro-auth/token" \
-d '{"grant_type": "client_credentials", "client_id": "your_client_id", \
"client_secret": "your_client_secret"}' -H "Content-Type: application/json"

API 2

(נוסף בגרסה 2.5.31) שולחים את פרטי הכניסה של הלקוח ככותרת אימות בסיסי ואת grant_type כפרמטר של טופס. עוד נסביר על טופס הפקודות הזה גם ב-RFC 6749: OAuth 2.0 Authorization Framework. 
http://<org>-<test>.apigee.net/edgemicro-auth/token -v -u your_client_id:your_client_secret \
-d 'grant_type=client_credentials' -H "Content-Type: application/x-www-form-urlencoded"

פלט לדוגמה

ה-API מחזיר תגובת JSON. חשוב לזכור שאין הבדל בין הנכס token לבין המאפיין access_token. אפשר להשתמש בכל אחת מהן. 
{
"token": "eyJraWQiOiIxIiwidHlwIjoi",
"access_token": "eyJraWQiOiIxIiwid",
"token_type": "bearer",
"expires_in": "108000"
}

איך מקבלים אסימון רענון

כדי לקבל אסימון רענון, צריך לבצע קריאה ל-API של נקודת הקצה /token של שרת ה-proxy מסוג edgemicro-auth. צריך לבצע את הקריאה הזו ל-API עם סוג המענק password. אלו השלבים לביצוע התהליך.

  1. אסימון גישה ורענון עם ה-API של /token. הערה: סוג המענק הוא password: 
    curl -X POST \
  https://your_organization-your_environment.apigee.net/edgemicro-auth/token \
  -H 'Content-Type: application/json' \
  -d '{
   "client_id":"mpK6l1Bx9oE5zLdifoDbF931TDnDtLq",
   "client_secret":"bUdDcFgv3nXffnU",
   "grant_type":"password",
   "username":"mpK6lBx9RoE5LiffoDbpF931TDnDtLq",
   "password":"bUdD2FvnMsXffnU"
}'

    ה-API מחזיר אסימון גישה ואסימון רענון. התשובה נראית כך: 

    {
    "token": "your-access-token",
    "access_token": "your-access-token",
    "token_type": "bearer",
    "expires_in": "108000",
    "refresh_token": "your-refresh-token",
    "refresh_token_expires_in": "431999",
    "refresh_token_issued_at": "1562087304302",
    "refresh_token_status": "approved"
}
  2. עכשיו אפשר להשתמש באסימון הרענון כדי לקבל אסימון גישה חדש. לשם כך, יש לקרוא לנקודת הקצה /refresh. למשל: 
    curl -X POST \
  https://willwitman-test.apigee.net/edgemicro-auth/refresh \
  -H 'Content-Type: application/json' \
  -d '{
   "client_id":"mpK6l1Bx9RoE5zLifoDbpF931TDnDtLq",
   "client_secret":"bUdDc2Fv3nMXffnU",
   "grant_type":"refresh_token",
   "refresh_token":"your-refresh-token"
}'

    ה-API מחזיר אסימון גישה חדש. התשובה נראית כך: 

    {
    "token": "your-new-access-token"
    }

מעקב לתמיד

Forever הוא כלי Node.js שמפעיל מחדש באופן אוטומטי אפליקציית Node.js במקרה שהתהליך קורס או מכיל שגיאה. ל-Edge Microgateway יש קובץ forever.json, שניתן להגדיר כדי לקבוע כמה פעמים ובאילו מרווחי הפעלה מחדש יש להפעיל את Microgateway Edge. בקובץ הזה מוגדר שירות 'לתמיד' בשם Forever-monitor, המשמש לניהול פרוגרמטי באופן סופי.

תוכלו למצוא את הקובץ forever.json בספריית ההתקנה של Edge Microgateway. למידע נוסף, קראו את המאמר איפה מותקן Microgateway Edge. לפרטים על אפשרויות ההגדרה, אפשר לעיין במסמכי התיעוד למעקב קבוע.

הפקודה edgemicro forever כוללת סימונים שמאפשרים לציין את המיקום של קובץ ה-forever.json (הסימון -f) ולהתחיל את תהליך המעקב לצמיתות (הסימון -a). לדוגמה:

edgemicro forever -f ~/mydir/forever.json -a start

למידע נוסף, עיינו במעקב תמידי בחומר העזר בנושא CLI.

ציון נקודת קצה (endpoint) של קובץ config

אם יש לך מספר מכונות של Microgateway Edge, כדאי לנהל את ההגדרות שלהן במקום אחד. אפשר לעשות זאת על ידי ציון נקודת קצה (endpoint) של HTTP, שבה אפשר להוריד את קובץ התצורה של Edge Micro. אפשר לציין את נקודת הקצה הזו כשפותחים את Edge Micro באמצעות הסימון -u.

לדוגמה:

edgemicro start -o jdoe -e test -u http://mylocalserver/mgconfig -k public_key -s secret_key

כאשר נקודת הקצה של mgconfig מחזירה את התוכן של קובץ התצורה. הקובץ הזה, שנמצא כברירת מחדל, נמצא ב-~/.edgemicro ואפשר להשתמש בו במוסכמה למתן שמות: org-env-config.yaml.

השבתה של אגירת נתונים של חיבור TCP

ניתן להשתמש במאפיין התצורה nodelay כדי להשבית את אחסון הנתונים הזמני עבור חיבורי TCP המשמשים את Edge Microgateway.

כברירת מחדל, חיבורי TCP משתמשים באלגוריתם Nagle כדי לאחסן נתונים במאגר לפני שליחתם. הגדרה של nodelay כ-true משביתה את ההתנהגות הזו (הנתונים יופעלו באופן מיידי בכל פעם שקריאה ל-socket.write() תתבצע). לפרטים נוספים, אפשר לעיין במסמכי התיעוד של Node.js.

כדי להפעיל את nodelay, צריך לערוך את קובץ התצורה של Edge Micro כך:

edgemicro:
  nodelay: true
  port: 8000
  max_connections: 1000
  config_change_poll_interval: 600
  logging:
    level: error
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24

מיקרו שער של Edge מופעל במצב עצמאי

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

בתכונות הבאות, התכונות הבאות לא פועלות כי הן מחייבות חיבור ל-Apigee Edge:

  • מפתח OAuth ומפתח API
  • מכסה
  • ניתוח נתונים

מצד שני, יישומי פלאגין מותאמים אישית ועצור מעקף פועלים כרגיל, כי הם לא דורשים חיבור ל-Apigee Edge. בנוסף, פלאגין חדש בשם extauth מאפשר לכם לאשר קריאות ל-API למיקרו-שער באמצעות JWT, במצב עצמאי.

הגדרה ופתיחה של השער

כדי להריץ את Edge Microgateway במצב עצמאי:

  1. ודאו ש-Edge Microgateway מגרסה 2.5.25 ואילך. אם לא, צריך לבצע את הפקודה הבאה כדי לשדרג לגרסה האחרונה: 
    npm install -g edgemicro

    אם דרושה לך עזרה, כדאי לעיין במאמר התקנת Edge Microgateway.

  2. יוצרים קובץ תצורה בשם הבא: $HOME/.edgemicro/org_name-env_name-config.yaml

    לדוגמה:

    vi $HOME/.edgemicro/foo-bar-config.yaml
  3. מדביקים את הקוד הבא בקובץ: 
    edgemicro:
  port: 8000
  max_connections: 1000
  config_change_poll_interval: 600
  logging:
    level: error
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24
  plugins:
    sequence:
      - extauth
      - spikearrest
headers:
  x-forwarded-for: true
  x-forwarded-host: true
  x-request-id: true
  x-response-time: true
  via: true
extauth:
  publickey_url: https://www.googleapis.com/oauth2/v1/certs
spikearrest:
  timeUnit: second
  allow: 10
  buffersize: 0
  4. מייצאים את משתנה הסביבה הבא עם הערך '1': 
    export EDGEMICRO_LOCAL=1
  5. מריצים את הפקודה start הבאה, שבה מזינים ערכים ליצירת שרת ה-proxy המקומי: 
    edgemicro start -o org_name -e environment_name -a local_proxy_name \
  -v local_proxy_version -t target_url -b base_path

    כאשר:

    • your_org הוא השם ה "ארגון" שבו השתמשת בשם קובץ התצורה.
    • your_environment הוא השם "env" שבו השתמשת בשם קובץ התצורה.
    • local_proxy_name הוא השם של שרת ה-proxy המקומי שנוצר. אפשר להשתמש בכל שם שרוצים.
    • local_proxy_version הוא מספר הגרסה של שרת ה-proxy.
    • target_url היא כתובת ה-URL של היעד של שרת ה-proxy. (היעד הוא השירות שאליו שרת ה-proxy קורא).
    • base_path הוא הנתיב הבסיסי של שרת ה-proxy. ערך זה חייב להתחיל בקו נטוי. בנתיב בסיס של בסיס, יש לציין רק קו נטוי לפנים. לדוגמה, "/".

    לדוגמה:

    edgemicro start -o local -e test -a proxy1 -v 1 -t http://mocktarget.apigee.net -b /
  6. בודקים את ההגדרה. 
    curl http://localhost:8000/echo  { "error" : "missing_authorization" }

    מכיוון שהפלאגין extauth נמצא בקובץ foo-bar-config.yaml, מופיעה השגיאה "missing_authorization". הפלאגין הזה מאמת JWT שחייב להיות קיים בכותרת ההרשאה של הקריאה ל-API. בקטע הבא תגלו פונקציית JWT שתאפשר לקריאות ל-API לעבור ללא השגיאה.

דוגמה: קבלת אסימון הרשאה

הדוגמה הבאה מראה איך להשיג JWT מנקודת הקצה של Edge Microgateway JWT ב-Apigee Edge (edgemicro-auth/jwkPublicKeys). נקודת הקצה הזו נפרסת כשמבצעים הגדרה רגילה של Edge Microgateway. כדי להשיג את ה-JWT מנקודת הקצה של Apigee, עליך לבצע תחילה את ההגדרה הרגילה של Edge Microgateway להיות מחובר לאינטרנט. נקודת הקצה Apigee משמשת כאן למטרות לדוגמה בלבד, ואינה נדרשת. אם רוצים, אפשר להשתמש בנקודת קצה אחרת של אסימון JWT. אם תעשו זאת, תצטרכו להשיג את ה-JWT באמצעות ה-API שסופק עבור נקודת הקצה.

בשלבים הבאים נסביר איך לקבל אסימון באמצעות נקודת הקצה edgemicro-auth/jwkPublicKeys:

  1. כדי לפרוס את שרת ה-proxy של edgemicro-auth לארגון או לסביבה שלך ב-Apigee Edge, צריך לבצע הגדרה ותצורה רגילות של Edge Microgateway. אם ביצעתם את השלב הזה בעבר, אין צורך לחזור עליו.
  2. אם פרסתם את Edge Microgateway ל-Apigee Cloud, אתם צריכים להיות מחוברים לאינטרנט כדי לקבל JWT מנקודת הקצה הזו.
  3. הפסקת מיקרו-שער לשוליים: 
    edgemicro stop
  4. בקובץ התצורה שיצרת בעבר ($HOME/.edgemicro/org-env-config.yaml), עליך להפנות את המאפיין extauth:publickey_url לנקודת הקצה edgemicro-auth/jwkPublicKeys בארגון/בסביבה של Apigee Edge. למשל: 
    extauth:
  publickey_url: 'https://your_org-your_env.apigee.net/edgemicro-auth/jwkPublicKeys'
  5. יש להפעיל מחדש את Edge Microgateway כמו קודם, באמצעות שמות הארגון/env שבהם השתמשת בשם של קובץ התצורה. למשל: 
    edgemicro start -o foo -e bar -a proxy1 -v 1 -t http://mocktarget.apigee.net -b /
  6. קבלת אסימון JWT מנקודת הקצה של ההרשאה. מכיוון שנעשה שימוש בedgemicro-auth/jwkPublicKeys נקודת הקצה של CLI, אפשר להשתמש בפקודת ה-CLI הזו:

אפשר ליצור JWT ל-Edge של Microgateway באמצעות הפקודה edgemicro token או ה-API. לדוגמה:

edgemicro token get -o your_org -e your_env \
  -i G0IAeU864EtBo99NvUbn6Z4CBwVcS2 -s uzHTbwNWvoSmOy

כאשר:

  • your_org הוא השם של ארגון Apigee שלך, שעבורו הגדרת בעבר את Edge Microgateway.
  • your_env היא סביבה בארגון.
  • האפשרות i מציינת את מפתח הצרכן מאפליקציה למפתחים שכוללת מוצר שכולל את שרת ה-proxy של edgemicro-auth.
  • האפשרות s מציינת את סוד הצרכן מאפליקציה למפתחים הכוללת מוצר שכולל את שרת ה-proxy של edgemicro-auth.

הפקודה מבקשת מ-Apigee Edge ליצור JWT שיכול לשמש לאימות קריאות ל-API.

כדאי לעיין גם במאמר יצירת אסימון.

בדיקה של ההגדרות האישיות

כדי לבדוק את ההגדרה, צריך לקרוא ל-API עם האסימון שנוסף בכותרת ההרשאה כך:

curl http://localhost:8000/echo -H "Authorization: Bearer your_token

דוגמה:

curl http://localhost:8000/echo -H "Authorization: Bearer eyJraWQiOiIxIiwidHlwIjo...iryF3kwcDWNv7OQ"

פלט לדוגמה:

{
   "headers":{
      "user-agent":"curl/7.54.0",
      "accept":"*/*",
      "x-api-key":"DvUdLlFwG9AvGGpEgfnNGwtvaXIlUUvP",
      "client_received_start_timestamp":"1535134472699",
      "x-authorization-claims":"eyJhdDbiO...M1OTE5MTA1NDkifQ==",
      "target_sent_start_timestamp":"1535134472702",
      "x-request-id":"678e3080-a7ae-11e8-a70f-87ae30db3896.8cc81cb0-a7c9-11e8-a70f-87ae30db3896",
      "x-forwarded-proto":"http",
      "x-forwarded-host":"localhost:8000",
      "host":"mocktarget.apigee.net",
      "x-cloud-trace-context":"e2ac4fa0112c2d76237e5473714f1c85/1746478453618419513",
      "via":"1.1 localhost, 1.1 google",
      "x-forwarded-for":"::1, 216.98.205.223, 35.227.194.212",
      "connection":"Keep-Alive"
   },
   "method":"GET",
   "url":"/",
   "body":""
}

שימוש במצב שרת proxy מקומי

במצב שרת proxy מקומי, אין צורך לפרוס את Edge Microgateway המבוסס על מיקרו-שערים ב-Apigee Edge. במקום זאת, צריך להגדיר "שרת proxy מקומי" על ידי ציון שם של שרת proxy מקומי, basebase וכתובת URL של יעד כשמתחילים את המיקרו-שער. קריאות ל-API למיקרו-שערים נשלחות לכתובת היעד של שרת ה-proxy המקומי. בכל שאר ההיבטים, מצב שרת proxy מקומי פועל בדיוק כמו הפעלה של Edge Microgateway במצב הרגיל. האימות פועל באותו אופן, וכן אכיפה של השהיית עומסים ומכסות, יישומי פלאגין מותאמים אישית וכן הלאה.

תרחיש לדוגמה ודוגמה

מצב שרת proxy מקומי שימושי כאשר צריך לשייך רק שרת proxy אחד למכונה של Edge Microgateway. לדוגמה, אפשר להחדיר את Microgateway Edge ל-Kubernetes כשרת צדדי, שבו מיקרו-שער ושירות מופעלים במוט אחד, כאשר המיקרו-גייטוויי מנהל את תעבורת הנתונים לשירותים הנלווים. האיור הבא ממחיש את הארכיטקטורה הזו, כאשר Edge Edge Microgateway פועל כשרת Proxy של צד שלישי באשכול של Kubernetes. כל מכונה של מיקרו-שער מדברת רק אל נקודת קצה אחת בשירות המלווה שלה:

אדג&#39;מיקרו בתור Sidecar

אחד היתרונות של ארכיטקטורת הארכיטקטורה הזו הוא ש-Edge Microgateway מספק ניהול API לשירותים נפרדים שנפרסים בסביבת קונטיינרים, כמו אשכול של Kubernetes.

הגדרת מצב שרת proxy מקומי

כדי להגדיר את Edge Microgateway לפעולה במצב שרת proxy מקומי, יש לבצע את השלבים הבאים:

  1. ודאו ש-Edge Microgateway מגרסה 2.5.25 ואילך. אם לא, צריך לבצע את הפקודה הבאה כדי לשדרג לגרסה האחרונה: 
    npm install -g edgemicro

    אם דרושה לך עזרה, כדאי לעיין במאמר התקנת Edge Microgateway.

  2. מריצים את הפקודה edgemicro init כדי להגדיר את סביבת ההגדרה המקומית, בדיוק כפי שמגדירים בהגדרת Microgateway אופיינית של Edge. למידע נוסף, ראו הגדרת מיקרו-שער של Edge.
  3. מריצים את edgemicro configure, בדיוק כמו שעושים בהליך אופייני של Edge Microgateway. למשל: 
    edgemicro configure -o your_org -e your_env -u your_apigee_username

    הפקודה הזו פורסת את המדיניות edgemicro-auth ל-Edge ומחזירה מפתח וסוד הדרושים למיקרו-שער. אם אתם זקוקים לעזרה, כדאי לעיין במאמר הגדרת Edge Microgateway.

  4. ב-Apigee Edge, יוצרים מוצר API ועומדים בדרישות הבאות לגבי הגדרות אישיות (אפשר לנהל את כל שאר ההגדרות כרצונכם):
    • חובה להוסיף את שרת ה-proxy של edgemicro-auth למוצר. שרת ה-proxy הזה נפרס באופן אוטומטי כשהפעלת את edgemicro configure.
    • עליכם לספק נתיב של משאב. ההמלצה של Apigee היא להוסיף את הנתיב הזה למוצר: /**. מידע נוסף זמין במאמר הגדרת ההתנהגות של נתיב המשאב. למידע נוסף, ראו יצירת מוצרי API במסמכי התיעוד של Edge.

  5. ב-Apigee Edge תוכלו ליצור מפתח, או להשתמש במפתח קיים, אם תרצו. לקבלת עזרה, אפשר לעיין במאמר הוספת מפתחים באמצעות ממשק המשתמש לניהול Edge.

  6. ב-Apigee Edge, צריך ליצור אפליקציה למפתחים. חובה להוסיף את מוצר ה-API שיצרת לאפליקציה. לקבלת עזרה, יש לעיין במאמר רישום אפליקציה בממשק המשתמש לניהול Edge.
  7. במחשב שבו מותקן Edge Microgateway, מייצאים את משתנה הסביבה הבא עם הערך "1". 
    export EDGEMICRO_LOCAL_PROXY=1
  8. מריצים את הפקודה start הבאה: 
    edgemicro start -o your_org -e your_environment -k your_key -s your_secret \
    -a local_proxy_name -v local_proxy_version -t target_url -b base_path

    כאשר:

    • your_org הוא ארגון Apigee שלך.
    • your_environment היא סביבה בארגון שלך.
    • your_key הוא המפתח שהוחזר כשהפעלת את edgemicro configure.
    • your_secret הוא הסוד שהוחזר כשהפעלת את edgemicro configure.
    • local_proxy_name הוא השם של שרת ה-proxy המקומי שנוצר.
    • local_proxy_version הוא מספר הגרסה של שרת ה-proxy.
    • target_url היא כתובת ה-URL של היעד של שרת ה-proxy (השירות ש-proxy יבצע).
    • base_path הוא הנתיב הבסיסי של שרת ה-proxy. ערך זה חייב להתחיל בקו נטוי. בנתיב בסיס של בסיס, יש לציין רק קו נטוי לפנים. לדוגמה, "/".

    לדוגמה:

    edgemicro start -o your_org -e test -k 7eb6aae644cbc09035a...d2eae46a6c095f \
  -s e16e7b1f5d5e24df...ec29d409a2df853163a -a proxy1 -v 1 \
  -t http://mocktarget.apigee.net -b /echo

בדיקת התצורה

כדי לבדוק את ההגדרות של שרת ה-proxy המקומי, אפשר להפעיל את נקודת הקצה הזו. לדוגמה, אם ציינתם נתיב בסיסי של /echo, תוכלו להפעיל את שרת ה-proxy כך:

curl  http://localhost:8000/echo
{
  "error" : "missing_authorization",
  "error_description" : "Missing Authorization header"
}

קריאת ה-API הראשונית הזו גרמה לשגיאה כי לא סיפקת מפתח API תקין. תוכלו למצוא את המפתח באפליקציה למפתחים שיצרתם בעבר. פותחים את האפליקציה בממשק המשתמש של Edge, מעתיקים את מפתח הצרכן ומשתמשים במפתח הזה באופן הבא:

curl  http://localhost:8000/echo -H 'x-api-key:your_api_key'

לדוגמה:

curl  http://localhost:8000/echo -H "x-api-key:DvUdLlFwG9AvGGpEgfnNGwtvaXIlUUvP"

פלט לדוגמה:

{
  "headers":{
    "user-agent":"curl/7.54.0",
    "accept":"*/*",
    "x-api-key":"DvUdLlFwG9AvGGpEgfnNGwtvaXIlUUvP",
    "client_received_start_timestamp":"1535134472699",
    "x-authorization-claims":"eyJhdWQiOi...TQ0YmUtOWNlOS05YzM1OTE5MTA1NDkifQ==",
    "target_sent_start_timestamp":"1535134472702",
    "x-request-id":"678e3080-a7ae-11e8-a70f-87ae30db3896.8cc81cb0-a7c9-11e8-a70f-87ae30db3896",
    "x-forwarded-proto":"http",
    "x-forwarded-host":"localhost:8000",
    "host":"mocktarget.apigee.net",
    "x-cloud-trace-context":"e2ac4fa0112c2d76237e5473714f1c85/1746478453618419513",
    "via":"1.1 localhost, 1.1 google",
    "x-forwarded-for":"::1, 216.98.205.223, 35.227.194.212",
    "connection":"Keep-Alive"
  },
  "method":"GET",
  "url":"/",
  "body":""
}