مرجع عملیات و پیکربندی برای Edge Microgateway

شما در حال مشاهده مستندات Apigee Edge هستید.
به مستندات Apigee X مراجعه کنید . اطلاعات

میکروگیت‌وی اج نسخه ۲.۵.x

این مبحث به نحوه مدیریت و پیکربندی Edge Microgateway می‌پردازد.

ارتقاء Edge Microgateway در صورت داشتن اتصال اینترنتی

  1. برای ارتقاء به آخرین نسخه Edge Microgateway، دستور npm زیر را اجرا کنید:
    npm upgrade edgemicro -g

    برای ارتقاء به یک نسخه خاص از Edge Microgateway، باید شماره نسخه را در دستور upgrade مشخص کنید. اگر شماره نسخه را مشخص نکنید، آخرین نسخه نصب خواهد شد. به عنوان مثال، برای ارتقاء به نسخه 2.5.26، از دستور زیر استفاده کنید:

    npm upgrade edgemicro@2.5.26 -g
  2. شماره نسخه را بررسی کنید. برای مثال، اگر نسخه ۲.۵.۲۶ را نصب کرده‌اید: 
    edgemicro --version
current nodejs version is v8.9.0
current edgemicro version is 2.5.26
  3. در نهایت، به آخرین نسخه از پروکسی edgemicro-auth ارتقا دهید: 
    edgemicro upgradeauth -o org_name -e env_name -u username

ایجاد تغییرات پیکربندی

فایل‌های پیکربندی که باید در مورد آنها بدانید عبارتند از:

  • فایل پیکربندی پیش‌فرض سیستم
  • فایل پیکربندی پیش‌فرض برای نمونه‌ی Edge Microgateway که به تازگی مقداردهی اولیه شده است
  • فایل پیکربندی پویا برای نمونه‌های در حال اجرا

این بخش در مورد این فایل‌ها و آنچه که باید در مورد تغییر آنها بدانید، بحث می‌کند.

فایل پیکربندی پیش‌فرض سیستم

وقتی Edge Microgateway را نصب می‌کنید، یک فایل پیکربندی سیستم پیش‌فرض در اینجا قرار می‌گیرد:

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

که prefix دایرکتوری پیشوند npm است. اگر نمی‌توانید این دایرکتوری را پیدا کنید ، به «محل نصب Edge Microgateway» مراجعه کنید.

اگر فایل پیکربندی سیستم را تغییر دهید، باید Edge Microgateway را مجدداً مقداردهی اولیه، پیکربندی و مجدداً راه‌اندازی کنید:

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

فایل پیکربندی پیش‌فرض برای نمونه‌های Edge Microgateway که به تازگی مقداردهی اولیه شده‌اند

وقتی 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 Microgateway در حال اجرا باشد (گزینه بدون قطعی):

  1. پیکربندی Edge Microgateway را مجدداً بارگذاری کنید:
    edgemicro reload -o org_name -e env_name -k key -s secret

    کجا:

    • org_name نام سازمان Edge شما است (شما باید مدیر سازمان باشید).
    • env_name یک محیط در سازمان شما است (مانند "test" یا "prod").
    • key کلیدی است که قبلاً توسط دستور configure برگردانده شده است.
    • secret کلیدی است که قبلاً توسط دستور configure برگردانده شده است.

    برای مثال

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

اگر Edge Microgateway متوقف شود:

  1. میکروگیت‌وی اج را مجدداً راه‌اندازی کنید:
    edgemicro start -o org_name -e env_name -k key -s secret

    کجا:

    • org_name نام سازمان Edge شما است (شما باید مدیر سازمان باشید).
    • env_name محیطی در سازمان شماست (مانند "test" یا "prod").
    • key کلیدی است که قبلاً توسط دستور configure برگردانده شده است.
    • secret کلیدی است که قبلاً توسط دستور configure برگردانده شده است.

    برای مثال: 

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

در اینجا یک نمونه فایل پیکربندی وجود دارد. برای جزئیات بیشتر در مورد تنظیمات فایل پیکربندی، به مرجع پیکربندی Edge 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

تنظیم این متغیرها اختیاری است. اگر آنها را تنظیم کنید، هنگام استفاده از رابط خط فرمان (CLI) برای پیکربندی و شروع Edge Microgateway نیازی به مشخص کردن مقادیر آنها ندارید.

پیکربندی SSL روی سرور Edge Microgateway

شما می‌توانید سرور Microgateway را طوری پیکربندی کنید که از SSL استفاده کند. برای مثال، با پیکربندی SSL، می‌توانید APIها را از طریق Edge Microgateway با پروتکل "https" فراخوانی کنید، مانند این: 

https://localhost:8000/myapi

برای پیکربندی SSL روی سرور Microgateway، مراحل زیر را دنبال کنید:

  1. با استفاده از ابزار openssl یا هر روش دیگری که ترجیح می‌دهید، یک گواهی SSL و کلید ایجاد یا دریافت کنید.
  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 اگر درست باشد، گواهی سرور با لیست CA های ارائه شده تأیید می‌شود. اگر تأیید ناموفق باشد، خطایی برگردانده می‌شود.
secureProtocol متد SSL مورد استفاده. برای مثال، SSLv3_method برای مجبور کردن SSL به نسخه ۳.
servername نام سرور برای پسوند TLS مربوط به SNI (نشانگر نام سرور).
requestCert برای SSL دوطرفه درست و برای SSL یکطرفه نادرست است.

استفاده از گزینه‌های SSL/TLS کلاینت

می‌توانید Edge Microgateway را طوری پیکربندی کنید که هنگام اتصال به نقاط انتهایی هدف، یک کلاینت TLS یا SSL باشد. در فایل پیکربندی Microgateway، از عنصر targets برای تنظیم گزینه‌های 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 اگر درست باشد، گواهی سرور با لیست CA های ارائه شده تأیید می‌شود. اگر تأیید ناموفق باشد، خطایی برگردانده می‌شود.
secureProtocol متد SSL مورد استفاده. برای مثال، SSLv3_method برای مجبور کردن SSL به نسخه ۳.
servername نام سرور برای پسوند TLS مربوط به SNI (نشانگر نام سرور).

سفارشی‌سازی پروکسی edgemicro-auth

به طور پیش‌فرض، Edge Microgateway از یک پروکسی مستقر در Apigee Edge برای احراز هویت OAuth2 استفاده می‌کند. این پروکسی زمانی که برای اولین بار edgemicro configure اجرا می‌کنید، مستقر می‌شود. می‌توانید پیکربندی پیش‌فرض این پروکسی را تغییر دهید تا پشتیبانی از ادعاهای سفارشی را به JSON Web Token (JWT) اضافه کنید، انقضای توکن را پیکربندی کنید و توکن‌های تازه‌سازی ایجاد کنید. برای جزئیات بیشتر، به صفحه edgemicro-auth در GitHub مراجعه کنید.

استفاده از یک سرویس احراز هویت سفارشی

به طور پیش‌فرض، Edge Microgateway از یک پروکسی مستقر در Apigee Edge برای احراز هویت OAuth2 استفاده می‌کند. این پروکسی هنگام اجرای اولیه edgemicro configure مستقر می‌شود. به طور پیش‌فرض، URL این پروکسی در فایل پیکربندی 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

با این تنظیم، گزارش‌ها به خروجی استاندارد ارسال می‌شوند. در حال حاضر، نمی‌توانید گزارش‌ها را هم به خروجی استاندارد و هم به یک فایل گزارش ارسال کنید.

نحوه تنظیم سطح ثبت وقایع

شما می‌توانید این سطوح ثبت وقایع را تنظیم کنید: info ، warn و error . سطح info توصیه می‌شود. این سطح، تمام درخواست‌ها و پاسخ‌های API را ثبت می‌کند و پیش‌فرض است.

نحوه تغییر فواصل لاگ

می‌توانید این فواصل را در فایل پیکربندی Edge Microgateway پیکربندی کنید. همچنین به بخش «ایجاد تغییرات پیکربندی» مراجعه کنید.

ویژگی‌های قابل تنظیم عبارتند از:

  • stats_log_interval : (پیش‌فرض: ۶۰) فاصله زمانی، بر حسب ثانیه، که رکورد آمار در فایل لاگ API نوشته می‌شود.
  • rotate_interval : (پیش‌فرض: ۲۴) فاصله زمانی، بر حسب ساعت، که فایل‌های لاگ چرخانده می‌شوند. برای مثال: 
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 توصیه می‌کند که شیوه‌های زیر را اتخاذ کنید:

  • از آنجا که فایل‌های لاگ می‌توانند بسیار بزرگ شوند، مطمئن شوید که دایرکتوری فایل لاگ فضای کافی دارد. به بخش‌های زیر مراجعه کنید: محل ذخیره فایل‌های لاگ و نحوه تغییر دایرکتوری پیش‌فرض فایل لاگ .
  • حداقل هفته‌ای یک بار، فایل‌های لاگ را حذف یا به یک پوشه بایگانی جداگانه منتقل کنید.
  • اگر سیاست شما حذف لاگ‌ها است، می‌توانید از دستور edgemicro log -c در CLI برای حذف (پاک‌سازی) لاگ‌های قدیمی‌تر استفاده کنید.

قرارداد نامگذاری فایل‌های لاگ

هر نمونه Edge Microgateway سه نوع فایل لاگ تولید می‌کند:

  • api - تمام درخواست‌ها و پاسخ‌هایی که از طریق Edge Microgateway جریان دارند را ثبت می‌کند. شمارنده‌های API (آمار) و خطاها نیز در این فایل ثبت می‌شوند.
  • err - هر چیزی که به stderr ارسال می‌شود را ثبت می‌کند.
  • خروجی - هر چیزی که به خروجی استاندارد ارسال شود را ثبت می‌کند.

این قرارداد نامگذاری است: 

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

درباره محتویات فایل لاگ

اضافه شده در: نسخه ۲.۳.۳

به طور پیش‌فرض، سرویس ثبت وقایع، JSON مربوط به پروکسی‌های دانلود شده، محصولات و JSON Web Token (JWT) را حذف می‌کند. اگر می‌خواهید این اشیاء را در فایل‌های گزارش خروجی دهید، هنگام شروع Edge Microgateway، DEBUG=* را تنظیم کنید. به عنوان مثال:

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

محتویات فایل گزارش "api"

فایل لاگ "api" حاوی اطلاعات دقیقی در مورد جریان درخواست‌ها و پاسخ‌ها از طریق Edge Microgateway است. فایل‌های لاگ "api" به این صورت نامگذاری شده‌اند: 

edgemicro-mymachine-local-MTQzNjIxOTk0NzY0Nw-api.log

برای هر درخواستی که به Edge Microgateway ارسال می‌شود، چهار رویداد در فایل گزارش "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

بیایید یکی یکی به آنها نگاه کنیم:

۱. نمونه درخواست دریافتی از مشتری: 

1436403888651 info req m=GET, u=/, h=localhost:8000, r=::1:59715, i=0
  • ۱۴۳۶۴۰۳۸۸۸۶۵۱ - مهر تاریخ یونیکس
  • اطلاعات - بستگی به متن دارد. بسته به سطح لاگ، می‌تواند اطلاعات، هشدار یا خطا باشد. می‌تواند برای یک رکورد آمار، آمار، هشدار یا خطا باشد.
  • req - رویداد را شناسایی می‌کند. در این مورد، از کلاینت درخواست می‌شود.
  • m - فعل HTTP استفاده شده در درخواست.
  • u - بخشی از URL که پس از مسیر پایه قرار می‌گیرد.
  • h - شماره میزبان و پورتی که Edge Microgateway در آن مشغول گوش دادن است.
  • r - میزبان و پورت راه دور که درخواست کلاینت از آنجا ارسال شده است.
  • i - شناسه درخواست. هر چهار ورودی رویداد این شناسه را به اشتراک می‌گذارند. به هر درخواست یک شناسه درخواست منحصر به فرد اختصاص داده می‌شود. مرتبط کردن رکوردهای لاگ بر اساس شناسه درخواست می‌تواند بینش ارزشمندی در مورد تأخیر هدف ارائه دهد.
  • d - مدت زمان بر حسب میلی‌ثانیه از زمان دریافت درخواست توسط Edge Microgateway. در مثال بالا، پاسخ هدف برای درخواست 0 پس از 7 میلی‌ثانیه (خط 3) دریافت شد و پاسخ پس از 4 میلی‌ثانیه اضافی (خط 4) به کلاینت ارسال شد. به عبارت دیگر، کل تأخیر درخواست 11 میلی‌ثانیه بود که از این تعداد 7 میلی‌ثانیه توسط هدف و 4 میلی‌ثانیه توسط خود Edge Microgateway گرفته شده است.

۲. نمونه درخواست خروجی ارسال شده به هدف: 

1436403888665 info treq m=GET, u=/, h=127.0.0.1:8080, i=0
  • ۱۴۳۶۴۰۳۸۸۸۶۵۱ - مهر تاریخ یونیکس
  • اطلاعات - بستگی به متن دارد. بسته به سطح لاگ، می‌تواند اطلاعات، هشدار یا خطا باشد. می‌تواند برای یک رکورد آمار، آمار، هشدار یا خطا باشد.
  • treq - رویداد را شناسایی می‌کند. در این مورد، درخواست هدف.
  • m - فعل HTTP استفاده شده در درخواست هدف.
  • u - بخشی از URL که پس از مسیر پایه قرار می‌گیرد.
  • h - شماره میزبان و پورت هدف backend.
  • i - شناسه‌ی ورودی لاگ. هر چهار ورودی رویداد این شناسه را به اشتراک می‌گذارند.

۳. نمونه‌ای از پاسخ دریافتی از هدف 

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

۱۴۳۶۴۰۳۸۸۸۶۵۱ - مهر تاریخ یونیکس

  • اطلاعات - بستگی به متن دارد. بسته به سطح لاگ، می‌تواند اطلاعات، هشدار یا خطا باشد. می‌تواند برای یک رکورد آمار، آمار، هشدار یا خطا باشد.
  • tres - رویداد را شناسایی می‌کند. در این مورد، پاسخ هدف.
  • s - وضعیت پاسخ HTTP.
  • d - مدت زمان بر حسب میلی‌ثانیه. مدت زمان صرف شده برای فراخوانی API توسط هدف.
  • i - شناسه‌ی ورودی لاگ. هر چهار ورودی رویداد این شناسه را به اشتراک می‌گذارند.

۴. نمونه پاسخ ارسالی به مشتری 

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

۱۴۳۶۴۰۳۸۸۸۶۵۱ - مهر تاریخ یونیکس

  • اطلاعات - بستگی به متن دارد. بسته به سطح لاگ، می‌تواند اطلاعات، هشدار یا خطا باشد. می‌تواند برای یک رکورد آمار، آمار، هشدار یا خطا باشد.
  • res - رویداد را شناسایی می‌کند. در این مورد، پاسخ به کلاینت.
  • s - وضعیت پاسخ HTTP.
  • d - مدت زمان بر حسب میلی‌ثانیه. این کل زمان صرف شده برای فراخوانی API است، شامل زمان صرف شده توسط API هدف و زمان صرف شده توسط خود Edge Microgateway.
  • i - شناسه‌ی ورودی لاگ. هر چهار ورودی رویداد این شناسه را به اشتراک می‌گذارند.

برنامه زمانبندی فایل لاگ

فایل‌های لاگ در بازه زمانی مشخص شده توسط ویژگی پیکربندی rotate_interval چرخش می‌یابند. ورودی‌ها تا زمان انقضای بازه چرخش، به همان فایل لاگ اضافه می‌شوند. با این حال، هر بار که Edge Microgateway مجدداً راه‌اندازی می‌شود، یک UID جدید دریافت می‌کند و مجموعه‌ای جدید از فایل‌های لاگ را با این UID ایجاد می‌کند. همچنین به شیوه‌های خوب نگهداری فایل لاگ مراجعه کنید.

پیام‌های خطا

برخی از ورودی‌های لاگ حاوی پیام‌های خطا هستند. برای کمک به شناسایی محل و دلیل وقوع خطاها، به مرجع خطای Edge Microgateway مراجعه کنید.

مرجع پیکربندی Edge Microgateway

محل فایل پیکربندی

ویژگی‌های پیکربندی شرح داده شده در این بخش در فایل پیکربندی Edge Microgateway قرار دارند. همچنین به بخش «ایجاد تغییرات پیکربندی» مراجعه کنید.

ویژگی‌های edge_config

این تنظیمات برای پیکربندی تعامل بین نمونه Edge Microgateway و Apigee Edge استفاده می‌شوند.

  • bootstrap : (پیش‌فرض: هیچ) یک URL که به یک سرویس خاص Edge Microgateway که روی Apigee Edge اجرا می‌شود اشاره می‌کند. Edge Microgateway از این سرویس برای ارتباط با Apigee Edge استفاده می‌کند. این URL هنگام اجرای دستور تولید جفت کلید عمومی/خصوصی: edgemicro genkeys بازگردانده می‌شود. برای جزئیات بیشتر به بخش راه‌اندازی و پیکربندی Edge Microgateway مراجعه کنید.
  • jwt_public_key : (پیش‌فرض: هیچ) یک URL که به پروکسی Edge Microgateway که روی Apigee Edge مستقر است اشاره می‌کند. این پروکسی به عنوان یک نقطه پایانی احراز هویت برای صدور توکن‌های دسترسی امضا شده به کلاینت‌ها عمل می‌کند. این URL هنگام اجرای دستور برای استقرار پروکسی برگردانده می‌شود: edgemicro configure . برای جزئیات بیشتر به بخش راه‌اندازی و پیکربندی Edge Microgateway مراجعه کنید.

ویژگی‌های edgemicro

این تنظیمات، فرآیند Edge Microgateway را پیکربندی می‌کنند.

  • پورت : (پیش‌فرض: ۸۰۰۰) شماره پورتی که پردازش Edge Microgateway به آن گوش می‌دهد.
  • max_connections : (پیش‌فرض: -1) حداکثر تعداد اتصالات ورودی همزمان که Edge Microgateway می‌تواند دریافت کند را مشخص می‌کند. اگر از این تعداد تجاوز شود، وضعیت زیر برگردانده می‌شود:

    res.statusCode = 429; // Too many requests
  • max_connections_hard : (پیش‌فرض: -1) حداکثر تعداد درخواست‌های همزمان که Edge Microgateway می‌تواند قبل از قطع اتصال دریافت کند. این تنظیم برای خنثی کردن حملات انکار سرویس در نظر گرفته شده است. معمولاً آن را روی عددی بزرگتر از max_connections تنظیم کنید.
  • ثبت وقایع :
    • سطح : (پیش‌فرض: خطا)
      • info - تمام درخواست‌ها و پاسخ‌هایی را که از طریق یک نمونه Edge Microgateway جریان دارند، ثبت می‌کند.
      • هشدار - فقط پیام‌های هشدار را ثبت می‌کند.
      • error - فقط پیام‌های خطا را ثبت می‌کند.
    • dir : (پیش‌فرض: /var/tmp) دایرکتوری که فایل‌های لاگ در آن ذخیره می‌شوند.
    • stats_log_interval : (پیش‌فرض: ۶۰) فاصله زمانی، بر حسب ثانیه، که رکورد آمار در فایل لاگ API نوشته می‌شود.
    • rotate_interval : (پیش‌فرض: ۲۴) فاصله زمانی، بر حسب ساعت، که فایل‌های لاگ چرخانده می‌شوند.
  • افزونه‌ها : افزونه‌ها به Edge Microgateway قابلیت اضافه می‌کنند. برای جزئیات بیشتر در مورد توسعه افزونه‌ها، به بخش توسعه افزونه‌های سفارشی مراجعه کنید.
  • dir : یک مسیر نسبی از دایرکتوری ./gateway به دایرکتوری ./plugins، یا یک مسیر مطلق.
  • sequence : فهرستی از ماژول‌های افزونه برای اضافه کردن به نمونه Edge Microgateway شما. ماژول‌ها به ترتیبی که در اینجا مشخص شده‌اند، اجرا خواهند شد.
  • اشکال‌زدایی: اشکال‌زدایی از راه دور را به فرآیند Edge Microgateway اضافه می‌کند.
    • پورت : شماره پورتی که باید به آن گوش دهید. برای مثال، اشکال‌زدای IDE خود را طوری تنظیم کنید که به این پورت گوش دهد.
    • args : آرگومان‌هایی برای فرآیند اشکال‌زدایی. برای مثال: args --nolazy
  • config_change_poll_interval: (پیش‌فرض: ۶۰۰ ثانیه) Edge Microgateway پیکربندی جدیدی را به صورت دوره‌ای بارگذاری می‌کند و در صورت تغییر هر چیزی، بارگذاری مجدد را اجرا می‌کند. این نظرسنجی هرگونه تغییر ایجاد شده در Edge (تغییر در محصولات، پروکسی‌های آگاه از microgateway و غیره) و همچنین تغییرات ایجاد شده در فایل پیکربندی محلی را ثبت می‌کند.
  • disable_config_poll_interval: (پیش‌فرض: false) برای غیرفعال کردن نظرسنجی خودکار تغییر، روی true تنظیم کنید.
  • request_timeout : برای درخواست‌های هدف، مهلت زمانی تعیین می‌کند. این مهلت زمانی بر حسب ثانیه تنظیم می‌شود. در صورت وقوع مهلت زمانی، Edge Microgateway با کد وضعیت ۵۰۴ پاسخ می‌دهد. (نسخه ۲.۴.x اضافه شده است)

ویژگی‌های هدرها

این تنظیمات نحوه برخورد با هدرهای HTTP خاص را پیکربندی می‌کنند.

  • x-forwarded-for : (پیش‌فرض: true) برای جلوگیری از ارسال هدرهای x-forwarded-for به مقصد، روی false تنظیم شود. توجه داشته باشید که اگر هدر x-forwarded-for در درخواست باشد، مقدار آن در Edge Analytics برابر با مقدار client-ip تنظیم می‌شود.
  • x-forwarded-host : (پیش‌فرض: true) برای جلوگیری از ارسال هدرهای x-forwarded-host به مقصد، روی false تنظیم شود.
  • x-request-id : (پیش‌فرض: true) برای جلوگیری از ارسال هدرهای x-request-id به مقصد، روی false تنظیم می‌شود.
  • x-response-time : (پیش‌فرض: true) برای جلوگیری از ارسال هدرهای x-response-time به مقصد، روی false تنظیم شود.
  • via : (پیش‌فرض: true) برای جلوگیری از ارسال هدرهای via به مقصد، روی false تنظیم می‌شود.

ویژگی‌های oauth

این تنظیمات نحوه‌ی اعمال احراز هویت کلاینت توسط Edge Microgateway را پیکربندی می‌کنند.

  • allowNoAuthorization : (پیش‌فرض: false) اگر روی true تنظیم شود، فراخوانی‌های API اجازه دارند بدون هیچ سربرگ Authorization از Edge Microgateway عبور کنند. برای نیاز به سربرگ Authorization (پیش‌فرض)، این مقدار را روی false تنظیم کنید.
  • allowInvalidAuthorization : (پیش‌فرض: false) اگر روی true تنظیم شود، در صورتی که توکن ارسالی در هدر Authorization نامعتبر یا منقضی شده باشد، فراخوانی‌های API مجاز به عبور هستند. برای درخواست توکن‌های معتبر، این مقدار را روی false تنظیم کنید (پیش‌فرض).
  • authorization-header : (پیش‌فرض: Authorization: Bearer) هدری که برای ارسال توکن دسترسی به Edge Microgateway استفاده می‌شود. در مواردی که هدف نیاز به استفاده از هدر Authorization برای هدف دیگری دارد، می‌توانید پیش‌فرض را تغییر دهید.
  • api-key-header : (پیش‌فرض: x-api-key) نام هدر یا پارامتر پرس‌وجو که برای ارسال کلید API به Edge Microgateway استفاده می‌شود. همچنین به بخش استفاده از کلید API مراجعه کنید.
  • keep-authorization-header : (پیش‌فرض: false) اگر روی true تنظیم شود، هدر Authorization ارسال‌شده در درخواست به مقصد منتقل می‌شود (حفظ می‌شود).
  • allowOAuthOnly -- اگر روی true تنظیم شود، هر API باید یک هدر مجوز با یک Bearer Access Token داشته باشد. به شما امکان می‌دهد فقط مدل امنیتی OAuth را مجاز کنید (ضمن حفظ سازگاری با نسخه‌های قبلی). (اضافه شده در نسخه ۲.۴.x)
  • allowAPIKeyOnly -- اگر روی true تنظیم شود، هر API باید یک هدر x-api-key (یا یک مکان سفارشی) با یک کلید API داشته باشد. به شما امکان می‌دهد فقط مدل امنیتی کلید API را مجاز کنید (ضمن حفظ سازگاری با نسخه‌های قبلی). (اضافه شده در نسخه ۲.۴.x)
  • gracePeriod -- این پارامتر به جلوگیری از خطاهای ناشی از اختلافات جزئی بین ساعت سیستم شما و زمان‌های Not Before (nbf) یا Issued At (iat) مشخص شده در توکن مجوز JWT کمک می‌کند. این پارامتر را روی تعداد ثانیه‌ها تنظیم کنید تا چنین اختلافاتی در نظر گرفته شود. (اضافه شده در 2.5.7)

ویژگی‌های خاص افزونه

برای جزئیات بیشتر در مورد ویژگی‌های قابل تنظیم برای هر افزونه، به بخش «استفاده از افزونه‌ها» مراجعه کنید.

فیلتر کردن پروکسی‌ها

شما می‌توانید پروکسی‌های آگاه از microgateway که یک نمونه Edge Microgateway پردازش می‌کند را فیلتر کنید. وقتی Edge Microgateway شروع به کار می‌کند، تمام پروکسی‌های آگاه از microgateway را در سازمانی که با آن مرتبط است دانلود می‌کند. از پیکربندی زیر برای محدود کردن پروکسی‌هایی که microgateway پردازش خواهد کرد استفاده کنید. به عنوان مثال، این پیکربندی پروکسی‌هایی را که microgateway پردازش خواهد کرد به سه عدد محدود می‌کند: edgemicro_proxy-1 ، edgemicro_proxy-2 و edgemicro_proxy-3 : 

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

پیکربندی فرکانس ارسال گزارش‌های تحلیلی

از این پارامترهای پیکربندی برای کنترل فرکانس ارسال داده‌های تحلیلی توسط Edge Microgateway به Apigee استفاده کنید:

  • bufferSize (اختیاری): حداکثر تعداد رکوردهای تحلیلی که بافر می‌تواند قبل از شروع حذف قدیمی‌ترین رکوردها در خود نگه دارد. پیش‌فرض: ۱۰۰۰۰
  • batchSize (اختیاری): حداکثر اندازه یک دسته از رکوردهای تحلیلی ارسال شده به Apigee. پیش‌فرض: ۵۰۰
  • flushInterval (اختیاری): تعداد میلی‌ثانیه‌ها بین هر بار خالی کردن دسته‌ای از رکوردهای تحلیلی ارسال شده به Apigee. پیش‌فرض: ۵۰۰۰

برای مثال: 

analytics:
  bufferSize: 15000
  batchSize: 1000
  flushInterval: 6000

پنهان کردن داده‌های تحلیلی

پیکربندی زیر از نمایش اطلاعات مسیر درخواست در Edge analytics جلوگیری می‌کند. برای پنهان کردن URI درخواست و/یا مسیر درخواست، موارد زیر را به پیکربندی microgateway اضافه کنید. توجه داشته باشید که URI شامل نام میزبان و بخش‌های مسیر درخواست است. 

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

جداسازی فراخوانی‌های API در Edge Analytics

شما می‌توانید افزونه‌ی آنالیتیکس را طوری پیکربندی کنید که یک مسیر API خاص را جدا کند تا به عنوان یک پروکسی جداگانه در داشبوردهای Edge Analytics ظاهر شود. به عنوان مثال، می‌توانید یک API بررسی سلامت را در داشبورد جدا کنید تا از اشتباه گرفته شدن آن با فراخوانی‌های پروکسی API واقعی جلوگیری شود. در داشبورد آنالیتیکس، پروکسی‌های جدا شده از این الگوی نامگذاری پیروی می‌کنند: 

edgemicro_proxyname-health

تصویر زیر دو پروکسی مجزا را در داشبورد آنالیتیکس نشان می‌دهد: edgemicro_hello-health و edgemicro_mock-health :

از این پارامترها برای جداسازی مسیرهای نسبی و مطلق در داشبورد آنالیتیکس به عنوان پروکسی‌های جداگانه استفاده کنید:

  • relativePath (اختیاری): یک مسیر نسبی برای جداسازی در داشبورد Analytics مشخص می‌کند. برای مثال، اگر /healthcheck را مشخص کنید، تمام فراخوانی‌های API که شامل مسیر /healthcheck هستند، در داشبورد به صورت edgemicro_ proxyname -health ظاهر می‌شوند. توجه داشته باشید که این پرچم، مسیر پایه پروکسی را نادیده می‌گیرد. برای جداسازی بر اساس یک مسیر کامل، از جمله مسیر پایه، از پرچم proxyPath استفاده کنید.
  • proxyPath (اختیاری): یک مسیر پروکسی کامل API، شامل مسیر پایه پروکسی، را برای جداسازی در داشبورد تحلیلی مشخص می‌کند. برای مثال، اگر /mocktarget/healthcheck مشخص کنید، که در آن /mocktarget مسیر پایه پروکسی است، تمام فراخوانی‌های API با مسیر /mocktarget/healthcheck در داشبورد به صورت edgemicro_ proxyname -health ظاهر می‌شوند.

برای مثال، در پیکربندی زیر، هر مسیر API که شامل /healthcheck باشد، توسط افزونه analytics تفکیک خواهد شد. این یعنی، /foo/healthcheck و /foo/bar/healthcheck به عنوان یک پروکسی جداگانه به نام edgemicro_ proxyname -health در داشبورد analytics تفکیک می‌شوند. 

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

در پیکربندی زیر، هر API با مسیر پروکسی /mocktarget/healthcheck به عنوان یک پروکسی جداگانه به نام edgemicro_ proxyname -health در داشبورد تحلیلی تفکیک خواهد شد. 

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

راه‌اندازی Edge Microgateway پشت فایروال شرکت

نسخه پشتیبانی‌شده ۲.۴.x

اگر Edge Microgateway پشت یک فایروال نصب شده باشد، ممکن است Gateway نتواند با Apigee Edge ارتباط برقرار کند. در این حالت، دو گزینه وجود دارد که می‌توانید در نظر بگیرید:

گزینه ۱:

اولین گزینه این است که گزینه edgemicro: proxy_tunnel را در فایل پیکربندی microgateway روی true تنظیم کنید: 

edge_config:

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

وقتی proxy_tunnel برابر با true باشد، Edge Microgateway از متد HTTP CONNECT برای تونل کردن درخواست‌های HTTP روی یک اتصال TCP واحد استفاده می‌کند. (اگر متغیرهای محیطی برای پیکربندی پروکسی TLS فعال باشند، همین امر صادق است).

گزینه ۲:

گزینه دوم این است که یک پروکسی مشخص کنید و proxy_tunnel را در فایل پیکربندی microgateway روی false تنظیم کنید. برای مثال: 

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

در این حالت، می‌توانید متغیرهای زیر را برای کنترل میزبان‌ها برای هر پروکسی HTTP که می‌خواهید استفاده کنید، یا اینکه کدام میزبان‌ها نباید پروکسی‌های Edge Microgateway را مدیریت کنند، تنظیم کنید: HTTP_PROXY ، HTTPS_PROXY و NO_PROXY .

شما می‌توانید NO_PROXY را به عنوان یک لیست جدا شده با کاما از دامنه‌هایی که Edge Microgateway نباید به آنها پروکسی بدهد، تنظیم کنید. برای مثال: 

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 مراجعه کنید.

همچنین ببینید

نحوه راه‌اندازی Edge Microgateway پشت فایروال شرکت در انجمن Apigee.

استفاده از wildcardها در پروکسی‌های آگاه از Microgateway

شما می‌توانید از یک یا چند کاراکتر "*" در مسیر پایه یک پروکسی edgemicro_* (Microgateway-aware) استفاده کنید. برای مثال، مسیر پایه /team/*/members به ​​کلاینت‌ها اجازه می‌دهد تا بدون نیاز به ایجاد پروکسی‌های API جدید برای پشتیبانی از تیم‌های جدید، https://[host]/team/blue/members و https://[host]/team/green/members را فراخوانی کنند. توجه داشته باشید که /**/ پشتیبانی نمی‌شود.

مهم: Apigee از استفاده از کاراکتر "*" به عنوان اولین عنصر یک مسیر پایه پشتیبانی نمی‌کند. برای مثال، این مورد پشتیبانی نمی‌شود: /*/ search.

کلیدهای چرخشی JWT

مدتی پس از تولید اولیه JWT، ممکن است نیاز به تغییر جفت کلید عمومی/خصوصی ذخیره شده در Edge encryption KVM داشته باشید. این فرآیند تولید یک جفت کلید جدید، چرخش کلید نامیده می‌شود.

نحوه استفاده Edge Microgateway از JWT

JSON Web Token (JWT) یک استاندارد توکن است که در RFC7519 شرح داده شده است. JWT راهی برای امضای مجموعه‌ای از ادعاها ارائه می‌دهد که می‌تواند به طور قابل اعتمادی توسط گیرنده JWT تأیید شود.

Edge Microgateway از JWTها به عنوان توکن‌های حامل برای امنیت OAuth استفاده می‌کند. وقتی یک توکن OAuth برای Edge Microgateway ایجاد می‌کنید، یک JWT دریافت می‌کنید. سپس می‌توانید از JWT در هدر Authorization فراخوانی‌های API استفاده کنید. به عنوان مثال: 

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

تولید یک JWT جدید

شما می‌توانید با استفاده از دستور edgemicro token یا یک API، یک JWT برای Edge Microgateway ایجاد کنید. برای مثال: 

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

این دستور از Apigee Edge می‌خواهد که یک JWT تولید کند که سپس می‌تواند برای تأیید فراخوانی‌های API مورد استفاده قرار گیرد. پارامترهای -i و -s شناسه مصرف‌کننده و مقادیر مخفی از یک برنامه توسعه‌دهنده در سازمان Apigee Edge شما هستند.

یا می‌توانید با استفاده از API مدیریت، یک JWT نیز تولید کنید: 

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 شما است (شما باید مدیر org باشید).
  • env یک محیط در سازمان شما است (مانند "test" یا "prod").
  • client_id شناسه مصرف‌کننده در برنامه توسعه‌دهنده‌ای است که قبلاً ایجاد کرده‌اید.
  • client_secret همان راز مصرف‌کننده در برنامه توسعه‌دهنده‌ای است که قبلاً ایجاد کرده‌اید.

چرخش کلید چیست؟

مدتی پس از تولید اولیه JWT، ممکن است نیاز به تغییر جفت کلید عمومی/خصوصی ذخیره شده در KVM رمزگذاری شده Edge داشته باشید. این فرآیند تولید یک جفت کلید جدید، چرخش کلید نامیده می‌شود. هنگامی که کلیدها را می‌چرخانید، یک جفت کلید خصوصی/عمومی جدید تولید و در KVM "microgateway" در سازمان/محیط Apigee Edge شما ذخیره می‌شود. علاوه بر این، کلید عمومی قدیمی به همراه مقدار شناسه کلید اصلی آن حفظ می‌شود.

برای تولید یک JWT، Edge از اطلاعات ذخیره شده در KVM رمزگذاری شده استفاده می‌کند. یک KVM به نام microgateway هنگام راه‌اندازی (پیکربندی) اولیه Edge Microgateway ایجاد و با کلیدها پر شده است. کلیدهای موجود در KVM برای امضا و رمزگذاری JWT استفاده می‌شوند.

کلیدهای KVM عبارتند از:

  • private_key - جدیدترین (جدیدترین) کلید خصوصی RSA که برای امضای JWTها استفاده می‌شود.

  • public_key - آخرین (اخیراً ایجاد شده) گواهی که برای تأیید JWT های امضا شده با private_key استفاده می‌شود.

  • private_key_kid - آخرین (آخرین) شناسه کلید خصوصی ایجاد شده. این شناسه کلید با مقدار private_key مرتبط است و برای پشتیبانی از چرخش کلید استفاده می‌شود.

  • public_key1_kid - آخرین (آخرین) شناسه کلید عمومی ایجاد شده. این کلید با مقدار public_key1 مرتبط است و برای پشتیبانی از چرخش کلید استفاده می‌شود. این مقدار همان کلید خصوصی kid است.

  • public_key1 - آخرین (آخرین کلید عمومی ایجاد شده).

وقتی چرخش کلید را انجام می‌دهید، مقادیر کلید موجود در نقشه جایگزین می‌شوند و کلیدهای جدید برای حفظ کلیدهای عمومی قدیمی اضافه می‌شوند. برای مثال:

  • public_key2_kid - شناسه کلید عمومی قدیمی. این کلید با مقدار public_key2 مرتبط است و برای پشتیبانی از چرخش کلید استفاده می‌شود.

  • public_key2 - کلید عمومی قدیمی.

JWT های ارائه شده برای تأیید با استفاده از کلید عمومی جدید تأیید می‌شوند. اگر تأیید ناموفق باشد، از کلید عمومی قدیمی استفاده می‌شود تا زمانی که منقضی شود (بعد از 30 دقیقه). به این ترتیب، می‌توانید کلیدها را بدون ایجاد اختلال فوری در ترافیک API، "چرخش" دهید.

نحوه چرخش کلید

این بخش نحوه انجام چرخش کلید را توضیح می‌دهد.

اگر نمونه Edge Microgateway خود را قبل از نسخه ۲.۵.۲ پیکربندی کرده‌اید

اگر نمونه Edge Microgateway خود را قبل از نسخه ۲.۵.۲ پیکربندی کرده‌اید، باید دو دستور زیر را برای ارتقاء KVM و سیاست احراز هویت اجرا کنید: 

upgradekvm -o org -e env -u username

برای اطلاعات بیشتر در مورد این دستور، به بخش ارتقاء KVM مراجعه کنید.

دستور بعدی، پروکسی edgemicro-oauth را که هنگام پیکربندی Edge Microgateway در Apigee org شما مستقر شده بود، ارتقا می‌دهد. این پروکسی سرویس‌های مورد نیاز برای تولید توکن‌ها را فراهم می‌کند. 

upgradeauth -o org -e env -u username

برای اطلاعات بیشتر در مورد این دستور، به ارتقاء پروکسی edgemicro-auth مراجعه کنید.

چرخاندن کلیدها

خط زیر را به فایل ~/.edgemicro/org-env-config.yaml خود اضافه کنید، که در آن باید همان سازمان و محیطی را که microgateway برای استفاده از آن پیکربندی کرده‌اید، مشخص کنید: 

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 یک شناسه کلید (kid) را مشخص می‌کند. این شناسه برای تطبیق با یک کلید خاص استفاده می‌شود. Edge Microgateway از این مقدار برای انتخاب از بین مجموعه‌ای از کلیدها در طول چرخش کلید استفاده می‌کند. برای اطلاعات بیشتر، به بخش 4.5 از مشخصات JSON Web Key مراجعه کنید.

پس از چرخش کلید، Edge چندین کلید را به Edge Microgateway برمی‌گرداند. در مثال زیر توجه داشته باشید که هر کلید یک مقدار منحصر به فرد "kid" (شناسه کلید) دارد. سپس microgateway از این کلیدها برای اعتبارسنجی توکن‌های مجوز استفاده می‌کند. اگر اعتبارسنجی توکن با شکست مواجه شود، microgateway بررسی می‌کند که آیا کلید قدیمی‌تری در مجموعه کلید وجود دارد یا خیر و آن کلید را امتحان می‌کند. قالب کلیدهای برگشتی 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"
    }
  ]
}

فیلتر کردن پروکسی‌های دانلود شده

به طور پیش‌فرض، Edge Microgateway تمام پروکسی‌های موجود در سازمان Edge شما را که با پیشوند نامگذاری "edgemicro_" شروع می‌شوند، دانلود می‌کند. می‌توانید این پیش‌فرض را تغییر دهید تا پروکسی‌هایی را دانلود کنید که نام آنها با یک الگو مطابقت دارد.

  1. فایل پیکربندی Edge Micro خود را باز کنید: ~/.edgemicro/org-env-config.yaml
  2. عنصر proxyPattern را در زیر edge_config اضافه کنید. برای مثال، الگوی زیر پروکسی‌هایی مانند edgemicro_foo، edgemicro_fast و edgemicro_first را دانلود می‌کند. 
    edge_config:
…
proxyPattern: edgemicro_f*

مشخص کردن محصولات بدون پروکسی API

در Apigee Edge، می‌توانید یک محصول API ایجاد کنید که حاوی هیچ پروکسی API نباشد. این پیکربندی محصول به یک کلید API مرتبط با آن محصول اجازه می‌دهد تا با هر پروکسی مستقر در سازمان شما کار کند. از نسخه ۲.۵.۴، Edge Microgateway از این پیکربندی محصول پشتیبانی می‌کند.

اشکال‌زدایی و عیب‌یابی

اتصال به دیباگر

شما می‌توانید Edge Microgateway را با یک اشکال‌زدا، مانند node-inspector ، اجرا کنید. این ابزار برای عیب‌یابی و اشکال‌زدایی افزونه‌های سفارشی مفید است.

  1. Edge Microgateway را در حالت اشکال‌زدایی (debug mode) مجدداً راه‌اندازی کنید. برای انجام این کار، DEBUG=* را به ابتدای دستور start اضافه کنید. برای مثال: 
    DEBUG=* edgemicro start -o  myorg -e test -k
      db4e9e8a95aa7fabfdeacbb1169d0a8cbe42bec19c6b98129e02 -s
      6e56af7c1b26dfe93dae78a735c8afc9796b077d105ae5618ce7ed
  2. اشکال‌زدای خود را اجرا کنید و آن را طوری تنظیم کنید که برای فرآیند اشکال‌زدایی به شماره پورت گوش دهد.
  3. اکنون می‌توانید کد Edge Microgateway را قدم به قدم بررسی کنید، نقاط شکست را تنظیم کنید، عبارات را بررسی کنید و غیره.

شما می‌توانید پرچم‌های استاندارد Node.js مربوط به حالت اشکال‌زدایی را مشخص کنید. برای مثال، --nolazy به اشکال‌زدایی کد ناهمزمان کمک می‌کند.

بررسی فایل‌های لاگ

اگر مشکلی دارید، حتماً فایل‌های لاگ را برای جزئیات اجرا و اطلاعات خطا بررسی کنید. برای جزئیات بیشتر، به مدیریت فایل‌های لاگ مراجعه کنید.

استفاده از امنیت کلید API

کلیدهای API مکانیزم ساده‌ای برای احراز هویت کلاینت‌هایی که به Edge Microgateway درخواست می‌دهند، ارائه می‌دهند. شما می‌توانید با کپی کردن مقدار Consumer Key (که به آن Client ID نیز گفته می‌شود) از یک محصول Apigee Edge که شامل پروکسی احراز هویت Edge Microgateway است، یک کلید API دریافت کنید.

ذخیره سازی کلیدها

کلیدهای API با توکن‌های حامل که ذخیره می‌شوند، مبادله می‌شوند. می‌توانید با تنظیم هدر Cache-Control: no-cache در درخواست‌های ورودی به Edge Microgateway، ذخیره سازی را غیرفعال کنید.

استفاده از کلید 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 با درخواست‌های پروکسی، به Secure Edge Microgateway مراجعه کنید.

استفاده از امنیت توکن OAuth2

این بخش نحوه دریافت توکن‌های دسترسی OAuth2 و توکن‌های به‌روزرسانی را توضیح می‌دهد. توکن‌های دسترسی برای برقراری تماس‌های API امن از طریق microgateway استفاده می‌شوند. توکن‌های به‌روزرسانی برای دریافت توکن‌های دسترسی جدید استفاده می‌شوند.

چگونه یک توکن دسترسی دریافت کنیم

این بخش نحوه استفاده از پروکسی edgemicro-auth برای دریافت توکن دسترسی را توضیح می‌دهد.

همچنین می‌توانید با استفاده از دستور edgemicro token CLI یک توکن دسترسی دریافت کنید. برای جزئیات بیشتر در مورد CLI، به مدیریت توکن‌ها مراجعه کنید.

API 1

نام‌های org و environment خود را در URL جایگزین کنید و مقادیر Consumer Id و Consumer Secret که از یک برنامه توسعه‌دهنده در 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

(اضافه شده در نسخه ۲.۵.۳۱) اعتبارنامه‌های کلاینت را به عنوان یک هدر Basic Authentication و grant_type را به عنوان پارامتر فرم ارسال کنید. این فرم دستور همچنین در RFC 6749: The 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 پروکسی 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 از همان API، از توکن 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 دارد که می‌توانید آن را پیکربندی کنید تا تعداد دفعات و فواصل زمانی راه‌اندازی مجدد Edge Microgateway را کنترل کنید. این فایل، یک سرویس Forever به نام forever-monitor را پیکربندی می‌کند که Forever را به صورت برنامه‌نویسی مدیریت می‌کند.

می‌توانید فایل forever.json را در دایرکتوری نصب ریشه Edge Microgateway پیدا کنید. به بخش «محل نصب Edge Microgateway» مراجعه کنید. برای جزئیات بیشتر در مورد گزینه‌های پیکربندی، به مستندات forever-monitor مراجعه کنید.

دستور edgemicro forever شامل فلگ‌هایی است که به شما امکان می‌دهد مکان فایل forever.json (فلگ -f ) را مشخص کنید و فرآیند نظارت Forever (فلگ -a ) را شروع/متوقف کنید. برای مثال: 

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

برای اطلاعات بیشتر، به مرجع نظارت دائمی در CLI مراجعه کنید.

مشخص کردن نقطه پایانی فایل پیکربندی

اگر چندین نمونه Edge Microgateway را اجرا می‌کنید، ممکن است بخواهید پیکربندی‌های آنها را از یک مکان واحد مدیریت کنید. می‌توانید این کار را با مشخص کردن یک نقطه پایانی 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 Microgateway در حالت مستقل

شما می‌توانید Edge Microgateway را بدون اتصال کامل به هرگونه وابستگی به Apigee Edge اجرا کنید. این سناریو که حالت مستقل نامیده می‌شود، به شما امکان می‌دهد Edge Microgateway را بدون اتصال به اینترنت اجرا و آزمایش کنید.

در حالت مستقل، ویژگی‌های زیر کار نمی‌کنند، زیرا نیاز به اتصال به Apigee Edge دارند:

  • کلید OAuth و API
  • سهمیه
  • تجزیه و تحلیل

از طرف دیگر، افزونه‌های سفارشی و spike arrest به طور معمول کار می‌کنند، زیرا نیازی به اتصال به Apigee Edge ندارند. علاوه بر این، افزونه جدیدی به نام extauth به شما امکان می‌دهد در حالت مستقل، فراخوانی‌های API به microgateway را با JWT مجاز کنید.

پیکربندی و شروع دروازه

برای اجرای Edge Microgateway در حالت مستقل:

  1. مطمئن شوید که Edge Microgateway نسخه ۲.۵.۲۵ یا بالاتر را نصب کرده‌اید. در غیر این صورت، برای ارتقا به آخرین نسخه، باید دستور زیر را اجرا کنید:
    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 زیر را اجرا کنید، که در آن مقادیری را برای نمونه‌سازی پروکسی محلی ارائه می‌دهید:
    edgemicro start -o org_name -e environment_name -a local_proxy_name \
  -v local_proxy_version -t target_url -b base_path

    کجا:

    • your_org نام "org" است که در نام فایل پیکربندی استفاده کرده‌اید.
    • your_environment نام "env" است که در نام فایل پیکربندی استفاده کرده‌اید.
    • local_proxy_name نام پروکسی محلی است که ایجاد خواهد شد. می‌توانید از هر نامی که می‌خواهید استفاده کنید.
    • local_proxy_version شماره نسخه پروکسی است.
    • target_url آدرس اینترنتی (URL) مربوط به هدف پروکسی است. ( هدف ، سرویسی است که پروکسی آن را فراخوانی می‌کند.)
    • base_path مسیر پایه پروکسی است. این مقدار باید با یک اسلش شروع شود. برای مسیر پایه ریشه، فقط یک اسلش مشخص کنید؛ برای مثال، "/".

    برای مثال: 

    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 را اعتبارسنجی می‌کند که باید در سربرگ Authorization فراخوانی 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. شما باید تنظیمات و پیکربندی استاندارد Edge Microgateway را برای استقرار پروکسی edgemicro-auth در سازمان/محیط خود در Apigee Edge انجام دهید. اگر قبلاً این مرحله را انجام داده‌اید، نیازی به تکرار آن ندارید.
  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. مانند قبل، با استفاده از نام‌های org/env که در نام فایل پیکربندی استفاده کردید، Edge Microgateway را مجدداً راه‌اندازی کنید. برای مثال: 
    edgemicro start -o foo -e bar -a proxy1 -v 1 -t http://mocktarget.apigee.net -b /
  6. یک توکن JWT از نقطه پایانی احراز هویت دریافت کنید. از آنجا که از نقطه پایانی edgemicro-auth/jwkPublicKeys استفاده می‌کنید، می‌توانید از این دستور CLI استفاده کنید:

شما می‌توانید با استفاده از دستور edgemicro token یا یک API، یک JWT برای Edge Microgateway ایجاد کنید. برای مثال: 

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

کجا:

  • your_org نام سازمان Apigee شماست که قبلاً Edge Microgateway را برای آن پیکربندی کرده‌اید.
  • your_env یک محیط در سازمان است.
  • گزینه i کلید مصرف‌کننده را از یک برنامه توسعه‌دهنده که محصولی شامل پروکسی edgemicro-auth دارد، مشخص می‌کند.
  • گزینه s ، راز مصرف‌کننده را از یک برنامه توسعه‌دهنده که محصولی شامل پروکسی edgemicro-auth دارد، مشخص می‌کند.

این دستور از Apigee Edge می‌خواهد که یک JWT تولید کند که بتوان از آن برای تأیید فراخوانی‌های API استفاده کرد.

همچنین به بخش «ایجاد یک توکن» مراجعه کنید.

پیکربندی مستقل را آزمایش کنید

برای آزمایش پیکربندی، API را با توکن اضافه شده در هدر Authorization به صورت زیر فراخوانی کنید: 

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":""
}

استفاده از حالت پروکسی محلی

در حالت پروکسی محلی، Edge Microgateway نیازی به استقرار یک پروکسی آگاه از microgateway در Apigee Edge ندارد. در عوض، شما با ارائه نام پروکسی محلی، مسیر پایه و URL هدف هنگام شروع microgateway، یک "پروکسی محلی" را پیکربندی می‌کنید. سپس فراخوانی‌های API به microgateway به URL هدف پروکسی محلی ارسال می‌شوند. از هر نظر دیگر، حالت پروکسی محلی دقیقاً مانند اجرای Edge Microgateway در حالت عادی خود عمل می‌کند. احراز هویت، همانند توقیف spike و اعمال سهمیه، افزونه‌های سفارشی و غیره، به همان شکل عمل می‌کند.

مورد استفاده و مثال

حالت پروکسی محلی زمانی مفید است که فقط نیاز به مرتبط کردن یک پروکسی واحد با یک نمونه Edge Microgateway داشته باشید. به عنوان مثال، می‌توانید Edge Microgateway را به عنوان یک پروکسی جانبی به Kubernetes تزریق کنید، که در آن یک microgateway و یک سرویس هر کدام در یک pod واحد اجرا می‌شوند و microgateway ترافیک را به و از سرویس همراه خود مدیریت می‌کند. شکل زیر این معماری را نشان می‌دهد که در آن Edge Microgateway به عنوان یک پروکسی جانبی در یک کلاستر Kubernetes عمل می‌کند. هر نمونه microgateway فقط با یک نقطه پایانی در سرویس همراه خود ارتباط برقرار می‌کند:

اج‌میکرو به عنوان سایدکار

یکی از مزایای این سبک معماری این است که Edge Microgateway مدیریت API را برای سرویس‌های منفرد مستقر در یک محیط کانتینر، مانند یک کلاستر Kubernetes، فراهم می‌کند.

پیکربندی حالت پروکسی محلی

برای پیکربندی Edge Microgateway برای اجرا در حالت پروکسی محلی، این مراحل را دنبال کنید:

  1. مطمئن شوید که Edge Microgateway نسخه ۲.۵.۲۵ یا بالاتر را نصب کرده‌اید. در غیر این صورت، برای ارتقا به آخرین نسخه، باید دستور زیر را اجرا کنید:
    npm install -g edgemicro

    اگر به کمک نیاز دارید، به نصب Edge Microgateway مراجعه کنید.

  2. edgemicro init اجرا کنید تا محیط پیکربندی محلی خود را تنظیم کنید، دقیقاً مانند کاری که در یک راه‌اندازی معمولی Edge Microgateway انجام می‌دهید. همچنین به Configure Edge Microgateway مراجعه کنید.
  3. edgemicro configure اجرا کنید، همانطور که در یک روش معمول راه‌اندازی Edge Microgateway انجام می‌دهید. برای مثال:
    edgemicro configure -o your_org -e your_env -u your_apigee_username

    این دستور، سیاست edgemicro-auth را در Edge مستقر می‌کند و یک کلید و رمز را که برای شروع microgateway به آن نیاز دارید، برمی‌گرداند. اگر به کمک نیاز دارید، به پیکربندی Edge Microgateway مراجعه کنید.

  4. در Apigee Edge، یک محصول API ایجاد کنید و الزامات پیکربندی اجباری زیر را در آن قرار دهید (می‌توانید سایر پیکربندی‌ها را به دلخواه خود مدیریت کنید):
    • شما باید پروکسی edgemicro-auth را به محصول اضافه کنید. این پروکسی هنگام اجرای 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 نام پروکسی محلی است که ایجاد خواهد شد.
    • local_proxy_version شماره نسخه پروکسی است.
    • target_url آدرس اینترنتی (URL) هدف پروکسی (سرویسی که پروکسی فراخوانی می‌کند) است.
    • base_path مسیر پایه پروکسی است. این مقدار باید با یک اسلش شروع شود. برای مسیر پایه ریشه، فقط یک اسلش مشخص کنید؛ برای مثال، "/".

    برای مثال: 

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

آزمایش پیکربندی

شما می‌توانید پیکربندی پروکسی محلی را با فراخوانی نقطه پایانی پروکسی آزمایش کنید. برای مثال، اگر مسیر پایه /echo را مشخص کرده‌اید، می‌توانید پروکسی را به صورت زیر فراخوانی کنید: 

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":""
}