Edge माइक्रोगेटवे के लिए कार्रवाई और कॉन्फ़िगरेशन रेफ़रंस

Apigee Edge के दस्तावेज़ देखे जा रहे हैं.
Apigee X के दस्तावेज़.
जानकारी पर जाएं

Edge Microgateway v. 3.3.x

इस विषय में, Edge Microgateway को मैनेज और कॉन्फ़िगर करने के तरीके के बारे में बताया गया है.

अगर आपके पास इंटरनेट कनेक्शन है, तो Edge Microgateway को अपग्रेड करना

इस सेक्शन में Edge Microgateway की मौजूदा इंस्टॉलेशन को अपग्रेड करने का तरीका बताया गया है. अगर इंटरनेट कनेक्शन के बिना काम किया जा रहा है, तो क्या इंटरनेट कनेक्शन के बिना Edge Microgateway को इंस्टॉल किया जा सकता है? देखें.

Apigee का सुझाव है कि आप प्रोडक्शन एनवायरमेंट को अपग्रेड करने से पहले, नए वर्शन के साथ अपने मौजूदा कॉन्फ़िगरेशन की जांच करें.

  1. Edge Microgateway के नए वर्शन में अपग्रेड करने के लिए, नीचे दिए गए npm कमांड का इस्तेमाल करें:
    npm upgrade edgemicro -g

    Edge Microgateway का कोई खास वर्शन इंस्टॉल करने के लिए, आपको इंस्टॉल कमांड में वर्शन नंबर बताना होगा. उदाहरण के लिए, वर्शन 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. आखिर में, agemicro-auth प्रॉक्सी के सबसे नए वर्शन में अपग्रेड करें:
    edgemicro upgradeauth -o $ORG -e $ENV -u $USERNAME

कॉन्फ़िगरेशन में बदलाव करना

आपको जिन कॉन्फ़िगरेशन फ़ाइलों के बारे में जानना ज़रूरी है उनमें ये शामिल हैं:

  • सिस्टम की डिफ़ॉल्ट कॉन्फ़िगरेशन फ़ाइल
  • नए शुरू किए गए Edge माइक्रोगेटवे इंस्टेंस के लिए, डिफ़ॉल्ट कॉन्फ़िगरेशन फ़ाइल
  • चल रहे इंस्टेंस के लिए डाइनैमिक कॉन्फ़िगरेशन फ़ाइल

इस सेक्शन में, इन फ़ाइलों के बारे में बताया गया है. साथ ही, यह भी बताया गया है कि इन्हें बदलने के बारे में आपके लिए क्या जानना ज़रूरी है.

सिस्टम की डिफ़ॉल्ट कॉन्फ़िगरेशन फ़ाइल

Edge माइक्रोगेटवे इंस्टॉल करने पर, एक डिफ़ॉल्ट सिस्टम कॉन्फ़िगरेशन फ़ाइल यहां दिखती है:

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

जहां prefix, npm प्रीफ़िक्स डायरेक्ट्री है. अगर यह डायरेक्ट्री नहीं मिल रही है, तो देखें कि Edge Microgateway कहां इंस्टॉल है.

सिस्टम कॉन्फ़िगरेशन फ़ाइल बदलने पर, आपको Edge माइक्रोगेटवे को फिर से शुरू और कॉन्फ़िगर करना होगा. साथ ही, उसे रीस्टार्ट करना होगा:

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

नए शुरू किए गए Edge Microgateway इंस्टेंस के लिए, डिफ़ॉल्ट कॉन्फ़िगरेशन फ़ाइल

edgemicro init को चलाने पर, सिस्टम कॉन्फ़िगरेशन फ़ाइल (ऊपर बताया गया है), default.yaml को ~/.edgemicro डायरेक्ट्री में रखा जाता है.

अगर ~/.edgemicro में कॉन्फ़िगरेशन फ़ाइल को बदला जाता है, तो आपको Edge माइक्रोगेटवे को फिर से कॉन्फ़िगर करके, रीस्टार्ट करना होगा:

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

चल रहे इंस्टेंस के लिए डाइनैमिक कॉन्फ़िगरेशन फ़ाइल

edgemicro configure [params] चलाने पर, ~/.edgemicro में एक डाइनैमिक कॉन्फ़िगरेशन फ़ाइल बन जाती है. फ़ाइल को इस पैटर्न के मुताबिक नाम दिया गया है: org-env-config.yaml. इसमें org और env आपके Apigee Edge संगठन और एनवायरमेंट के नाम हैं. इस फ़ाइल का इस्तेमाल करके, कॉन्फ़िगरेशन में बदलाव किए जा सकते हैं. इसके बाद, ज़ीरो-डाउनटाइम के साथ उन्हें फिर से लोड किया जा सकता है. उदाहरण के लिए, किसी प्लगिन को जोड़ने और कॉन्फ़िगर करने पर, कॉन्फ़िगरेशन को फिर से लोड किया जा सकता है. ऐसा करने के लिए, किसी भी डाउनटाइम की ज़रूरत नहीं होती, जैसा कि यहां बताया गया है.

अगर Edge माइक्रोगेटवे चालू है, तो डाउनटाइम का विकल्प चुनें:

  1. Edge माइक्रोगेटवे कॉन्फ़िगरेशन को फिर से लोड करें:
    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 माइक्रोगेटवे को रीस्टार्ट करें:
    edgemicro start -o $ORG -e $ENV -k $KEY -s $SECRET

    जगह:

    • $ORG आपके Edge संगठन का नाम है. इसके लिए, ज़रूरी है कि आप संगठन के एडमिन हों.
    • $ENV आपके संगठन का एक एनवायरमेंट है. जैसे, "जांच" या "प्रोडक्शन".
    • $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

इन वैरिएबल को सेट करना ज़रूरी नहीं है. अगर इन्हें सेट किया जाता है, तो एज माइक्रोगेटवे को कॉन्फ़िगर और शुरू करने के लिए, आपको कमांड-लाइन इंटरफ़ेस (सीएलआई) का इस्तेमाल करते समय इनकी वैल्यू तय करने की ज़रूरत नहीं है.

Edge Microgateway सर्वर पर एसएसएल कॉन्फ़िगर करना

Apigee Edge Microgateway में TLS को कॉन्फ़िगर करने के बारे में जानने के लिए, ये वीडियो देखें:

वीडियो ब्यौरा
एकतरफ़ा नॉर्थबाउंड TLS कॉन्फ़िगर करना Apigee Edge Microgateway में TLS को कॉन्फ़िगर करने के बारे में जानें. इस वीडियो में TLS की खास जानकारी और इसकी अहमियत के बारे में बताया गया है. साथ ही, Edge Microgateway में TLS की जानकारी दी गई है. साथ ही, नॉर्थबाउंड वन-वे TLS को कॉन्फ़िगर करने का तरीका बताया गया है.
2-वे नॉर्थबाउंड TLS कॉन्फ़िगर करना Apigee Edge Microgateway में TLS को कॉन्फ़िगर करने के बारे में यह दूसरा वीडियो है. इस वीडियो में, नॉर्थबाउंड 2-वे TLS को कॉन्फ़िगर करने का तरीका बताया गया है.
1-तरफ़ा और 2-वे साउथबाउंड TLS कॉन्फ़िगर करना Apigee Edge Microgateway में TLS को कॉन्फ़िगर करने के बारे में इस तीसरे वीडियो में, दक्षिण की ओर एक-तरफ़ा और 2-वे TLS को कॉन्फ़िगर करने का तरीका बताया गया है.

एसएसएल का इस्तेमाल करने के लिए, माइक्रोगेटवे सर्वर को कॉन्फ़िगर किया जा सकता है. उदाहरण के लिए, एसएसएल को कॉन्फ़िगर करने के बाद, "https" प्रोटोकॉल वाले Edge माइक्रोगेटवे से एपीआई को कॉल किया जा सकता है, जैसे कि:

https://localhost:8000/myapi

माइक्रोगेटवे सर्वर पर SSL कॉन्फ़िगर करने के लिए, इन चरणों का पालन करें:

  1. openssl का इस्तेमाल करके या अपनी पसंद के किसी भी तरीके से, एसएसएल सर्टिफ़िकेट और कुंजी जनरेट करें या पाएं.
  2. Edge Microgateway कॉन्फ़िगरेशन फ़ाइल में edgemicro:ssl एट्रिब्यूट जोड़ें. विकल्पों की पूरी सूची के लिए, नीचे दी गई टेबल देखें. उदाहरण के लिए:
    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 माइक्रोगेटवे को रीस्टार्ट करें. आपने जिस कॉन्फ़िगरेशन फ़ाइल में बदलाव किया है उसके हिसाब से कॉन्फ़िगरेशन फ़ाइल में बदलाव करना लेख में बताया गया तरीका अपनाएं: डिफ़ॉल्ट फ़ाइल या रनटाइम कॉन्फ़िगरेशन फ़ाइल.

यहां कॉन्फ़िगरेशन फ़ाइल के edgemicro सेक्शन का उदाहरण दिया गया है, जिसमें एसएसएल कॉन्फ़िगर की गई है:

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 इस्तेमाल करने के लिए एसएसएल वाला तरीका. उदाहरण के लिए, एसएसएल को वर्शन 3 पर लागू करने के लिए, SSLv3_method का इस्तेमाल करें.
servername SNI (सर्वर नेम इंंडिकेशन) TLS एक्सटेंशन के लिए, सर्वर का नाम.
requestCert 2-वे एसएसएल के लिए सही; 1-वे एसएसएल के लिए गलत

क्लाइंट एसएसएल/टीएलएस के विकल्पों का इस्तेमाल करना

टारगेट एंडपॉइंट से कनेक्ट करते समय, Edge Microgateway को TLS या एसएसएल क्लाइंट के तौर पर कॉन्फ़िगर किया जा सकता है. माइक्रोगेटवे कॉन्फ़िगरेशन फ़ाइल में, एसएसएल/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/एसएसएल सेटिंग लागू करनी है, आपको कॉन्फ़िगरेशन में पहले होस्ट को "खाली" के तौर पर बताना होगा. इससे यूनिवर्सल अनुरोधों को चालू किया जाता है. इसके बाद, किसी भी क्रम में खास होस्ट तय करें. इस उदाहरण में, सेटिंग कई खास होस्ट पर लागू की गई हैं:

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 इस्तेमाल करने के लिए एसएसएल वाला तरीका. उदाहरण के लिए, एसएसएल को वर्शन 3 पर लागू करने के लिए, SSLv3_method का इस्तेमाल करें.
servername SNI (सर्वर नेम इंंडिकेशन) TLS एक्सटेंशन के लिए, सर्वर का नाम.

Edgeमाइक्रो-auth प्रॉक्सी को पसंद के मुताबिक बनाना

डिफ़ॉल्ट रूप से, Edge Microgateway, OAuth2 की पुष्टि करने के लिए Apigee Edge पर डिप्लॉय की गई प्रॉक्सी का इस्तेमाल करता है. यह प्रॉक्सी तब लागू की जाती है, जब शुरुआत में edgemicro configure का इस्तेमाल किया जाता है. JSON Web Token (JWT) में कस्टम दावों के लिए सहायता जोड़ने, टोकन की समयसीमा खत्म होने की तारीख कॉन्फ़िगर करने, और रीफ़्रेश टोकन जनरेट करने के लिए, इस प्रॉक्सी का डिफ़ॉल्ट कॉन्फ़िगरेशन बदला जा सकता है. ज़्यादा जानकारी के लिए, GitHub में edgemicro-auth पेज देखें.

पुष्टि करने वाली कस्टम सेवा का इस्तेमाल करना

डिफ़ॉल्ट रूप से, Edge Microgateway, OAuth2 की पुष्टि करने के लिए Apigee Edge पर डिप्लॉय की गई प्रॉक्सी का इस्तेमाल करता है. यह प्रॉक्सी तब लागू की जाती है, जब शुरुआत में 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

किसी दूसरी लॉग फ़ाइल डायरेक्ट्री के बारे में बताने के लिए, direct वैल्यू को बदलें.

कंसोल पर लॉग भेजें

आपके पास लॉग फ़ाइल को कॉन्फ़िगर करने का विकल्प है, ताकि लॉग की जानकारी, लॉग फ़ाइल के बजाय स्टैंडर्ड आउटपुट पेज पर भेजी जाए. to_console फ़्लैग को 'सही है' पर इस तरह सेट करें:

edgemicro:
  logging:
    to_console: true

इस सेटिंग को चुनने पर, लॉग स्टैंडर्ड आउट में भेजे जाएंगे. फ़िलहाल, stdout और लॉग फ़ाइल, दोनों पर लॉग नहीं भेजे जा सकते.

लॉगिन लेवल सेट करने का तरीका

आपको edgemicro कॉन्फ़िगरेशन में इस्तेमाल करने के लिए, लॉग लेवल तय करना होता है. लॉग लेवल की पूरी सूची और उनके ब्यौरे के लिए, agemicro एट्रिब्यूट देखें.

उदाहरण के लिए, यह कॉन्फ़िगरेशन लॉग इन लेवल को 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) इंटरवल, सेकंड में, जब एपीआई लॉग फ़ाइल में आंकड़े का रिकॉर्ड लिखा जाता है.
  • 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 पर सेट होता है, तो लॉग फ़ाइल बनाई जाती है. साथ ही, फ़ाइल को 0755 पर सेट करने की अनुमति दी जाती है. अगर false या एट्रिब्यूट नहीं दिया जाता है, तो अनुमति डिफ़ॉल्ट रूप से 0600 होती है.

वर्शन 3.2.3 में जोड़ा गया.

उदाहरण के लिए:

edgemicro:
 logging:
   disableStrictLogFile: true

लॉग फ़ाइल के रखरखाव के अच्छे तरीके

समय के साथ लॉग फ़ाइल का डेटा इकट्ठा होने पर, Apigee का सुझाव है कि आप इन तरीकों का इस्तेमाल करें:

  • लॉग फ़ाइलें बहुत बड़ी हो सकती हैं. इसलिए, पक्का करें कि लॉग फ़ाइल डायरेक्ट्री में ज़रूरत के मुताबिक जगह हो. लॉग फ़ाइलें कहां सेव होती हैं और डिफ़ॉल्ट लॉग फ़ाइल डायरेक्ट्री को बदलने का तरीका जानने के लिए, नीचे दिए गए सेक्शन देखें.
  • हफ़्ते में कम से कम एक बार, लॉग फ़ाइलों को मिटाएं या उन्हें किसी अलग संग्रह डायरेक्ट्री में ले जाएं.
  • अगर आपकी नीति के लॉग मिटाने हैं, तो सीएलआई कमांड edgemicro log -c का इस्तेमाल करके, पुराने लॉग को हटाएं (साफ़ करें).

लॉग फ़ाइल का नाम रखने के तरीके

हर Edge Microgateway इंस्टेंस, .log एक्सटेंशन वाली एक लॉग फ़ाइल बनाता है. लॉग फ़ाइलों का नाम इस तरह से रखा जाता है:

edgemicro-HOST_NAME-INSTANCE_ID-api.log

उदाहरण के लिए:

edgemicro-mymachine-local-MTQzNTgNDMxODAyMQ-api.log

लॉग फ़ाइल के कॉन्टेंट के बारे में जानकारी

वर्शन 2.3.3 में जोड़ा गया

डेटा को लॉग करने वाली सेवा, डिफ़ॉल्ट रूप से डाउनलोड की गई प्रॉक्सी, प्रॉडक्ट, और JSON Web Token (JWT) के JSON का इस्तेमाल नहीं करती. अगर आपको इन ऑब्जेक्ट को कंसोल पर आउटपुट करना है, तो Edge माइक्रोगेटवे शुरू करते समय, कमांड-लाइन फ़्लैग DEBUG=* को सेट करें. उदाहरण के लिए:

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

"एपीआई" लॉग फ़ाइल का कॉन्टेंट

"एपीआई" लॉग फ़ाइल में, Edge माइक्रोगेटवे से मिलने वाले अनुरोधों और रिस्पॉन्स के फ़्लो के बारे में पूरी जानकारी होती है. "api" लॉग फ़ाइलों के नाम इस तरह होते हैं:

edgemicro-mymachine-local-MTQzNjIxOTk0NzY0Nw-api.log

Edge माइक्रोगेटवे को किए गए हर अनुरोध के लिए, "एपीआई" लॉग फ़ाइल में चार इवेंट कैप्चर किए जाते हैं:

  • क्लाइंट से मिलने वाला अनुरोध
  • टारगेट खाते के लिए किया गया अनुरोध
  • टारगेट से मिलने वाला जवाब
  • क्लाइंट को भेजा जाने वाला जवाब

इनमें से हर एक अलग एंट्री को शॉर्टहैंड नोटेशन में दिखाया जाता है, ताकि लॉग फ़ाइलों को ज़्यादा छोटा बनाने में मदद मिल सके. यहां चार इवेंट में से हर एक को दिखाने वाली चार सैंपल एंट्री दी गई हैं. लॉग फ़ाइल में, वे इस तरह दिखते हैं. लाइन नंबर सिर्फ़ दस्तावेज़ में रेफ़रंस के लिए होते हैं, वे लॉग फ़ाइल में नहीं दिखते.

(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 - यूनिक्स तारीख का स्टैंप
  • info - लॉगिंग लेवल. यह वैल्यू, लेन-देन के कॉन्टेक्स्ट और edgemicro कॉन्फ़िगरेशन में सेट किए गए लॉगिंग लेवल पर निर्भर करती है. लॉगिंग लेवल सेट करने का तरीका देखें. आंकड़ों के रिकॉर्ड के लिए, लेवल stats पर सेट है. आंकड़ों के रिकॉर्ड को stats_log_interval कॉन्फ़िगरेशन के साथ, तय किए गए समय के हिसाब से रिपोर्ट किया जाता है. लॉग इंटरवल बदलने का तरीका भी देखें.
  • req - इवेंट की पहचान करता है. इस मामले में, क्लाइंट का अनुरोध करें.
  • m - अनुरोध में इस्तेमाल की गई एचटीटीपी क्रिया.
  • u - बेसपाथ के बाद आने वाले यूआरएल का हिस्सा.
  • h - वह होस्ट और पोर्ट नंबर जहां Edge Microgateway सुन रहा है.
  • r - वह रिमोट होस्ट और पोर्ट जहां से क्लाइंट का अनुरोध शुरू किया गया था.
  • i - अनुरोध का आईडी. इवेंट की चारों एंट्री का यह आईडी शेयर होगा. हर अनुरोध को एक यूनीक अनुरोध आईडी असाइन किया जाता है. लॉग रिकॉर्ड को अनुरोध आईडी के हिसाब से जोड़ने से, टारगेट होने में लगने वाले समय के बारे में अहम जानकारी मिल सकती है.
  • d - Edge माइक्रोगेटवे से अनुरोध मिलने के बाद से, मिलीसेकंड में कुल समय. ऊपर दिए गए उदाहरण में, अनुरोध 0 के लिए टारगेट का जवाब सात मिलीसेकंड (लाइन 3) के बाद मिला और क्लाइंट को जवाब चार मिलीसेकंड (लाइन 4) के बाद भेजा गया. दूसरे शब्दों में, अनुरोध के लिए इंतज़ार का कुल समय 11 मिलीसेकंड था, जिसमें से 7 मिलीसेकंड टारगेट ने लिए और 4 मिलीसेकंड, खुद एज माइक्रोगेटवे ने लिए थे.

2. टारगेट किए जाने वाले आउटगोइंग अनुरोध का सैंपल:

1436403888665 info treq m=GET, u=/, h=127.0.0.1:8080, i=0
  • 1436403888651 - यूनिक्स तारीख का स्टैंप
  • info - लॉगिंग लेवल. यह वैल्यू, लेन-देन के कॉन्टेक्स्ट और edgemicro कॉन्फ़िगरेशन में सेट किए गए लॉगिंग लेवल पर निर्भर करती है. लॉगिंग लेवल सेट करने का तरीका देखें. आंकड़ों के रिकॉर्ड के लिए, लेवल stats पर सेट है. आंकड़ों के रिकॉर्ड को stats_log_interval कॉन्फ़िगरेशन के साथ, तय किए गए समय के हिसाब से रिपोर्ट किया जाता है. लॉग इंटरवल बदलने का तरीका भी देखें.
  • treq - इवेंट की पहचान करता है. इस मामले में, टारगेट अनुरोध.
  • m - टारगेट अनुरोध में इस्तेमाल की गई एचटीटीपी क्रिया.
  • u - बेसपाथ के बाद आने वाले यूआरएल का हिस्सा.
  • h - बैकएंड टारगेट का होस्ट और पोर्ट नंबर.
  • i - लॉग एंट्री का आईडी. इवेंट की चारों एंट्री, इस आईडी के साथ शेयर की जाएंगी.

3. टारगेट से मिलने वाले जवाब का सैंपल

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

1436403888651 - यूनिक्स तारीख का स्टैंप

  • info - लॉगिंग लेवल. यह वैल्यू, लेन-देन के कॉन्टेक्स्ट और edgemicro कॉन्फ़िगरेशन में सेट किए गए लॉगिंग लेवल पर निर्भर करती है. लॉगिंग लेवल सेट करने का तरीका देखें. आंकड़ों के रिकॉर्ड के लिए, लेवल stats पर सेट है. आंकड़ों के रिकॉर्ड को stats_log_interval कॉन्फ़िगरेशन के साथ, तय किए गए समय के हिसाब से रिपोर्ट किया जाता है. लॉग इंटरवल बदलने का तरीका भी देखें.
  • tres - इवेंट की पहचान करता है. इस मामले में, टारगेट रिस्पॉन्स.
  • s - एचटीटीपी रिस्पॉन्स की स्थिति.
  • d - मिलीसेकंड में अवधि. टारगेट के हिसाब से एपीआई कॉल में लगने वाला समय.
  • i - लॉग एंट्री का आईडी. इवेंट की चारों एंट्री, इस आईडी के साथ शेयर की जाएंगी.

4. क्लाइंट को किए जाने वाले आउटगोइंग जवाब का सैंपल

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

1436403888651 - यूनिक्स तारीख का स्टैंप

  • info - लॉगिंग लेवल. यह वैल्यू, लेन-देन के कॉन्टेक्स्ट और edgemicro कॉन्फ़िगरेशन में सेट किए गए लॉगिंग लेवल पर निर्भर करती है. लॉगिंग लेवल सेट करने का तरीका देखें. आंकड़ों के रिकॉर्ड के लिए, लेवल stats पर सेट है. आंकड़ों के रिकॉर्ड को stats_log_interval कॉन्फ़िगरेशन के साथ, तय किए गए समय के हिसाब से रिपोर्ट किया जाता है. लॉग इंटरवल बदलने का तरीका भी देखें.
  • res - इवेंट की पहचान करता है. इस मामले में, क्लाइंट को जवाब दिया जाना चाहिए.
  • s - एचटीटीपी रिस्पॉन्स की स्थिति.
  • d - मिलीसेकंड में अवधि. यह एपीआई कॉल में लगने वाला कुल समय होता है. इसमें टारगेट एपीआई और एज माइक्रोगेटवे को लगने वाला समय भी शामिल होता है.
  • i - लॉग एंट्री का आईडी. इवेंट की चारों एंट्री, इस आईडी के साथ शेयर की जाएंगी.

लॉग फ़ाइल शेड्यूल करें

लॉग फ़ाइलें, rotate_interval कॉन्फ़िगरेशन एट्रिब्यूट में दिए गए इंटरवल पर घुमाती हैं. रोटेशन इंटरवल की समयसीमा खत्म होने तक उसी लॉग फ़ाइल में एंट्री जोड़ी जाती रहेंगी. हालांकि, Edge Microgateway को हर बार रीस्टार्ट करने पर उसे एक नया यूआईडी मिलता है और वह इस यूआईडी के साथ, लॉग फ़ाइलों का एक नया सेट बनाता है. लॉग फ़ाइल के रखरखाव के अच्छे तरीके भी देखें.

गड़बड़ी के मैसेज

कुछ लॉग एंट्री में गड़बड़ी के मैसेज होंगे. गड़बड़ियां कहां और क्यों होती हैं, इसका पता लगाने में मदद के लिए, Edge Microgateway गड़बड़ी का रेफ़रंस देखें.

एज माइक्रोगेटवे कॉन्फ़िगरेशन का रेफ़रंस

कॉन्फ़िगरेशन फ़ाइल की जगह

इस सेक्शन में बताए गए कॉन्फ़िगरेशन एट्रिब्यूट, Edge Microgateway कॉन्फ़िगरेशन फ़ाइल में होते हैं. कॉन्फ़िगरेशन में बदलाव करना भी देखें.

Edge_config एट्रिब्यूट

इन सेटिंग का इस्तेमाल, Edge Microgateway इंस्टेंस और Apigee Edge के बीच इंटरैक्शन को कॉन्फ़िगर करने के लिए किया जाता है.

  • bootstrap: (डिफ़ॉल्ट: कोई नहीं) ऐसा यूआरएल जो Apigee Edge पर चल रही Edge Microgateway की खास सेवा पर ले जाता है. Edge Microgateway इस सेवा का इस्तेमाल, Apigee Edge से संपर्क करने के लिए करता है. सार्वजनिक/निजी कुंजी के जोड़े को जनरेट करने के लिए, यह निर्देश दिए जाने पर यह यूआरएल दिखता है: edgemicro genkeys. ज़्यादा जानकारी के लिए, Edge माइक्रोगेटवे को सेट अप और कॉन्फ़िगर करना लेख पढ़ें.
  • jwt_public_key: (डिफ़ॉल्ट: कोई नहीं) ऐसा यूआरएल जो Apigee Edge पर डिप्लॉय किए गए एज माइक्रोगेटवे प्रॉक्सी को पॉइंट करता है. यह प्रॉक्सी, क्लाइंट को साइन किए हुए ऐक्सेस टोकन जारी करने के लिए, पुष्टि करने वाले एंडपॉइंट के तौर पर काम करता है. जब आप प्रॉक्सी को डिप्लॉय करने के लिए यह निर्देश एक्ज़ीक्यूट करते हैं, तो यह यूआरएल दिखता है: agemicro कॉन्फ़िगरेशन. ज़्यादा जानकारी के लिए, Edge माइक्रोगेटवे को सेट अप और कॉन्फ़िगर करना लेख पढ़ें.
  • quotaUri: अगर संगठन में डिप्लॉय किए गए edgemicro-auth प्रॉक्सी की मदद से कोटे मैनेज करने हैं, तो इस कॉन्फ़िगरेशन प्रॉपर्टी को सेट करें. अगर यह प्रॉपर्टी सेट नहीं है, तो कोटा एंडपॉइंट, अंदरूनी Edge माइक्रोगेटवे एंडपॉइंट पर डिफ़ॉल्ट रूप से सेट होता है.
    edge_config:
      quotaUri: https://your_org-your_env.apigee.net/edgemicro-auth
    

एजमाइक्रो एट्रिब्यूट

ये सेटिंग, Edge Microgateway प्रोसेस को कॉन्फ़िगर करती हैं.

  • पोर्ट: (डिफ़ॉल्ट: 8000) वह पोर्ट नंबर जिस पर Edge Microgateway प्रोसेस सुनती है.
  • max_connections: (डिफ़ॉल्ट: -1) यह बताता है कि Edge माइक्रोगेटवे पर एक साथ ज़्यादा से ज़्यादा कितने कनेक्शन मिल सकते हैं. अगर इस संख्या से ज़्यादा हो जाती है, तो यह स्टेटस दिखता है:

    res.statusCode = 429; // Too many requests
  • max_connections_hard: (डिफ़ॉल्ट: -1) कनेक्शन बंद करने से पहले, Edge माइक्रोगेटवे को एक साथ मिलने वाले अनुरोधों की ज़्यादा से ज़्यादा संख्या. इस सेटिंग का मकसद, सेवा से इनकार किए जाने वाले हमलों को रोकना है. आम तौर पर, इसे max_कनेक्शन से बड़ी संख्या पर सेट करें.
  • लॉगिंग:
    • लेवल: (डिफ़ॉल्ट: गड़बड़ी)
      • info - (सुझाया गया) एज माइक्रोगेटवे इंस्टेंस से आने वाले सभी अनुरोधों और रिस्पॉन्स को लॉग करता है.
      • warn - सिर्फ़ चेतावनी मैसेज को लॉग करता है.
      • error - सिर्फ़ गड़बड़ी के मैसेज को लॉग करता है.
      • डीबग - जानकारी, चेतावनी, और गड़बड़ी के मैसेज के साथ डीबग मैसेज को लॉग करता है.
      • trace - इससे गड़बड़ियों को ट्रेस करने के लिए जानकारी, चेतावनी, और गड़बड़ी के मैसेज का लॉग रखा जाता है.
      • none - लॉग फ़ाइल न बनाएं.
    • direct: (डिफ़ॉल्ट: /var/tmp) वह डायरेक्ट्री जहां लॉग फ़ाइलें स्टोर की जाती हैं.
    • stats_log_interval: (डिफ़ॉल्ट: 60) इंटरवल, सेकंड में, जब आंकड़े रिकॉर्ड को एपीआई लॉग फ़ाइल में लिखा जाता है.
    • rotate_interval: (डिफ़ॉल्ट: 24) इंटरवल, घंटों में, जब लॉग फ़ाइलों को घुमाया जाता है.
  • डायर: ./gateway डायरेक्ट्री से ./Plugins डायरेक्ट्री तक ले जाने वाला रिलेटिव पाथ या कोई ऐब्सलूट पाथ.
  • क्रम: आपके Edge Microgateway इंस्टेंस में जोड़ने के लिए प्लगिन मॉड्यूल की सूची. मॉड्यूल यहां बताए गए क्रम में काम करेंगे.
  • डीबग: एज माइक्रोगेटवे प्रोसेस में रिमोट डीबगिंग जोड़ता है.
    • पोर्ट: वह पोर्ट नंबर जिसे सुनना है. उदाहरण के लिए, अपना IDE डीबगर इस पोर्ट पर सुनने के लिए सेट करें.
    • args: डीबग प्रोसेस के लिए तर्क. उदाहरण के लिए: args --nolazy
  • config_change_poll_interval: (डिफ़ॉल्ट: 600 सेकंड) Edge Microgateway समय-समय पर नया कॉन्फ़िगरेशन लोड करता है और अगर कुछ बदलता है, तो फिर से लोड करता है. पोल में, Edge में किए गए बदलाव (प्रॉडक्ट, माइक्रोगेटवे-अवेयर प्रॉक्सी वगैरह) में किए गए बदलाव शामिल होते हैं. साथ ही, लोकल कॉन्फ़िगरेशन फ़ाइल में किए गए बदलाव भी देखे जाते हैं.
  • disable_config_poll_interval: (डिफ़ॉल्ट: गलत) अपने-आप होने वाले बदलाव वाले पोल को बंद करने के लिए, true पर सेट करें.
  • request_timeout: टारगेट अनुरोधों के लिए टाइम आउट सेट करता है. टाइम आउट सेकंड में सेट किया जाता है. टाइम आउट होने पर, Edge Microgateway 504 स्टेटस कोड दिखाता है. (v2.4.x को जोड़ा गया)
  • keep_alive_timeout: इस प्रॉपर्टी की मदद से, एज माइक्रोगेटवे का टाइम आउट (मिलीसेकंड में) सेट किया जा सकता है. (डिफ़ॉल्ट: 5 सेकंड) (v3.0.6 जोड़ा गया)
  • headers_timeout: इस एट्रिब्यूट की मदद से, एचटीटीपी पार्सर को पूरा एचटीटीपी हेडर मिलने का इंतज़ार करना होगा. यह समयसीमा मिलीसेकंड में होती है.

    उदाहरण के लिए:

    edgemicro:
      keep_alive_timeout: 6000
      headers_timeout: 12000

    अंदरूनी तौर पर, पैरामीटर, अनुरोधों पर Node.js Server.headersTimeout एट्रिब्यूट को सेट करता है. (डिफ़ॉल्ट: edgemicro.keep_alive_timeout के साथ सेट किए गए समय से पांच सेकंड ज़्यादा. यह डिफ़ॉल्ट सेटिंग, लोड बैलेंसर या प्रॉक्सी को गलती से कनेक्शन छोड़ने से रोकती है.) (v3.1.1 जोड़ा गया)

  • noRuleMatchAction: (स्ट्रिंग) अगर accesscontrol प्लगिन में बताए गए मिलते-जुलते वीडियो के नियम का समाधान नहीं होता है (मेल नहीं खाता है), तो की जाने वाली कार्रवाई (ऐक्सेस देने की अनुमति देना या अस्वीकार करना). मान्य मान: ALLOW या DENY डिफ़ॉल्ट: ALLOW (जोड़ा गया: v3.1.7)
  • enableAnalytics: (डिफ़ॉल्ट: true) Analytics प्लगिन को लोड होने से रोकने के लिए, एट्रिब्यूट को false पर सेट करें. इस मामले में, Apigee Edge के आंकड़ों को कॉल नहीं किया जाएगा. अगर इस एट्रिब्यूट की वैल्यू को true पर सेट किया जाता है या यह एट्रिब्यूट नहीं दिया जाता है, तो Analytics प्लगिन सामान्य तरीके से काम करेगा. ज़्यादा जानकारी के लिए, agemicro के एट्रिब्यूट देखें. (v3.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 ने अनुरोध रद्द कर दिया है और लॉग फ़ाइलों पर चेतावनी लिखी गई: 502 अनुरोध के स्टेटस कोड के साथ TargetResponseAborted.

उदाहरण:

edgemicro:
 on_target_response_abort: appendErrorToClientResponseBody | abortClientRequest

हेडर एट्रिब्यूट

ये सेटिंग कॉन्फ़िगर करती हैं कि कुछ एचटीटीपी हेडर का इस्तेमाल कैसे किया जाता है.

  • x-forwarded-for: (डिफ़ॉल्ट: सही) x-forwarded-for हेडर को टारगेट में भेजे जाने से रोकने के लिए, इस वैल्यू को 'गलत' पर सेट करें. ध्यान दें कि अगर अनुरोध में x-forwarded-for हेडर है, तो इसकी वैल्यू Edge Analytics में Client-ip वैल्यू पर सेट होगी.
  • x-forwarded-host: (डिफ़ॉल्ट: सही) x-forwarded-host हेडर को टारगेट में भेजे जाने से रोकने के लिए, 'गलत' पर सेट करें.
  • x-request-id: (डिफ़ॉल्ट: सही) x-request-id हेडर को टारगेट में भेजे जाने से रोकने के लिए, 'गलत' पर सेट करें.
  • x-response-time: (डिफ़ॉल्ट: सही) टारगेट को x-response-time हेडर भेजने से रोकने के लिए, 'गलत' पर सेट करें.
  • के ज़रिए: (डिफ़ॉल्ट: सही) हेडर के ज़रिए टारगेट को भेजे जाने से रोकने के लिए, 'गलत' पर सेट करें.

oauth एट्रिब्यूट

ये सेटिंग कॉन्फ़िगर करती हैं कि Edge Microgateway से क्लाइंट की पुष्टि कैसे करनी है.

  • allowNoAuthorization: (डिफ़ॉल्ट: गलत) अगर 'सही है' पर सेट किया जाता है, तो एपीआई कॉल को Edge Microgateway से बिना किसी ऑथराइज़ेशन हेडर के पास किया जा सकता है. 'ऑथराइज़ेशन हेडर' ज़रूरी बनाने के लिए, इसे 'गलत है' पर सेट करें (डिफ़ॉल्ट).
  • allowInvalidAuthorization: (डिफ़ॉल्ट: गलत) अगर इसे सही पर सेट किया जाता है, तो एपीआई कॉल को तब पास किया जा सकता है, जब ऑथराइज़ेशन हेडर में पास किया गया टोकन अमान्य हो या उसकी समयसीमा खत्म हो गई हो. मान्य टोकन ज़रूरी बनाने के लिए, इसे 'गलत' पर सेट करें (डिफ़ॉल्ट).
  • Authorize-header: (डिफ़ॉल्ट: Authorize: Bearer) इस हेडर का इस्तेमाल, Edge Microgateway पर ऐक्सेस टोकन भेजने के लिए किया जाता है. उन मामलों में डिफ़ॉल्ट को बदला जा सकता है जहां टारगेट को किसी दूसरे मकसद के लिए अनुमति देने वाले हेडर का इस्तेमाल करने की ज़रूरत हो.
  • api-key-header: (डिफ़ॉल्ट: x-api-key) एज माइक्रोगेटवे को एपीआई पासकोड भेजने के लिए इस्तेमाल किए जाने वाले हेडर या क्वेरी पैरामीटर का नाम. एपीआई पासकोड इस्तेमाल करने का तरीका भी देखें.
  • keep-Authorize-header: (डिफ़ॉल्ट: गलत) 'सही' पर सेट होने पर, अनुरोध में भेजा गया ऑथराइज़ेशन हेडर, टारगेट को पास कर दिया जाता है.
  • allowOAuthOnly -- अगर इस नीति को 'सही है' पर सेट किया जाता है, तो हर एपीआई में बेयर ऐक्सेस टोकन के साथ ऑथराइज़ेशन हेडर होना चाहिए. आपको सिर्फ़ OAuth सुरक्षा मॉडल को अनुमति देने की अनुमति मिलती है (हालांकि, पुराने सिस्टम के साथ काम करने की सुविधा को बनाए रखते हुए). (2.4.x जोड़ा गया)
  • allowAPIKeyOnly -- अगर 'सही है' पर सेट किया जाता है, तो हर एपीआई में एपीआई पासकोड के साथ एक x-api-key हेडर (या पसंद के मुताबिक जगह) होना चाहिए.इससे आपको सिर्फ़ एपीआई कुंजी के सुरक्षा मॉडल को अनुमति मिलती है (पिछले सिस्टम के साथ काम करने की सुविधा को बनाए रखते हुए). (2.4.x को जोड़ा गया)
  • gracePeriod -- यह पैरामीटर, JWT के अनुमति टोकन में बताए गए समय से पहले नहीं (nbf) या जारी होने की तारीख (iat) समय के बीच, मामूली अंतर की वजह से होने वाली गड़बड़ियों को रोकने में मदद करता है. इस तरह की गड़बड़ी को ठीक करने के लिए, पैरामीटर को सेकंड की संख्या पर सेट करें. (2.5.7 को जोड़ा गया)

प्लग इन के लिए बने एट्रिब्यूट

हर प्लगिन की कॉन्फ़िगर करने लायक विशेषताओं के बारे में ज़्यादा जानकारी के लिए प्लग इन इस्तेमाल करना देखें.

प्रॉक्सी फ़िल्टर करना

आपके पास यह फ़िल्टर करने का विकल्प है कि कोई Edge Microgateway इंस्टेंस किस माइक्रोगेटवे-अवेयर प्रॉक्सी को प्रोसेस करेगा. Edge Microgateway के शुरू होने पर, वह उस संगठन में मौजूद सभी माइक्रोगेटवे अवेयर प्रॉक्सी को डाउनलोड करता है जिससे वह जुड़ा है. नीचे दिए गए कॉन्फ़िगरेशन का इस्तेमाल करके यह तय करें कि माइक्रोगेटवे किन प्रॉक्सी को प्रोसेस करेगा. उदाहरण के लिए, यह कॉन्फ़िगरेशन उन प्रॉक्सी को सीमित करता है जिन्हें माइक्रोगेटवे तीन प्रोसेस करेगा: edgemicro_proxy-1, edgemicro_proxy-2, और edgemicro_proxy-3:

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

प्रॉडक्ट को नाम के हिसाब से फ़िल्टर करना

नीचे दिए गए कॉन्फ़िगरेशन का इस्तेमाल करके, ऐसे एपीआई प्रॉडक्ट की संख्या को सीमित करें जिन्हें Edge माइक्रोगेटवे से डाउनलोड और प्रोसेस किया जाता है. डाउनलोड किए गए प्रॉडक्ट को फ़िल्टर करने के लिए, Edge माइक्रोगेटवे *.config.yaml फ़ाइल में दिए गए /products एपीआई में, productnamefilter क्वेरी पैरामीटर जोड़ें. उदाहरण के लिए:

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'

ध्यान दें कि क्वेरी पैरामीटर की वैल्यू, रेगुलर एक्सप्रेशन फ़ॉर्मैट में होनी चाहिए. साथ ही, वैल्यू यूआरएल कोड में होनी चाहिए. उदाहरण के लिए, रेगुलर एक्सप्रेशन ^[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 के यूज़र इंटरफ़ेस (यूआई) में, उस संगठन/एनवायरमेंट में edgemicro_auth प्रॉक्सी को चुनें जहां आपने Edge Microgateway को कॉन्फ़िगर किया है.
  2. डेवलप करें टैप में, एडिटर में Javaकॉलआउट नीति खोलें.
  3. products.filter.attributes कुंजी का इस्तेमाल करके कस्टम एट्रिब्यूट जोड़ें. इसके लिए, एट्रिब्यूट के नामों की कॉमा-सेपरेटेड लिस्ट दें. सिर्फ़ उन प्रॉडक्ट को Edge Microgateway पर वापस भेजा जाएगा जिनमें कस्टम एट्रिब्यूट का कोई भी नाम शामिल होगा.
  4. आपके पास जांच को बंद करने का विकल्प होता है. इससे यह पता चलता है कि प्रॉडक्ट को मौजूदा एनवायरमेंट के लिए इस्तेमाल किया जा सकता है या नहीं. इसके लिए, कस्टम एट्रिब्यूट products.filter.env.enable को false पर सेट करें. (डिफ़ॉल्ट सत्य है.)
  5. (सिर्फ़ प्राइवेट क्लाउड) अगर आप Private Cloud के लिए Edge का इस्तेमाल कर रहे हैं, तो गैर-सीपीएस प्लैटफ़ॉर्म के लिए प्रॉडक्ट की जानकारी पाने के लिए, org.noncps प्रॉपर्टी को true पर सेट करें.
  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>
    

Analytics पुश फ़्रीक्वेंसी को कॉन्फ़िगर करना

Apigee को Edge Microgateway पर Analytics का डेटा भेजने की फ़्रीक्वेंसी को कंट्रोल करने के लिए, इन कॉन्फ़िगरेशन पैरामीटर का इस्तेमाल करें:

  • bufferSize (ज़रूरी नहीं): सबसे पुराने रिकॉर्ड को छोड़ने से पहले, बफ़र में सेव किए जाने वाले Analytics के रिकॉर्ड की ज़्यादा से ज़्यादा संख्या. डिफ़ॉल्ट: 10000
  • batchSize (ज़रूरी नहीं): Apigee को भेजे गए Analytics रिकॉर्ड के बैच का ज़्यादा से ज़्यादा साइज़. डिफ़ॉल्ट: 500
  • flushInterval (ज़रूरी नहीं): Apigee को भेजे गए Analytics रिकॉर्ड के एक बैच के हर फ़्लश के बीच मिलीसेकंड की संख्या. डिफ़ॉल्ट: 5000

उदाहरण के लिए:

analytics:
  bufferSize: 15000
  batchSize: 1000
  flushInterval: 6000

आंकड़ों का डेटा मास्क करना

यह कॉन्फ़िगरेशन, अनुरोध के पाथ की जानकारी को Edge के Analytics में दिखने से रोकता है. अनुरोध यूआरआई और/या अनुरोध के पाथ को मास्क करने के लिए, माइक्रोगेटवे कॉन्फ़िगरेशन में यह जोड़ें. ध्यान दें कि यूआरआई में अनुरोध के होस्टनेम और पाथ के हिस्से शामिल होते हैं.

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

Edge के Analytics में एपीआई कॉल को अलग करना

किसी खास एपीआई पाथ को अलग-अलग करने के लिए, Analytics प्लगिन को कॉन्फ़िगर किया जा सकता है. इससे यह Edge Analytics के डैशबोर्ड में एक अलग प्रॉक्सी के तौर पर दिखेगा. उदाहरण के लिए, डैशबोर्ड में हेल्थ चेक एपीआई को अलग-अलग किया जा सकता है, ताकि असल एपीआई प्रॉक्सी कॉल से कोई भ्रम पैदा न हो. Analytics के डैशबोर्ड में, अलग-अलग प्रॉक्सी, नाम रखने के इस पैटर्न को फ़ॉलो करती हैं:

edgemicro_proxyname-health

इस इमेज में, Analytics के डैशबोर्ड में दो अलग-अलग प्रॉक्सी दिखाई गई हैं: edgemicro_hello-health और edgemicro_mock-health:

Analytics के डैशबोर्ड में, रिलेटिव और ऐब्सलूट पाथ को अलग-अलग प्रॉक्सी के तौर पर अलग-अलग करने के लिए, इन पैरामीटर का इस्तेमाल करें:

  • relativePath (ज़रूरी नहीं): Analytics के डैशबोर्ड में अलग-अलग किए जाने के लिए, रिलेटिव पाथ की जानकारी देता है. उदाहरण के लिए, /healthcheck तय करने पर, /healthcheck पाथ वाले सभी एपीआई कॉल, डैशबोर्ड में edgemicro_proxyname-health के तौर पर दिखेंगे. ध्यान दें कि यह फ़्लैग प्रॉक्सी बेसपाथ को अनदेखा करता है. बेसपाथ के साथ पूरे पाथ के हिसाब से अलग-अलग करने के लिए, proxyPath फ़्लैग का इस्तेमाल करें.
  • proxyPath (ज़रूरी नहीं): Analytics डैशबोर्ड में अलग-अलग दिखाने के लिए, प्रॉक्सी बेसपाथ के साथ-साथ पूरे एपीआई प्रॉक्सी पाथ की जानकारी देता है. उदाहरण के लिए, अगर /mocktarget/healthcheck के बारे में बताया जाता है और /mocktarget एक प्रॉक्सी बेसपाथ है, तो /mocktarget/healthcheck पाथ वाले सभी एपीआई कॉल, डैशबोर्ड में edgemicro_proxyname-health के तौर पर दिखेंगे.

उदाहरण के लिए, यहां दिए गए कॉन्फ़िगरेशन में, /healthcheck वाले किसी भी एपीआई पाथ को Analytics प्लगिन की मदद से अलग किया जाएगा. इसका मतलब है कि Analytics के डैशबोर्ड में, /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 प्रॉक्सी पाथ वाले किसी भी एपीआई को Analytics के डैशबोर्ड में, edgemicro_proxyname-health नाम की एक अलग प्रॉक्सी के तौर पर अलग-अलग कर दिया जाएगा.

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

कंपनी के फ़ायरवॉल के पीछे Edge माइक्रोगेटवे सेट अप करना

Apigee Edge से संपर्क करने के लिए, एचटीटीपी प्रॉक्सी का इस्तेमाल करें

वर्शन 3.1.2 में जोड़ा गया.

Edge Microgateway और Apigee Edge के बीच कम्यूनिकेशन के लिए, एचटीटीपी प्रॉक्सी का इस्तेमाल करने के लिए, ये काम करें:

  1. एनवायरमेंट वैरिएबल HTTP_PROXY, HTTPS_PROXY, और NO_PROXY सेट करें. ये वैरिएबल हर उस एचटीटीपी प्रॉक्सी के होस्ट को कंट्रोल करते हैं जिसका इस्तेमाल आपको 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 माइक्रोगेटवे को रीस्टार्ट करें.

टारगेट कम्यूनिकेशन के लिए एचटीटीपी प्रॉक्सी का इस्तेमाल करें

वर्शन 3.1.2 में जोड़ा गया.

Edge Microgateway और बैकएंड टारगेट के बीच कम्यूनिकेशन के लिए, एचटीटीपी प्रॉक्सी का इस्तेमाल करने के लिए, ये काम करें:

  1. माइक्रोगेटवे कॉन्फ़िगरेशन फ़ाइल में, यह कॉन्फ़िगरेशन जोड़ें:
    edgemicro:
      proxy:
        tunnel: true | false
        url: proxy_url
        bypass: target_host # target hosts to bypass the proxy.
        enabled: true | false

    जगह:

    • tunnel: (ज़रूरी नहीं) सही होने पर, Edge Microgateway, एचटीटीपी कनेक्शन के तरीके का इस्तेमाल करके एचटीटीपी अनुरोधों को एक टीसीपी कनेक्शन पर टनल करता है. (अगर प्रॉक्सी कॉन्फ़िगर करने के लिए, एनवायरमेंट वैरिएबल के लिए TLS की सुविधा चालू है, तो भी यही बात लागू होगी). डिफ़ॉल्ट: false
    • url: एचटीटीपी प्रॉक्सी यूआरएल.
    • बाईपास: (ज़रूरी नहीं) एक या कॉमा लगाकर अलग किए गए टारगेट होस्ट यूआरएल के बारे में बताता है जिन्हें एचटीटीपी प्रॉक्सी को बायपास करना चाहिए. अगर यह प्रॉपर्टी सेट नहीं है, तो NO_PROXY एनवायरमेंट वैरिएबल का इस्तेमाल करके तय करें कि किन टारगेट यूआरएल को बायपास करना है.
    • चालू है: अगर सही और proxy.url सेट है, तो एचटीटीपी प्रॉक्सी के लिए proxy.url वैल्यू इस्तेमाल करें. अगर सही है और proxy.url सेट नहीं है, तो एचटीटीपी प्रॉक्सी एनवायरमेंट वैरिएबल HTTP_PROXY और HTTPS_PROXY में बताई गई प्रॉक्सी का इस्तेमाल करें, जैसा कि Apigee Edge से संपर्क करने के लिए एचटीटीपी प्रॉक्सी का इस्तेमाल करना में बताया गया है.

    उदाहरण के लिए:

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

  2. Edge माइक्रोगेटवे को रीस्टार्ट करें.

माइक्रोगेटवे-अवेयर प्रॉक्सी में वाइल्डकार्ड इस्तेमाल करना

ageमाइक्रो_* (माइक्रोगेटवे-अवेयर) प्रॉक्सी के बेस पाथ में, एक या उससे ज़्यादा "*" वाइल्डकार्ड का इस्तेमाल किया जा सकता है. उदाहरण के लिए, /team/*/members के बेस पाथ की मदद से क्लाइंट, https://[host]/team/blue/members और https://[host]/team/green/members को कॉल कर सकते हैं, इसके लिए आपको नई टीम की मदद करने के लिए, नई एपीआई प्रॉक्सी बनाने की ज़रूरत नहीं होती. ध्यान दें कि /**/ का इस्तेमाल नहीं किया जा सकता.

अहम जानकारी: Apigee, बेस पाथ के पहले एलिमेंट के तौर पर, वाइल्डकार्ड "*" का इस्तेमाल नहीं करता है. उदाहरण के लिए, यह काम नहीं करता: /*/ खोज.

रोटेटिंग JWT कुंजियां

जेडब्लयूटी जनरेट करने के कुछ समय बाद, आपको Edge से एन्क्रिप्ट (सुरक्षित) किए गए KVM में सेव किए गए सार्वजनिक/निजी पासकोड के जोड़े को बदलने की ज़रूरत पड़ सकती है. कुंजी का नया जोड़ा जनरेट करने की इस प्रोसेस को 'की रोटेशन' कहा जाता है.

Edge Microgateway, JWT का इस्तेमाल कैसे करता है

JSON वेब टोकन (JWT), एक टोकन स्टैंडर्ड है. इसकी जानकारी RFC7519 में दी गई है. JWT, दावों के सेट पर हस्ताक्षर करने का तरीका देता है. हालांकि, JWT पाने वाले लोग इन दावों की भरोसेमंद तरीके से पुष्टि कर सकते हैं.

सीएलआई का इस्तेमाल करके, JWT जनरेट किया जा सकता है. साथ ही, इसे एपीआई पासकोड के बजाय, एपीआई कॉल के ऑथराइज़ेशन हेडर में इस्तेमाल किया जा सकता है. उदाहरण के लिए:

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

सीएलआई की मदद से JWT जनरेट करने के बारे में जानकारी पाने के लिए, टोकन जनरेट करना लेख पढ़ें.

डेटा सुरक्षित करने वाली कुंजी का नया वर्शन बनाना क्या होता है?

जेडब्लयूटी जनरेट करने के कुछ समय बाद, आपको Edge से एन्क्रिप्ट (सुरक्षित) किए गए KVM में सेव किए गए सार्वजनिक/निजी पासकोड के जोड़े को बदलने की ज़रूरत पड़ सकती है. कुंजी का नया जोड़ा जनरेट करने की इस प्रोसेस को 'की रोटेशन' कहा जाता है. कुंजियों को बदलने पर, निजी/सार्वजनिक कुंजी का एक नया जोड़ा जनरेट होता है. साथ ही, यह आपके Apigee Edge के संगठन/एनवायरमेंट में "माइक्रोगेटवे" केवीएम में सेव होता है. इसके अलावा, पुरानी सार्वजनिक कुंजी को उसके मूल आईडी की वैल्यू के साथ बनाए रखा जाता है.

JWT जनरेट करने के लिए, Edge एन्क्रिप्ट (सुरक्षित) किए गए केवीएम में सेव की गई जानकारी का इस्तेमाल करता है. जब आपने शुरुआत में Edge माइक्रोगेटवे को सेट अप (कॉन्फ़िगर किया) किया था, तब microgateway नाम का केवीएम बनाया गया था और कुंजियों से भरा गया था. KVM में मौजूद कुंजियों का इस्तेमाल, JWT पर साइन और उसे एन्क्रिप्ट करने के लिए किया जाता है.

केवीएम कुंजियों में ये शामिल हैं:

  • private_key - सबसे नई (हाल ही में बनाई गई) आरएसए निजी कुंजी, जिसका इस्तेमाल JWT को साइन करने के लिए किया जाता है.

  • public_key - यह सबसे नया (सबसे हाल ही में बनाया गया) प्रमाणपत्र है, जिसका इस्तेमाल Private_key से साइन किए गए JWT की पुष्टि करने के लिए किया जाता है.

  • private_key_kid - सबसे नया (सबसे हाल में बनाया गया) निजी कुंजी आईडी. यह कुंजी आईडी Private_key वैल्यू से जुड़ा होता है और इसका इस्तेमाल कुंजी का नया वर्शन बनाने के लिए किया जाता है.

  • public_key1_kid - सबसे नई (सबसे हाल में बनाई गई) सार्वजनिक कुंजी आईडी. यह कुंजी Public_key1 मान से जुड़ी होती है और इसका इस्तेमाल कुंजी बदलने की सुविधा के लिए किया जाता है. यह वैल्यू और किड के 'निजी' के तौर पर सेट की गई 'निजी कुंजी', दोनों एक ही है.

  • public_key1 - सबसे नई (हाल ही में बनाई गई) सार्वजनिक कुंजी.

कुंजी का नया वर्शन बनाते समय, मैप में मौजूदा कुंजी की वैल्यू बदल दी जाती हैं और पुरानी सार्वजनिक कुंजियों को बनाए रखने के लिए नई कुंजियां जोड़ दी जाती हैं. उदाहरण के लिए:

  • public_key2_kid - पुराना सार्वजनिक कुंजी आईडी. यह कुंजी Public_key2 मान से जुड़ी होती है और इसका इस्तेमाल कुंजी बदलने की सुविधा के लिए किया जाता है.

  • public_key2 - पुरानी सार्वजनिक कुंजी.

पुष्टि के लिए दिए गए JWT की पुष्टि, नई सार्वजनिक कुंजी से की जाएगी. अगर पुष्टि नहीं हो पाती है, तो JWT की समयसीमा खत्म होने तक, पुरानी सार्वजनिक कुंजी का इस्तेमाल किया जाएगा. इस तरह, एपीआई ट्रैफ़िक में तुरंत रुकावट डाले बिना, कुंजियों को “रोटेट” किया जा सकता है.

डेटा सुरक्षित करने वाली कुंजी का नया वर्शन बनाने का तरीका

इस सेक्शन में बताया गया है कि डेटा सुरक्षित करने वाली 'की' का नया वर्शन कैसे बनाया जाता है.

  1. केवीएम को अपग्रेड करने के लिए, edgemicro upgradekvm कमांड का इस्तेमाल करें. इस निर्देश को चलाने के बारे में जानकारी पाने के लिए, केवीएम को अपग्रेड करना लेख पढ़ें. आपको यह चरण सिर्फ़ एक बार करना होगा.
  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 माइक्रोगेटवे पर कई कुंजियां दिखाता है. नीचे दिए गए उदाहरण में, ध्यान दें कि हर कुंजी की एक यूनीक "किड" (मुख्य आईडी) वैल्यू होती है. इसके बाद, माइक्रोगेटवे इन कुंजियों का इस्तेमाल, ऑथराइज़ेशन टोकन की पुष्टि करने के लिए करता है. अगर टोकन की पुष्टि नहीं हो पाती है, तो माइक्रोगेटवे यह देखता है कि कुंजी के सेट में कोई पुरानी कुंजी है या नहीं. साथ ही, वह उसी कुंजी के लिए कोशिश करता है. दिखाई गई कुंजियों का फ़ॉर्मैट, JSON वेब कुंजी (JWK) होता है. इस फ़ॉर्मैट के बारे में आरएफ़सी 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"
    }
  ]
}

"पहले नहीं" की देरी को कॉन्फ़िगर करना

3.1.5 और उससे पहले के वर्शन में, rotatekey कमांड से जनरेट किए गए नए निजी पासकोड को तुरंत लागू किया गया. साथ ही, जनरेट किए गए नए टोकन को नई निजी कुंजी से साइन किया गया. हालांकि, नई सार्वजनिक कुंजी, माइक्रोगेटवे कॉन्फ़िगरेशन को रीफ़्रेश करते समय ही हर 10 मिनट (डिफ़ॉल्ट रूप से) Edge माइक्रोगेटवे के इंस्टेंस के लिए उपलब्ध कराई गई थी. टोकन साइनिंग और माइक्रोगेटवे इंस्टेंस के रीफ़्रेश होने के बीच इस फ़र्क़ की वजह से, सबसे नई कुंजी से साइन किए गए टोकन अस्वीकार कर दिए जाएंगे. ऐसा तब तक होगा, जब तक सभी इंस्टेंस को सार्वजनिक तौर पर उपलब्ध नया पासकोड नहीं मिल जाता.

ऐसे मामलों में जहां कई माइक्रोगेटवे इंस्टेंस मौजूद हैं, वहां कभी-कभी सार्वजनिक पासकोड लैग की वजह से स्थिति 403 के साथ, रुक-रुककर चलने वाली रनटाइम गड़बड़ियां होती हैं. ऐसा इसलिए होता है, क्योंकि टोकन की पुष्टि एक इंस्टेंस पर पास हो जाती है और दूसरे इंस्टेंस पर तब तक काम नहीं करती, जब तक सभी इंस्टेंस रीफ़्रेश नहीं हो जाते.

वर्शन 3.1.6 से, rotatekey कमांड के नए फ़्लैग की मदद से नई निजी कुंजी के लागू होने में देरी होने का समय तय किया जा सकता है. इससे सभी माइक्रोगेटवे इंस्टेंस को रीफ़्रेश करने और नई सार्वजनिक कुंजी पाने का समय मिल जाता है. नया फ़्लैग --nbf है, जिसका मतलब है "पहले से नहीं". इस फ़्लैग का एक पूर्णांक मान होता है, जो कि देरी में लगने वाले मिनट की संख्या है.

नीचे दिए गए उदाहरण में, देरी को 15 मिनट पर सेट किया गया है:

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

ध्यान दें कि देरी को config_change_poll_internal कॉन्फ़िगरेशन सेटिंग से ज़्यादा पर सेट करना सबसे सही तरीका है. यह डिफ़ॉल्ट रूप से 10 मिनट की होती है. agemicro के एट्रिब्यूट देखें.

डाउनलोड की गई प्रॉक्सी फ़िल्टर करना

डिफ़ॉल्ट रूप से, Edge Microgateway आपके Edge संगठन की सभी प्रॉक्सी डाउनलोड करता है, जो नाम वाले प्रीफ़िक्स "agemicro_" से शुरू होते हैं. इस डिफ़ॉल्ट सेटिंग को बदलकर उन प्रॉक्सी को डाउनलोड किया जा सकता है जिनके नाम किसी पैटर्न से मेल खाते हैं.

  1. Edge Micro की कॉन्फ़िगरेशन फ़ाइल खोलें: ~/.edgemicro/org-env-config.yaml
  2. game_config में प्रॉक्सी पैटर्न एलिमेंट जोड़ें. उदाहरण के लिए, नीचे दिया गया पैटर्न, Edgemicro_foo, Edgemicro_Fast, और Edgemicro_first जैसे प्रॉक्सी डाउनलोड करेगा.
    edge_config:
    …
    proxyPattern: edgemicro_f*

एपीआई प्रॉक्सी के बिना प्रॉडक्ट के बारे में जानकारी देना

Apigee Edge में, एक ऐसा एपीआई प्रॉडक्ट बनाया जा सकता है जिसमें कोई एपीआई प्रॉक्सी न हो. इस प्रॉडक्ट कॉन्फ़िगरेशन की मदद से, उस प्रॉडक्ट से जुड़ा एपीआई पासकोड, आपके संगठन में डिप्लॉय किए गए किसी भी प्रॉक्सी पासकोड के साथ काम कर सकता है. 2.5.4 वर्शन के साथ, Edge Microgateway पर यह प्रॉडक्ट कॉन्फ़िगरेशन काम करता है.

डीबग करना और समस्या हल करना

डीबगर से कनेक्ट करना

Edge Microgateway को नोड-इंस्पेक्टर जैसे डीबगर की मदद से चलाया जा सकता है. इससे कस्टम प्लग इन की समस्या को हल करने और डीबग करने में मदद मिलती है.

  1. डीबग मोड में Edge माइक्रोगेटवे को रीस्टार्ट करें. ऐसा करने के लिए, start निर्देश की शुरुआत में DEBUG=* जोड़ें:
    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. अब एज माइक्रोगेटवे कोड का इस्तेमाल करके कई काम किए जा सकते हैं. जैसे, ब्रेकपॉइंट सेट करना, वॉच एक्सप्रेशन देखना वगैरह.

आपके पास डीबग मोड से जुड़े स्टैंडर्ड Node.js फ़्लैग तय करने का विकल्प होता है. उदाहरण के लिए, --nolazy, एसिंक्रोनस कोड को डीबग करने में मदद करता है.

लॉग फ़ाइलों की जांच की जा रही है

अगर आपको समस्याएं आ रही हैं, तो काम करने की प्रोसेस की जानकारी और गड़बड़ी की जानकारी के लिए, लॉग फ़ाइलों की जांच ज़रूर करें. ज़्यादा जानकारी के लिए, लॉग फ़ाइलें मैनेज करना लेख पढ़ें.

एपीआई पासकोड सुरक्षा का इस्तेमाल करना

एपीआई पासकोड, Edge Microgateway को अनुरोध भेजने वाले क्लाइंट की पुष्टि करने का आसान तरीका देते हैं. आपके पास किसी ऐसे Apigee Edge प्रॉडक्ट से उपभोक्ता कुंजी (जिसे Client-ID भी कहा जाता है) वैल्यू को कॉपी करके, एपीआई कुंजी मिल सकती है जिसमें Edge Microgateway पुष्टि करने वाला प्रॉक्सी शामिल है.

कुंजियों को कैश मेमोरी में सेव करना

एपीआई कुंजियों को बेयर टोकन से बदल दिया जाता है, जिन्हें कैश मेमोरी में सेव किया जाता है. Edge Microgateway पर आने वाले अनुरोधों पर, Cache-Control: no-cache हेडर सेट करके कैश मेमोरी में सेव करने की सुविधा बंद करें.

एपीआई पासकोड का इस्तेमाल करना

एपीआई अनुरोध में, एपीआई पासकोड को क्वेरी पैरामीटर के तौर पर या हेडर में पास किया जा सकता है. डिफ़ॉल्ट रूप से, हेडर और क्वेरी पैरामीटर का नाम, 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 नाम का इस्तेमाल किया जाता है. कॉन्फ़िगरेशन फ़ाइल में बदलाव करना लेख में बताए गए तरीके के मुताबिक, डिफ़ॉल्ट कॉन्फ़िगरेशन फ़ाइल में बदलाव किया जा सकता है. उदाहरण के लिए, नाम को 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 देखें.

अपस्ट्रीम रिस्पॉन्स कोड चालू करें

अगर रिस्पॉन्स, 200 स्टेटस नहीं है, तो डिफ़ॉल्ट रूप से oauth प्लगिन सिर्फ़ 4xx गड़बड़ी वाले स्टेटस कोड दिखाता है. इस व्यवहार को बदला जा सकता है, ताकि यह गड़बड़ी के आधार पर हमेशा 4xx या 5xx कोड दिखाए.

इस सुविधा को चालू करने के लिए, oauth.useUpstreamResponse: true प्रॉपर्टी को अपने Edge Microgateway कॉन्फ़िगरेशन में जोड़ें. उदाहरण के लिए:

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

OAuth2 टोकन सुरक्षा का इस्तेमाल किया जा रहा है

इस सेक्शन में, OAuth2 ऐक्सेस टोकन पाने और रीफ़्रेश करने का तरीका बताया गया है. ऐक्सेस टोकन का इस्तेमाल माइक्रोगेटवे से सुरक्षित एपीआई कॉल करने के लिए किया जाता है. रीफ़्रेश टोकन का इस्तेमाल नए ऐक्सेस टोकन पाने के लिए किया जाता है.

ऐक्सेस टोकन पाने का तरीका

इस सेक्शन में बताया गया है कि ऐक्सेस टोकन पाने के लिए, edgemicro-auth प्रॉक्सी का इस्तेमाल कैसे किया जाता है.

edgemicro token सीएलआई कमांड का इस्तेमाल करके भी आपको ऐक्सेस टोकन मिल सकता है. सीएलआई पर ज़्यादा जानकारी के लिए, टोकन मैनेज करना लेख पढ़ें.

पहला एपीआई: क्रेडेंशियल को बॉडी पैरामीटर के तौर पर भेजना

यूआरएल में अपने संगठन और एनवायरमेंट के नामों को बदलें. साथ ही, Apigee पर डेवलपर ऐप्लिकेशन से मिले उपभोक्ता आईडी और उपभोक्ता सीक्रेट की वैल्यू को 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"

एपीआई 2: बेसिक पुष्टि वाले हेडर में क्रेडेंशियल भेजना

क्लाइंट क्रेडेंशियल को पुष्टि करने के बुनियादी हेडर के तौर पर और grant_type को फ़ॉर्म पैरामीटर के तौर पर भेजें. इस कमांड फ़ॉर्म के बारे में आरएफ़सी 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"

आउटपुट का सैंपल

एपीआई, JSON फ़ॉर्मैट में जवाब देता है. ध्यान दें कि token और access_token प्रॉपर्टी के बीच कोई अंतर नहीं है. आप इनमें से किसी एक का इस्तेमाल कर सकते हैं. ध्यान दें कि expires_in, पूर्णांक की वैल्यू होती है. इसकी वैल्यू सेकंड में दी जाती है.
{
"token": "eyJraWQiOiIxIiwidHlwIjoi",
"access_token": "eyJraWQiOiIxIiwid",
"token_type": "bearer",
"expires_in": 1799
}

रीफ़्रेश टोकन पाने का तरीका

रीफ़्रेश टोकन पाने के लिए, edgemicro-auth प्रॉक्सी के /token एंडपॉइंट पर एपीआई कॉल करें. आपको यह एपीआई कॉल, 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 एंडपॉइंट पर कॉल करके नया ऐक्सेस टोकन पाने का विकल्प है. उदाहरण के लिए:
    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 के एक से ज़्यादा इंस्टेंस चलाए हैं, तो हो सकता है कि आप एक ही जगह से उनके कॉन्फ़िगरेशन मैनेज करना चाहें. ऐसा करने के लिए, एक एचटीटीपी एंडपॉइंट तय किया जा सकता है. यहां Edge Micro की कॉन्फ़िगरेशन फ़ाइल डाउनलोड कर सकता है. -u फ़्लैग का इस्तेमाल करके, Edge Micro को शुरू करने पर इस एंडपॉइंट को तय किया जा सकता है.

उदाहरण के लिए:

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

जहां mgconfig एंडपॉइंट आपकी कॉन्फ़िगरेशन फ़ाइल का कॉन्टेंट दिखाता है. यह ऐसी फ़ाइल है जो डिफ़ॉल्ट रूप से, ~/.edgemicro में मौजूद होती है और इसका नाम रखने का फ़ॉर्मैट org-env-config.yaml होता है.

टीसीपी कनेक्शन का डेटा बफ़र होने की सुविधा बंद करना

आपके पास nodelay कॉन्फ़िगरेशन एट्रिब्यूट का इस्तेमाल करके, Edge Microgateway में इस्तेमाल किए गए टीसीपी कनेक्शन के लिए डेटा बफ़रिंग को बंद करने का विकल्प है.

डिफ़ॉल्ट रूप से, टीसीपी कनेक्शन डेटा भेजने से पहले उसे बफ़र करने के लिए 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

स्टैंडअलोन मोड में एज माइक्रोगेटवे चल रहा है

किसी भी Apigee Edge डिपेंडेंसी से डिसकनेक्ट किया गया, Edge Microgateway चलाया जा सकता है. इस स्थिति को स्टैंडअलोन मोड कहा जाता है. इससे आपको बिना इंटरनेट कनेक्शन के Edge Microgateway को चलाने और उसकी जांच करने की सुविधा मिलती है.

स्टैंडअलोन मोड में, ये सुविधाएं काम नहीं करती हैं, क्योंकि उन्हें Apigee Edge से कनेक्ट करने की ज़रूरत होती है:

  • OAuth और एपीआई पासकोड
  • अनुरोध भेजने की तय सीमा (कोटा)
  • Analytics

वहीं दूसरी ओर, कस्टम प्लगिन और स्पाक अरेस्ट सामान्य तौर पर काम करते हैं, क्योंकि उन्हें Apigee Edge से कनेक्ट करने की ज़रूरत नहीं होती. साथ ही, extauth नाम के नए प्लग इन की मदद से, स्टैंडअलोन मोड में रहते हुए, JWT से माइक्रोगेटवे को एपीआई कॉल की अनुमति दी जा सकती है.

गेटवे को कॉन्फ़िगर करना और उसे शुरू करना

Edge माइक्रोगेटवे को स्टैंडअलोन मोड में चलाने के लिए:

  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 एक "संगठन" नाम है, जिसका इस्तेमाल आपने कॉन्फ़िगरेशन फ़ाइल के नाम में किया है.
    • $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" }

    foo-bar-config.yaml फ़ाइल में extauth प्लगिन होने की वजह से, आपको "missing_permission" वाली गड़बड़ी मिली है. यह प्लगिन ऐसे JWT की पुष्टि करता है जो एपीआई कॉल के ऑथराइज़ेशन हेडर में मौजूद होना चाहिए. अगले सेक्शन में, आपको एक JWT मिलेगा, जिसकी मदद से एपीआई कॉल बिना गड़बड़ी के किए जा सकेंगे.

उदाहरण: ऑथराइज़ेशन टोकन पाना

नीचे दिए गए उदाहरण में, Apigee Edge (edgemicro-auth/jwkPublicKeys) पर, Edge Microgateway JWT एंडपॉइंट से JWT पाने का तरीका बताया गया है. यह एंडपॉइंट, Edge Microgateway का स्टैंडर्ड सेटअप और कॉन्फ़िगरेशन करने पर डिप्लॉय किया जाता है. Apigee एंडपॉइंट से JWT पाने के लिए, आपको सबसे पहले स्टैंडर्ड Edge Microgateway सेटअप करना होगा. साथ ही, आपको इंटरनेट से कनेक्ट होना होगा. यहां Apigee एंडपॉइंट का इस्तेमाल सिर्फ़ उदाहरण के लिए किया जाता है. यह ज़रूरी नहीं है. आपके पास किसी दूसरे JWT टोकन एंडपॉइंट का इस्तेमाल करने का भी विकल्प होता है. अगर आपने ऐसा किया, तो आपको उस एंडपॉइंट के लिए दिए गए एपीआई का इस्तेमाल करके JWT पाना होगा.

edgemicro-auth/jwkPublicKeys एंडपॉइंट का इस्तेमाल करके टोकन पाने का तरीका यहां बताया गया है:.

  1. आपको Apigee Edge पर अपने संगठन/एनवायरमेंट में edgemicro-auth प्रॉक्सी डिप्लॉय करने के लिए, Edge Microgateway का स्टैंडर्ड सेटअप और कॉन्फ़िगरेशन करना होगा. अगर आपने यह चरण पहले ही कर लिया है, तो आपको उसे दोहराने की ज़रूरत नहीं है.
  2. अगर आपने Apigee Cloud में Edge Microgateway को लागू किया है, तो आपका इंटरनेट से कनेक्ट होना ज़रूरी है, ताकि आप इस एंडपॉइंट से JWT पा सकें.
  3. Edge माइक्रोगेटवे बंद करें:
    edgemicro stop
  4. आपने पहले जो कॉन्फ़िगरेशन फ़ाइल बनाई थी ($HOME/.edgemicro/org-env-config.yaml), उसमें extauth:publickey_url एट्रिब्यूट को अपने Apigee Edge के संगठन/एनवायरमेंट में edgemicro-auth/jwkPublicKeys एंडपॉइंट पर ले जाएं. उदाहरण के लिए:
    extauth:
      publickey_url: 'https://your_org-your_env.apigee.net/edgemicro-auth/jwkPublicKeys'
  5. कॉन्फ़िगरेशन फ़ाइल के नाम में इस्तेमाल किए गए संगठन/env नाम का इस्तेमाल करके, Edge Microgateway को पहले की तरह रीस्टार्ट करें. उदाहरण के लिए:
    edgemicro start -o foo -e bar -a proxy1 -v 1 -t http://mocktarget.apigee.net -b /
  6. ऑथराइज़ेशन एंडपॉइंट से JWT टोकन पाएं. edgemicro-auth/jwkPublicKeys एंडपॉइंट का इस्तेमाल किया जा रहा है, इसलिए इस सीएलआई कमांड का इस्तेमाल किया जा सकता है:

edgemicro token कमांड या एपीआई का इस्तेमाल करके, Edge Microgateway के लिए JWT जनरेट किया जा सकता है. उदाहरण के लिए:

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

जगह:

  • आपके संगठन के Apigee संगठन का नाम your_org है. इसके लिए, आपने Edge Microgateway को पहले कॉन्फ़िगर किया था.
  • your_env, संगठन का एक एनवायरमेंट है.
  • i विकल्प ऐसे डेवलपर ऐप्लिकेशन की उपभोक्ता कुंजी के बारे में बताता है जिसमें ऐसा प्रॉडक्ट है जिसमें edgemicro-auth प्रॉक्सी शामिल है.
  • s विकल्प ऐसे डेवलपर ऐप्लिकेशन के उपभोक्ता की जानकारी के बारे में बताता है जिसमें ऐसा प्रॉडक्ट है जिसमें edgemicro-auth प्रॉक्सी शामिल है.

यह निर्देश, Apigee Edge से एक JWT जनरेट करने के लिए कहता है. इसके बाद, इसका इस्तेमाल एपीआई कॉल की पुष्टि करने के लिए किया जा सकता है.

टोकन जनरेट करना भी देखें.

स्टैंडअलोन कॉन्फ़िगरेशन की जांच करना

कॉन्फ़िगरेशन की जांच करने के लिए, अनुमति वाले हेडर में जोड़े गए टोकन के साथ एपीआई को इस तरह कॉल करें:

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 Edge पर लागू करने के लिए, माइक्रोगेटवे-अवेयर प्रॉक्सी की ज़रूरत नहीं होती. इसके बजाय, जब आप माइक्रोगेटवे शुरू करें, तो स्थानीय प्रॉक्सी नाम, बेसपाथ, और टारगेट यूआरएल देकर "लोकल प्रॉक्सी" को कॉन्फ़िगर करें. इसके बाद, माइक्रोगेटवे पर किए गए एपीआई कॉल को स्थानीय प्रॉक्सी के टारगेट यूआरएल पर भेजा जाता है. अन्य सभी मामलों में, स्थानीय प्रॉक्सी मोड ठीक उसी तरह काम करता है जैसा कि Edge Microgateway को अपने सामान्य मोड में चल रहा है. पुष्टि करने की प्रक्रिया ठीक उसी तरह काम करती है, जिस तरह से करता है जैसे कि स्पाइक अरेस्ट और कोटा लागू करना, कस्टम प्लगिन वगैरह.

इस्तेमाल की स्थिति और उसका उदाहरण

लोकल प्रॉक्सी मोड तब काम आता है, जब आपको एज माइक्रोगेटवे इंस्टेंस के साथ सिर्फ़ एक प्रॉक्सी जोड़ने की ज़रूरत हो. उदाहरण के लिए, Edge Microgateway को Kubernetes में साइडकार प्रॉक्सी के रूप में इंजेक्ट करें, जहां एक माइक्रोगेटवे और एक सेवा एक ही पॉड में चलती है. साथ ही, जहां माइक्रोगेटवे अपनी साथी सेवा से आने-जाने का ट्रैफ़िक मैनेज करता है. नीचे दी गई इमेज में इस आर्किटेक्चर को दिखाया गया है. यहां एज माइक्रोगेटवे एक कुबेरनेट क्लस्टर में साइडकार प्रॉक्सी के तौर पर काम करता है. हर माइक्रोगेटवे इंस्टेंस, अपनी साथी सेवा पर सिर्फ़ एक एंडपॉइंट से बात करता है:

साइडकार के तौर पर एजमाइक्रो

आर्किटेक्चर की इस शैली का एक फ़ायदा यह है कि Edge Microgateway है, वह कंटेनर एनवायरमेंट में डिप्लॉय की जाने वाली अलग-अलग सेवाओं के लिए, एपीआई मैनेजमेंट की सुविधा देता है, जैसे कि Kubernetes क्लस्टर.

स्थानीय प्रॉक्सी मोड कॉन्फ़िगर करना

Edge Microgateway को लोकल प्रॉक्सी मोड में चलाने के लिए, यह तरीका अपनाएं:

  1. अपना लोकल कॉन्फ़िगरेशन एनवायरमेंट सेट अप करने के लिए, edgemicro init चलाएं. यह ठीक वैसे ही होता है, जैसा कि सामान्य Edge माइक्रोगेटवे के सेटअप में किया जाता है. यह भी देखें Edge माइक्रोगेटवे कॉन्फ़िगर करना.
  2. edgemicro configure को उसी तरह चलाएं, जैसे कि Edge माइक्रोगेटवे सेटअप करने के दौरान किया जाता है. उदाहरण के लिए:
    edgemicro configure -o your_org -e your_env -u your_apigee_username

    यह निर्देश, Edge पर agemicro-auth नीति को डिप्लॉय करता है. साथ ही, यह कुंजी और सीक्रेट दिखाता है कि आपको माइक्रोगेटवे को शुरू करने की ज़रूरत है. अगर आपको मदद चाहिए, तो Edge Microgateway कॉन्फ़िगर करना देखें.

  3. Apigee Edge पर, एक एपीआई प्रॉडक्ट बनाएं और उसे कॉन्फ़िगरेशन से जुड़ी इन ज़रूरी शर्तों के साथ बनाएं. दूसरे सभी कॉन्फ़िगरेशन को अपने हिसाब से मैनेज किया जा सकता है:
    • आपको प्रॉडक्ट में agemicro-auth प्रॉक्सी जोड़ना ज़रूरी है. जब आपने edgemicro configure चलाया, तो यह प्रॉक्सी अपने-आप डिप्लॉय हो गई.
    • आपको एक संसाधन पाथ देना ज़रूरी है. Apigee, प्रॉडक्ट में इस पाथ को जोड़ने का सुझाव देता है: /**. ज़्यादा जानने के लिए, संसाधन पाथ के व्यवहार को कॉन्फ़िगर करना लेख पढ़ें. Edge के दस्तावेज़ में एपीआई प्रॉडक्ट बनाएं भी देखें.
  4. Apigee Edge पर, डेवलपर बनाएं. इसके अलावा, आपके पास किसी मौजूदा डेवलपर का इस्तेमाल करने का भी विकल्प है. मदद के लिए, Edge मैनेजमेंट के यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल करके डेवलपर जोड़ना लेख पढ़ें.

  5. Apigee Edge पर, डेवलपर ऐप्लिकेशन बनाएं. आपको उस एपीआई प्रॉडक्ट को जोड़ना ज़रूरी है जिसे आपने अभी ऐप्लिकेशन में बनाया है. मदद के लिए, Edge मैनेजमेंट के यूज़र इंटरफ़ेस (यूआई) में ऐप्लिकेशन को रजिस्टर करना देखें.
  6. जिस मशीन पर Edge Microgateway इंस्टॉल है, उस पर "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, प्रॉक्सी के टारगेट के लिए यूआरएल है (वह सेवा जिसे प्रॉक्सी कॉल करेगा).
    • 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"
}

इस शुरुआती एपीआई कॉल में कोई गड़बड़ी हुई, क्योंकि आपने मान्य एपीआई पासकोड उपलब्ध नहीं कराया. आपने पहले जो डेवलपर ऐप्लिकेशन बनाया था, उसमें जाकर कुंजी देखी जा सकती है. ऐप को Edge यूज़र इंटरफ़ेस (यूआई) में खोलें, उपभोक्ता कुंजी को कॉपी करें, और उस कुंजी का इस तरह इस्तेमाल करें:

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

उदाहरण के लिए:

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

आउटपुट का उदाहरण:

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

सिंकर का इस्तेमाल करना

इस सेक्शन में बताया गया है कि सिंक्रोनर का इस्तेमाल कैसे किया जाए. यह एक वैकल्पिक सुविधा है, जो Edge Microgteway के काम करने के तरीके को बेहतर बनाती है. ऐसा करने के लिए, Apigee Edge से कॉन्फ़िगरेशन डेटा हासिल किया जाता है और उसे स्थानीय Redis डेटाबेस में लिखा जाता है. सिंक्रोनर इंस्टेंस के चलने पर, अलग-अलग नोड पर चल रहे अन्य Edge माइक्रोगेटवे इंस्टेंस, सीधे इस डेटाबेस से अपना कॉन्फ़िगरेशन हासिल कर सकते हैं.

फ़िलहाल, सिंक्रोनाइज़र सुविधा Redis 5.0.x के साथ काम करने के लिए काम करती है.

सिंकर क्या है?

सिंकर, Edge Microgateway के लिए रेज़िलिएंस का लेवल उपलब्ध कराता है. इससे यह पक्का करने में मदद मिलती है कि Edge Microgateway का हर इंस्टेंस एक ही कॉन्फ़िगरेशन का इस्तेमाल करे. साथ ही, इंटरनेट में रुकावट आने पर, Edge Microgateway के इंस्टेंस सही तरीके से चालू और ठीक से काम करें.

डिफ़ॉल्ट रूप से, Edge Microgateway इंस्टेंस को Apigee Edge से संपर्क करना चाहिए, ताकि वे एपीआई प्रॉक्सी और एपीआई प्रॉडक्ट के कॉन्फ़िगरेशन जैसे कॉन्फ़िगरेशन डेटा को वापस पा सकें और रीफ़्रेश कर सकें. अगर Edge के साथ इंटरनेट कनेक्शन काम नहीं करता है, तो माइक्रोगेटवे इंस्टेंस काम करना जारी रख सकते हैं, क्योंकि सबसे नए कॉन्फ़िगरेशन डेटा को कैश मेमोरी में सेव किया जाता है. हालांकि, कनेक्शन के बिना माइक्रोगेटवे के नए इंस्टेंस शुरू नहीं हो सकते. इसके अलावा, इंटरनेट में रुकावट की वजह से, एक या एक से ज़्यादा माइक्रोगेटवे इंस्टेंस चल सकते हैं. ये इंस्टेंस, कॉन्फ़िगरेशन की ऐसी जानकारी के साथ चल सकते हैं जो अन्य इंस्टेंस के साथ सिंक नहीं होती.

Edge Microgateway सिंकर, Edge Microgateway इंस्टेंस के लिए एक वैकल्पिक तरीका उपलब्ध कराता है, ताकि वह एपीआई प्रॉक्सी ट्रैफ़िक को शुरू करने और प्रोसेस करने के लिए ज़रूरी कॉन्फ़िगरेशन डेटा वापस पा सके. Apigee Edge पर मिले कॉल से मिले कॉन्फ़िगरेशन डेटा में, ये शामिल हैं: jwk_public_keys कॉल, jwt_public_key कॉल, बूटस्ट्रैप कॉल, और एपीआई प्रॉडक्ट कॉल. सिंकर की मदद से, अलग-अलग नोड पर चल रहे सभी Edge Microgateway इंस्टेंस के लिए, यह संभव है कि वे अलग-अलग नोड पर ठीक से शुरू हो पाएं और सिंक में बने रहें. भले ही, Edge Microgateway और Apigee Edge के बीच का इंटरनेट कनेक्शन टूट गया हो.

सिंकर, Edge Microgateway का खास तौर पर कॉन्फ़िगर किया गया इंस्टेंस है. इसका सिर्फ़ एक ही मकसद है, Apigee Edge (समय को कॉन्फ़िगर किया जा सकता है) को पोल कराना, कॉन्फ़िगरेशन डेटा को फिर से हासिल करना, और उसे स्थानीय Redis डेटाबेस में लिखना. सिंकर इंस्टेंस, एपीआई प्रॉक्सी ट्रैफ़िक को प्रोसेस नहीं कर सकता. अलग-अलग नोड पर चलने वाले Edge माइक्रोगेटवे के अन्य इंस्टेंस को, Apigee Edge के बजाय, Redis डेटाबेस से कॉन्फ़िगरेशन डेटा पाने के लिए कॉन्फ़िगर किया जा सकता है. सभी माइक्रोगेटवे इंस्टेंस, लोकल डेटाबेस से अपना कॉन्फ़िगरेशन डेटा लेते हैं. इसलिए, इंटरनेट में रुकावट आने पर भी वे एपीआई अनुरोधों को चालू और प्रोसेस कर सकते हैं.

सिंक्रोनर इंस्टेंस को कॉन्फ़िगर करना

एज माइक्रोगेटवे को इंस्टॉल करने के लिए, org-env/config.yaml फ़ाइल में यह कॉन्फ़िगरेशन जोड़ें जिसे आपको सिंकर के तौर पर इस्तेमाल करना है:

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 आपका डेटाबेस पासवर्ड.

आखिर में, कॉन्फ़िगरेशन फ़ाइल सेव करें और Edge Microgateway इंस्टेंस शुरू करें. यह Apigee Edge की पोलिंग शुरू कर देगा और डाउनलोड किए गए कॉन्फ़िगरेशन डेटा को Redis डेटाबेस में सेव करना शुरू कर देगा.

सामान्य Edge माइक्रोगेटवे इंस्टेंस कॉन्फ़िगर करना

सिंकर के चालू होने पर, एपीआई प्रॉक्सी ट्रैफ़िक को प्रोसेस करने वाले सामान्य माइक्रोगेटवे इंस्टेंस चलाने के लिए, अतिरिक्त एज माइक्रोगेटवे नोड कॉन्फ़िगर किए जा सकते हैं. हालांकि, इन इंस्टेंस को Apigee Edge के बजाय, Redis डेटाबेस से उनका कॉन्फ़िगरेशन डेटा पाने के लिए कॉन्फ़िगर किया जा सकता है.

हर अतिरिक्त Edge माइक्रोगेटवे नोड की org-env/config.yaml फ़ाइल में नीचे दिया गया कॉन्फ़िगरेशन जोड़ें. ध्यान दें कि synchronizerMode प्रॉपर्टी को 0 पर सेट किया गया है. यह प्रॉपर्टी, इंस्टेंस को सामान्य एज माइक्रोगेटवे इंस्टेंस के तौर पर ऑपरेट करने के लिए सेट करती है. यह इंस्टेंस एपीआई प्रॉक्सी ट्रैफ़िक को प्रोसेस करता है. साथ ही, इंस्टेंस को 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

अगर 0 (डिफ़ॉल्ट) Edge Microgateway अपने स्टैंडर्ड मोड में काम करता है.

अगर 1 हो, तो सिंकर के तौर पर काम करने के लिए, Edge Microgateway इंस्टेंस शुरू करें. इस मोड में इंस्टेंस, Apigee Edge से कॉन्फ़िगरेशन डेटा लेगा और उसे स्थानीय Redis डेटाबेस में सेव करेगा. यह इंस्टेंस, एपीआई के प्रॉक्सी अनुरोधों को प्रोसेस नहीं कर सकता. इसका सिर्फ़ मकसद कॉन्फ़िगरेशन डेटा के लिए Apigee Edge की जांच करना और उसे स्थानीय डेटाबेस में लिखना है. इसके बाद, आपको डेटाबेस से पढ़ने के लिए अन्य माइक्रोगेटवे इंस्टेंस कॉन्फ़िगर करना होगा.

edge_config.redisBasedConfigCache सही या गलत सही होने पर, Edge Microgateway इंस्टेंस अपने कॉन्फ़िगरेशन डेटा को Apigee Edge के बजाय, Redis डेटाबेस से फ़ेच करता है. Redis डेटाबेस वही होना चाहिए जिसमें सिंकर को लिखने के लिए कॉन्फ़िगर किया गया है. अगर Redis डेटाबेस उपलब्ध नहीं है या डेटाबेस खाली है, तो माइक्रोगेटवे उसके कॉन्फ़िगरेशन के लिए मौजूदा cache-config.yaml फ़ाइल ढूंढता है.

अगर यह डिफ़ॉल्ट तौर पर सेट नहीं है, तो Edge Microgateway इंस्टेंस हमेशा की तरह Apigee Edge से कॉन्फ़िगरेशन डेटा फ़ेच करता है.

edgemicro.config_change_poll_interval समय अंतराल, सेकंड में यह सिंक करने के लिए, Apigee Edge से डेटा फ़ेच करने के लिए, पोलिंग इंटरवल तय करता है.

प्लग इन के लिए बाहर रखे जाने वाले यूआरएल कॉन्फ़िगर करना

आप माइक्रोगेटवे को कॉन्फ़िगर करके यह तय कर सकते हैं कि किसी खास यूआरएल के लिए प्लग इन की प्रोसेसिंग स्किप करनी है या नहीं. आप इन "बाहर रखें" यूआरएल को दुनिया भर में (सभी प्लग इन के लिए) या खास प्लग इन के लिए कॉन्फ़िगर कर सकते हैं.

उदाहरण के लिए:

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