आपको Apigee Edge का दस्तावेज़ दिख रहा है.
Apigee X के दस्तावेज़ पर जाएं. जानकारी
हम अगस्त और सितंबर 2015 के दौरान, Apigee Edge के क्लाउड राऊटर और लोड बैलेंसर को NGINX (इसे "इंजन एक्स" कहा जाता है) पर माइग्रेट कर रहे हैं. NGINX एक ओपन-सोर्स वेब सर्वर है. यह हमारे मौजूदा लोड बैलेंसर और राऊटर की तुलना में, बेहतर परफ़ॉर्म करता है और एक साथ कई अनुरोधों को प्रोसेस कर सकता है.
क्लाउड ग्राहकों पर इसका क्या असर होगा
कुल मिलाकर, इस बदलाव के बारे में आपको पूरी जानकारी होनी चाहिए. साथ ही, आपको यह पुष्टि करने के अलावा कोई और कार्रवाई करने की ज़रूरत नहीं है कि आपके सिस्टम उम्मीद के मुताबिक काम कर रहे हैं. यहां उन चरणों के बारे में बताया गया है जिन्हें हम पूरा करेंगे. साथ ही, अक्सर पूछे जाने वाले कुछ सवालों के जवाब भी दिए गए हैं.
पहला चरण - सॉफ़्टवेयर अपडेट करना
हम सभी राऊटर को NGINX पर आधारित नए राऊटर पर अपग्रेड करेंगे. इसके लिए, हम चरणबद्ध तरीके से डिप्लॉयमेंट करने वाले मॉडल का इस्तेमाल करेंगे. इससे यह पक्का किया जा सकेगा कि इस गतिविधि की वजह से सेवाओं पर कोई असर न पड़े.
चरण 2 - नॉन-प्रोडक्शन एनवायरमेंट में लोड बैलेंसर टियर हटाना
लोड बैलेंसिंग की सुविधा को मैनेज करने के लिए, नए NGINX राउटर का इस्तेमाल किया जाएगा. इसलिए, हम सबसे पहले आपके नॉन-प्रोडक्शन एनवायरमेंट में मौजूद लोड बैलेंसर टियर को हटाने की प्रोसेस शुरू करेंगे. इस चरण के दौरान, प्रोडक्शन लोड बैलेंसर में कोई बदलाव नहीं किया जाएगा. मौजूदा लोड बैलेंसर हटाने से पहले, हम यह पक्का करने के लिए पूरी कोशिश करेंगे कि ट्रैफ़िक उम्मीद के मुताबिक काम कर रहा हो. इस चरण को पूरा करने के लिए, आपको कुछ नहीं करना है. हालांकि, आपको Apigee को किसी भी समस्या के बारे में बताना चाहिए. हम तीसरे चरण को पूरा करने से पहले, आपके साथ मिलकर समस्याओं को हल करेंगे.
तीसरा चरण - प्रोडक्शन एनवायरमेंट में लोड बैलेंसर टियर हटाना
दूसरे चरण के पूरा होने के बाद, हम रखरखाव की अवधि तय करेंगे. इस दौरान, प्रोडक्शन एनवायरमेंट में लोड बैलेंसर टियर को हटाया जाएगा. इसके लिए, दूसरे चरण में बताई गई प्रोसेस का इस्तेमाल किया जाएगा. इससे यह पक्का किया जा सकेगा कि रनटाइम एपीआई ट्रैफ़िक, उम्मीद के मुताबिक काम करता रहे.
प्रॉडक्ट की सुविधाओं में बदलाव
NGINX पर स्विच करने से, प्रॉडक्ट की सुविधाओं में ये बदलाव होंगे.
बहिष्कृत
ProxyEndpoints में अब इन प्रॉपर्टी का इस्तेमाल नहीं किया जा सकता:
- allow.http10
- allow.http11
- allow.http.method.*
- allow.POST.without.content.length
- allow.PUT.without.content.length
इस सुविधा के बंद होने की समस्या को हल करने के लिए, कम्यूनिटी का यह लेख पढ़ें: Proxy Endpoint HTTP allow method properties not working.
अक्सर पूछे जाने वाले सवाल
NGINX पर माइग्रेट करने के बारे में अक्सर पूछे जाने वाले कुछ सवालों के जवाब यहां दिए गए हैं.
पहले चरण के दौरान, जवाब ‘नहीं’ है, क्योंकि हम मौजूदा लोड बैलेंसर में कोई बदलाव नहीं कर रहे हैं. इससे, ट्रैफ़िक दिखाने वाले किसी भी आईपी में सीधे तौर पर कोई बदलाव नहीं होगा. हालांकि, Amazon Web Services (AWS) की लोड बैलेंसिंग सेवा की प्रकृति को देखते हुए, सामान्य स्केलिंग के नियम लागू होते हैं. इसका मतलब है कि स्केलिंग लॉजिक (मौजूदा सुविधा) के तहत आईपी पते बदल सकते हैं. इसलिए, हम Apigee Edge प्रॉडक्ट सुइट के साथ, नॉर्थबाउंड की अनुमति वाली सूची के कॉन्फ़िगरेशन लागू करने का सुझाव नहीं देते. दूसरे और तीसरे चरण के दौरान, लोड बैलेंसर और उससे जुड़े आईपी पतों को हटाने पर, अनुमति वाली सूची पर असर पड़ता है. इसलिए, हम इन चरणों के दौरान आपके साथ मिलकर काम करेंगे, ताकि आपको ऐक्सेस देने के लिए आईपी पतों का नया सेट उपलब्ध कराकर, आसानी से ट्रांज़िशन किया जा सके.
अगर ओरिजन सर्वर, टारगेट एंडपॉइंट सर्वर (प्रॉक्सी बंडल से कॉल किए गए सर्वर) हैं, तो किसी भी बदलाव की ज़रूरत नहीं है. यह बदलाव, Apigee के नॉर्थबाउंड साइड या Apigee में इनग्रेस पॉइंट पर किया गया है.
नहीं. मौजूदा CNAME एंट्री पहले की तरह काम करती रहेंगी.
अगर एसएसएल का इस्तेमाल किया जा रहा है, तो शुरुआती चरण से मौजूदा एसएसएल कॉन्फ़िगरेशन पर कोई असर नहीं पड़ेगा. हालांकि, दूसरे और तीसरे चरण को पूरा करने से पहले, हमें आपके साथ मिलकर काम करना होगा. इससे यह पक्का किया जा सकेगा कि नए राउटर पर एसएसएल सही तरीके से सेट अप किया गया है.
एसएनआई की सुविधा चालू होने की पुष्टि होने तक, दूसरा और तीसरा चरण पूरा नहीं किया जा सकेगा.
हमें किसी भी तरह के डाउनटाइम की उम्मीद नहीं है. बदलावों को लागू करने के लिए, हम मौजूदा रिलीज़ विंडो के दौरान अपने स्टैंडर्ड डिप्लॉयमेंट मॉडल का इस्तेमाल करेंगे.