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

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

Edge Microgateway نسخه 3.3.x

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

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

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

Apigee توصیه می‌کند پیکربندی موجودتان را با نسخه جدید قبل‌از ارتقا دادن محیط تولیدتان آزمایش کنید.

1. فرمان npm زیر را برای ارتقا به جدیدترین نسخه Edge Microgateway اجرا کنید:

   npm upgrade edgemicro -g

   برای نصب نسخه خاصی از Edge Microgateway، باید شماره نسخه را در فرمان نصب مشخص کنید. برای مثال، برای نصب نسخه ۳.۲.۳، از فرمان زیر استفاده کنید:

   npm install edgemicro@3.2.3 -g

2. شماره نسخه را بررسی کنید؛ برای مثال، اگر نسخه ۳.۲.۳ را نصب کرده‌اید:

   edgemicro --version
   current nodejs version is v12.5.0
   current edgemicro version is 3.2.3
       

3. درنهایت، به جدیدترین نسخه پراکسی edgemicro-auth ارتقا دهید:

   edgemicro upgradeauth -o $ORG -e $ENV -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 -e $ENV -k $KEY -s $SECRET

   مکان:

   • $ORG نام سازمان Edge شما است (باید سرپرست سازمان باشید).
   • $ENV محیطی در سازمان شما است (مثل «test» یا «prod»).
   • $KEY کلیدی است که قبلاً توسط فرمان پیکربندی برگردانده شده است.
   • $SECRET کلیدی است که قبلاً توسط فرمان پیکربندی برگردانده شده است.

   برای مثال

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

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

1. بازراه‌اندازی Edge Microgateway:

   edgemicro start -o $ORG -e $ENV -k $KEY -s $SECRET

   مکان:

   • $ORG نام سازمان Edge شما است (باید سرپرست سازمان باشید).
   • $ENV محیطی در سازمان شما است (مثل «test» یا «prod»).
   • $KEY کلیدی است که قبلاً توسط فرمان پیکربندی برگردانده شده است.
   • $SECRET کلیدی است که قبلاً توسط فرمان پیکربندی برگردانده شده است.

   برای مثال:

   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

برای آشنایی با پیکربندی TLS در Apigee Edge Microgateway، ویدیوهای زیر را تماشا کنید:

می‌توانید سرور Microgateway را برای استفاده از SSL پیکربندی کنید. برای مثال، با پیکربندی SSL، می‌توانید میاناهای برنامه‌سازی کاربردی را ازطریق 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

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

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

می‌توانید Edge Microgateway را به‌گونه‌ای پیکربندی کنید که هنگام اتصال به نقاط پایانی هدف، کارخواه «امنیت لایه انتقال» یا 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

در مواردی که می‌خواهید تنظیمات TLS/SSL را برای چند هدف خاص اعمال کنید، باید اولین میزبان را در پیکربندی به‌عنوان «خالی» مشخص کنید که درخواست‌های جهانی را فعال می‌کند، و سپس میزبان‌های خاص را به هر ترتیبی مشخص کنید. در این مثال، تنظیمات برای چند میزبان خاص اعمال می‌شود:

targets:
 - host:   ## Note that this value must be "empty"
   ssl:
     client:
       key: /Users/myname/twowayssl/ssl/client.key
       cert: /Users/myname/twowayssl/ssl/ca.crt
       passphrase: admin123
       rejectUnauthorized: true
 - host: 'myserver1.example.com'
   ssl:
     client:
       key: /Users/myname/twowayssl/ssl/client.key
       cert: /Users/myname/twowayssl/ssl/ca.crt
       rejectUnauthorized: true
 - host: 'myserver2.example.com'
   ssl:
     client:
       key: /Users/myname/twowayssl/ssl/client.key
       cert: /Users/myname/twowayssl/ssl/ca.crt
       rejectUnauthorized: true

در اینجا فهرستی از همه گزینه‌های مشتری پشتیبانی‌شده ارائه شده است:

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

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

استفاده از سرویس اصالت‌سنجی سفارشی

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

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

نحوه تنظیم سطح ثبت گزارش

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

برای مثال، پیکربندی زیر سطح ثبت گزارش را روی debug تنظیم می‌کند:

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

نحوه تغییر دادن فواصل گزارش‌گیری

می‌توانید این فاصله‌ها را در فایل پیکربندی 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

نحوه کاهش سخت‌گیری اجازه‌های فایل گزارش

به‌طور پیش‌فرض، Edge Microgateway فایل گزارش برنامه (api-log.log) را با سطح اجازه فایل تنظیم‌شده روی ۰۶۰۰ تولید می‌کند. این سطح اجازه به برنامه‌ها یا کاربران خارجی اجازه نمی‌دهد فایل گزارش را بخوانند. برای کاهش این سطح اجازه سخت‌گیرانه، logging:disableStrictLogFile را روی true تنظیم کنید. وقتی این مشخصه true باشد، فایل گزارش با اجازه فایل تنظیم‌شده روی ۰۷۵۵ ایجاد می‌شود. اگر false یا اگر مشخصه ارائه نشده باشد، اجازه به‌طور پیش‌فرض روی ۰۶۰۰ تنظیم می‌شود.

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

برای مثال:

edgemicro:
 logging:
   disableStrictLogFile: true

روش‌های خوب نگهداری فایل گزارش

ازآنجایی‌که داده‌های فایل گزارش به‌مرور زمان انباشته می‌شوند، Apigee توصیه می‌کند که از روش‌های زیر استفاده کنید:

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

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

هر نمونه Edge Microgateway یک فایل گزارش با پسوند .log تولید می‌کند. قرارداد نام‌گذاری برای فایل‌های گزارش به شرح زیر است:

edgemicro-HOST_NAME-INSTANCE_ID-api.log

برای مثال:

edgemicro-mymachine-local-MTQzNTgNDMxODAyMQ-api.log

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

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

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

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

• 1436403888651 - مُهر تاریخ یونیکس
• info - سطح ثبت گزارش. این مقدار به بافت تراکنش و سطح ثبت تنظیم‌شده در پیکربندی edgemicro بستگی دارد. نحوه تنظیم سطح ثبت گزارش را ببینید. برای سوابق آمار، سطح روی stats تنظیم شده است. سوابق آمار در فواصل زمانی منظمی که با پیکربندی stats_log_interval تنظیم شده است گزارش می‌شود. نحوه تغییر دادن فاصله‌های زمانی گزارش را نیز ببینید.
• req - رویداد را شناسایی می‌کند. در این مورد، درخواست از کلاینت.
• m - فعل HTTP استفاده‌شده در درخواست.
• u - بخشی از نشانی وب که پس‌از مسیر پایه می‌آید.
• h - میزبان و شماره درگاهی که Edge Microgateway در آن گوش می‌دهد.
• r - میزبان و درگاه راه دور که درخواست مشتری از آنجا منشأ گرفته است.
• i - شناسه درخواست. هر چهار ورودی رویداد این شناسه را هم‌رسانی خواهند کرد. به هر درخواست یک شناسه درخواست یکتا اختصاص داده می‌شود. مرتبط کردن سوابق گزارش با شناسه درخواست می‌تواند اطلاعات آماری ارزشمندی درباره تأخیر هدف ارائه دهد.
• d - مدت زمان برحسب میلی‌ثانیه از زمانی که درخواست توسط Edge Microgateway دریافت شد. در مثال بالا، پاسخ هدف برای درخواست ۰ پس‌از ۷ میلی‌ثانیه دریافت شد (خط ۳)، و پاسخ پس‌از ۴ میلی‌ثانیه دیگر به مشتری ارسال شد (خط ۴). به عبارت دیگر، کل تأخیر درخواست ۱۱ میلی‌ثانیه بود که از این مقدار، ۷ میلی‌ثانیه توسط هدف و ۴ میلی‌ثانیه توسط خود Edge Microgateway صرف شد.

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

1436403888665 info treq m=GET, u=/, h=127.0.0.1:8080, i=0

• 1436403888651 - مُهر تاریخ یونیکس
• info - سطح ثبت گزارش. این مقدار به بافت تراکنش و سطح ثبت تنظیم‌شده در پیکربندی edgemicro بستگی دارد. نحوه تنظیم سطح ثبت گزارش را ببینید. برای سوابق آمار، سطح روی stats تنظیم شده است. سوابق آمار در فواصل زمانی منظمی که با پیکربندی stats_log_interval تنظیم شده است گزارش می‌شود. نحوه تغییر دادن فاصله‌های زمانی گزارش را نیز ببینید.
• treq - رویداد را شناسایی می‌کند. دراین‌صورت، درخواست هدف.
• m - فعل HTTP استفاده‌شده در درخواست هدف.
• u - بخشی از نشانی وب که پس‌از مسیر پایه می‌آید.
• h - شماره میزبان و درگاه هدف باطن.
• i - شناسه ورودی گزارش. هر چهار ورودی رویداد این شناسه را هم‌رسانی خواهند کرد.

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

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

1436403888651 - مُهر تاریخ یونیکس

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

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

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

1436403888651 - مُهر تاریخ یونیکس

• info - سطح ثبت گزارش. این مقدار به بافت تراکنش و سطح ثبت تنظیم‌شده در پیکربندی edgemicro بستگی دارد. نحوه تنظیم سطح ثبت گزارش را ببینید. برای سوابق آمار، سطح روی stats تنظیم شده است. سوابق آمار در فواصل زمانی منظمی که با پیکربندی stats_log_interval تنظیم شده است گزارش می‌شود. نحوه تغییر دادن فاصله‌های زمانی گزارش را نیز ببینید.
• res - رویداد را شناسایی می‌کند. در این مورد، پاسخ به کارخواه.
• s - وضعیت پاسخ‌های HTTP.
• d - مدت‌زمان به میلی‌ثانیه. این کل زمان صرف‌شده برای فراخوانی میانای برنامه‌سازی کاربردی است، ازجمله زمان صرف‌شده برای میانای برنامه‌سازی کاربردی هدف و زمان صرف‌شده توسط خود Edge Microgateway.
• i - شناسه ورودی گزارش. هر چهار ورودی رویداد این شناسه را هم‌رسانی خواهند کرد.

زمان‌بندی فایل گزارش

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

پیام‌های خطا

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

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

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

مشخصه‌های پیکربندی شرح‌داده‌شده در این بخش در فایل پیکربندی Edge Microgateway قرار دارند. ایجاد تغییرات پیکربندی را نیز ببینید.

مشخصه‌های edge_config

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

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

  edge_config:
    quotaUri: https://your_org-your_env.apigee.net/edgemicro-auth
  

مشخصه‌های edgemicro

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

• درگاه: (پیش‌فرض: ۸۰۰۰) شماره درگاهی که فرایند Edge Microgateway به آن گوش می‌دهد.
• max_connections: (پیش‌فرض: -1) حداکثر تعداد اتصالات ورودی هم‌زمان را که Edge Microgateway می‌تواند دریافت کند مشخص می‌کند. اگر از این تعداد فراتر بروید، وضعیت زیر برگردانده می‌شود:
  
  res.statusCode = 429; // Too many requests
  
• max_connections_hard: (پیش‌فرض: -1) حداکثر تعداد درخواست‌های هم‌زمان که Edge Microgateway می‌تواند قبل‌از قطع اتصال دریافت کند. این تنظیم برای خنثی کردن حملات منع سرویس درنظر گرفته شده است. معمولاً آن را روی عددی بزرگ‌تر از max_connections تنظیم کنید.
• ورود به سیستم:
  • level: (پیش‌فرض: error)
    • info - (توصیه‌شده) همه درخواست‌ها و پاسخ‌هایی را که ازطریق نمونه Edge Microgateway جریان می‌یابند ثبت می‌کند.
    • warn - فقط پیام‌های هشدار را ثبت می‌کند.
    • error - فقط پیام‌های خطا را ثبت می‌کند.
    • debug - پیام‌های اشکال‌زدایی را به‌همراه پیام‌های اطلاعات، هشدار، و خطا ثبت می‌کند.
    • ردیابی - اطلاعات ردیابی را برای خطاها به‌همراه اطلاعات، هشدار، و پیام‌های خطا ثبت می‌کند.
    • none - فایل گزارش ایجاد نمی‌شود.
  • 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 (تغییرات در محصولات، پراکسی‌های آگاه از ریزدروازه، و غیره) و همچنین تغییرات ایجادشده در فایل پیکربندی محلی را دریافت می‌کند.
  
• disable_config_poll_interval: (پیش‌فرض: false) برای خاموش کردن نظرسنجی تغییر خودکار، روی true تنظیم کنید.
• request_timeout: زمان استراحت را برای درخواست‌های هدف تنظیم می‌کند. زمان استراحت برحسب ثانیه تنظیم شده است. اگر وقفه زمانی رخ دهد، Edge Microgateway با رمز وضعیت ۵۰۴ پاسخ می‌دهد. (افزوده‌شده v2.4.x)
• keep_alive_timeout: این ویژگی به شما امکان می‌دهد زمان اتمام Edge Microgateway را (به میلی‌ثانیه) تنظیم کنید. (پیش‌فرض: ۵ ثانیه) (نسخه ۳.۰.۶ اضافه شد)
• headers_timeout: این مشخصه مقدار زمانی (به میلی‌ثانیه) را که تجزیه‌کننده HTTP برای دریافت سرصفحه‌های کامل HTTP منتظر می‌ماند محدود می‌کند.

  برای مثال:

  edgemicro:
    keep_alive_timeout: 6000
    headers_timeout: 12000

  در داخل، پارامتر Node.js را تنظیم می‌کند Server.headersTimeout مشخصه در درخواست‌ها. (پیش‌فرض: ۵ ثانیه بیشتر از زمان تنظیم‌شده با edgemicro.keep_alive_timeout. این تنظیم پیش‌فرض مانع از قطع اشتباهی اتصال توسط متعادل‌کننده‌های بار یا پراکسی‌ها می‌شود.) (نسخه ۳.۱.۱ اضافه شد)

• noRuleMatchAction: (رشته) کنشی که باید انجام شود (اجازه دادن یا رد کردن دسترسی) اگر قانون مطابقت مشخص‌شده در افزونه accesscontrol حل‌وفصل نشود (مطابقت نداشته باشد). مقادیر معتبر: ALLOW یا DENY پیش‌فرض: ALLOW (اضافه‌شده: نسخه ۳.۱.۷)
• enableAnalytics: (پیش‌فرض: true) برای جلوگیری از بار شدن افزونه Analytics، این مشخصه را روی false تنظیم کنید. در این حالت، هیچ فراخوانی‌ای برای تجزیه‌وتحلیل Apigee Edge انجام نخواهد شد. اگر روی درست تنظیم شود، یا وقتی این مشخصه ارائه نشده باشد، افزونه Analytics طبق معمول کار خواهد کرد. برای جزئیات، مشخصه‌های edgemicro را ببینید. (در نسخه ۳.۱.۸ اضافه شده است).

  مثال:

  edgemicro
    enableAnalytics=false|true

• on_target_response_abort: این مشخصه به شما امکان می‌دهد نحوه رفتار Edge Microgateway را درصورت بسته شدن زودهنگام اتصال بین کلاینت (Edge Microgateway) و سرور هدف کنترل کنید.

  مقدار	شرح
  پیش‌فرض	اگر on_target_response_abort مشخص نشده باشد، رفتار پیش‌فرض این است که پاسخ بدون نشان دادن خطا کوتاه می‌شود. در فایل‌های گزارش، پیام هشدار با targetResponse aborted و کد پاسخ ۵۰۲ نشان داده می‌شود.
  appendErrorToClientResponseBody	خطای سفارشی TargetResponseAborted به کارخواه برگردانده می‌شود. در فایل‌های گزارش، پیام هشدار با targetResponse aborted و کد پاسخ ۵۰۲ نشان داده می‌شود. به‌علاوه، خطای TargetResponseAborted با پیام Target response ended prematurely. ثبت می‌شود
  abortClientRequest	‫Edge Microgateway درخواست را لغو می‌کند و هشداری در فایل‌های گزارش نوشته می‌شود: TargetResponseAborted با کد وضعیت درخواست ۵۰۲.

مثال:

edgemicro:
 on_target_response_abort: appendErrorToClientResponseBody | abortClientRequest

مشخصه‌های سرصفحه

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

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

مشخصه‌های oauth

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

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

مشخصه‌های مختص افزایه

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

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

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

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

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

از پیکربندی زیر برای محدود کردن تعداد محصولات API که Edge Microgateway بارگیری و پردازش می‌کند استفاده کنید. برای فیلتر کردن محصولات بارگیری‌شده، پارامتر پُرسمان productnamefilter را به API /products فهرست‌شده در فایل Edge Microgateway *.config.yaml اضافه کنید. برای مثال:

edge_config:
  bootstrap: >-
    https://edgemicroservices.apigee.net/edgemicro/bootstrap/organization/willwitman/environment/test
  jwt_public_key: 'https://myorg-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://myorg-test.apigee.net/edgemicro-auth/products?productnamefilter=%5E%5BEe%5Ddgemicro.%2A%24'

توجه داشته باشید که مقدار پارامتر پُرسمان باید در قالب عبارت باقاعده مشخص شود و با URL کدگذاری شود. برای مثال، عبارت باقاعده ^[Ee]dgemicro.*$ نام‌هایی مثل موارد زیر را می‌گیرد: «edgemicro-test-1»،‏ «edgemicro_demo»، و «Edgemicro_New_Demo». مقدار کدبندی‌شده نشانی وب، مناسب برای استفاده در پارامتر پُرسمان، عبارت است از: %5E%5BEe%5Ddgemicro.%2A%24.

برونداد اشکال‌زدایی زیر نشان می‌دهد که فقط محصولات فیلترشده بارگیری شده‌اند:

...
2020-05-27T03:13:50.087Z [76060] [microgateway-config network] products download from https://gsc-demo-prod.apigee.net/edgemicro-auth/products?productnamefilter=%5E%5BEe%5Ddgemicro.%2A%24 returned 200 OK
...
....
....
{
   "apiProduct":[
      {
         "apiResources":[

         ],
         "approvalType":"auto",
         "attributes":[
            {
               "name":"access",
               "value":"public"
            }
         ],
         "createdAt":1590549037549,
         "createdBy":"k***@g********m",
         "displayName":"test upper case in name",
         "environments":[
            "prod",
            "test"
         ],
         "lastModifiedAt":1590549037549,
         "lastModifiedBy":"k***@g********m",
         "name":"Edgemicro_New_Demo",
         "proxies":[
            "catchall"
         ],
         "quota":"null",
         "quotaInterval":"null",
         "quotaTimeUnit":"null",
         "scopes":[

         ]
      },
      {
         "apiResources":[

         ],
         "approvalType":"auto",
         "attributes":[
            {
               "name":"access",
               "value":"public"
            }
         ],
         "createdAt":1590548328998,
         "createdBy":"k***@g********m",
         "displayName":"edgemicro test 1",
         "environments":[
            "prod",
            "test"
         ],
         "lastModifiedAt":1590548328998,
         "lastModifiedBy":"k***@g********m",
         "name":"edgemicro-test-1",
         "proxies":[
            "Lets-Encrypt-Validation-DoNotDelete"
         ],
         "quota":"null",
         "quotaInterval":"null",
         "quotaTimeUnit":"null",
         "scopes":[

         ]
      },
      {
         "apiResources":[
            "/",
            "/**"
         ],
         "approvalType":"auto",
         "attributes":[
            {
               "name":"access",
               "value":"public"
            }
         ],
         "createdAt":1558182193472,
         "createdBy":"m*********@g********m",
         "displayName":"Edge microgateway demo product",
         "environments":[
            "prod",
            "test"
         ],
         "lastModifiedAt":1569077897465,
         "lastModifiedBy":"m*********@g********m",
         "name":"edgemicro_demo",
         "proxies":[
            "edgemicro-auth",
            "edgemicro_hello"
         ],
         "quota":"600",
         "quotaInterval":"1",
         "quotaTimeUnit":"minute",
         "scopes":[

         ]
      }
   ]
}

فیلتر کردن محصولات براساس مشخصه‌های سفارشی

برای فیلتر کردن محصولات براساس مشخصه‌های سفارشی:

1. در Edge UI، پراکسی edgemicro_auth را در سازمان/محیطی که Edge Microgateway را پیکربندی کرده‌اید انتخاب کنید.
2. در برگه «توسعه»، خط‌مشی JavaCallout را در ویرایشگر باز کنید.
3. مشخصه سفارشی با کلید products.filter.attributes با فهرست جداشده با کاما از نام‌های مشخصه اضافه کنید. فقط محصولاتی که حاوی هریک از نام‌های مشخصه سفارشی باشند به Edge Microgateway برگردانده خواهند شد.
4. می‌توانید با تنظیم کردن مشخصه سفارشی products.filter.env.enable روی false، بررسی فعال بودن محصول برای محیط فعلی را به‌صورت اختیاری غیرفعال کنید. (پیش‌فرض true است.)
5. (فقط Private Cloud) اگر در Edge برای Private Cloud هستید، ویژگی org.noncps را روی true تنظیم کنید تا محصولات را برای محیط‌های غیر CPS بکشید.

برای مثال:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<JavaCallout async="false" continueOnError="false" enabled="true" name="JavaCallout">
    <DisplayName>JavaCallout</DisplayName>
    <FaultRules/>
    <Properties>
        <Property name="products.filter.attributes">attrib.one, attrib.two</Property>
        <Property name="products.filter.env.enable">false</Property>
        <Property name="org.noncps">true</Property>
    </Properties>
    <ClassName>io.apigee.microgateway.javacallout.Callout</ClassName>
    <ResourceURL>java://micro-gateway-products-javacallout-2.0.0.jar</ResourceURL>
</JavaCallout>

محصولات براساس وضعیت لغو فیلتر می‌شوند

محصولات API سه کد وضعیت دارند - درانتظار، تأییدشده، و لغوشده. ویژگی جدیدی به‌نام allowProductStatus به خط‌مشی «تنظیم متغیرهای JWT» در پراکسی edgemicro-auth اضافه شده است. برای استفاده از این ویژگی برای فیلتر کردن محصولات API فهرست‌شده در JWT:

1. پراکسی edgemicro-auth را در ویرایشگر پراکسی Apigee باز کنید.
2. ویژگی allowProductStatus را به XML خط‌مشی SetJWTVariables اضافه کنید و فهرست جداشده با کاما از کدهای وضعیت را برای فیلتر کردن مشخص کنید. برای مثال، برای فیلتر کردن براساس وضعیت درانتظار و لغوشده:

   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
   <Javascript timeLimit="20000" async="false" continueOnError="false"
       enabled="true" name="Set-JWT-Variables">
       <DisplayName>Set JWT Variables</DisplayName>
       <FaultRules/>
       <Properties>
           <Property name="allowProductStatus">Pending,Revoked</Property>
       </Properties>
       <ResourceURL>jsc://set-jwt-variables.js</ResourceURL>
   </Javascript>

   اگر می‌خواهید فقط محصولات تأییدشده فهرست شوند، ویژگی را به‌صورت زیر تنظیم کنید:

   <Property name="allowProductStatus">Approved</Property>

3. پراکسی را ذخیره کنید.

   اگر برچسب Property وجود نداشته باشد، محصولات با همه کدهای وضعیت در JWT فهرست خواهند شد.

   برای استفاده از این ویژگی جدید، باید پراکسی edgemicro-auth را ارتقا دهید.

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

از این پارامترهای پیکربندی برای کنترل کردن فرکانسی که 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'

جداسازی فراخوانی‌های میانای برنامه‌سازی کاربردی در Edge Analytics

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

edgemicro_proxyname-health

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

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

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

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

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

در پیکربندی زیر، هر میانای برنامه‌سازی کاربردی با مسیر پراکسی /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 پشت دیوار آتش شرکت

استفاده از پراکسی HTTP برای ارتباط با Apigee Edge

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

برای استفاده از پراکسی HTTP برای ارتباط بین Edge Microgateway و Apigee Edge، کارهای زیر را انجام دهید:

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

   export HTTP_PROXY='http://localhost:3786'
   export HTTPS_PROXY='https://localhost:3786'
   export NO_PROXY='localhost,localhost:8080'

   توجه داشته باشید که NO_PROXY می‌تواند فهرستی از دامنه‌های جداشده با کاما باشد که Edge Microgateway نباید به آن‌ها پروکسی کند.

   برای اطلاعات بیشتر درباره این متغیرها، https://www.npmjs.com/package/request#controlling-proxy-behaviour-using-environment-variables را ببینید

2. Edge Microgateway را بازراه‌اندازی کنید.

استفاده از پروکسی HTTP برای ارتباط هدف

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

برای استفاده از پراکسی HTTP برای ارتباط بین Edge Microgateway و هدف‌های پس‌بک، کارهای زیر را انجام دهید:

1. پیکربندی زیر را به فایل پیکربندی microgateway اضافه کنید:

   edgemicro:
     proxy:
       tunnel: true | false
       url: proxy_url
       bypass: target_host # target hosts to bypass the proxy.
       enabled: true | false

   مکان:

   • tunnel: (اختیاری) وقتی درست باشد، Edge Microgateway از روش HTTP CONNECT برای تونل کردن درخواست‌های HTTP ازطریق یک اتصال TCP استفاده می‌کند. (اگر متغیرهای محیطی، همان‌طور که در زیر ذکر شده است، برای پیکربندی پراکسی TLS فعال باشند، همین امر صادق است). پیش‌فرض: false
   • url: نشانی وب پروکسی HTTP.
   • bypass: (اختیاری) یک یا چند نشانی وب میزبان هدف جداشده با کاما را مشخص می‌کند که باید پراکسی HTTP را دور بزنند. اگر این ویژگی تنظیم نشده است، از متغیر محیطی NO_PROXY برای مشخص کردن نشانی‌های وب هدف برای دور زدن استفاده کنید.
   • enabled: اگر درست باشد و proxy.url تنظیم شده باشد، از مقدار proxy.url برای پراکسی HTTP استفاده کنید. اگر درست باشد و proxy.url تنظیم نشده باشد، از پراکسی‌های مشخص‌شده در متغیرهای محیطی پراکسی HTTP HTTP_PROXY و HTTPS_PROXY استفاده کنید، همان‌طور که در استفاده از پراکسی HTTP برای ارتباط با Apigee Edge شرح داده شده است.

   برای مثال:

   edgemicro:
     proxy:
       tunnel: true
       url: 'http://localhost:3786'
       bypass: 'localhost','localhost:8080' # target hosts to bypass the proxy.
       enabled: true

2. Edge Microgateway را بازراه‌اندازی کنید.

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

می‌توانید از یک یا چند نویسه عام «*» در مسیر پایه یک پراکسی edgemicro_* (آگاه از Microgateway) استفاده کنید. برای مثال، مسیر پایه /team/*/members به کارخواه‌ها اجازه می‌دهد https://[host]/team/blue/members و https://[host]/team/green/members را بدون نیاز به ایجاد پراکسی‌های میانای برنامه‌سازی کاربردی جدید برای پشتیبانی از تیم‌های جدید فراخوانی کنند. توجه داشته باشید که از /**/ پشتیبانی نمی‌شود.

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

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

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

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

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

می‌توانید بااستفاده از CLI یک JWT تولید کنید و از آن در سرصفحه «مجوز» تماس‌های API به‌جای کلید API استفاده کنید. برای مثال:

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

برای کسب اطلاعات درباره تولید کردن JWT با میانای خط فرمان، به تولید کردن کد مراجعه کنید.

تغییر کلید چیست؟

مدتی پس‌از تولید اولیه 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 مرتبط است و برای پشتیبانی از چرخش کلید استفاده می‌شود. این مقدار با شناسه کلید خصوصی یکسان است.

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

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

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

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

JWTهای ارائه‌شده برای درستی‌سنجی بااستفاده از کلید عمومی جدید درستی‌سنجی خواهند شد. اگر درستی‌سنجی ناموفق باشد، از کلید عمومی قدیمی استفاده خواهد شد تا زمانی که JWT منقضی شود (پس‌از فاصله token_expiry*، به‌طور پیش‌فرض ۳۰ دقیقه). به‌این‌ترتیب، می‌توانید کلیدها را بدون ایجاد اختلال فوری در ترافیک میانای برنامه‌سازی کاربردی «بچرخانید».

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

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

1. برای ارتقا دادن KVM، از فرمان edgemicro upgradekvm استفاده کنید. برای جزئیات درباره اجرای این فرمان، به ارتقا دادن KVM مراجعه کنید. فقط یک‌بار باید این مرحله را انجام دهید.
2. برای ارتقا دادن پروکسی edgemicro-oauth، از فرمان edgemicro upgradeauth استفاده کنید. برای جزئیات مربوط به اجرای این فرمان، ارتقا دادن پراکسی edgemicro-auth را ببینید. فقط یک‌بار باید این مرحله را انجام دهید.
3. خط زیر را به فایل ~/.edgemicro/org-env-config.yaml اضافه کنید، که در آن باید همان سازمان و محیطی را که برای استفاده از ریزدروازه پیکربندی کرده‌اید مشخص کنید:

   jwk_public_keys: 'https://$ORG-$ENV.apigee.net/edgemicro-auth/jwkPublicKeys'

4. فرمان چرخش کلید را برای چرخاندن کلیدها اجرا کنید. برای جزئیات مربوط به این فرمان، کلیدهای چرخشی را ببینید.

   edgemicro rotatekey -o $ORG -e $ENV -k $KEY -s $SECRET

   برای مثال:

   edgemicro rotatekey -o docs -e test \
   -k 27ee39567c75e4567a66236cbd4e86d1cc93df6481454301bd5fac4d3497fcbb \
   -s 4618b0008a6185d7327ebf53bee3c50282ccf45a3cceb1ed9828bfbcf1148b47
   

پس‌از چرخش کلید، 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"
    }
  ]
}

پیکربندی کردن تأخیر «نه قبل‌از»

برای نسخه‌های ۳.۱.۵ و قبل‌از آن، کلید خصوصی جدیدی که با فرمان rotatekey تولید می‌شد بلافاصله اعمال می‌شد و توکن‌های جدید تولیدشده با کلید خصوصی جدید امضا می‌شدند. بااین‌حال، کلید عمومی جدید فقط هر ۱۰ دقیقه یک‌بار (به‌طور پیش‌فرض) هنگام بازآوری پیکربندی ریزدروازه برای نمونه‌های Edge Microgateway دردسترس قرار می‌گرفت. به‌دلیل این تأخیر بین امضای ژتون و بازآوری نمونه microgateway، ژتون‌های امضاشده با جدیدترین کلید تا زمانی که همه نمونه‌ها جدیدترین کلید عمومی را دریافت نکنند رد می‌شوند.

در مواردی که چندین نمونه ریزدروازه وجود دارد، تأخیر کلید عمومی گاهی اوقات منجر به خطاهای زمان اجرای متناوب با وضعیت ۴۰۳ می‌شود، زیرا اعتبارسنجی رمز در یک نمونه موفقیت‌آمیز است، اما در نمونه دیگر تا زمانی که همه نمونه‌ها بازآوری نشوند، ناموفق است.

از نسخه ۳.۱.۶، پرچم جدیدی در فرمان rotatekey به شما امکان می‌دهد تأخیری را برای فعال شدن کلید خصوصی جدید مشخص کنید، که این کار به همه نمونه‌های ریزدروازه زمان می‌دهد تا بازآوری شوند و کلید عمومی جدید را دریافت کنند. پرچم جدید --nbf است که مخفف «نه قبل‌از» است. این پرچم مقدار عدد صحیح می‌گیرد، تعداد دقیقه‌هایی که باید تأخیر داشته باشد.

در مثال زیر، تأخیر روی ۱۵ دقیقه تنظیم شده است:

edgemicro rotatekey -o docs -e test \
-k 27ee39567c75e4567a66236cbd4e86d1cc93df6481454301bd5fac4d3497fcbb \
-s 4618b0008a6185d7327ebf53bee3c50282ccf45a3cceb1ed9828bfbcf1148b47 \
--nbf 15

توجه داشته باشید که روش خوب این است که تأخیر را بیشتر از تنظیم پیکربندی config_change_poll_internal تنظیم کنید، که به‌طور پیش‌فرض ۱۰ دقیقه است. همچنین مشخصه‌های edgemicro را ببینید.

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

به‌طور پیش‌فرض، 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*

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

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

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

درحال اتصال به اشکال‌زدا

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

1. Edge Microgateway را در حالت اشکال‌زدایی بازراه‌اندازی کنید. برای انجام این کار، DEBUG=* را به ابتدای فرمان start اضافه کنید:

   DEBUG=* edgemicro start -o $ORG -e $ENV -k $KEY -s $SECRET

   برای هدایت خروجی اشکال‌زدایی به فایل، می‌توانید از این فرمان استفاده کنید:

   export DEBUG=* nohup edgemicro start \
   -o $ORG -e $ENV -k $KEY -s $SECRET 2>&1 | tee /tmp/file.log

2. اشکال‌زدا را راه‌اندازی کنید و آن را روی شماره درگاه فرایند اشکال‌زدایی تنظیم کنید.
3. اکنون می‌توانید کد Edge Microgateway را گام‌به‌گام اجرا کنید، نقاط توقف تنظیم کنید، عبارت‌ها را تماشا کنید، و غیره.

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

درحال بررسی فایل‌های گزارش

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

استفاده از امنیت کلید میانای برنامه‌سازی کاربردی

کلیدهای میانای برنامه‌سازی کاربردی سازوکار ساده‌ای برای اصالت‌سنجی کردن کارخواه‌هایی که به Edge Microgateway درخواست ارسال می‌کنند ارائه می‌دهد. می‌توانید با کپی کردن مقدار «کلید مصرف‌کننده» (که «شناسه کارخواه» نیز نامیده می‌شود) از محصول Apigee Edge که شامل پراکسی اصالت‌سنجی Edge Microgateway است، کلید میانای برنامه‌سازی کاربردی دریافت کنید.

ذخیره کلیدها در حافظه پنهان

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

استفاده از کلید میانای برنامه‌سازی کاربردی

می‌توانید کلید میانای برنامه‌سازی کاربردی را در درخواست میانای برنامه‌سازی کاربردی به‌عنوان پارامتر پُرسمان یا در سرصفحه ارسال کنید. به‌طور پیش‌فرض، نام پارامتر پُرسمان و سرایند هر دو x-api-key است.

نمونه پارامتر پُرسمان:

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

نمونه سرایند:

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

درحال پیکربندی نام کلید میانای برنامه‌سازی کاربردی

به‌طور پیش‌فرض، 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"

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

فعال کردن کدهای پاسخ بالادستی

به‌طور پیش‌فرض، افزونه oauth فقط رمزهای وضعیت خطای 4xx را برمی‌گرداند اگر پاسخ رمز وضعیت 200 نباشد. می‌توانید این رفتار را تغییر دهید تا همیشه کد دقیق 4xx یا 5xx را بسته به خطا برگرداند.

برای فعال کردن این ویژگی، ویژگی oauth.useUpstreamResponse: true را به پیکربندی Edge Microgateway خود اضافه کنید. برای مثال:

oauth:
  allowNoAuthorization: false
  allowInvalidAuthorization: false
  gracePeriod: 10
  useUpstreamResponse: true

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

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

نحوه دریافت کد دسترسی

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

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

میانای برنامه‌سازی کاربردی ۱: ارسال اطلاعات کاربری به‌عنوان پارامترهای بدنه

نام‌های سازمان و محیط خود را در نشانی وب جایگزین کنید و مقادیر «شناسه مصرف‌کننده» و «رمز مصرف‌کننده» را که از برنامه توسعه‌دهنده در 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"

میانای برنامه‌سازی کاربردی ۲: ارسال اطلاعات کاربری در سرصفحه Basic Auth

اعتبارنامه کارخواه را به‌عنوان سرصفحه «اصالت‌سنجی پایه» و grant_type را به‌عنوان پارامتر فرم ارسال کنید. این فرم فرمان در RFC 6749: چارچوب مجوز OAuth 2.0 نیز مورد بحث قرار گرفته است.

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"

نمونه خروجی

{
"token": "eyJraWQiOiIxIiwidHlwIjoi",
"access_token": "eyJraWQiOiIxIiwid",
"token_type": "bearer",
"expires_in": 1799
}

نحوه دریافت ژتون بازآوری

برای دریافت ژتون بازآوری، یک فراخوانی میانای برنامه‌سازی کاربردی به نقطه پایانی /token از پراکسی edgemicro-auth انجام دهید. باید این فراخوانی میانای برنامه‌سازی کاربردی را با نوع اعطای مجوز password انجام دهید. مراحل زیر این فرایند را توضیح می‌دهد.

1. بااستفاده از میانای برنامه‌سازی کاربردی /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"
   }'

   میانای برنامه‌سازی کاربردی یک کد دسترسی و یک ژتون بازآوری برمی‌گرداند. پاسخ شبیه به این است. توجه داشته باشید که مقادیر expires_in عدد صحیح هستند و برحسب ثانیه مشخص می‌شوند.

   {
       "token": "your-access-token",
       "access_token": "your-access-token",
       "token_type": "bearer",
       "expires_in": 108,
       "refresh_token": "your-refresh-token",
       "refresh_token_expires_in": 431,
       "refresh_token_issued_at": "1562087304302",
       "refresh_token_status": "approved"
   }

2. اکنون می‌توانید با فراخوانی نقطه پایانی /refresh در همان API، از کد بازآوری برای دریافت کد دسترسی جدید استفاده کنید. برای مثال:

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

   میانای برنامه‌سازی کاربردی کد دسترسی جدیدی برمی‌گرداند. پاسخ شبیه به این است:

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

پایش همیشگی

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

اگر چند نمونه 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 و کلید میانای برنامه‌سازی کاربردی
• سهمیه
• Analytics

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

درحال پیکربندی و راه‌اندازی درگاه

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

1. فایل پیکربندی را با نام زیر ایجاد کنید: $HOME/.edgemicro/$ORG-$ENV-config.yaml

   برای مثال:

   vi $HOME/.edgemicro/foo-bar-config.yaml

2. کد زیر را در فایل جای‌گذاری کنید:

   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

3. متغیر محیطی زیر را با مقدار «۱» صادر کنید:

   export EDGEMICRO_LOCAL=1

4. فرمان start زیر را اجرا کنید و مقادیر را برای نمونه‌سازی پراکسی محلی ارائه دهید:

   edgemicro start -o $ORG -e $ENV -a $LOCAL_PROXY_NAME \
     -v $LOCAL_PROXY_VERSION -t $TARGET_URL -b $BASE_PATH

   مکان:

   • $ORG نام «سازمان» است که در نام فایل پیکربندی استفاده کرده‌اید.
   • $ENV نام «env» است که در نام فایل پیکربندی استفاده کرده‌اید.
   • $LOCAL_PROXY_NAME نام پراکسی محلی است که ایجاد خواهد شد. می‌توانید از هر نامی که می‌خواهید استفاده کنید.
   • $LOCAL_PROXY_VERSION شماره نسخه پراکسی است.
   • ‫$TARGET_URL نشانی وب هدف پراکسی است. (هدف سرویسی است که پراکسی آن را فراخوانی می‌کند.)
   • $BASE_PATH مسیر پایه پراکسی است. این مقدار باید با خط مورب رو به جلو شروع شود. برای مسیر پایه ریشه، فقط یک خط مورب رو به جلو مشخص کنید؛ برای مثال، «/».

   برای مثال:

   edgemicro start -o local -e test -a proxy1 -v 1 -t http://mocktarget.apigee.net -b /

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

   curl http://localhost:8000/echo  { "error" : "missing_authorization" }

   چون افزونه extauth در فایل foo-bar-config.yaml است، خطای «missing_authorization» دریافت می‌کنید. این افزونه JWT را که باید در سرصفحه «مجوز» فراخوانی میانای برنامه‌سازی کاربردی وجود داشته باشد، اعتبارسنجی می‌کند. در بخش بعدی، یک JWT دریافت خواهید کرد که به فراخوانی‌های API اجازه می‌دهد بدون خطا انجام شوند.

مثال: دریافت کردن نمودافزار مجوز

مثال زیر نشان می‌دهد که چگونه می‌توان یک JWT را از نقطه پایانی JWT Edge Microgateway در Apigee Edge (edgemicro-auth/jwkPublicKeys) دریافت کرد. این نقطه پایانی زمانی مستقر می‌شود که شما یک راه‌اندازی و پیکربندی استاندارد از Edge Microgateway انجام دهید. برای دریافت JWT از نقطه پایانی Apigee، ابتدا باید راه‌اندازی استاندارد Edge Microgateway را انجام دهید و به اینترنت متصل باشید. نقطه پایانی Apigee در اینجا فقط برای اهداف نمونه استفاده می‌شود و الزامی نیست. درصورت تمایل می‌توانید از نقطه پایانی توکن JWT دیگری استفاده کنید. اگر این کار را انجام دهید، باید JWT را بااستفاده از میانای برنامه‌سازی کاربردی ارائه‌شده برای آن نقطه پایانی دریافت کنید.

مراحل زیر نحوه دریافت کردن توکن بااستفاده از نقطه پایانی edgemicro-auth/jwkPublicKeys را توضیح می‌دهد:.

1. برای استقرار پراکسی edgemicro-auth در سازمان/محیط خود در Apigee Edge، باید راه‌اندازی و پیکربندی استاندارد Edge Microgateway را انجام دهید. اگر قبلاً این مرحله را انجام داده‌اید، نیازی به تکرار آن نیست.
2. اگر Edge Microgateway را در Apigee Cloud مستقر کرده‌اید، باید به اینترنت متصل باشید تا بتوانید JWT را از این نقطه پایانی دریافت کنید.
3. توقف Edge Microgateway:

   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 را مانند قبل بااستفاده از نام‌های org/env که در نام فایل پیکربندی استفاده کردید بازراه‌اندازی کنید. برای مثال:

   edgemicro start -o foo -e bar -a proxy1 -v 1 -t http://mocktarget.apigee.net -b /

6. یک کد JWT از نقطه پایان مجوز دریافت کنید. چون از نقطه پایانی edgemicro-auth/jwkPublicKeys استفاده می‌کنید، می‌توانید از این فرمان CLI استفاده کنید:

می‌توانید بااستفاده از فرمان edgemicro token یا میانای برنامه‌سازی کاربردی، 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 استفاده کرد.

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

برای آزمایش پیکربندی، میانای برنامه‌سازی کاربردی را با کد اضافه‌شده در سرصفحه «مجوز» به‌صورت زیر فراخوانی کنید:

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-aware برای استقرار در Apigee Edge ندارد. درعوض، با ارائه نام پراکسی محلی، مسیر پایه، و نشانی وب هدف هنگام شروع microgateway، یک «پراکسی محلی» را پیکربندی می‌کنید. سپس فراخوانی‌های API به ریزدروازه به نشانی وب هدف پراکسی محلی ارسال می‌شود. در سایر موارد، حالت پراکسی محلی دقیقاً مانند اجرای Edge Microgateway در حالت عادی عمل می‌کند. اصالت‌سنجی به همان صورت کار می‌کند، همان‌طور که توقف جهش و اجرای سهمیه، افزایه‌های سفارشی، و غیره کار می‌کنند.

مورد استفاده و نمونه

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

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

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

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

1. edgemicro init را اجرا کنید تا محیط پیکربندی محلی‌تان را دقیقاً همان‌طور که در راه‌اندازی Edge Microgateway معمولی انجام می‌دهید، راه‌اندازی کنید. همچنین پیکربندی Edge Microgateway را ببینید.
2. edgemicro configure را اجرا کنید، همان‌طور که در روش راه‌اندازی Edge Microgateway معمولی انجام می‌دهید. برای مثال:

   edgemicro configure -o your_org -e your_env -u your_apigee_username

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

3. در Apigee Edge، محصول API را با الزامات پیکربندی اجباری زیر ایجاد کنید (می‌توانید همه پیکربندی‌های دیگر را به‌دلخواه خودتان مدیریت کنید):
   • باید پراکسی edgemicro-auth را به محصول اضافه کنید. این پراکسی هنگام اجرای edgemicro configure به‌طور خودکار مستقر شد.
   • باید مسیر منبع را ارائه کنید. Apigee توصیه می‌کند این مسیر به محصول اضافه شود: /**. برای اطلاعات بیشتر، پیکربندی رفتار مسیر منبع را ببینید. همچنین، ایجاد محصولات میانای برنامه‌سازی کاربردی را در اسناد Edge ببینید.

4. در Apigee Edge، توسعه‌دهنده‌ای ایجاد کنید یا اگر مایلید می‌توانید از توسعه‌دهنده موجود استفاده کنید. برای راهنمایی، افزودن توسعه‌دهندگان بااستفاده از واسط کاربر مدیریت Edge را ببینید.

5. در Apigee Edge، برنامه توسعه‌دهنده ایجاد کنید. باید محصول API را که به‌تازگی ایجاد کرده‌اید به برنامه اضافه کنید. برای راهنمایی، ثبت برنامه در Edge رابط کاربری مدیریت را ببینید.
6. در دستگاهی که Edge Microgateway نصب شده است، متغیر محیطی زیر را با مقدار «۱» صادر کنید.

   export EDGEMICRO_LOCAL_PROXY=1

7. فرمان 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 نشانی وب هدف پیشکار است (سرویسی که پیشکار با آن تماس خواهد گرفت).
   • 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) با خطا مواجه شد زیرا کلید میانای برنامه‌سازی کاربردی معتبری ارائه نکردید. می‌توانید کلید را در برنامه «توسعه‌دهنده» که قبلاً ایجاد کرده‌اید پیدا کنید. برنامه را در Edge UI باز کنید، «کلید مصرف‌کننده» را کپی کنید، و از آن کلید به‌صورت زیر استفاده کنید:

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

استفاده از همگام‌ساز

این بخش نحوه استفاده از همگام‌ساز را توضیح می‌دهد، ویژگی اختیاری‌ای که انعطاف‌پذیری Edge Microgteway را با اجازه دادن به آن برای بازیابی داده‌های پیکربندی از Apigee Edge و نوشتن آن در پایگاه داده محلی Redis بهبود می‌بخشد. با اجرای نمونه همگام‌ساز، سایر نمونه‌های Edge Microgateway که در گره‌های مختلف اجرا می‌شوند می‌توانند پیکربندی خود را مستقیماً از این پایگاه داده بازیابی کنند.

ویژگی همگام‌ساز درحال‌حاضر برای کار با Redis 5.0.x پشتیبانی می‌شود.

همگام‌ساز چیست؟

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

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

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

همگام‌ساز نمونه‌ای از Edge Microgateway است که به‌طور ویژه پیکربندی شده است. تنها هدف آن نظرسنجی Apigee Edge (زمان‌بندی قابل پیکربندی است)، بازیابی داده‌های پیکربندی، و نوشتن آن در پایگاه داده محلی Redis است. نمونه همگام‌ساز خودش نمی‌تواند ترافیک پراکسی میانای برنامه‌سازی کاربردی را پردازش کند. سایر نمونه‌های Edge Microgateway که روی گره‌های مختلف اجرا می‌شوند را می‌توان به‌گونه‌ای پیکربندی کرد که داده‌های پیکربندی را به‌جای Apigee Edge از پایگاه داده Redis بازیابی کنند. چون همه نمونه‌های microgateway داده‌های پیکربندی‌شان را از پایگاه داده محلی می‌گیرند، می‌توانند حتی درصورت قطع اینترنت، درخواست‌های API را راه‌اندازی و پردازش کنند.

پیکربندی نمونه همگام‌ساز

پیکربندی زیر را به فایل org-env/config.yaml برای نصب Edge Microgateway که می‌خواهید به‌عنوان همگام‌ساز استفاده کنید اضافه کنید:

edgemicro:
  redisHost: host_IP
  redisPort: host_port
  redisDb: database_index
  redisPassword: password
edge_config:
  synchronizerMode: 1
  redisBasedConfigCache: true

برای مثال:

edgemicro:
  redisHost: 192.168.4.77
  redisPort: 6379
  redisDb: 0
  redisPassword: codemaster
edge_config:
  synchronizerMode: 1
  redisBasedConfigCache: true

درنهایت، فایل پیکربندی را ذخیره کنید و نمونه Edge Microgateway را شروع کنید. این سرویس شروع به نظرسنجی از Apigee Edge و ذخیره داده‌های پیکربندی بارگیری‌شده در پایگاه داده Redis می‌کند.

درحال پیکربندی نمونه‌های Edge Microgateway معمولی

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

پیکربندی زیر را به فایل org-env/config.yaml هر گره Edge Microgateway اضافی اضافه کنید. توجه داشته باشید که خصوصیت synchronizerMode روی 0 تنظیم شده است. این ویژگی نمونه را طوری تنظیم می‌کند که به‌عنوان نمونه Edge Microgateway معمولی عمل کند که ترافیک پراکسی میانای برنامه‌سازی کاربردی را پردازش می‌کند و نمونه داده‌های پیکربندی خود را از پایگاه داده Redis دریافت خواهد کرد.

edgemicro:
  redisHost: host_IP
  redisPort: host_port
  redisDb: database_index
  redisPassword: password
edge_config:
  synchronizerMode: 0
  redisBasedConfigCache: true

برای مثال:

edgemicro:
  redisHost: 192.168.4.77
  redisPort: 6379
  redisDb: 0
  redisPassword: codemaster
edge_config:
  synchronizerMode: 0
  redisBasedConfigCache: true

خصوصیت‌های پیکربندی

ویژگی‌های پیکربندی زیر برای پشتیبانی از استفاده از همگام‌ساز اضافه شده‌اند:

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

می‌توانید ریزدروازه را به‌گونه‌ای پیکربندی کنید که از پردازش افزایه‌ها برای نشانی‌های وب مشخص‌شده صرف‌نظر کند. می‌توانید این نشانی‌های وب «مستثنی‌شده» را به‌صورت سراسری (برای همه افزایه‌ها) یا برای افزایه‌های خاص پیکربندی کنید.

برای مثال:

...
edgemicro:
  ...
  plugins:
    excludeUrls: '/hello,/proxy_one' # global exclude urls
    sequence:
      - oauth
      - json2xml
      - quota
json2xml:
  excludeUrls: '/hello/xml'  # plugin level exclude urls
...

در این مثال، افزونه‌ها تماس‌های ورودی پراکسی میانای برنامه‌سازی کاربردی را با مسیرهای /hello یا /proxy_one پردازش نخواهند کرد. علاوه‌براین، از افزونه json2xml برای میاناهای برنامه‌سازی کاربردی که /hello/xml در مسیرشان دارند رد خواهد شد.

تنظیم مشخصه‌های پیکربندی با مقادیر متغیر محیطی

می‌توانید متغیرهای محیطی را بااستفاده از برچسب‌ها در فایل پیکربندی مشخص کنید. برچسب‌های متغیر محیطی مشخص‌شده با مقادیر متغیر محیطی واقعی جایگزین می‌شوند. جایگزین‌ها فقط در حافظه ذخیره می‌شوند و در پیکربندی اصلی یا فایل‌های حافظه پنهان ذخیره نمی‌شوند.

در این مثال، مشخصه key با مقدار متغیر محیطی TARGETS_SSL_CLIENT_KEY جایگزین می‌شود و غیره.

targets:
  - ssl:
      client:
        key: <E>TARGETS_SSL_CLIENT_KEY</E>
        cert: <E>TARGETS_SSL_CLIENT_CERT</E>
        passphrase: <E>TARGETS_SSL_CLIENT_PASSPHRASE</E>

در این مثال، از برچسب <n> برای نشان دادن مقدار عدد صحیح استفاده می‌شود. فقط اعداد صحیح مثبت پشتیبانی می‌شود.

edgemicro:
  port: <E><n>EMG_PORT</n></E>

در این مثال، از برچسب <b> برای نشان دادن مقدار بولی (یعنی درست یا نادرست) استفاده می‌شود.

quotas:
  useRedis: <E><b>EMG_USE_REDIS</b></E>