बेसिक रिवर्स प्रॉक्सी सेटअप में केवल तीन निर्णयों की आवश्यकता होती है, और यह गाइड प्रत्येक में सहायता प्रदान करती है: होस्ट नाम, पथ और बैकएंड। एक HTTP प्रॉक्सी खोज अग्र या पश्च प्रॉक्सी हो सकती है, और यहाँ आप उस सर्वर की योजना बनाते हैं और जाँचते हैं जिसे आप स्वयं चलाते हैं। एजेंट कभी भी यह निर्णय नहीं लेता कि कौन सा होस्ट या पथ सही है। यह वही लिखता है जिसे आप माँगते हैं, प्रत्येक परिवर्तन को diff के रूप में दिखाता है, और प्रत्येक कमांड के वास्तविक परिणाम की रिपोर्ट करता है, ताकि आप अगले निर्णय से पहले प्रत्येक निर्णय के प्रभाव को देख सकें। नीचे दिए गए चार चरणों को क्रम से पूरा करें, और रूटिंग योजना को उस दस्तावेज़ के रूप में मानें जिसका पालन आप और एजेंट दोनों पहले कमांड से लेकर अंतिम अनुरोध तक करते हैं।
Segment Route शुरू करें और उस कार्य फ़ोल्डर को खोलें जिसमें आपकी कॉन्फ़िगरेशन और रूट फ़ाइलें हैं। फ़ाइल टूल्स इसी फ़ोल्डर में काम करते हैं, इसलिए एक स्वच्छ फ़ोल्डर जिसमें केवल उस डोमेन के लिए महत्वपूर्ण फ़ाइलें हों, diff को छोटा रखता है और खोज परिणामों को पठनीय बनाता है। यदि आपकी लाइव फ़ाइलें एक सर्वर पर हैं जिसे आप स्वयं चलाते हैं, तो उन्हें पहले फ़ोल्डर में कॉपी करें, या कमांड्स के लिए SSH वातावरण चुनें और योजना फ़ोल्डर में रखें।
एजेंट से routing-plan.txt लिखने के लिए कहें जिसमें आपके रूट, आपके रीडायरेक्ट और प्रत्येक के लिए आपकी अपेक्षित स्थिति कोड हो। योजना सादा पाठ है, आप इसे संपादित कर सकते हैं, और यह वह सूची है जिसके साथ आप अंत में वास्तविक परिणामों की तुलना करते हैं। प्रत्येक रूट और प्रत्येक रीडायरेक्ट के लिए एक अपेक्षा निर्दिष्ट करें, ताकि कोई भी नियम जाँच से बचा न रहे। फ़ाइल को छोटा और पठनीय रखें।
प्रत्येक नियम के लिए diff को स्वीकार करें, फिर किसी भी रीलोड से पहले Shell को अपनी कॉन्फ़िगरेशन टेस्ट कमांड चलाने दें। Ask first मोड में एजेंट प्रत्येक परिवर्तन से पहले रुक जाता है, और टेस्ट के लिए कार्ड वास्तविक एग्जिट कोड और पूर्ण आउटपुट दिखाता है। टेस्ट पास होने से पहले कभी रीलोड न करें, और नए व्यवहार की पुष्टि होने तक पिछली फ़ाइल का बैकअप रखें।
प्रत्येक पते पर अनुरोध करें, स्थिति कोड और Location हेडर पढ़ें, और उन्हें अपनी योजना से तुलना करें। यदि कोई मान भिन्न है, तो बैकअप पुनर्स्थापित करें, रीलोड करें, और एक नियम फिर से बदलें। तब तक दोहराएँ जब तक योजना में प्रत्येक अपेक्षा परिणाम से मेल न खाए जाए, फिर अंतिम योजना को इस रिकॉर्ड के रूप में रखें कि कॉन्फ़िगरेशन क्या करना चाहिए।
.3 फ़ाइलेंroutes.confलोड किया गयाrouting-plan.txtसहेजा गयाyour request commandरिकॉर्ड किया गया# routing plan for my own domain
# one line per rule, written before any change
route 1: host app, path /api, goes to service api
route 2: host app, path /, goes to service web
route 3: host admin, path /, goes to service admin
redirect 1: old page to new page, code 301
redirect 2: www host to bare host, code 301
redirect 3: http to https, code 301
# status to expect after the change
expect 1: app path /api answers with a success code
expect 2: old page answers 301 and gives the new address
# keep the old configuration file as a backup
# end of routing planप्रत्येक पंक्ति एक नियम या एक अपेक्षा है। पहले लिखी गई योजना आपको हर परिवर्तन के बाद वास्तविक स्थिति कोड की तुलना के लिए कुछ देती है, और एक परिवर्तन जो अपेक्षा को तोड़ता है, उसे आसानी से देखा जा सकता है। होस्ट, पथ और सेवाएँ केवल उदाहरण हैं; इन्हें अपने स्वयं के डोमेन के लिए बदलें, और योजना को उस कॉन्फ़िगरेशन के पास रखें जिसका वर्णन वह करती है। कोड के साथ शब्द redirect एजेंट को यह समझने के लिए पर्याप्त है कि क्या लिखना है।
इस स्व-होस्टिंग गाइड में, आपके सेवाओं के सामने एक रिवर्स प्रॉक्सी सर्वर के साथ, नियम कहाँ रहते हैं, यह खोजने से शुरू होता है। list_dir कार्य फ़ोल्डर दिखाता है, glob उन फ़ाइलों की सूची बनाता है जो रूट सूचियों जैसी दिखती हैं, और grep उनमें route और redirect शब्दों के लिए खोजता है। परिणाम फ़ाइल नाम और पंक्ति संख्याओं के साथ एक छोटी सूची है। अभी कुछ बदलता नहीं है। उस फ़ाइल को चुनें जिसमें आपके स्वयं के डोमेन के लिए नियम हैं, read_file से उसे खोलें, और वर्तमान स्थिति कोड को नोट करने के लिए प्रत्येक पते पर अनुरोध करें। यदि आप चाहते हैं कि एजेंट पहले काम के क्रम का प्रस्ताव दे, तो Plan only मोड में योजना की समीक्षा करें, और नोट्स को अपनी रूटिंग योजना के पास सहेजें ताकि पहली स्थिति कोड रिकॉर्ड में हों।
एक समय में एक नियम बदलें, क्योंकि एक छोटा diff आसानी से निर्णय लिया जा सकता है। edit_file फ़ाइल पढ़ता है, नई पंक्ति का प्रस्ताव रखता है और जुड़ी और हटाई गई पंक्तियों के साथ एक diff दिखाता है। जब एक सबडोमेन रीडायरेक्ट नियम के बारे में प्रश्न आता है, तो एजेंट नियम को उस कोड के साथ दिखाता है जिसे उसे लौटना चाहिए, और आप निर्णय लेते हैं। Ask first मोड में, जब तक आप स्वीकार न करें, कुछ भी सहेजा नहीं जाता। Auto-run तुरंत सहेज देगा, इसलिए इसे केवल उन फ़ाइलों पर उपयोग करें जिन्हें आप पुनर्स्थापित कर सकते हैं। पुरानी फ़ाइल को बैकअप के रूप में रखें, diff को स्वीकार करें, और अगले चरण पर जाएं। यदि एक पंक्ति आपको हैरान करती है, तो diff को अस्वीकार करें, और एक छोटे परिवर्तन के लिए कहें।
एक टूटी फ़ाइल के साथ रीलोड एक काम करने वाली साइट को नीचे ला सकता है, इसलिए पहले परीक्षण करें। Shell आपकी कॉन्फ़िगरेशन टेस्ट कमांड चलाता है, और सफलता वास्तविक एग्जिट कोड द्वारा निर्धारित की जाती है: एक पास कोड का मतलब है कि फ़ाइल पार्स हो गई, कुछ भी अन्य का मतलब है कि आप पुरानी कॉन्फ़िगरेशन पर रहेंगे। कार्ड पूर्ण आउटपुट तक विस्तारित होता है, जिसमें त्रुटि की पंक्ति संख्या भी शामिल है। इसे एक और छोटे diff से ठीक करें। एक पास टेस्ट के बाद, रीलोड करें, पते पर फिर से अनुरोध करें और पुरानी और नई रन के HTTP स्थिति कोड की तुलना करें। आउटपुट की स्वयं समीक्षा करें, क्योंकि एक पास टेस्ट केवल यह कहता है कि सिंटैक्स वैध है और यह नहीं कि रूट सही है।
स्थिति कोड उनके पहले अंक के आधार पर समूहीकृत होते हैं: 2xx सफलता, 3xx रीडायरेक्ट, 4xx क्लाइंट त्रुटि, 5xx सर्वर त्रुटि। एक प्रॉक्सी के लिए, 502 का मतलब बैकएंड से अमान्य उत्तर है, 503 का मतलब सेवा अनुपलब्ध है, 504 का मतलब बैकएंड ने बहुत धीरे उत्तर दिया, और 404 का मतलब नहीं मिला। http_get आपके स्वयं की सेवा की एक पृष्ठ खींचता है, और आपकी request कमांड एक रीडायरेक्ट के नए पते को दिखाती है। यदि कोई कोड आपकी योजना से भिन्न है, तो बैकअप फ़ाइल पुनर्स्थापित करें, रीलोड करें और फिर से परीक्षण करें। फिर योजना या नियम बदलें और दोहराएँ, एक राउंड में एक नियम। एक छोटी रूटिंग योजना और एक बैकअप फ़ाइल ही वह रोलबैक है जिसकी आपको आवश्यकता है।
