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

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

Edge Microgateway نسخه 3.2.x

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

اگر اتصال اینترنت دارید Edge Microgateway را ارتقا دهید

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

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

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

    برای نصب یک نسخه خاص از Edge Microgateway، باید شماره نسخه را در دستور install مشخص کنید. به عنوان مثال، برای نصب به نسخه 3.2.3، از دستور زیر استفاده کنید:

    npm install edgemicro@3.2.3 -g
  2. شماره نسخه را بررسی کنید. به عنوان مثال، اگر نسخه 3.2.3 را نصب کرده اید: 
    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 کلیدی است که قبلاً توسط دستور configure بازگردانده شده است.
    • $SECRET کلیدی است که قبلاً توسط دستور configure بازگردانده شده است.

    به عنوان مثال

    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 کلیدی است که قبلاً توسط دستور 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

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

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

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

ویدئو توضیحات
پیکربندی TLS یک طرفه Northbound درباره پیکربندی TLS در Apigee Edge Microgateway بیاموزید. این ویدئو مروری بر TLS و اهمیت آن ارائه می‌کند، TLS را در Edge Microgateway معرفی می‌کند و نحوه پیکربندی Northbound One-Way TLS را نشان می‌دهد.
پیکربندی TLS دو طرفه Northbound این دومین ویدیو در مورد پیکربندی TLS در Apigee Edge Microgateway است. این ویدیو نحوه پیکربندی TLS دو طرفه شمال را توضیح می دهد.
پیکربندی TLS یک طرفه و دو طرفه Southbound این سومین ویدیو در مورد پیکربندی TLS در Apigee Edge Microgateway نحوه پیکربندی TLS یک طرفه و دو طرفه جنوب به جنوب را توضیح می دهد.

شما می توانید سرور 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 به نسخه 3.
servername نام سرور برای برنامه افزودنی SNI (Server Name Indication) TLS.
requestCert درست برای SSL دو طرفه. false برای 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

در موردی که می‌خواهید تنظیمات 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

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

گزینه توضیحات
pfx مسیر فایل pfx حاوی کلید خصوصی، گواهینامه و گواهینامه های CA مشتری در قالب PFX.
key مسیر فایل ca.key (در قالب PEM).
passphrase رشته ای حاوی عبارت عبور برای کلید خصوصی یا PFX.
cert مسیر فایل ca.cert (در قالب PEM).
ca مسیر فایل حاوی لیستی از گواهینامه های قابل اعتماد در قالب PEM.
ciphers رشته ای که رمزهای مورد استفاده را توصیف می کند که با یک ":" از هم جدا شده اند.
rejectUnauthorized اگر درست باشد، گواهی سرور در برابر لیست CA های ارائه شده تأیید می شود. اگر تأیید ناموفق باشد، یک خطا برگردانده می شود.
secureProtocol روش SSL برای استفاده به عنوان مثال، SSLv3_method برای مجبور کردن SSL به نسخه 3.
servername نام سرور برای برنامه افزودنی SNI (Server Name Indication) TLS.

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

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

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

نحوه تنظیم سطح ورود به سیستم

شما سطح log را برای استفاده در پیکربندی 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 : (پیش‌فرض: 60) فاصله زمانی، بر حسب ثانیه، زمانی که رکورد آمار در فایل گزارش API نوشته می‌شود.
  • rotate_interval : (پیش‌فرض: 24) بازه زمانی، بر حسب ساعت، زمانی که فایل‌های گزارش چرخش می‌شوند. به عنوان مثال:
edgemicro:
  home: ../gateway
  port: 8000
  max_connections: -1
  max_connections_hard: -1
  logging:
    level: info
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24

چگونه مجوزهای سختگیرانه پرونده ورود را کاهش دهیم

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

اضافه شده در نسخه 3.2.3.

به عنوان مثال: 

edgemicro:
 logging:
   disableStrictLogFile: true

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

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

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

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

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

edgemicro- HOST_NAME - INSTANCE_ID -api.log

به عنوان مثال:

edgemicro-mymachine-local-MTQzNTgNDMxODAyMQ-api.log

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

اضافه شده در: v2.3.3

به‌طور پیش‌فرض، سرویس گزارش‌گیری 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" ثبت می شود:

  • درخواست دریافتی از مشتری
  • درخواست خروجی به هدف
  • پاسخ دریافتی از هدف
  • پاسخ خروجی به مشتری

هر یک از این ورودی‌های جداگانه به صورت خلاصه نشان داده می‌شود تا به فشرده‌تر کردن فایل‌های گزارش کمک کند. در اینجا چهار ورودی نمونه وجود دارد که هر یک از چهار رویداد را نشان می دهد. در فایل log، آنها به این شکل هستند (شماره خطوط فقط برای مرجع در doc هستند، آنها در فایل log ظاهر نمی شوند).

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

بیایید یک به یک آنها را بررسی کنیم:

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

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

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

1436403888665 info treq m=GET, u=/, h=127.0.0.1:8080, i=0
  • 1436403888651 - مهر تاریخ یونیکس
  • اطلاعات - سطح ورود به سیستم. این مقدار به زمینه تراکنش و سطح ورود به سیستم تنظیم شده در پیکربندی edgemicro بستگی دارد. نحوه تنظیم سطح گزارش را ببینید. برای رکوردهای آمار، سطح روی stats تنظیم شده است. رکوردهای آمار در یک بازه زمانی منظم با پیکربندی stats_log_interval گزارش می‌شوند. نحوه تغییر فواصل گزارش را نیز ببینید.
  • treq - رویداد را شناسایی می کند. در این مورد، درخواست هدف.
  • m - فعل HTTP مورد استفاده در درخواست هدف.
  • u - بخشی از URL که مسیر پایه را دنبال می کند.
  • h - شماره میزبان و پورت هدف باطن.
  • i - شناسه ورودی گزارش. هر چهار ورودی رویداد این شناسه را به اشتراک خواهند گذاشت.

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

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

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

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

4. نمونه پاسخ خروجی به مشتری

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

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

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

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

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

پیام های خطا

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

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

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

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

ویژگی های edge_config

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

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

ویژگی های edgemicro

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

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

    res.statusCode = 429; // Too many requests
  • max_connections_hard : (پیش‌فرض: -1) حداکثر تعداد درخواست‌های همزمانی که Edge Microgateway می‌تواند قبل از قطع کردن اتصال دریافت کند. این تنظیم برای خنثی کردن حملات انکار سرویس در نظر گرفته شده است. به طور معمول، آن را روی عددی بزرگتر از max_connections تنظیم کنید.
  • ورود به سیستم :
    • سطح : (پیش‌فرض: خطا)
      • اطلاعات - (توصیه می‌شود) همه درخواست‌ها و پاسخ‌هایی را که از طریق یک نمونه Edge Microgateway جریان می‌یابند ثبت می‌کند.
      • هشدار - فقط پیام های هشدار را ثبت می کند.
      • خطا - فقط پیام های خطا را ثبت می کند.
      • اشکال زدایی - پیام های اشکال زدایی را همراه با اطلاعات، اخطار و پیام های خطا ثبت می کند.
      • ردیابی - اطلاعات ردیابی خطاها را همراه با اطلاعات، هشدار و پیام های خطا ثبت می کند.
      • هیچ - فایل لاگ ایجاد نکنید.
    • dir : (پیش‌فرض: /var/tmp) فهرستی که فایل‌های گزارش در آن ذخیره می‌شوند.
    • stats_log_interval : (پیش‌فرض: 60) فاصله زمانی که رکورد آمار در فایل لاگ api نوشته می‌شود، بر حسب ثانیه.
    • rotate_interval : (پیش‌فرض: 24) بازه زمانی، بر حسب ساعت، زمانی که فایل‌های گزارش چرخش می‌شوند.
  • پلاگین ها : پلاگین ها قابلیت هایی را به Edge Microgateway اضافه می کنند. برای جزئیات در مورد توسعه افزونه ها، به توسعه افزونه های سفارشی مراجعه کنید.
  • dir : یک مسیر نسبی از دایرکتوری ./gateway به دایرکتوری ./plugins یا یک مسیر مطلق.
  • sequence : لیستی از ماژول های افزونه برای افزودن به نمونه Edge Microgateway. ماژول ها به ترتیبی که در اینجا مشخص شده اند اجرا می شوند.
  • اشکال زدایی: اشکال زدایی از راه دور را به فرآیند Edge Microgateway اضافه می کند.
    • پورت : شماره پورتی برای گوش دادن. برای مثال، دیباگر IDE خود را طوری تنظیم کنید که در این پورت گوش کند.
    • args : استدلال هایی برای فرآیند اشکال زدایی. به عنوان مثال: args --nolazy
  • config_change_poll_interval: (پیش‌فرض: 600 ثانیه) Edge Microgateway یک پیکربندی جدید را به صورت دوره‌ای بارگیری می‌کند و در صورت تغییر، بارگذاری مجدد را اجرا می‌کند. نظرسنجی هر گونه تغییر ایجاد شده در Edge (تغییر در محصولات، پروکسی های آگاه از microgateway و غیره) و همچنین تغییرات ایجاد شده در فایل پیکربندی محلی را انتخاب می کند.
  • disable_config_poll_interval: (پیش‌فرض: نادرست) برای خاموش کردن نظرسنجی تغییر خودکار روی true تنظیم کنید.
  • request_timeout : یک مهلت زمانی برای درخواست های هدف تعیین می کند. تایم اوت بر حسب ثانیه تنظیم می شود. اگر مهلت زمانی رخ دهد، Edge Microgateway با یک کد وضعیت 504 پاسخ می دهد. (نسخه 2.4.x اضافه شد)
  • keep_alive_timeout : این ویژگی به شما امکان می دهد تا زمان پایان Edge Microgateway را (در میلی ثانیه) تنظیم کنید. (پیش‌فرض: 5 ثانیه) (نسخه 3.0.6 اضافه شد)
  • headers_timeout : این ویژگی مدت زمانی را که تجزیه کننده HTTP منتظر دریافت سرصفحه های کامل HTTP است (بر حسب میلی ثانیه) محدود می کند.

    به عنوان مثال:

    edgemicro:
  keep_alive_timeout: 6000
  headers_timeout: 12000

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

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

    مثال:

    edgemicro
  enableAnalytics=false|true
  • on_target_response_abort : این ویژگی به شما امکان می دهد اگر اتصال بین کلاینت (Edge Microgateway) و سرور هدف پیش از موعد بسته شود، نحوه رفتار Edge Microgateway را کنترل کنید.
    ارزش توضیحات
    پیش فرض اگر on_target_response_abort نامشخص باشد، رفتار پیش‌فرض این است که پاسخ را بدون نشان دادن خطا کوتاه کنیم. در فایل‌های گزارش، یک پیام هشدار با targetResponse aborted و کد پاسخ 502 نشان داده می‌شود.
    appendErrorToClientResponseBody خطای سفارشی TargetResponseAborted به مشتری برگردانده می شود. در فایل‌های گزارش، یک پیام هشدار با targetResponse aborted و کد پاسخ 502 نشان داده می‌شود. علاوه بر این، خطای TargetResponseAborted با پیام Target response ended prematurely.
    abortClientRequest Edge Microgateway درخواست را لغو می کند و یک اخطار روی فایل های گزارش نوشته می شود: TargetResponseAborted با کد وضعیت درخواست 502.

مثال: 

edgemicro:
 on_target_response_abort: appendErrorToClientResponseBody | abortClientRequest

ویژگی های سرصفحه ها

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

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

ویژگی های oauth

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

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

ویژگی های خاص پلاگین

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

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

می‌توانید فیلتر کنید کدام پروکسی‌های آگاه از میکروگیت‌وی را یک نمونه 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 دانلود و پردازش می کند، از پیکربندی زیر استفاده کنید. برای فیلتر کردن محصولات دانلود شده، پارامتر query productnamefilter را به /products API فهرست شده در فایل 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 باشد. برای مثال، regex ^[Ee]dgemicro.*$ نام‌هایی مانند: "edgemicro-test-1"، "edgemicro_demo" و "Edgemicro_New_Demo" را می‌گیرد. مقدار کدگذاری شده URL، مناسب برای استفاده در پارامتر پرس و جو، این است: %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، پراکسی edgemicro_auth را در سازمان/محیطی که Edge Microgateway را پیکربندی کرده‌اید، انتخاب کنید.
  2. در شیر توسعه، سیاست JavaCallout را در ویرایشگر باز کنید.
  3. یک ویژگی سفارشی را با products.filter.attributes با لیستی از نام ویژگی‌های جدا شده با کاما اضافه کنید. فقط محصولاتی که حاوی هر یک از نام‌های ویژگی سفارشی هستند به Edge Microgateway بازگردانده می‌شوند.
  4. می‌توانید با تنظیم ویژگی سفارشی products.filter.env.enable روی false ، بررسی را غیرفعال کنید تا ببینید آیا محصول برای محیط فعلی فعال است یا خیر. (پیش فرض درست است.)
  5. (فقط Private Cloud) اگر در Edge برای Private Cloud هستید، ویژگی org.noncps را روی true تنظیم کنید تا محصولات را برای محیط های غیر CPS بکشید.

    6. به عنوان مثال:

    <?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>

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

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

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

به عنوان مثال: 

analytics:
  bufferSize: 15000
  batchSize: 1000
  flushInterval: 6000

پوشاندن داده های تحلیلی

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

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

جداسازی تماس‌های API در Edge Analytics

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

edgemicro_proxyname-health

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

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

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

در پیکربندی زیر، هر 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 در پشت فایروال شرکت

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

اضافه شده در نسخه 3.1.2.

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

اضافه شده در نسخه 3.1.2.

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

    کجا:

    • تونل : (اختیاری) وقتی درست است، Edge Microgateway از روش HTTP CONNECT برای تونل کردن درخواست‌های HTTP از طریق یک اتصال TCP استفاده می‌کند. (اگر متغیرهای محیطی، همانطور که در زیر ذکر شد، برای پیکربندی پراکسی، TLS فعال باشند، صادق است). پیش فرض: false
    • url : URL پروکسی HTTP.
    • bypass : (اختیاری) یک یا چند URL میزبان هدف جدا شده با کاما را مشخص می کند که باید پروکسی HTTP را دور بزنند. اگر این ویژگی تنظیم نشده است، از متغیر محیطی NO_PROXY استفاده کنید تا مشخص کنید کدام URL های هدف را دور بزنیم.
    • enabled : اگر true و proxy.url تنظیم شده است، از مقدار proxy.url برای پراکسی HTTP استفاده کنید. اگر true و 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 را مجددا راه اندازی کنید.

استفاده از wildcard در پروکسی های Microgateway-aware

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

مهم: 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 با CLI، به ایجاد توکن مراجعه کنید.

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

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

برای تولید JWT، Edge از اطلاعات ذخیره شده در KVM رمزگذاری شده استفاده می کند. هنگامی که شما در ابتدا Edge Microgateway را راه‌اندازی (پیکربندی) کردید، یک KVM به نام 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 های ارائه شده برای تأیید با استفاده از کلید عمومی جدید تأیید می شوند. اگر تأیید ناموفق باشد، از کلید عمومی قدیمی استفاده می‌شود، تا زمانی که JWT منقضی شود (بعد از بازه زمانی token_expiry*، پیش‌فرض 30 دقیقه). به این ترتیب، می‌توانید کلیدها را بدون ایجاد اختلال در ترافیک API، «چرخش» کنید.

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

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

  1. برای ارتقاء KVM از دستور edgemicro upgradekvm استفاده کنید. برای جزئیات در مورد اجرای این دستور، به ارتقای KVM مراجعه کنید. این مرحله را فقط یک بار باید انجام دهید.
  2. برای ارتقای پراکسی edgemicro-oauth ، از دستور edgemicro upgradeauth استفاده کنید. برای جزئیات در مورد اجرای این دستور، به ارتقای پروکسی edgemicro-auth مراجعه کنید. این مرحله را فقط یک بار باید انجام دهید.
  3. خط زیر را به فایل ~/.edgemicro/org-env-config.yaml خود اضافه کنید، جایی که باید همان سازمان و محیطی را که microgateway را برای استفاده از آن پیکربندی کرده اید، مشخص کنید: 
    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" (شناسه کلید) منحصر به فرد است. سپس 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"
    }
  ]
}

پیکربندی تاخیر "not before".

برای نسخه های 3.1.5 و قبل از آن، کلید خصوصی جدید تولید شده توسط دستور rotatekey بلافاصله اعمال شد و توکن های جدید تولید شده با کلید خصوصی جدید امضا شدند. با این حال، کلید عمومی جدید تنها هر 10 دقیقه (به طور پیش‌فرض) زمانی که پیکربندی میکروگیت‌وی به‌روزرسانی می‌شد، در دسترس نمونه‌های Edge Microgateway قرار می‌گرفت. به دلیل این تاخیر بین امضای توکن و به‌روزرسانی نمونه میکرو گیت‌وی، توکن‌هایی که با آخرین کلید امضا شده‌اند تا زمانی که همه نمونه‌ها آخرین کلید عمومی را دریافت کنند رد می‌شوند.

در مواردی که چندین نمونه microgateway وجود دارد، تاخیر کلید عمومی گاهی اوقات منجر به خطاهای متناوب در زمان اجرا با وضعیت 403 می‌شود، زیرا اعتبار سنجی رمز روی یک نمونه ارسال می‌شود، اما در نمونه دیگری تا زمانی که همه نمونه‌ها تازه‌سازی شوند، شکست می‌خورد.

با شروع در نسخه 3.1.6، یک پرچم جدید بر روی فرمان rotatekey به شما امکان می دهد یک تاخیر برای فعال شدن کلید خصوصی جدید تعیین کنید، و زمان را برای بازنگری تمام نمونه های microgateway و دریافت کلید عمومی جدید فراهم می کند. پرچم جدید --nbf است که مخفف "not before" است. این پرچم یک مقدار صحیح یعنی تعداد دقیقه تاخیر می گیرد.

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

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

توجه داشته باشید که یک تمرین خوب این است که تاخیر را بیشتر از تنظیمات پیکربندی config_change_poll_internal که به طور پیش فرض 10 دقیقه است تنظیم کنید. ویژگی‌های 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*

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

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

بررسی فایل های گزارش

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

استفاده از امنیت کلید 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 و هم برای پارامتر query استفاده می‌شود. می توانید این پیش فرض را در فایل پیکربندی تغییر دهید، همانطور که در ایجاد تغییرات پیکربندی توضیح داده شده است. به عنوان مثال، برای تغییر نام به 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 مراجعه کنید.

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

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

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

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

با استفاده از امنیت رمز OAuth2

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

نحوه دریافت رمز دسترسی

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

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

API 1: اعتبارنامه ها را به عنوان پارامترهای بدنه ارسال کنید

نام سازمان و محیط خود را در 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 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"

خروجی نمونه

API پاسخ JSON را برمی‌گرداند. توجه داشته باشید که هیچ تفاوتی بین ویژگی های token و access_token وجود ندارد. می توانید از هر کدام استفاده کنید. توجه داشته باشید که expires_in یک مقدار صحیح است که در ثانیه مشخص شده است. 
{
"token": "eyJraWQiOiIxIiwidHlwIjoi",
"access_token": "eyJraWQiOiIxIiwid",
"token_type": "bearer",
"expires_in": 1799
}

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

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

  1. با /token API یک نشانه دسترسی و بازخوانی دریافت کنید. توجه داشته باشید که نوع کمک هزینه 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 یک نشانه دسترسی و یک نشانه تازه‌سازی را برمی‌گرداند. پاسخ شبیه به این به نظر می رسد. توجه داشته باشید که 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، از نشانه 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.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
  • سهمیه
  • تجزیه و تحلیل

از طرف دیگر، پلاگین های سفارشی و دستگیری اسپیک به طور معمول کار می کنند، زیرا نیازی به اتصال به 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. متغیر محیط زیر را با مقدار "1" صادر کنید: 
    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 نام "org" است که در نام پرونده پیکربندی استفاده کرده اید.
    • $ENV نام "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 /
  5. پیکربندی را آزمایش کنید. 
    curl http://localhost:8000/echo  { "error" : "missing_authorization" }

    از آنجا که افزونه extauth در پرونده foo-bar-config.yaml قرار دارد ، شما یک خطای "mission_authorization" دریافت می کنید. این افزونه JWT را تأیید می کند که باید در عنوان مجوز تماس API وجود داشته باشد. در بخش بعدی ، شما یک JWT به دست می آورید که به تماس های API اجازه می دهد بدون خطا از بین برود.

مثال: به دست آوردن نشانه مجوز

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

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

  1. شما باید یک تنظیم استاندارد و پیکربندی Microgateway Edge را انجام دهید تا پروکسی edgemicro-auth به سازمان/محیط خود در Edge Edge مستقر کنید. اگر قبلاً این مرحله را انجام دادید ، نیازی به تکرار آن ندارید.
  2. اگر Microgateway Edge را به Apigee Cloud مستقر کرده اید ، باید به اینترنت وصل شوید تا بتوانید JWT را از این نقطه پایانی بدست آورید.
  3. Microgateway Edge Stop:
    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. 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 یا API می توانید JWT را برای Microgateway Edge تولید کنید. به عنوان مثال:

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

کجا:

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

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

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

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

برای آزمایش پیکربندی ، API را با نشانه اضافه شده در عنوان مجوز به شرح زیر فراخوانی کنید:

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

مثال:

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

خروجی مثال: 

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

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

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

از مورد و مثال استفاده کنید

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

edgemicro به عنوان sidecar

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

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

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

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

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

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

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

  5. در Apigee Edge ، یک برنامه توسعه دهنده ایجاد کنید. شما باید محصول API را که تازه ایجاد کرده اید به برنامه اضافه کنید. برای کمک ، به ثبت نام یک برنامه در UI Edge Management مراجعه کنید.
  6. در دستگاهی که Microgateway Edge نصب شده است ، متغیر محیط زیر را با مقدار "1" صادر کنید. 
    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 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 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":""
}

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

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

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

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

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

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

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

Synchronizer یک نمونه خاص پیکربندی شده از Microgateway Edge است. تنها هدف آن نظرسنجی Apigee Edge (زمان بندی قابل تنظیم است) ، بازیابی داده های پیکربندی و نوشتن آن در یک پایگاه داده محلی Redis است. نمونه هماهنگ کننده خود نمی تواند ترافیک پروکسی API را پردازش کند. سایر موارد Microgateway Edge که روی گره های مختلف اجرا می شود ، می تواند برای بازیابی داده های پیکربندی از پایگاه داده Redis به جای Apigee Edge تنظیم شود. از آنجا که تمام نمونه های 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
گزینه توضیحات
redisHost میزبان جایی که نمونه Redis شما در حال اجرا است. پیش فرض: 127.0.0.1
redisPort بندر نمونه Redis. پیش فرض: 6379
redisDb redis db برای استفاده. پیش فرض: 0
redisPassword رمز ورود پایگاه داده شما

در آخر ، پرونده پیکربندی را ذخیره کرده و نمونه Microgateway Edge را شروع کنید. شروع به نظرسنجی Edge Edge و ذخیره داده های پیکربندی بارگیری شده در پایگاه داده Redis خواهد کرد.

پیکربندی نمونه های Microgateway به طور منظم

با اجرای همگام سازی ، می توانید گره های Microgateway Edge اضافی را پیکربندی کنید تا نمونه های Microgateway منظم را انجام دهید که ترافیک پروکسی API را پردازش می کنند. با این حال ، شما این موارد را پیکربندی می کنید تا داده های پیکربندی آنها را از پایگاه داده Redis به جای Apigee Edge بدست آورید.

پیکربندی زیر را به هر فایل org-env /config.yaml Microgateway Edge Microgateway اضافه کنید. توجه داشته باشید که خاصیت synchronizerMode روی 0 تنظیم شده است. این ویژگی نمونه ای را به عنوان نمونه ای از Microgateway Edge نرمال که ترافیک پروکسی API را پردازش می کند ، کار می کند و نمونه آن داده های پیکربندی خود را از پایگاه داده 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

ویژگی های پیکربندی

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

صفت ارزش ها توضیحات
edge_config.synchronizerMode 0 یا 1

اگر Microgateway Edge 0 (پیش فرض) در حالت استاندارد خود عمل کند.

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

edge_config.redisBasedConfigCache درست یا نادرست در صورت صحت ، نمونه Edge Microgateway داده های پیکربندی خود را از پایگاه داده Redis به جای آن از Apigee Edge واکشی می کند. پایگاه داده Redis باید همان موردی باشد که همگام ساز برای نوشتن آن پیکربندی شده است. اگر پایگاه داده redis در دسترس نباشد یا اگر پایگاه داده خالی باشد ، Microgateway برای پیکربندی خود به دنبال یک پرونده موجود cache-config.yaml است.

اگر FALSE (پیش فرض) ، نمونه Microgateway Edge داده های پیکربندی را از Apigee Edge به طور معمول واگذار می کند.

edgemicro.config_change_poll_interval فاصله زمانی ، در ثانیه فاصله رای گیری را برای همگام سازی برای کشیدن داده ها از لبه Apigee مشخص می کند.

پیکربندی URL های حذف شده برای افزونه ها

می توانید Microgateway را پیکربندی کنید تا از پردازش افزونه ها برای URL های مشخص استفاده کنید. می توانید این URL های "مستثنی" را در سطح جهان (برای همه افزونه ها) یا برای افزونه های خاص پیکربندی کنید.

به عنوان مثال:

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

در این مثال ، افزونه ها تماس های پروکسی API ورودی را با مسیرها /hello یا /proxy_one پردازش نمی کنند. علاوه بر این ، افزونه json2xml برای API با /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>