आपको Apigee Edge का दस्तावेज़ दिख रहा है.
Apigee X के दस्तावेज़ पर जाएं. जानकारी
Edge Microgateway v. 3.3.x
इस विषय में, Edge Microgateway को मैनेज और कॉन्फ़िगर करने का तरीका बताया गया है.
इंटरनेट कनेक्शन होने पर Edge Microgateway को अपग्रेड करना
इस सेक्शन में, Edge Microgateway के मौजूदा इंस्टॉलेशन को अपग्रेड करने का तरीका बताया गया है. अगर इंटरनेट कनेक्शन के बिना काम किया जा रहा है, तो क्या इंटरनेट कनेक्शन के बिना Edge Microgateway इंस्टॉल किया जा सकता है? लेख पढ़ें.
Apigee का सुझाव है कि प्रोडक्शन एनवायरमेंट को अपग्रेड करने से पहले, अपने मौजूदा कॉन्फ़िगरेशन को नए वर्शन के साथ टेस्ट करें.
- Edge
Microgateway के नए वर्शन पर अपग्रेड करने के लिए, यह
npmकमांड चलाएं:npm upgrade edgemicro -g
Edge Microgateway का कोई खास वर्शन इंस्टॉल करने के लिए, आपको इंस्टॉल करने के कमांड में वर्शन नंबर देना होगा. उदाहरण के लिए, 3.2.3 वर्शन इंस्टॉल करने के लिए, इस निर्देश का इस्तेमाल करें:
npm install edgemicro@3.2.3 -g
- वर्शन नंबर देखें। उदाहरण के लिए, अगर आपने 3.2.3 वर्शन इंस्टॉल किया है, तो:
edgemicro --version current nodejs version is v12.5.0 current edgemicro version is 3.2.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 initedgemicro configure [params]edgemicro start [params]
Edge Microgateway के नए इंस्टेंस के लिए डिफ़ॉल्ट कॉन्फ़िगरेशन फ़ाइल
edgemicro init चलाने पर, सिस्टम कॉन्फ़िगरेशन फ़ाइल (ऊपर बताई गई), default.yaml, को ~/.edgemicro डायरेक्ट्री में रखा जाता है.
अगर आपने ~/.edgemicro में कॉन्फ़िगरेशन फ़ाइल में बदलाव किया है, तो आपको Edge Microgateway को फिर से कॉन्फ़िगर करना होगा और उसे रीस्टार्ट करना होगा:
edgemicro stopedgemicro configure [params]edgemicro start [params]
चल रहे इंस्टेंस के लिए डाइनैमिक कॉन्फ़िगरेशन फ़ाइल
edgemicro configure [params] चलाने पर, ~/.edgemicro में एक डाइनैमिक कॉन्फ़िगरेशन फ़ाइल बनती है. फ़ाइल का नाम इस पैटर्न के हिसाब से रखा जाता है: org-env-config.yaml. यहां org और env, आपके Apigee Edge संगठन और एनवायरमेंट के नाम हैं. इस फ़ाइल का इस्तेमाल करके, कॉन्फ़िगरेशन में बदलाव किए जा सकते हैं. इसके बाद, बिना किसी रुकावट के उन्हें फिर से लोड किया जा सकता है. उदाहरण के लिए, अगर आपने कोई प्लगिन जोड़ा और उसे कॉन्फ़िगर किया है, तो बिना किसी रुकावट के कॉन्फ़िगरेशन को फिर से लोड किया जा सकता है. इसके बारे में यहां बताया गया है.
अगर Edge Microgateway चल रहा है (बिना किसी रुकावट के काम करने का विकल्प):
- Edge Microgateway के कॉन्फ़िगरेशन को फिर से लोड करें:
edgemicro reload -o $ORG -e $ENV -k $KEY -s $SECRET
कहां:
- $ORG आपके Edge संगठन का नाम है. इसके लिए, आपको संगठन का एडमिन होना चाहिए.
- $ENV आपके संगठन का एनवायरमेंट है. जैसे, "test" या "prod".
- $KEY वह कुंजी है जिसे कॉन्फ़िगर कमांड ने पहले दिखाया था.
- $SECRET वह कुंजी है जिसे कॉन्फ़िगर कमांड ने पहले दिखाया था.
उदाहरण के लिए
edgemicro reload -o docs -e test -k 701e70ee718ce6dc188...78b6181d000723 \ -s 05c14356e42ed1...4e34ab0cc824
अगर Edge Microgateway बंद है, तो:
- Edge Microgateway को रीस्टार्ट करने के लिए:
edgemicro start -o $ORG -e $ENV -k $KEY -s $SECRET
कहां:
- $ORG आपके Edge संगठन का नाम है. इसके लिए, आपको संगठन का एडमिन होना चाहिए.
- $ENV आपके संगठन का एनवायरमेंट है. जैसे, "test" या "prod".
- $KEY वह कुंजी है जिसे कॉन्फ़िगर कमांड ने पहले दिखाया था.
- $SECRET वह कुंजी है जिसे कॉन्फ़िगर कमांड ने पहले दिखाया था.
उदाहरण के लिए:
edgemicro start -o docs -e test -k 701e70ee718ce...b6181d000723 \ -s 05c1435...e34ab0cc824
यहां कॉन्फ़िगरेशन फ़ाइल का एक उदाहरण दिया गया है. कॉन्फ़िगरेशन फ़ाइल की सेटिंग के बारे में ज़्यादा जानने के लिए, Edge Microgateway कॉन्फ़िगरेशन रेफ़रंस देखें.
edge_config: bootstrap: >- https://edgemicroservices-us-east-1.apigee.net/edgemicro/bootstrap/organization/docs/environment/test jwt_public_key: 'https://docs-test.apigee.net/edgemicro-auth/publicKey' managementUri: 'https://api.enterprise.apigee.com' vaultName: microgateway authUri: 'https://%s-%s.apigee.net/edgemicro-auth' baseUri: >- https://edgemicroservices.apigee.net/edgemicro/%s/organization/%s/environment/%s bootstrapMessage: Please copy the following property to the edge micro agent config keySecretMessage: The following credentials are required to start edge micro products: 'https://docs-test.apigee.net/edgemicro-auth/products' edgemicro: port: 8000 max_connections: 1000 max_connections_hard: 5000 config_change_poll_interval: 600 logging: level: error dir: /var/tmp stats_log_interval: 60 rotate_interval: 24 plugins: sequence: - oauth headers: x-forwarded-for: true x-forwarded-host: true x-request-id: true x-response-time: true via: true oauth: allowNoAuthorization: false allowInvalidAuthorization: false verify_api_key_url: 'https://docs-test.apigee.net/edgemicro-auth/verifyApiKey' analytics: uri: >- https://edgemicroservices-us-east-1.apigee.net/edgemicro/axpublisher/organization/docs/environment/test
एनवायरमेंट वैरिएबल सेट करना
कमांड-लाइन इंटरफ़ेस की उन कमांड के लिए, Edge संगठन और एनवायरमेंट की वैल्यू ज़रूरी होती हैं. साथ ही, Edge Microgateway शुरू करने के लिए ज़रूरी कुंजी और सीक्रेट को इन एनवायरमेंट वैरिएबल में सेव किया जा सकता है:
EDGEMICRO_ORGEDGEMICRO_ENVEDGEMICRO_KEYEDGEMICRO_SECRET
इन वैरिएबल को सेट करना ज़रूरी नहीं है. इन्हें सेट करने पर, Edge Microgateway को कॉन्फ़िगर करने और शुरू करने के लिए कमांड-लाइन इंटरफ़ेस (सीएलआई) का इस्तेमाल करते समय, आपको इनकी वैल्यू तय करने की ज़रूरत नहीं होती.
Edge Microgateway सर्वर पर एसएसएल कॉन्फ़िगर करना
Apigee Edge Microgateway में टीएलएस को कॉन्फ़िगर करने के बारे में जानने के लिए, ये वीडियो देखें:
| वीडियो | ब्यौरा |
|---|---|
| एकतरफ़ा नॉर्थबाउंड टीएलएस कॉन्फ़िगर करना | Apigee Edge Microgateway में टीएलएस को कॉन्फ़िगर करने के बारे में जानें. इस वीडियो में, टीएलएस और इसके महत्व के बारे में खास जानकारी दी गई है. साथ ही, Edge Microgateway में टीएलएस के बारे में बताया गया है. इसमें, नॉर्थबाउंड वन-वे टीएलएस को कॉन्फ़िगर करने का तरीका भी दिखाया गया है. |
| दोनों तरफ़ से नॉर्थबाउंड टीएलएस कॉन्फ़िगर करना | यह Apigee Edge Microgateway में टीएलएस को कॉन्फ़िगर करने के बारे में दूसरा वीडियो है. इस वीडियो में, नॉर्थबाउंड 2-वे टीएलएस को कॉन्फ़िगर करने का तरीका बताया गया है. |
| एकतरफ़ा और दोतरफ़ा साउथबाउंड टीएलएस को कॉन्फ़िगर करना | Apigee Edge Microgateway में टीएलएस को कॉन्फ़िगर करने के बारे में इस तीसरे वीडियो में बताया गया है कि साउथबाउंड 1-वे और 2-वे टीएलएस को कैसे कॉन्फ़िगर किया जाए. |
एसएसएल का इस्तेमाल करने के लिए, Microgateway सर्वर को कॉन्फ़िगर किया जा सकता है. उदाहरण के लिए, एसएसएल कॉन्फ़िगर होने पर, "https" प्रोटोकॉल का इस्तेमाल करके, Edge Microgateway के ज़रिए एपीआई को कॉल किया जा सकता है. जैसे:
https://localhost:8000/myapi
Microgateway सर्वर पर एसएसएल कॉन्फ़िगर करने के लिए, यह तरीका अपनाएं:
- openssl यूटिलिटी या अपनी पसंद के किसी भी तरीके का इस्तेमाल करके, एसएसएल सर्टिफ़िकेट और कुंजी जनरेट करें या पाएं.
- 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
- Edge Microgateway को रीस्टार्ट करें. आपने जिस कॉन्फ़िगरेशन फ़ाइल में बदलाव किया है उसके हिसाब से, कॉन्फ़िगरेशन में बदलाव करना लेख में दिया गया तरीका अपनाएँ. आपने डिफ़ॉल्ट फ़ाइल में बदलाव किया है या रनटाइम कॉन्फ़िगरेशन फ़ाइल में, इसके हिसाब से तरीका अपनाएँ.
यहां कॉन्फ़िगरेशन फ़ाइल के 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 |
इस्तेमाल किया जाने वाला SSL तरीका. उदाहरण के लिए, SSLv3_method का इस्तेमाल करके, एसएसएल को वर्शन 3 पर सेट किया जा सकता है. |
servername |
एसएनआई (सर्वर नेम इंडिकेशन) टीएलएस एक्सटेंशन के लिए सर्वर का नाम. |
requestCert |
दो-तरफ़ा एसएसएल के लिए सही; एक-तरफ़ा एसएसएल के लिए गलत |
क्लाइंट एसएसएल/टीएलएस विकल्पों का इस्तेमाल करना
टारगेट एंडपॉइंट से कनेक्ट करते समय, Edge Microgateway को टीएलएस या एसएसएल क्लाइंट के तौर पर कॉन्फ़िगर किया जा सकता है. Microgateway की कॉन्फ़िगरेशन फ़ाइल में, SSL/TLS के विकल्प सेट करने के लिए, targets एलिमेंट का इस्तेमाल करें. ध्यान दें कि एक से ज़्यादा टारगेट तय किए जा सकते हैं. एक से ज़्यादा टारगेट वाले कैंपेन का उदाहरण यहां दिया गया है.
इस उदाहरण में ऐसी सेटिंग दी गई हैं जो सभी होस्ट पर लागू होंगी:
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यहां टीएलएस का एक उदाहरण दिया गया है:
edgemicro:
...
targets:
- host: 'myserver.example.com'
tls:
client:
pfx: /Users/myname/twowayssl/ssl/client.pfx
passphrase: admin123
rejectUnauthorized: trueअगर आपको टीएलएस/एसएसएल सेटिंग को कई खास टारगेट पर लागू करना है, तो आपको कॉन्फ़िगरेशन में पहले होस्ट को "खाली" के तौर पर सेट करना होगा. इससे सभी अनुरोधों को अनुमति मिल जाती है. इसके बाद, किसी भी क्रम में खास होस्ट सेट करें. इस उदाहरण में, सेटिंग को कई होस्ट पर लागू किया गया है:
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 का इस्तेमाल करके, एसएसएल को वर्शन 3 पर सेट किया जा सकता है. |
servername |
एसएनआई (सर्वर नेम इंडिकेशन) टीएलएस एक्सटेंशन के लिए सर्वर का नाम. |
edgemicro-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
लॉग फ़ाइल की डायरेक्ट्री बदलने के लिए, dir वैल्यू बदलें.
कंसोल को लॉग भेजें
लॉगिंग को इस तरह कॉन्फ़िगर किया जा सकता है कि लॉग की जानकारी, लॉग फ़ाइल के बजाय स्टैंडर्ड आउटपुट को भेजी जाए. to_console फ़्लैग को इस तरह से सही पर सेट करें:
edgemicro:
logging:
to_console: trueइस सेटिंग की मदद से, लॉग को स्टैंडर्ड आउटपुट में भेजा जाएगा. फ़िलहाल, लॉग को stdout और लॉग फ़ाइल, दोनों में नहीं भेजा जा सकता.
लॉगिंग लेवल सेट करने का तरीका
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) यह इंटरवल सेकंड में होता है. इस इंटरवल के बाद, stats रिकॉर्ड को एपीआई लॉग फ़ाइल में लिखा जाता है.
- 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 पर सेट होती है.
इसे v3.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
लॉग फ़ाइल के कॉन्टेंट के बारे में जानकारी
इस वर्शन में जोड़ा गया: v2.3.3
डिफ़ॉल्ट रूप से, लॉगिंग सेवा डाउनलोड की गई प्रॉक्सी, प्रॉडक्ट, और JSON वेब टोकन (JWT) के JSON को शामिल नहीं करती है. अगर आपको इन ऑब्जेक्ट को कंसोल पर आउटपुट करना है, तो Edge Microgateway शुरू करते समय कमांड-लाइन फ़्लैग
DEBUG=* सेट करें. उदाहरण के लिए:
DEBUG=* edgemicro start -o docs -e test -k abc123 -s xyz456
"api" लॉग फ़ाइल का कॉन्टेंट
"api" लॉग फ़ाइल में, Edge Microgateway के ज़रिए अनुरोधों और जवाबों के फ़्लो के बारे में पूरी जानकारी होती है. "api" लॉग फ़ाइलों के नाम इस तरह होते हैं:
edgemicro-mymachine-local-MTQzNjIxOTk0NzY0Nw-api.log
Edge Microgateway को किए गए हर अनुरोध के लिए, "api" लॉग फ़ाइल में चार इवेंट कैप्चर किए जाते हैं:
- क्लाइंट से मिला अनुरोध
- टारगेट को भेजा गया अनुरोध
- टारगेट से मिला जवाब
- क्लाइंट को भेजा गया जवाब
इन अलग-अलग एंट्री में से हर एक को शॉर्टहैंड नोटेशन में दिखाया जाता है, ताकि लॉग फ़ाइलों को ज़्यादा कंपैक्ट बनाया जा सके. यहां चार सैंपल एंट्री दी गई हैं. इनमें से हर एंट्री, चार इवेंट में से किसी एक को दिखाती है. लॉग फ़ाइल में, ये इस तरह दिखते हैं. लाइन नंबर सिर्फ़ दस्तावेज़ में रेफ़रंस के लिए दिए गए हैं. ये लॉग फ़ाइल में नहीं दिखते.
(1) 1436403888651 info req m=GET, u=/, h=localhost:8000, r=::1:59715, i=0 (2) 1436403888665 info treq m=GET, u=/, h=127.0.0.18080, i=0 (3) 1436403888672 info tres s=200, d=7, i=0 (4) 1436403888676 info res s=200, d=11, i=0
आइए, इनके बारे में एक-एक करके जानें:
1. क्लाइंट से मिले अनुरोध का सैंपल:
1436403888651 info req m=GET, u=/, h=localhost:8000, r=::1:59715, i=0
- 1436403888651 - Unix date stamp
- info - लॉगिंग का लेवल. यह वैल्यू, लेन-देन के कॉन्टेक्स्ट और
edgemicroकॉन्फ़िगरेशन में सेट किए गए लॉगिंग लेवल पर निर्भर करती है. लॉगिंग लेवल सेट करने का तरीका देखें. आंकड़ों के रिकॉर्ड के लिए, लेवलstatsपर सेट होता है. आंकड़ों के रिकॉर्ड,stats_log_intervalकॉन्फ़िगरेशन में सेट किए गए नियमित अंतराल पर रिपोर्ट किए जाते हैं. लॉग इंटरवल बदलने का तरीका भी देखें. - req - इस कुकी से इवेंट की पहचान होती है. इस मामले में, क्लाइंट से अनुरोध करें.
- m - अनुरोध में इस्तेमाल किया गया एचटीटीपी वर्ब.
- u - यूआरएल का वह हिस्सा जो बेसपाथ के बाद आता है.
- h - होस्ट और पोर्ट नंबर, जहाँ Edge Microgateway सुन रहा है.
- r - रिमोट होस्ट और पोर्ट, जहां से क्लाइंट का अनुरोध भेजा गया था.
- i - यह अनुरोध आईडी है. इवेंट की चारों एंट्री, इस आईडी को शेयर करेंगी. हर अनुरोध को एक यूनीक अनुरोध आईडी असाइन किया जाता है. अनुरोध आईडी के हिसाब से लॉग रिकॉर्ड को एक-दूसरे से जोड़ने पर, टारगेट की लेटेन्सी के बारे में अहम जानकारी मिल सकती है.
- d - Edge Microgateway को अनुरोध मिलने के बाद से, मिलीसेकंड में अवधि. ऊपर दिए गए उदाहरण में, अनुरोध 0 के लिए टारगेट का जवाब 7 मिलीसेकंड (लाइन 3) के बाद मिला. इसके बाद, जवाब को क्लाइंट को भेजने में 4 मिलीसेकंड (लाइन 4) और लगे. दूसरे शब्दों में कहें, तो अनुरोध में कुल 11 मिलीसेकंड लगे. इसमें से 7 मिलीसेकंड टारगेट ने और 4 मिलीसेकंड Edge Microgateway ने लिए.
2. टारगेट को भेजे गए अनुरोध का सैंपल:
1436403888665 info treq m=GET, u=/, h=127.0.0.1:8080, i=0
- 1436403888651 - Unix date stamp
- info - लॉगिंग का लेवल. यह वैल्यू, लेन-देन के कॉन्टेक्स्ट और
edgemicroकॉन्फ़िगरेशन में सेट किए गए लॉगिंग लेवल पर निर्भर करती है. लॉगिंग लेवल सेट करने का तरीका देखें. आंकड़ों के रिकॉर्ड के लिए, लेवलstatsपर सेट होता है. आंकड़ों के रिकॉर्ड,stats_log_intervalकॉन्फ़िगरेशन में सेट किए गए नियमित अंतराल पर रिपोर्ट किए जाते हैं. लॉग इंटरवल बदलने का तरीका भी देखें. - treq - यह कुकी, इवेंट की पहचान करती है. इस मामले में, अनुरोध को टारगेट करें.
- m - टारगेट अनुरोध में इस्तेमाल किया गया एचटीटीपी वर्ब.
- u - यूआरएल का वह हिस्सा जो बेसपाथ के बाद आता है.
- h - बैकएंड टारगेट का होस्ट और पोर्ट नंबर.
- i - लॉग एंट्री का आईडी. इवेंट की चारों एंट्री, इस आईडी को शेयर करेंगी.
3. टारगेट से मिले रिस्पॉन्स का सैंपल
1436403888672 info tres s=200, d=7, i=0
1436403888651 - Unix date stamp
- info - लॉगिंग का लेवल. यह वैल्यू, लेन-देन के कॉन्टेक्स्ट और
edgemicroकॉन्फ़िगरेशन में सेट किए गए लॉगिंग लेवल पर निर्भर करती है. लॉगिंग लेवल सेट करने का तरीका देखें. आंकड़ों के रिकॉर्ड के लिए, लेवलstatsपर सेट होता है. आंकड़ों के रिकॉर्ड,stats_log_intervalकॉन्फ़िगरेशन में सेट किए गए नियमित अंतराल पर रिपोर्ट किए जाते हैं. लॉग इंटरवल बदलने का तरीका भी देखें. - tres - इससे इवेंट की पहचान होती है. इस मामले में, टारगेट रिस्पॉन्स.
- s - एचटीटीपी रिस्पॉन्स का स्टेटस.
- d - यह अवधि मिलीसेकंड में होती है. टारगेट के ज़रिए एपीआई कॉल में लगा समय.
- i - लॉग एंट्री का आईडी. इवेंट की चारों एंट्री, इस आईडी को शेयर करेंगी.
4. क्लाइंट को भेजे गए जवाब का सैंपल
1436403888676 info res s=200, d=11, i=0
1436403888651 - Unix date stamp
- info - लॉगिंग का लेवल. यह वैल्यू, लेन-देन के कॉन्टेक्स्ट और
edgemicroकॉन्फ़िगरेशन में सेट किए गए लॉगिंग लेवल पर निर्भर करती है. लॉगिंग लेवल सेट करने का तरीका देखें. आंकड़ों के रिकॉर्ड के लिए, लेवलstatsपर सेट होता है. आंकड़ों के रिकॉर्ड,stats_log_intervalकॉन्फ़िगरेशन में सेट किए गए नियमित अंतराल पर रिपोर्ट किए जाते हैं. लॉग इंटरवल बदलने का तरीका भी देखें. - res - इससे इवेंट की पहचान होती है. इस मामले में, क्लाइंट को जवाब दिया जाता है.
- s - एचटीटीपी रिस्पॉन्स का स्टेटस.
- d - यह अवधि मिलीसेकंड में होती है. यह एपीआई कॉल में लगा कुल समय है. इसमें टारगेट एपीआई में लगा समय और Edge Microgateway में लगा समय शामिल है.
- i - लॉग एंट्री का आईडी. इवेंट की चारों एंट्री, इस आईडी को शेयर करेंगी.
लॉग फ़ाइल शेड्यूल करना
लॉग फ़ाइलें, rotate_interval कॉन्फ़िगरेशन एट्रिब्यूट में तय किए गए इंटरवल के हिसाब से रोटेट की जाती हैं. रोटेशन इंटरवल खत्म होने तक, एंट्री उसी लॉग फ़ाइल में जुड़ती रहेंगी. हालांकि, Edge Microgateway को हर बार रीस्टार्ट करने पर, एक नया यूआईडी मिलता है. साथ ही, यह इस यूआईडी के साथ लॉग फ़ाइलों का एक नया सेट बनाता है. लॉग फ़ाइल के रखरखाव के सबसे सही तरीके भी देखें.
गड़बड़ी के मैसेज
कुछ लॉग एंट्री में गड़बड़ी के मैसेज शामिल होंगे. गड़बड़ियां कहां और क्यों होती हैं, यह जानने के लिए Edge Microgateway की गड़बड़ी का रेफ़रंस देखें.
Edge Microgateway के कॉन्फ़िगरेशन का रेफ़रंस
कॉन्फ़िगरेशन फ़ाइल की जगह
इस सेक्शन में बताए गए कॉन्फ़िगरेशन एट्रिब्यूट, Edge Microgateway की कॉन्फ़िगरेशन फ़ाइल में मौजूद होते हैं. कॉन्फ़िगरेशन में बदलाव करना भी देखें.
edge_config एट्रिब्यूट
इन सेटिंग का इस्तेमाल, Edge Microgateway इंस्टेंस और Apigee Edge के बीच इंटरैक्शन को कॉन्फ़िगर करने के लिए किया जाता है.
- bootstrap: (डिफ़ॉल्ट: none) यह एक ऐसा यूआरएल होता है जो Apigee Edge पर चल रही Edge Microgateway की किसी सेवा की ओर ले जाता है. Edge Microgateway, Apigee Edge के साथ कम्यूनिकेट करने के लिए इस सेवा का इस्तेमाल करता है. सार्वजनिक/निजी कुंजी का जोड़ा जनरेट करने के लिए,
edgemicro genkeysकमांड चलाने पर यह यूआरएल मिलता है. ज़्यादा जानकारी के लिए, Edge Microgateway सेट अप करना और कॉन्फ़िगर करना लेख पढ़ें. - jwt_public_key: (डिफ़ॉल्ट: कोई नहीं) यह एक ऐसा यूआरएल होता है जो Apigee Edge पर डिप्लॉय किए गए Edge Microgateway प्रॉक्सी की ओर ले जाता है. यह प्रॉक्सी, क्लाइंट को हस्ताक्षर किए गए ऐक्सेस टोकन जारी करने के लिए, पुष्टि करने वाले एंडपॉइंट के तौर पर काम करती है. यह यूआरएल तब दिखता है, जब प्रॉक्सी को डिप्लॉय करने के लिए यह कमांड दी जाती है: edgemicro configure. ज़्यादा जानकारी के लिए, Edge Microgateway सेट अप करना और कॉन्फ़िगर करना लेख पढ़ें.
- quotaUri: अगर आपको अपने संगठन में डिप्लॉय की गई
edgemicro-authप्रॉक्सी के ज़रिए कोटे मैनेज करने हैं, तो इस कॉन्फ़िगरेशन प्रॉपर्टी को सेट करें. अगर इस प्रॉपर्टी को सेट नहीं किया जाता है, तो कोटा एंडपॉइंट डिफ़ॉल्ट रूप से, Edge Microgateway के इंटरनल एंडपॉइंट पर सेट हो जाता है.edge_config: quotaUri: https://your_org-your_env.apigee.net/edgemicro-auth
edgemicro एट्रिब्यूट
ये सेटिंग, Edge Microgateway प्रोसेस को कॉन्फ़िगर करती हैं.
- port: (डिफ़ॉल्ट: 8000) यह पोर्ट नंबर है जिस पर Edge Microgateway प्रोसेस सिग्नल पाने के लिए कॉन्फ़िगर की जाती है.
- max_connections: (डिफ़ॉल्ट: -1) इससे यह तय होता है कि Edge Microgateway एक साथ ज़्यादा से ज़्यादा कितने इनकमिंग कनेक्शन स्वीकार कर सकता है. अगर यह संख्या
इससे ज़्यादा है, तो यह स्टेटस दिखता है:
res.statusCode = 429; // Too many requests
- max_connections_hard: (डिफ़ॉल्ट: -1) यह एक साथ किए जाने वाले अनुरोधों की वह ज़्यादा से ज़्यादा संख्या होती है जो Edge Microgateway को कनेक्शन बंद करने से पहले मिल सकती है. इस सेटिंग का मकसद, सेवा में रुकावट डालने वाले हमलों को रोकना है. आम तौर पर, इसे max_connections से ज़्यादा पर सेट करें.
-
logging:
-
level: (डिफ़ॉल्ट: error)
- info - (सुझाया गया) यह Edge Microgateway इंस्टेंस से होकर गुज़रने वाले सभी अनुरोधों और जवाबों को लॉग करता है.
- warn - सिर्फ़ चेतावनी वाले मैसेज लॉग करता है.
- error - सिर्फ़ गड़बड़ी के मैसेज लॉग करता है.
- debug - यह विकल्प, जानकारी, चेतावनी, और गड़बड़ी के मैसेज के साथ-साथ डीबग मैसेज भी लॉग करता है.
- trace - यह गड़बड़ियों के लिए ट्रेस की जानकारी को लॉग करता है. साथ ही, जानकारी, चेतावनी, और गड़बड़ी के मैसेज भी लॉग करता है.
- none - लॉग फ़ाइल न बनाएं.
- dir: (डिफ़ॉल्ट: /var/tmp) यह वह डायरेक्ट्री है जहां लॉग फ़ाइलें सेव की जाती हैं.
- stats_log_interval: (डिफ़ॉल्ट: 60) यह इंटरवल सेकंड में होता है. इस इंटरवल के दौरान, आंकड़ों का रिकॉर्ड, एपीआई लॉग फ़ाइल में लिखा जाता है.
- rotate_interval: (डिफ़ॉल्ट: 24) यह वह इंटरवल है जिसमें लॉग फ़ाइलें रोटेट की जाती हैं. यह इंटरवल घंटों में होता है.
-
level: (डिफ़ॉल्ट: error)
- प्लगिन: प्लगिन, Edge Microgateway में सुविधाएं जोड़ते हैं. प्लगिन डेवलप करने के बारे में ज़्यादा जानकारी के लिए, कस्टम प्लगिन डेवलप करना लेख पढ़ें.
- dir: ./gateway डायरेक्ट्री से ./plugins डायरेक्ट्री तक का रिलेटिव पाथ या ऐब्सलूट पाथ.
- sequence: Edge Microgateway के इंस्टेंस में जोड़ने के लिए, प्लगिन मॉड्यूल की सूची. मॉड्यूल, यहां दिए गए क्रम के हिसाब से लागू होंगे.
-
debug: इससे Edge Microgateway प्रोसेस में रिमोट डीबगिंग की सुविधा जुड़ जाती है.
- port: यह वह पोर्ट नंबर है जिस पर सुना जाता है. उदाहरण के लिए, अपने आईडीई डीबगर को इस पोर्ट पर सुनने के लिए सेट करें.
- args: डीबग करने की प्रोसेस के लिए आर्ग्युमेंट. उदाहरण के लिए:
args --nolazy
- config_change_poll_interval: (डिफ़ॉल्ट: 600 सेकंड) Edge Microgateway
समय-समय पर नया कॉन्फ़िगरेशन लोड करता है. अगर कोई बदलाव होता है, तो यह रीलोड करता है. पोलिंग, Edge पर किए गए किसी भी बदलाव (जैसे, प्रॉडक्ट, माइक्रोगेटवे के बारे में जानने वाली प्रॉक्सी वगैरह में बदलाव) के साथ-साथ स्थानीय कॉन्फ़िगरेशन फ़ाइल में किए गए बदलावों को भी चुनती है.
- disable_config_poll_interval: (डिफ़ॉल्ट: false) इसे true पर सेट करके, कॉन्फ़िगरेशन में अपने-आप होने वाले बदलावों की जांच करने की सुविधा को बंद करें.
- request_timeout: यह टारगेट अनुरोधों के लिए टाइम आउट सेट करता है. टाइम आउट को सेकंड में सेट किया जाता है. अगर टाइमआउट होता है, तो Edge Microgateway, 504 स्टेटस कोड के साथ जवाब देता है. (Added v2.4.x)
- keep_alive_timeout: इस प्रॉपर्टी की मदद से, Edge Microgateway के टाइमआउट को सेट किया जा सकता है. यह टाइमआउट मिलीसेकंड में होता है. (डिफ़ॉल्ट: 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: (String) The action to take (allow or deny access) if the
match rule specified in the
accesscontrolplugin is not resolved (is unmatched). मान्य वैल्यू:ALLOWयाDENYडिफ़ॉल्ट:ALLOW(v3.1.7 में जोड़ा गया) - enableAnalytics: (डिफ़ॉल्ट: true) इस एट्रिब्यूट को false पर सेट करें, ताकि
analytics प्लगिन लोड न हो. इस मामले में, Apigee Edge Analytics को कोई कॉल नहीं किया जाएगा. अगर इस एट्रिब्यूट को true पर सेट किया जाता है या इसकी वैल्यू नहीं दी जाती है, तो Analytics प्लगिन सामान्य तरीके से काम करेगा. ज़्यादा जानकारी के लिए, edgemicro एट्रिब्यूट देखें. (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.के साथ लॉग किया जाता हैabortClientRequestEdge Microgateway, अनुरोध को रद्द कर देता है और लॉग फ़ाइलों में एक चेतावनी लिखता है: TargetResponseAborted, जिसमें अनुरोध की स्थिति का कोड 502 होता है.
उदाहरण:
edgemicro: on_target_response_abort: appendErrorToClientResponseBody | abortClientRequest
हेडर एट्रिब्यूट
इन सेटिंग से यह कॉन्फ़िगर किया जाता है कि कुछ एचटीटीपी हेडर को कैसे प्रोसेस किया जाए.
- x-forwarded-for: (डिफ़ॉल्ट: true) इस पैरामीटर की वैल्यू को false पर सेट करें, ताकि x-forwarded-for हेडर को टारगेट पर पास होने से रोका जा सके. ध्यान दें कि अगर अनुरोध में x-forwarded-for हेडर मौजूद है, तो Edge Analytics में इसकी वैल्यू, client-ip वैल्यू पर सेट हो जाएगी.
- x-forwarded-host: (डिफ़ॉल्ट: true) इस वैल्यू को false पर सेट करें, ताकि x-forwarded-host हेडर को टारगेट पर पास होने से रोका जा सके.
- x-request-id: (डिफ़ॉल्ट: सही) इस वैल्यू को गलत पर सेट करें, ताकि x-request-id हेडर को टारगेट पर पास होने से रोका जा सके.
- x-response-time: (डिफ़ॉल्ट: सही) इस हेडर को टारगेट तक पहुंचने से रोकने के लिए, इसे गलत पर सेट करें.
- via: (डिफ़ॉल्ट: true) इसे false पर सेट करें, ताकि via हेडर को टारगेट तक न पहुंचाया जा सके.
OAuth एट्रिब्यूट
इन सेटिंग से यह कॉन्फ़िगर किया जाता है कि Edge Microgateway, क्लाइंट की पुष्टि करने की प्रोसेस को कैसे लागू करता है.
- allowNoAuthorization: (डिफ़ॉल्ट: false) अगर इसे true पर सेट किया जाता है, तो एपीआई कॉल को Edge Microgateway से बिना किसी Authorization हेडर के पास होने की अनुमति होती है. इसे फ़ॉल्स पर सेट करें, ताकि अनुमति हेडर (डिफ़ॉल्ट) की ज़रूरत पड़े.
- allowInvalidAuthorization: (डिफ़ॉल्ट: false) अगर इसे true पर सेट किया जाता है, तो एपीआई कॉल को पास होने की अनुमति दी जाती है. ऐसा तब होता है, जब Authorization हेडर में पास किया गया टोकन अमान्य हो या उसकी समयसीमा खत्म हो गई हो. मान्य टोकन की ज़रूरत होने पर, इसे गलत पर सेट करें (डिफ़ॉल्ट).
- authorization-header: (डिफ़ॉल्ट: Authorization: Bearer) इस हेडर का इस्तेमाल, Edge Microgateway को ऐक्सेस टोकन भेजने के लिए किया जाता है. आपको डिफ़ॉल्ट वैल्यू में बदलाव करने की ज़रूरत तब पड़ सकती है, जब टारगेट को किसी अन्य मकसद के लिए, Authorization हेडर का इस्तेमाल करना हो.
- api-key-header: (डिफ़ॉल्ट: x-api-key) यह हेडर या क्वेरी पैरामीटर का नाम है. इसका इस्तेमाल, Edge Microgateway को एपीआई पासकोड भेजने के लिए किया जाता है. एपीआई पासकोड का इस्तेमाल करना लेख भी पढ़ें.
- keep-authorization-header: (डिफ़ॉल्ट: false) अगर इसे true पर सेट किया जाता है, तो अनुरोध में भेजा गया Authorization हेडर, टारगेट को पास कर दिया जाता है (इसे सुरक्षित रखा जाता है).
- allowOAuthOnly -- अगर इसे सही पर सेट किया जाता है, तो हर एपीआई में Bearer Access Token के साथ Authorization हेडर होना चाहिए. इसकी मदद से, सिर्फ़ OAuth सुरक्षा मॉडल को अनुमति दी जा सकती है. हालांकि, ऐसा करते समय पुराने सिस्टम के साथ काम करने की सुविधा बनी रहती है. (2.4.x में जोड़ा गया)
- allowAPIKeyOnly -- अगर इसे सही पर सेट किया जाता है, तो हर एपीआई में एपीआई पासकोड के साथ x-api-key हेडर (या कस्टम लोकेशन) होना चाहिए. इससे आपको सिर्फ़ एपीआई पासकोड सुरक्षा मॉडल को अनुमति देने में मदद मिलती है. हालांकि, इससे पिछले वर्शन के साथ काम करने की सुविधा पर कोई असर नहीं पड़ता. (2.4.x में जोड़ा गया)
- gracePeriod -- यह पैरामीटर, आपके सिस्टम क्लॉक और JWT ऑथराइज़ेशन टोकन में दिए गए Not Before (nbf) या Issued At (iat) समय के बीच मामूली अंतर की वजह से होने वाली गड़बड़ियों को रोकने में मदद करता है. इस पैरामीटर को सेकंड की उस संख्या पर सेट करें जितने समय तक इस तरह की गड़बड़ियों की अनुमति देनी है. (2.5.7 में जोड़ा गया)
प्लगिन के हिसाब से एट्रिब्यूट
हर प्लगिन के लिए कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट के बारे में जानने के लिए, प्लगिन का इस्तेमाल करना लेख पढ़ें.
प्रॉक्सी फ़िल्टर करना
आपके पास यह फ़िल्टर करने का विकल्प होता है कि Edge Microgateway का कौनसा इंस्टेंस, माइक्रोगेटवे के बारे में जानकारी रखने वाली प्रॉक्सी को प्रोसेस करेगा.
Edge Microgateway शुरू होने पर, यह उस संगठन में मौजूद microgateway-aware प्रॉक्सी को डाउनलोड करता है जिससे यह जुड़ा है. इस कॉन्फ़िगरेशन का इस्तेमाल करके, यह तय करें कि माइक्रोगेटवे किन प्रॉक्सी को प्रोसेस करेगा. उदाहरण के लिए, इस कॉन्फ़िगरेशन में, माइक्रोगेटवे जिन प्रॉक्सी को प्रोसेस करेगा उनकी संख्या तीन तक सीमित कर दी गई है: edgemicro_proxy-1, edgemicro_proxy-2, और edgemicro_proxy-3:
edgemicro: proxies: - edgemicro_proxy-1 - edgemicro_proxy-2 - edgemicro_proxy-3
नाम के हिसाब से प्रॉडक्ट फ़िल्टर करना
Edge Microgateway, एपीआई प्रॉडक्ट की जितनी संख्या डाउनलोड और प्रोसेस करता है उसे सीमित करने के लिए, यहां दिए गए कॉन्फ़िगरेशन का इस्तेमाल करें. डाउनलोड किए गए प्रॉडक्ट को फ़िल्टर करने के लिए, Edge Microgateway *.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":[
]
}
]
}कस्टम एट्रिब्यूट के हिसाब से प्रॉडक्ट फ़िल्टर करना
कस्टम एट्रिब्यूट के आधार पर प्रॉडक्ट फ़िल्टर करने के लिए:
- Edge के यूज़र इंटरफ़ेस (यूआई) में, उस संगठन/एनवायरमेंट में edgemicro_auth प्रॉक्सी चुनें जहां आपने Edge Microgateway कॉन्फ़िगर किया है.
- Develop टैब में, एडिटर में JavaCallout नीति खोलें.
products.filter.attributesकी के साथ एक कस्टम एट्रिब्यूट जोड़ें. इसमें कॉमा लगाकर एट्रिब्यूट के नामों की सूची दी गई हो. सिर्फ़ वे प्रॉडक्ट Edge Microgateway को वापस भेजे जाएंगे जिनमें कस्टम एट्रिब्यूट के नाम शामिल हैं.- आपके पास यह जांच बंद करने का विकल्प होता है कि मौजूदा एनवायरमेंट के लिए प्रॉडक्ट चालू है या नहीं. इसके लिए, कस्टम एट्रिब्यूट
products.filter.env.enableकोfalseपर सेट करें. (डिफ़ॉल्ट रूप से, यह सही पर सेट होता है.) - (सिर्फ़ Private Cloud के लिए) अगर Edge for Private Cloud का इस्तेमाल किया जा रहा है, तो नॉन-सीपीएस एनवायरमेंट के लिए प्रॉडक्ट पाने के लिए, प्रॉपर्टी
org.noncpsकोtrueपर सेट करें.
उदाहरण के लिए:
<?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>निलंबन रद्द करने की स्थिति के हिसाब से प्रॉडक्ट फ़िल्टर करना
एपीआई प्रॉडक्ट के लिए तीन स्टेटस कोड होते हैं - मंज़ूरी बाकी है, मंज़ूरी मिल गई है, और रद्द कर दिया गया है. edgemicro-auth प्रॉक्सी में, Set JWT Variables policy में allowProductStatus नाम की एक नई प्रॉपर्टी जोड़ी गई है. इस प्रॉपर्टी का इस्तेमाल करके, JWT में शामिल एपीआई प्रॉडक्ट को फ़िल्टर करने के लिए:
- Apigee प्रॉक्सी एडिटर में edgemicro-auth प्रॉक्सी खोलें.
- SetJWTVariables नीति के एक्सएमएल में
allowProductStatusप्रॉपर्टी जोड़ें. साथ ही, कॉमा लगाकर अलग किए गए स्टेटस कोड की सूची दें, ताकि उन पर फ़िल्टर किया जा सके. उदाहरण के लिए, लंबित है और रद्द किया गया स्टेटस के हिसाब से फ़िल्टर करने के लिए:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <Javascript timeLimit="20000" async="false" continueOnError="false" enabled="true" name="Set-JWT-Variables"> <DisplayName>Set JWT Variables</DisplayName> <FaultRules/> <Properties> <Property name="allowProductStatus">Pending,Revoked</Property> </Properties> <ResourceURL>jsc://set-jwt-variables.js</ResourceURL> </Javascript>
अगर आपको सिर्फ़ मंज़ूरी पा चुके प्रॉडक्ट दिखाने हैं, तो प्रॉपर्टी को इस तरह सेट करें:
<Property name="allowProductStatus">Approved</Property>
- प्रॉक्सी सेव करें.
अगर Property टैग मौजूद नहीं है, तो सभी स्टेटस कोड वाले प्रॉडक्ट, JWT में लिस्ट किए जाएंगे.
इस नई प्रॉपर्टी का इस्तेमाल करने के लिए, आपको edgemicro-auth प्रॉक्सी को अपग्रेड करना होगा.
Analytics के लिए पुश नोटिफ़िकेशन की फ़्रीक्वेंसी कॉन्फ़िगर करना
इन कॉन्फ़िगरेशन पैरामीटर का इस्तेमाल करके, यह कंट्रोल करें कि Edge Microgateway, Apigee को कितनी बार Analytics डेटा भेजेगा:
- bufferSize (ज़रूरी नहीं): यह Analytics के उन रिकॉर्ड की ज़्यादा से ज़्यादा संख्या होती है जिन्हें बफ़र में सेव किया जा सकता है. इससे ज़्यादा रिकॉर्ड होने पर, सबसे पुराने रिकॉर्ड मिटने लगते हैं. डिफ़ॉल्ट: 10000
- batchSize (ज़रूरी नहीं): Apigee को भेजे गए, Analytics रिकॉर्ड के बैच का ज़्यादा से ज़्यादा साइज़. डिफ़ॉल्ट: 500
- flushInterval (ज़रूरी नहीं): Apigee को भेजे गए आंकड़ों के बैच को फ़्लश करने के बीच मिलीसेकंड की संख्या. डिफ़ॉल्ट: 5000
उदाहरण के लिए:
analytics: bufferSize: 15000 batchSize: 1000 flushInterval: 6000
Analytics डेटा को मास्क करना
नीचे दिए गए कॉन्फ़िगरेशन से, 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 (ज़रूरी नहीं): यह एपीआई प्रॉक्सी का पूरा पाथ बताता है. इसमें प्रॉक्सी बेसपाथ भी शामिल होता है, ताकि इसे आंकड़ों के डैशबोर्ड में अलग किया जा सके. उदाहरण के लिए, अगर आपने
/mocktarget/healthcheckतय किया है, तो/mocktargetप्रॉक्सी बेसपाथ है. साथ ही,/mocktarget/healthcheckपाथ वाले सभी एपीआई कॉल, डैशबोर्ड मेंedgemicro_proxyname-healthके तौर पर दिखेंगे.
उदाहरण के लिए, इस कॉन्फ़िगरेशन में /healthcheck वाला कोई भी एपीआई पाथ, Analytics प्लगिन से अलग किया जाएगा. इसका मतलब है कि /foo/healthcheck और /foo/bar/healthcheck को Analytics डैशबोर्ड में, 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 Microgateway सेट अप करना
Apigee Edge के साथ कम्यूनिकेट करने के लिए, एचटीटीपी प्रॉक्सी का इस्तेमाल करना
इसे वर्शन 3.1.2 में जोड़ा गया है.
Edge Microgateway और Apigee Edge के बीच कम्यूनिकेशन के लिए, एचटीटीपी प्रॉक्सी का इस्तेमाल करने के लिए, यह तरीका अपनाएं:
- एनवायरमेंट वैरिएबल
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 पर जाएं
- Edge Microgateway को रीस्टार्ट करें.
टारगेट से कम्यूनिकेट करने के लिए, एचटीटीपी प्रॉक्सी का इस्तेमाल करना
इसे वर्शन 3.1.2 में जोड़ा गया है.
Edge Microgateway और बैकएंड टारगेट के बीच कम्यूनिकेशन के लिए, एचटीटीपी प्रॉक्सी का इस्तेमाल करने के लिए, यह तरीका अपनाएं:
- माइक्रोगेटवे की कॉन्फ़िगरेशन फ़ाइल में, यह कॉन्फ़िगरेशन जोड़ें:
edgemicro: proxy: tunnel: true | false url: proxy_url bypass: target_host # target hosts to bypass the proxy. enabled: true | falseकहां:
- tunnel: (ज़रूरी नहीं) अगर यह वैल्यू true पर सेट है, तो Edge Microgateway, एचटीटीपी अनुरोधों को टनल करने के लिए एचटीटीपी CONNECT तरीके का इस्तेमाल करता है. ऐसा एक टीसीपी कनेक्शन पर किया जाता है. (अगर प्रॉक्सी को कॉन्फ़िगर करने के लिए, नीचे दिए गए एनवायरमेंट वैरिएबल के लिए टीएलएस चालू है, तो भी ऐसा ही होगा). डिफ़ॉल्ट:
false - url: एचटीटीपी प्रॉक्सी का यूआरएल.
- bypass: (ज़रूरी नहीं) इसमें कॉमा लगाकर अलग किए गए एक या उससे ज़्यादा टारगेट होस्ट यूआरएल दिए जाते हैं. इन यूआरएल को एचटीटीपी प्रॉक्सी को बायपास करना चाहिए. अगर यह प्रॉपर्टी सेट नहीं है, तो NO_PROXY एनवायरमेंट वैरिएबल का इस्तेमाल करके यह बताएं कि किन टारगेट यूआरएल को बायपास करना है.
- enabled: अगर यह वैल्यू सही है और
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 - tunnel: (ज़रूरी नहीं) अगर यह वैल्यू true पर सेट है, तो Edge Microgateway, एचटीटीपी अनुरोधों को टनल करने के लिए एचटीटीपी CONNECT तरीके का इस्तेमाल करता है. ऐसा एक टीसीपी कनेक्शन पर किया जाता है. (अगर प्रॉक्सी को कॉन्फ़िगर करने के लिए, नीचे दिए गए एनवायरमेंट वैरिएबल के लिए टीएलएस चालू है, तो भी ऐसा ही होगा). डिफ़ॉल्ट:
- Edge Microgateway को रीस्टार्ट करें.
Microgateway-aware प्रॉक्सी में वाइल्डकार्ड का इस्तेमाल करना
edgemicro_* (माइक्रोगेटवे के बारे में जानकारी रखने वाली) प्रॉक्सी के बेस पाथ में, एक या उससे ज़्यादा "*" वाइल्डकार्ड इस्तेमाल किए जा सकते हैं. उदाहरण के लिए, /team/*/members के बेस पाथ की मदद से, क्लाइंट https://[host]/team/blue/members और https://[host]/team/green/members को कॉल कर सकते हैं. इसके लिए, आपको नई टीमों के लिए नई एपीआई प्रॉक्सी बनाने की ज़रूरत नहीं होगी. ध्यान दें कि /**/ का इस्तेमाल नहीं किया जा सकता.
अहम जानकारी: Apigee, वाइल्डकार्ड "*" को बेस पाथ के पहले एलिमेंट के तौर पर इस्तेमाल करने की अनुमति नहीं देता. उदाहरण के लिए, /*/ खोज की सुविधा काम नहीं करती.
JWT कुंजियों को रोटेट करना
शुरुआत में JWT जनरेट करने के बाद, आपको Edge के एन्क्रिप्ट (सुरक्षित) किए गए KVM में सेव किए गए सार्वजनिक/निजी पासकोड के जोड़े को बदलना पड़ सकता है. नई कुंजी का जोड़ा जनरेट करने की इस प्रोसेस को कुंजी रोटेशन कहा जाता है.
Edge Microgateway, JWT का इस्तेमाल कैसे करता है
JSON Web Token (JWT) एक टोकन स्टैंडर्ड है. इसके बारे में RFC7519 में बताया गया है. JWT, दावों के सेट पर हस्ताक्षर करने का एक तरीका है. JWT पाने वाला व्यक्ति, इन दावों की पुष्टि भरोसेमंद तरीके से कर सकता है.
सीएलआई का इस्तेमाल करके, JWT जनरेट किया जा सकता है. साथ ही, इसका इस्तेमाल एपीआई पासकोड के बजाय, एपीआई कॉल के Authorization हेडर में किया जा सकता है. उदाहरण के लिए:
curl -i http://localhost:8000/hello -H "Authorization: Bearer eyJhbGciOiJ..dXDefZEA"
सीएलआई की मदद से JWT जनरेट करने के बारे में जानकारी के लिए, टोकन जनरेट करना लेख पढ़ें.
डेटा सुरक्षित करने वाली कुंजी का नया वर्शन बनाना क्या होता है?
शुरुआत में JWT जनरेट करने के बाद, आपको Edge के एन्क्रिप्ट (सुरक्षित) किए गए KVM में सेव किए गए सार्वजनिक/निजी पासकोड के जोड़े को बदलना पड़ सकता है. नई कुंजी का जोड़ा जनरेट करने की इस प्रोसेस को कुंजी रोटेशन कहा जाता है. कुंजियां रोटेट करने पर, निजी/सार्वजनिक कुंजियों का एक नया जोड़ा जनरेट होता है. इसे आपके Apigee Edge संगठन/एनवायरमेंट में "माइक्रोगेटवे" केवीएम में सेव किया जाता है. इसके अलावा, पुरानी सार्वजनिक पासकोड को उसके ओरिजनल पासकोड आईडी वैल्यू के साथ सेव करके रखा जाता है.
JWT जनरेट करने के लिए, Edge एन्क्रिप्ट (सुरक्षित) किए गए KVM में सेव की गई जानकारी का इस्तेमाल करता है. आपने Edge Microgateway को पहली बार सेट अप (कॉन्फ़िगर) करते समय, microgateway नाम का एक KVM बनाया था और उसमें कुंजियां जोड़ी थीं. केवीएम में मौजूद कुंजियों का इस्तेमाल, JWT को साइन और एन्क्रिप्ट करने के लिए किया जाता है.
KVM कुंजियों में ये शामिल हैं:
-
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 की समयसीमा खत्म नहीं हो जाती. यह समयसीमा, token_expiry* इंटरवल के बाद खत्म होती है. डिफ़ॉल्ट रूप से, यह 30 मिनट होती है. इस तरह, एपीआई ट्रैफ़िक में तुरंत रुकावट आए बिना कुंजियों को "रोटेट" किया जा सकता है.
डेटा सुरक्षित करने वाली कुंजी का नया वर्शन बनाने का तरीका
इस सेक्शन में, कुंजी को रोटेट करने का तरीका बताया गया है.
- KVM को अपग्रेड करने के लिए,
edgemicro upgradekvmकमांड का इस्तेमाल करें. इस निर्देश को चलाने के बारे में ज़्यादा जानकारी के लिए, केवीएम को अपग्रेड करना लेख पढ़ें. आपको यह चरण सिर्फ़ एक बार पूरा करना होगा. - edgemicro-oauth प्रॉक्सी को अपग्रेड करने के लिए,
edgemicro upgradeauthकमांड का इस्तेमाल करें. इस निर्देश को चलाने के बारे में ज़्यादा जानने के लिए, edgemicro-auth प्रॉक्सी को अपग्रेड करना लेख पढ़ें. आपको यह चरण सिर्फ़ एक बार पूरा करना होगा. - अपनी
~/.edgemicro/org-env-config.yamlफ़ाइल में यह लाइन जोड़ें. इसमें आपको उसी संगठन और एनवायरमेंट की जानकारी देनी होगी जिसके लिए आपने माइक्रोगेटवे को कॉन्फ़िगर किया है:jwk_public_keys: 'https://$ORG-$ENV.apigee.net/edgemicro-auth/jwkPublicKeys'
कुंजियों को रोटेट करने के लिए, कुंजी रोटेशन कमांड चलाएं. इस कमांड के बारे में ज़्यादा जानने के लिए, रोटेटिंग कुंजियां लेख पढ़ें.
edgemicro rotatekey -o $ORG -e $ENV -k $KEY -s $SECRET
उदाहरण के लिए:
edgemicro rotatekey -o docs -e test \ -k 27ee39567c75e4567a66236cbd4e86d1cc93df6481454301bd5fac4d3497fcbb \ -s 4618b0008a6185d7327ebf53bee3c50282ccf45a3cceb1ed9828bfbcf1148b47
डेटा सुरक्षित करने वाली कुंजी का नया वर्शन बनने के बाद, Edge, Edge Microgateway को कई कुंजियां भेजता है. नीचे दिए गए उदाहरण में ध्यान दें कि हर कुंजी की "kid" (कुंजी आईडी) वैल्यू यूनीक होती है. इसके बाद, माइक्रोगेटवे इन कुंजियों का इस्तेमाल करके, ऑथराइज़ेशन टोकन की पुष्टि करता है. अगर टोकन की पुष्टि नहीं हो पाती है, तो माइक्रोगेटवे यह देखता है कि कुंजी सेट में कोई पुरानी कुंजी है या नहीं. अगर कोई पुरानी कुंजी मौजूद होती है, तो माइक्रोगेटवे उस कुंजी का इस्तेमाल करता है. जवाब में मिली कुंजियों का फ़ॉर्मैट, JSON Web Key (JWK) होता है. इस फ़ॉर्मैट के बारे में RFC 7517 में पढ़ा जा सकता है.
{
"keys": [
{
"kty": "RSA",
"n": "nSl7R_0wKLiWi6cO3n8aOJwYGBtinq723Jgg8i7KKWTSTYoszOjgGsJf_MX4JEW1YCScwpE5o4o8ccQN09iHVTlIhk8CNiMZNPipClmRVjaL_8IWvMQp1iN66qy4ldWXzXnHfivUZZogCkBNqCz7VSC5rw2Jf57pdViULVvVDGwTgf46sYveW_6h8CAGaD0KLd3vZffxIkoJubh0yMy0mQP3aDOeIGf_akeZeZ6GzF7ltbKGd954iNTiKmdm8IKhz6Y3gLpC9iwQ-kex_j0CnO_daHl1coYxUSCIdv4ziWIeM3dmjQ5_2dEvUDIGG6_Az9hTpNgPE5J1tvrOHAmunQ",
"e": "AQAB",
"kid": "2"
},
{
"kty": "RSA",
"n": "8BKwzx34BMUcHwTuQtmp8LFRCMxbkKg_zsWD6eOMIUTAsORexTGJsTy7z-4aH0wJ3fT-3luAAUPLBQwGcuHo0P1JnbtPrpuYjaJKSZOeIMOnlryJCspmv-1xG4qAqQ9XaZ9C97oecuj7MMoNwuaZno5MvsY-oi5B_gqED3vIHUjaWCErd4reONyFSWn047dvpE6mwRhZbcOTkAHT8ZyKkHISzopkFg8CD-Mij12unxA3ldcTV7yaviXgxd3eFSD1_Z4L7ZRsDUukCJkJ-8qY2-GWjewzoxl-mAW9D1tLK6qAdc89yFem3JHRW6L1le3YK37-bs6b2a_AqJKsKm5bWw",
"e": "AQAB",
"kid": "1"
}
]
}"इससे पहले नहीं" के लिए देरी कॉन्फ़िगर करना
3.1.5 और इससे पहले के वर्शन के लिए, rotatekey कमांड से जनरेट की गई नई निजी कुंजी तुरंत लागू हो जाती थी. साथ ही, जनरेट किए गए नए टोकन पर नई निजी कुंजी से हस्ताक्षर किए जाते थे. हालांकि,
माइक्रोगेटवे के कॉन्फ़िगरेशन को रीफ़्रेश करने पर, नई सार्वजनिक कुंजी को Edge Microgateway इंस्टेंस के लिए हर 10 मिनट में (डिफ़ॉल्ट रूप से) उपलब्ध कराया जाता था. टोकन पर हस्ताक्षर करने और माइक्रोगेटवे इंस्टेंस को रीफ़्रेश करने के बीच इस अंतर की वजह से, नई कुंजी से हस्ताक्षर किए गए टोकन तब तक अस्वीकार कर दिए जाएंगे, जब तक सभी इंस्टेंस को सार्वजनिक नई कुंजी नहीं मिल जाती.
जब एक से ज़्यादा माइक्रोगेटवे इंस्टेंस मौजूद होते हैं, तो कभी-कभी सार्वजनिक कुंजी के अपडेट में देरी होने की वजह से, रनटाइम में 403 स्टेटस वाली गड़बड़ियां होती हैं. ऐसा इसलिए होता है, क्योंकि टोकन की पुष्टि एक इंस्टेंस पर हो जाती है, लेकिन दूसरे इंस्टेंस पर तब तक नहीं होती, जब तक सभी इंस्टेंस रीफ़्रेश नहीं हो जाते.
वर्शन 3.1.6 से, rotatekey कमांड पर एक नया फ़्लैग उपलब्ध है. इसकी मदद से, नई निजी कुंजी के लागू होने में देरी की जा सकती है. इससे सभी माइक्रोगेटवे इंस्टेंस को रीफ़्रेश होने और नई सार्वजनिक कुंजी पाने का समय मिल जाता है. नया फ़्लैग --nbf है, जिसका मतलब "इससे पहले नहीं" है.
इस फ़्लैग में पूर्णांक वैल्यू दी जाती है. यह वैल्यू, देरी के मिनटों की संख्या होती है.
यहां दिए गए उदाहरण में, देरी को 15 मिनट पर सेट किया गया है:
edgemicro rotatekey -o docs -e test \ -k 27ee39567c75e4567a66236cbd4e86d1cc93df6481454301bd5fac4d3497fcbb \ -s 4618b0008a6185d7327ebf53bee3c50282ccf45a3cceb1ed9828bfbcf1148b47 \ --nbf 15
ध्यान दें कि डिफ़ॉल्ट रूप से config_change_poll_internal कॉन्फ़िगरेशन सेटिंग 10 मिनट पर सेट होती है. इसलिए, सबसे सही तरीका यह है कि आप डिले को 10 मिनट से ज़्यादा पर सेट करें. edgemicro एट्रिब्यूट भी देखें.
डाउनलोड की गई प्रॉक्सी को फ़िल्टर करना
डिफ़ॉल्ट रूप से, Edge Microgateway आपके Edge संगठन में मौजूद उन सभी प्रॉक्सी को डाउनलोड करता है जिनके नाम "edgemicro_" से शुरू होते हैं. इस डिफ़ॉल्ट सेटिंग को बदलकर, ऐसी प्रॉक्सी डाउनलोड की जा सकती हैं जिनके नाम किसी पैटर्न से मेल खाते हों.
- Edge Micro की कॉन्फ़िगरेशन फ़ाइल खोलें:
~/.edgemicro/org-env-config.yaml - edge_config के तहत proxyPattern एलिमेंट जोड़ें. उदाहरण के लिए, यहां दिया गया पैटर्न edgemicro_foo, edgemicro_fast, और edgemicro_first जैसी प्रॉक्सी डाउनलोड करेगा.
edge_config: … proxyPattern: edgemicro_f*
एपीआई प्रॉक्सी के बिना प्रॉडक्ट तय करना
Apigee Edge में, ऐसा एपीआई प्रॉडक्ट बनाया जा सकता है जिसमें कोई एपीआई प्रॉक्सी शामिल न हो. इस प्रॉडक्ट कॉन्फ़िगरेशन की मदद से, उस प्रॉडक्ट से जुड़ी एपीआई कुंजी को आपकी कंपनी में डिप्लॉय किए गए किसी भी प्रॉक्सी के साथ इस्तेमाल किया जा सकता है. Edge Microgateway के वर्शन 2.5.4 के बाद से, इस प्रॉडक्ट कॉन्फ़िगरेशन का इस्तेमाल किया जा सकता है.
डीबग करना और समस्या हल करना
डीबगर से कनेक्ट किया जा रहा है
Edge Microgateway को node-inspector जैसे डीबगर के साथ चलाया जा सकता है. यह कस्टम प्लगिन की समस्याओं को हल करने और उन्हें डीबग करने के लिए काम आता है.
- 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
- डीबगर शुरू करें और उसे डीबग करने की प्रोसेस के लिए पोर्ट नंबर पर सुनने के लिए सेट करें.
- अब Edge Microgateway कोड को चरण दर चरण देखा जा सकता है. साथ ही, ब्रेकपॉइंट सेट किए जा सकते हैं, एक्सप्रेशन देखे जा सकते हैं वगैरह.
डीबग मोड से जुड़े स्टैंडर्ड Node.js फ़्लैग तय किए जा सकते हैं. उदाहरण के लिए,
--nolazy एसिंक्रोनस कोड को डीबग करने में मदद करता है.
लॉग फ़ाइलों की जांच की जा रही है
अगर आपको कोई समस्या आ रही है, तो पक्का करें कि आपने लॉग फ़ाइलों में, एक्ज़ीक्यूशन की जानकारी और गड़बड़ी की जानकारी देखी हो. ज़्यादा जानकारी के लिए, लॉग फ़ाइलें मैनेज करना लेख पढ़ें.
एपीआई पासकोड की सुरक्षा का इस्तेमाल करना
एपीआई पासकोड, Edge Microgateway से अनुरोध करने वाले क्लाइंट की पुष्टि करने का आसान तरीका है. एपीआई पासकोड पाने के लिए, Apigee Edge प्रॉडक्ट से उपभोक्ता पासकोड (इसे क्लाइंट आईडी भी कहा जाता है) की वैल्यू कॉपी करें. इस प्रॉडक्ट में Edge Microgateway authentication proxy शामिल होती है.
कुंजियों को कैश मेमोरी में सेव करना
एपीआई कुंजियों को बेरर टोकन के लिए बदला जाता है. इन्हें कैश मेमोरी में सेव किया जाता है. 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 कोड मिले.
इस सुविधा को चालू करने के लिए, अपने Edge Microgateway कॉन्फ़िगरेशन में oauth.useUpstreamResponse: true प्रॉपर्टी जोड़ें. उदाहरण के लिए:
oauth: allowNoAuthorization: false allowInvalidAuthorization: false gracePeriod: 10 useUpstreamResponse: true
OAuth2 टोकन की सुरक्षा का इस्तेमाल करना
इस सेक्शन में, OAuth2 ऐक्सेस टोकन और रीफ़्रेश टोकन पाने का तरीका बताया गया है. ऐक्सेस टोकन का इस्तेमाल, माइक्रोगेटवे के ज़रिए सुरक्षित एपीआई कॉल करने के लिए किया जाता है. रिफ़्रेश टोकन का इस्तेमाल, नए ऐक्सेस टोकन पाने के लिए किया जाता है.
ऐक्सेस टोकन पाने का तरीका
इस सेक्शन में, ऐक्सेस टोकन पाने के लिए edgemicro-auth प्रॉक्सी का इस्तेमाल करने का तरीका बताया गया है.
edgemicro token सीएलआई कमांड का इस्तेमाल करके भी ऐक्सेस टोकन पाया जा सकता है.
सीएलआई के बारे में ज़्यादा जानने के लिए, टोकन मैनेज करना लेख पढ़ें.
एपीआई 1: बॉडी पैरामीटर के तौर पर क्रेडेंशियल भेजना
यूआरएल में अपने संगठन और एनवायरमेंट के नाम डालें. साथ ही, Apigee Edge पर डेवलपर ऐप्लिकेशन से मिले Consumer Id और Consumer Secret की वैल्यू को 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 को फ़ॉर्म पैरामीटर के तौर पर भेजें. इस कमांड फ़ॉर्म के बारे में, RFC 6749: The OAuth 2.0 Authorization Framework में भी बताया गया है.
http://<org>-<test>.apigee.net/edgemicro-auth/token -v -u your_client_id:your_client_secret \ -d 'grant_type=client_credentials' -H "Content-Type: application/x-www-form-urlencoded"
आउटपुट का सैंपल
एपीआई, JSON फ़ॉर्मैट में जवाब देता है. ध्यान दें किtoken और access_token प्रॉपर्टी में कोई अंतर नहीं है. इनमें से किसी एक का इस्तेमाल किया जा सकता है. ध्यान दें कि expires_in एक पूर्णांक वैल्यू है, जिसे सेकंड में बताया गया है.
{ "token": "eyJraWQiOiIxIiwidHlwIjoi", "access_token": "eyJraWQiOiIxIiwid", "token_type": "bearer", "expires_in": 1799 }
रीफ़्रेश टोकन पाने का तरीका
रीफ़्रेश टोकन पाने के लिए, edgemicro-auth प्रॉक्सी के /token एंडपॉइंट पर एपीआई कॉल करें. आपको यह एपीआई कॉल, password
ग्रांट टाइप के साथ करना होगा. यहां दी गई प्रोसेस को पूरा करें.
/tokenAPI की मदद से, ऐक्सेस और रीफ़्रेश टोकन पाएं. ध्यान दें कि ग्रांट टाइप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" }- अब रीफ़्रेश टोकन का इस्तेमाल करके, नया ऐक्सेस टोकन पाया जा सकता है. इसके लिए, आपको उसी एपीआई के
/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.
टीसीपी कनेक्शन के डेटा बफ़रिंग की सुविधा बंद करना
Edge Microgateway के ज़रिए इस्तेमाल किए जाने वाले टीसीपी कनेक्शन के लिए, डेटा बफ़रिंग की सुविधा बंद करने के लिए, nodelay कॉन्फ़िगरेशन एट्रिब्यूट का इस्तेमाल किया जा सकता है.
डिफ़ॉल्ट रूप से, टीसीपी कनेक्शन डेटा को बफ़र करने के लिए Nagle एल्गोरिदम का इस्तेमाल करते हैं. इसके बाद, डेटा को भेजा जाता है. nodelay को true पर सेट करने से, यह सुविधा बंद हो जाती है. ऐसा होने पर, socket.write() को कॉल किए जाने पर डेटा तुरंत भेज दिया जाता है. ज़्यादा जानकारी के लिए, Node.js
दस्तावेज़ भी देखें.
nodelay को चालू करने के लिए, Edge Micro की कॉन्फ़िगरेशन फ़ाइल में इस तरह बदलाव करें:
edgemicro:
nodelay: true
port: 8000
max_connections: 1000
config_change_poll_interval: 600
logging:
level: error
dir: /var/tmp
stats_log_interval: 60
rotate_interval: 24
Edge Microgateway को स्टैंडअलोन मोड में चलाना
Edge Microgateway को Apigee Edge से पूरी तरह डिसकनेक्ट करके चलाया जा सकता है. इस स्थिति को स्टैंडअलोन मोड कहा जाता है. इसकी मदद से, इंटरनेट कनेक्शन के बिना Edge Microgateway को चलाया और टेस्ट किया जा सकता है.
स्टैंडअलोन मोड में, ये सुविधाएं काम नहीं करतीं, क्योंकि इनके लिए Apigee Edge से कनेक्शन की ज़रूरत होती है:
- OAuth और एपीआई पासकोड
- कोटा
- Analytics
दूसरी ओर, कस्टम प्लगिन और स्पाइक अरेस्ट की सुविधा सामान्य रूप से काम करती है, क्योंकि इन्हें Apigee Edge से कनेक्ट करने की ज़रूरत नहीं होती. इसके अलावा, extauth नाम का एक नया प्लगिन, स्टैंडअलोन मोड में जेडब्लयूटी की मदद से माइक्रोगेटवे को एपीआई कॉल की अनुमति देने की सुविधा देता है.
गेटवे को कॉन्फ़िगर करना और शुरू करना
Edge Microgateway को स्टैंडअलोन मोड में चलाने के लिए:
- नीचे दिए गए नाम की कॉन्फ़िगरेशन फ़ाइल बनाएं:
$HOME/.edgemicro/$ORG-$ENV-config.yamlउदाहरण के लिए:
vi $HOME/.edgemicro/foo-bar-config.yaml
- इस कोड को फ़ाइल में चिपकाएं:
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 - नीचे दिए गए एनवायरमेंट वैरिएबल को "1" वैल्यू के साथ एक्सपोर्ट करें:
export EDGEMICRO_LOCAL=1
- यहां दी गई
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 प्रॉक्सी के टारगेट का यूआरएल है. (टारगेट वह सेवा है जिसे प्रॉक्सी कॉल करता है.)
- $BASE_PATH, प्रॉक्सी का बेस पाथ है. यह वैल्यू फ़ॉरवर्ड स्लैश से शुरू होनी चाहिए. रूट बेस पाथ के लिए, सिर्फ़ फ़ॉरवर्ड स्लैश डालें. उदाहरण के लिए, "/".
उदाहरण के लिए:
edgemicro start -o local -e test -a proxy1 -v 1 -t http://mocktarget.apigee.net -b /
- कॉन्फ़िगरेशन की जांच करें.
curl http://localhost:8000/echo { "error" : "missing_authorization" }extauthप्लगिन,foo-bar-config.yamlफ़ाइल में है. इसलिए, आपको "missing_authorization" गड़बड़ी का मैसेज दिखता है. यह प्लगिन, ऐसे JWT की पुष्टि करता है जो एपीआई कॉल के Authorization हेडर में मौजूद होना चाहिए. अगले सेक्शन में, आपको एक JWT मिलेगा. इससे एपीआई कॉल बिना किसी गड़बड़ी के पूरे किए जा सकेंगे.
उदाहरण: ऑथराइज़ेशन टोकन पाना
यहां दिए गए उदाहरण में, Apigee Edge (edgemicro-auth/jwkPublicKeys) पर Edge Microgateway JWT एंडपॉइंट से JWT पाने का तरीका बताया गया है.
यह एंडपॉइंट तब डिप्लॉय होता है, जब Edge Microgateway का स्टैंडर्ड सेटअप और कॉन्फ़िगरेशन किया जाता है.
Apigee के एंडपॉइंट से JWT पाने के लिए, आपको पहले Edge Microgateway का स्टैंडर्ड सेटअप करना होगा. साथ ही, आपको इंटरनेट से कनेक्ट करना होगा. यहां Apigee एंडपॉइंट का इस्तेमाल सिर्फ़ उदाहरण के तौर पर किया गया है. इसकी ज़रूरत नहीं है. अगर चाहें, तो किसी दूसरे JWT टोकन एंडपॉइंट का इस्तेमाल किया जा सकता है. अगर ऐसा होता है, तो आपको उस एंडपॉइंट के लिए उपलब्ध कराए गए एपीआई का इस्तेमाल करके, JWT हासिल करना होगा.
edgemicro-auth/jwkPublicKeys एंडपॉइंट का इस्तेमाल करके टोकन पाने का तरीका यहां बताया गया है:.
- Apigee Edge पर अपने संगठन/एनवायरमेंट में
edgemicro-authप्रॉक्सी को डिप्लॉय करने के लिए, आपको Edge Microgateway का स्टैंडर्ड सेटअप और कॉन्फ़िगरेशन करना होगा. अगर आपने यह चरण पहले ही पूरा कर लिया है, तो इसे दोबारा करने की ज़रूरत नहीं है. - अगर आपने Edge Microgateway को Apigee Cloud पर डिप्लॉय किया है, तो आपको इंटरनेट से कनेक्ट होना होगा. इससे आपको इस एंडपॉइंट से JWT मिल पाएगा.
-
Edge Microgateway को बंद करने के लिए:
edgemicro stop
- आपने पहले जो कॉन्फ़िगरेशन फ़ाइल बनाई थी (
$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'
-
Edge Microgateway को पहले की तरह फिर से शुरू करें. इसके लिए, कॉन्फ़िगरेशन फ़ाइल के नाम में इस्तेमाल किए गए संगठन/एनवायरमेंट के नामों का इस्तेमाल करें. उदाहरण के लिए:
edgemicro start -o foo -e bar -a proxy1 -v 1 -t http://mocktarget.apigee.net -b /
-
ऑथराइज़ेशन एंडपॉइंट से JWT टोकन पाएं.
edgemicro-auth/jwkPublicKeysएंडपॉइंट का इस्तेमाल करने पर, इस सीएलआई कमांड का इस्तेमाल किया जा सकता है:
edgemicro token कमांड या एपीआई का इस्तेमाल करके, Edge Microgateway के लिए JWT जनरेट किया जा सकता है. उदाहरण के लिए:
edgemicro token get -o your_org -e your_env \ -i G0IAeU864EtBo99NvUbn6Z4CBwVcS2 -s uzHTbwNWvoSmOy
कहां:
- your_org आपके Apigee संगठन का नाम है. इसके लिए, आपने पहले Edge Microgateway कॉन्फ़िगर किया था.
- your_env, संगठन में मौजूद एक एनवायरमेंट है.
iविकल्प, डेवलपर के उस ऐप्लिकेशन की उपभोक्ता कुंजी के बारे में बताता है जिसमें ऐसा प्रॉडक्ट शामिल है जिसमेंedgemicro-authप्रॉक्सी शामिल है.sविकल्प, डेवलपर के ऐसे ऐप्लिकेशन का Consumer Secret तय करता है जिसमें ऐसा प्रॉडक्ट शामिल होता है जिसमें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 पर microgateway-aware प्रॉक्सी को डिप्लॉय करने की ज़रूरत नहीं होती है. इसके बजाय, माइक्रोगेटवे शुरू करते समय, लोकल प्रॉक्सी का नाम, बेसपाथ, और टारगेट यूआरएल देकर "लोकल प्रॉक्सी" कॉन्फ़िगर की जाती है. इसके बाद, माइक्रोगेटवे को किए गए एपीआई कॉल, लोकल प्रॉक्सी के टारगेट यूआरएल पर भेजे जाते हैं. अन्य सभी मामलों में, लोकल प्रॉक्सी मोड ठीक उसी तरह काम करता है जैसे Edge Microgateway सामान्य मोड में काम करता है. पुष्टि करने की प्रोसेस एक जैसी होती है. साथ ही, स्पाइक अरेस्ट और कोटा लागू करने की प्रोसेस, कस्टम प्लगिन वगैरह भी एक जैसी होती हैं.
इस्तेमाल का उदाहरण
लोकल प्रॉक्सी मोड तब काम आता है, जब आपको सिर्फ़ एक प्रॉक्सी को Edge Microgateway इंस्टेंस से जोड़ना हो. उदाहरण के लिए, Edge Microgateway को Kubernetes में साइडकार प्रॉक्सी के तौर पर इंजेक्ट किया जा सकता है. इसमें एक माइक्रोगेटवे और एक सेवा, दोनों एक ही पॉड में चलती हैं. साथ ही, माइक्रोगेटवे अपनी कंपैनियन सेवा से आने-जाने वाले ट्रैफ़िक को मैनेज करता है. इस इमेज में, आर्किटेक्चर दिखाया गया है. इसमें Edge Microgateway, Kubernetes क्लस्टर में साइडकार प्रॉक्सी के तौर पर काम करता है. हर माइक्रोगेटवे इंस्टेंस, कंपैनियन सेवा के सिर्फ़ एक एंडपॉइंट से कम्यूनिकेट करता है:

इस तरह के आर्किटेक्चर का एक फ़ायदा यह है कि Edge Microgateway, कंटेनर एनवायरमेंट में डिप्लॉय की गई अलग-अलग सेवाओं के लिए एपीआई मैनेजमेंट की सुविधा देता है. जैसे, Kubernetes क्लस्टर.
लोकल प्रॉक्सी मोड कॉन्फ़िगर करना
Edge Microgateway को लोकल प्रॉक्सी मोड में चलाने के लिए, यह तरीका अपनाएं:
edgemicro initचलाकर, अपना लोकल कॉन्फ़िगरेशन एनवायरमेंट सेट अप करें. यह ठीक उसी तरह से किया जाता है जैसे Edge Microgateway के सामान्य सेटअप में किया जाता है. यह भी देखें Edge Microgateway को कॉन्फ़िगर करना.edgemicro configureचलाएं. इसे Edge Microgateway के सामान्य सेटअप की प्रक्रिया में चलाया जाता है. उदाहरण के लिए:edgemicro configure -o your_org -e your_env -u your_apigee_username
यह कमांड, Edge पर edgemicro-auth नीति को डिप्लॉय करती है. साथ ही, एक कुंजी और सीक्रेट वापस भेजती है. आपको माइक्रोगेटवे शुरू करने के लिए इनकी ज़रूरत होगी. अगर आपको मदद चाहिए, तो Edge Microgateway कॉन्फ़िगर करना लेख पढ़ें.
- Apigee Edge पर, एक एपीआई प्रॉडक्ट बनाएं. साथ ही, यहां दी गई ज़रूरी कॉन्फ़िगरेशन की शर्तों को पूरा करें. हालांकि, अन्य सभी कॉन्फ़िगरेशन को अपनी ज़रूरत के हिसाब से मैनेज किया जा सकता है:
- आपको प्रॉडक्ट में edgemicro-auth प्रॉक्सी को जोड़ना होगा.
edgemicro configureचलाने पर, यह प्रॉक्सी अपने-आप डिप्लॉय हो गई थी. - आपको संसाधन का पाथ ज़रूर देना होगा. Apigee, इस पाथ को प्रॉडक्ट में जोड़ने का सुझाव देता है:
/**. ज़्यादा जानने के लिए, संसाधन के पाथ के व्यवहार को कॉन्फ़िगर करना लेख पढ़ें. Edge के दस्तावेज़ में, एपीआई प्रॉडक्ट बनाना भी देखें.
- आपको प्रॉडक्ट में edgemicro-auth प्रॉक्सी को जोड़ना होगा.
Apigee Edge पर, एक डेवलपर बनाएं. इसके अलावा, अगर चाहें, तो किसी मौजूदा डेवलपर का इस्तेमाल भी किया जा सकता है. मदद पाने के लिए, Edge मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल करके डेवलपर जोड़ना लेख पढ़ें.
- Apigee Edge पर, डेवलपर ऐप्लिकेशन बनाएं. आपको अभी बनाए गए एपीआई प्रॉडक्ट को ऐप्लिकेशन में जोड़ना ज़रूरी है. मदद पाने के लिए, Edge मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) में ऐप्लिकेशन रजिस्टर करना लेख पढ़ें.
- जिस मशीन पर Edge Microgateway इंस्टॉल किया गया है उस पर, नीचे दिए गए एनवायरमेंट वैरिएबल को "1" वैल्यू के साथ एक्सपोर्ट करें.
export EDGEMICRO_LOCAL_PROXY=1
- यह
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 UI में ऐप्लिकेशन खोलें, उपभोक्ता कुंजी कॉपी करें, और इस कुंजी का इस्तेमाल इस तरह करें:
curl http://localhost:8000/echo -H 'x-api-key:your_api_key'
उदाहरण के लिए:
curl http://localhost:8000/echo -H "x-api-key:DvUdLlFwG9AvGGpEgfnNGwtvaXIlUUvP"
आउटपुट का उदाहरण:
{
"headers":{
"user-agent":"curl/7.54.0",
"accept":"*/*",
"x-api-key":"DvUdLlFwG9AvGGpEgfnNGwtvaXIlUUvP",
"client_received_start_timestamp":"1535134472699",
"x-authorization-claims":"eyJhdWQiOi...TQ0YmUtOWNlOS05YzM1OTE5MTA1NDkifQ==",
"target_sent_start_timestamp":"1535134472702",
"x-request-id":"678e3080-a7ae-11e8-a70f-87ae30db3896.8cc81cb0-a7c9-11e8-a70f-87ae30db3896",
"x-forwarded-proto":"http",
"x-forwarded-host":"localhost:8000",
"host":"mocktarget.apigee.net",
"x-cloud-trace-context":"e2ac4fa0112c2d76237e5473714f1c85/1746478453618419513",
"via":"1.1 localhost, 1.1 google",
"x-forwarded-for":"::1, 216.98.205.223, 35.227.194.212",
"connection":"Keep-Alive"
},
"method":"GET",
"url":"/",
"body":""
}सिंक्रनाइज़र का इस्तेमाल करना
इस सेक्शन में, सिंक्रनाइज़र का इस्तेमाल करने का तरीका बताया गया है. यह एक वैकल्पिक सुविधा है. इससे Edge Microgateway की विश्वसनीयता बढ़ती है. ऐसा इसलिए होता है, क्योंकि यह Apigee Edge से कॉन्फ़िगरेशन डेटा को वापस पाने और उसे स्थानीय Redis डेटाबेस में लिखने की अनुमति देता है. सिंक्रनाइज़र इंस्टेंस चालू होने पर, अलग-अलग नोड पर चल रहे अन्य Edge Microgateway इंस्टेंस, इस डेटाबेस से सीधे तौर पर अपना कॉन्फ़िगरेशन वापस पा सकते हैं.
फ़िलहाल, सिंक्रनाइज़र की सुविधा Redis 5.0.x के साथ काम करती है.
सिंक्रनाइज़र क्या होता है?
सिंक्रनाइज़र, Edge Microgateway के लिए एक लेवल की सुरक्षा उपलब्ध कराता है. इससे यह पक्का करने में मदद मिलती है कि Edge Microgateway का हर इंस्टेंस एक ही कॉन्फ़िगरेशन का इस्तेमाल करे. साथ ही, इंटरनेट में रुकावट आने पर, Edge Microgateway के इंस्टेंस सही तरीके से शुरू हो सकें और काम कर सकें.
डिफ़ॉल्ट रूप से, Edge Microgateway इंस्टेंस को Apigee Edge के साथ कम्यूनिकेट करना होगा, ताकि वे अपने कॉन्फ़िगरेशन डेटा को वापस पा सकें और उसे रीफ़्रेश कर सकें. जैसे, एपीआई प्रॉक्सी और एपीआई प्रॉडक्ट कॉन्फ़िगरेशन. अगर Edge से इंटरनेट कनेक्शन में रुकावट आती है, तो माइक्रोगेटवे इंस्टेंस काम करना जारी रख सकते हैं. ऐसा इसलिए होता है, क्योंकि कॉन्फ़िगरेशन का नया डेटा कैश मेमोरी में सेव होता है. हालांकि, नए माइक्रोगेटवे इंस्टेंस, कनेक्शन के बिना शुरू नहीं हो सकते. इसके अलावा, इंटरनेट में रुकावट आने की वजह से, एक या उससे ज़्यादा माइक्रोगेटवे इंस्टेंस ऐसे कॉन्फ़िगरेशन के साथ चल सकते हैं जिनकी जानकारी अन्य इंस्टेंस के साथ सिंक नहीं होती.
Edge Microgateway सिंक्रनाइज़र, Edge Microgateway इंस्टेंस के लिए कॉन्फ़िगरेशन डेटा पाने का एक वैकल्पिक तरीका उपलब्ध कराता है. इस डेटा की ज़रूरत, Edge Microgateway इंस्टेंस को शुरू होने और एपीआई प्रॉक्सी ट्रैफ़िक को प्रोसेस करने के लिए होती है.
Apigee Edge को किए गए कॉल से वापस लाए गए कॉन्फ़िगरेशन डेटा में ये शामिल हैं: jwk_public_keys कॉल,
jwt_public_key कॉल, बूटस्ट्रैप कॉल, और एपीआई प्रॉडक्ट कॉल.
सिंक्रनाइज़र की मदद से, अलग-अलग नोड पर चल रहे Edge Microgateway के सभी इंस्टेंस सही तरीके से शुरू हो पाते हैं. साथ ही, Edge Microgateway और Apigee Edge के बीच इंटरनेट कनेक्शन में रुकावट आने पर भी, वे सिंक में बने रहते हैं.
सिंक्रनाइज़र, Edge Microgateway का खास तौर पर कॉन्फ़िगर किया गया इंस्टेंस होता है. इसका मकसद सिर्फ़ Apigee Edge को पोल करना है. इसके लिए, समय को कॉन्फ़िगर किया जा सकता है. साथ ही, कॉन्फ़िगरेशन डेटा को वापस पाना और उसे स्थानीय Redis डेटाबेस में लिखना है. सिंक्रनाइज़र इंस्टेंस, एपीआई प्रॉक्सी ट्रैफ़िक को प्रोसेस नहीं कर सकता. अलग-अलग नोड पर चल रहे Edge Microgateway के अन्य इंस्टेंस को, Apigee Edge के बजाय Redis डेटाबेस से कॉन्फ़िगरेशन डेटा पाने के लिए कॉन्फ़िगर किया जा सकता है. सभी माइक्रोगेटवे इंस्टेंस, कॉन्फ़िगरेशन डेटा को लोकल डेटाबेस से पुल करते हैं. इसलिए, इंटरनेट कनेक्शन न होने पर भी ये इंस्टेंस चालू हो सकते हैं और एपीआई अनुरोधों को प्रोसेस कर सकते हैं.
सिंक्रनाइज़र इंस्टेंस को कॉन्फ़िगर करना
आपको Edge Microgateway के जिस इंस्टॉलेशन को सिंक्रनाइज़र के तौर पर इस्तेमाल करना है उसके लिए, 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 Microgateway के सामान्य इंस्टेंस कॉन्फ़िगर करना
सिंक्रनाइज़र के चालू होने पर, एपीआई प्रॉक्सी ट्रैफ़िक को प्रोसेस करने वाले सामान्य माइक्रोगेटवे इंस्टेंस चलाने के लिए, Edge Microgateway के अतिरिक्त नोड कॉन्फ़िगर किए जा सकते हैं. हालांकि, इन इंस्टेंस को इस तरह कॉन्फ़िगर किया जाता है कि ये Apigee Edge के बजाय Redis डेटाबेस से कॉन्फ़िगरेशन डेटा पाएं.
हर अतिरिक्त Edge Microgateway नोड की org-env/config.yaml फ़ाइल में, यह कॉन्फ़िगरेशन जोड़ें. ध्यान दें कि synchronizerMode प्रॉपर्टी को 0 पर सेट किया गया है. यह प्रॉपर्टी, इंस्टेंस को सामान्य Edge Microgateway इंस्टेंस के तौर पर काम करने के लिए सेट करती है. यह इंस्टेंस, एपीआई प्रॉक्सी ट्रैफ़िक को प्रोसेस करता है. साथ ही, इंस्टेंस को अपना कॉन्फ़िगरेशन डेटा, Redis डेटाबेस से मिलेगा.
edgemicro: redisHost: host_IP redisPort: host_port redisDb: database_index redisPassword: password edge_config: synchronizerMode: 0 redisBasedConfigCache: true
उदाहरण के लिए:
edgemicro: redisHost: 192.168.4.77 redisPort: 6379 redisDb: 0 redisPassword: codemaster edge_config: synchronizerMode: 0 redisBasedConfigCache: true
कॉन्फ़िगरेशन प्रॉपर्टी
सिंक्रनाइज़र का इस्तेमाल करने के लिए, कॉन्फ़िगरेशन की ये प्रॉपर्टी जोड़ी गई हैं:
| एट्रिब्यूट | वैल्यू | ब्यौरा |
|---|---|---|
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 फ़ाइल ढूंढता है.
अगर यह वैल्यू false (डिफ़ॉल्ट) पर सेट है, तो 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 पाथ वाले, एपीआई प्रॉक्सी कॉल को प्रोसेस नहीं करेंगे. इसके अलावा, जिन एपीआई के पाथ में /hello/xml मौजूद है उनके लिए json2xml प्लगिन को स्किप कर दिया जाएगा.
एनवायरमेंट वैरिएबल की वैल्यू के साथ कॉन्फ़िगरेशन एट्रिब्यूट सेट करना
कॉन्फ़िगरेशन फ़ाइल में टैग का इस्तेमाल करके, एनवायरमेंट वैरिएबल तय किए जा सकते हैं. दिए गए एनवायरमेंट वैरिएबल टैग को, एनवायरमेंट वैरिएबल की असली वैल्यू से बदल दिया जाता है. बदलावों को सिर्फ़ मेमोरी में सेव किया जाता है. इन्हें ओरिजनल कॉन्फ़िगरेशन या कैश मेमोरी फ़ाइलों में सेव नहीं किया जाता.
इस उदाहरण में, एट्रिब्यूट 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>