एकाधिक उप डोमेन के साथ एक रेल ऐप बनाना

आज की पोस्ट में, हम सीखेंगे कि एक रेल ऐप कैसे बनाया जाए जो मल्टीपल सबडोमेन को सपोर्ट कर सके। मान लेते हैं कि हमारे पास एक गेमिंग वेबसाइट है funkygames.co और हम कई उप डोमेन का समर्थन करना चाहते हैं जैसे app.funkygames.co , api.funkygames.co , और dev.funkygames.co एक रेल आवेदन के साथ। हम यह सुनिश्चित करना चाहते हैं कि सभी उप डोमेन के लिए उचित प्रमाणीकरण किया गया है और कोई डुप्लिकेट मार्ग नहीं हैं।

हम अपने एप्लिकेशन में एकाधिक सबडोमेन का समर्थन करने के लिए रेल की शक्तिशाली रूटिंग संरचनाओं का उपयोग करेंगे। हम स्थानीय रूप से उप डोमेन भी सेट करेंगे और अनेक उप डोमेन के लिए परीक्षण लिखेंगे।

आवश्यकताएं

इस पोस्ट के प्रयोजन के लिए, मैं मान रहा हूं कि आपने सभी उप डोमेन के लिए रेल ऐप को इंगित करने के लिए उपयुक्त DNS रिकॉर्ड स्थापित किए हैं। हम इस पोस्ट में केवल रेल पक्ष के बारे में बात करेंगे।

एकाधिक उप डोमेन को संभालना

रेल routes.rb . का उपयोग करती है आने वाले अनुरोधों को संभालने के लिए फ़ाइल और उन्हें विशिष्ट नियंत्रक क्रियाओं के लिए मैप करें। एक तुच्छ ऐप में, routes.rb . में प्रत्येक मैपिंग नियंत्रक कार्रवाई के लिए मार्ग को निम्नानुसार मैप करता है:

  get '/games/:id', to: 'games#show'

इस दृष्टिकोण के साथ, हमारे routes.rb . में परिभाषित सभी अंतिम बिंदु fileare सभी उप डोमेन पर लागू होता है। तो app.funkygames.co/games/1 साथ ही api.funkygames.co/games/1 इस रूट से किया जाएगा। हालांकि, हम केवल app . से अनुरोध करना चाहते हैं उपडोमेन को इस मार्ग द्वारा नियंत्रित किया जाना है। api उपडोमेन केवल एपीआई मार्गों के लिए उपयोग किया जाना है। हम मार्गों में कुछ नियम जोड़ेंगे ताकि आने वाले अनुरोध के लिए एक विशिष्ट नियम पूरा होने पर ही उन्हें नियंत्रित किया जा सके।

रेल रूटिंग एक constraints provides प्रदान करता है सहायक विधि जो दिए गए मार्ग के लिए अतिरिक्त नियम निर्दिष्ट कर सकती है।

  get '/games/:id', to: 'games#show', constraints: { subdomain: 'app' }

यह सुनिश्चित करेगा कि यदि अनुरोध app.funkygames.co/games/1 से आ रहा है , इसे GamesController's . द्वारा नियंत्रित किया जाएगा कार्रवाई दिखाओ। app . के अलावा अन्य उप डोमेन से कोई भी अनुरोध इस मार्ग से नियंत्रित नहीं किया जाएगा।

constraints . को परिभाषित करना बहुत बोझिल हो जाएगा इस तरह प्रत्येक मार्ग के लिए।

  get '/games/:id', to: 'games#show', constraints: { subdomain: 'app' }
  get '/games/list', to: 'games#list', constraints: { subdomain: 'app' }
  post '/games/start', to: 'games#start', constraints: { subdomain: 'app' }

हम constraints . के ब्लॉक फॉर्म का उपयोग कर सकते हैं एकल उप डोमेन के लिए बहुमार्गों को परिभाषित करने में सहायक।

  constraints subdomain: 'app' do
    get '/games/:id', to: 'games#show'
    get '/games/list', to: 'games#list'
    post '/games/start', to: 'games#start'
  end

अनेक उप डोमेन के लिए मार्ग निर्धारित करने के लिए, हमें बस एक से अधिक constraints . को जोड़ना होगा हमारे routes.rb . में ब्लॉक करता है फ़ाइल।

constraints subdomain: 'app' do
  ...
end
 
constraints subdomain: 'api' do
  ...
end
 
constraints subdomain: 'dev' do
  ...
end

अंडर द हुड

रेल रूटिंग अनुरोध बाधाओं और खंड बाधाओं को प्रदान करता है। खंड की बाधाएं अनुरोध पथ पर नियम जोड़ती हैं जबकि अनुरोध बाधाएं आने वाले अनुरोध पर शर्तें जोड़ती हैं। अनुरोध बाधा में हैश कुंजी Request . पर एक विधि होनी चाहिए ऑब्जेक्ट जो एक स्ट्रिंग लौटाता है और मान अपेक्षित मान होना चाहिए।

constraints subdomain: 'app' do
  ...
end

उपरोक्त मामले में, हम subdomain . का उपयोग कर रहे हैं Request . पर विधि ऑब्जेक्ट और इसे app . जैसी स्ट्रिंग से मिलान करना , api या dev ।

अधिक जानकारी के लिए, रेल रूटिंग गाइड देखें।

बहु-स्तरीय उप डोमेन को संभालना

मान लें कि हम app.staging.funkygames.co . का उपयोग कर रहे हैं हमारे मंचन वातावरण के लिए। यदि हमारे पास उपरोक्त सेटअप है, तो हम जल्दी से देखेंगे कि सभी अनुरोध जो app को हिट करने वाले हैं सबडोमेन 404 लौटा रहा है। अगर हम चीजों को और डीबग करते हैं, तो हम देखेंगे कि सबडोमेन के लिए हमारी बाधा विफल हो रही है।

request.subdomain #=> app.staging

हमें उम्मीद थी कि उप डोमेन app लौटाएगा , लेकिन इसके बजाय, यह app.staging . लौटाता है . बेशक, हम पर्यावरण-विशिष्ट कोड को जोड़े बिना इसे हल करना चाहते हैं! अनुरोध के उप डोमेन की पार्सिंग config.action_dispatch.tld_length द्वारा प्रबंधित की जाती है विकल्प। इस कॉन्फ़िगरेशन का डिफ़ॉल्ट मान 1 है, जो मूल रूप से उप डोमेन के एक स्तर का समर्थन करता है। चूंकि हमारे पास दो स्तरीय उप डोमेन हैं, हमें config.action_dispatch.tld_length के लिए मान सेट करने की आवश्यकता है टू 2.

# config/application.rb
config.action_dispatch.tld_length = Integer(ENV['TLD_LENGTH'] || 1)

हम इसे एक पर्यावरण चर का उपयोग करके सेट कर सकते हैं ताकि हम स्टेजिंग के साथ-साथ उत्पादन वातावरण में समान कोड का उपयोग कर सकें। अब, हमारा रूटिंग सेटअप app.staging.funkygames.co . के लिए काम करेगा साथ ही।

सत्र प्रबंधन

अब जबकि मार्गों को कई उप डोमेन से आने वाले अनुरोधों को संभालने के लिए परिभाषित किया गया है, हमें सभी उप डोमेन के लिए प्रमाणीकरण का ध्यान रखना होगा। हम इसे दो तरीकों से कर सकते हैं—हम या तो सभी उप डोमेन में एक ही उपयोगकर्ता सत्र का उपयोग करने की अनुमति दे सकते हैं, या हम अलग उप डोमेन के लिए अलग सत्र रख सकते हैं।

संक्षेप में प्रमाणीकरण

रेल डिफ़ॉल्ट रूप से उपयोगकर्ता सत्र कुंजी को संग्रहीत करने के लिए कुकीज़ का उपयोग करता है। एक बार जब उपयोगकर्ता लॉग इन करता है, तो उपयोगकर्ता की सत्र जानकारी हमारी पसंद के सत्र स्टोर में संग्रहीत होती है और सत्र कुंजी ब्राउज़र में कुकी के रूप में संग्रहीत होती है। तो अगली बार जब उपयोगकर्ता हमारी वेबसाइट पर जाता है, तो वही सत्र कुकी ब्राउज़र से सर्वर पर भेजी जाती है और सर्वर यह तय करता है कि उपयोगकर्ता लॉग इन है या नहीं, इस आधार पर कि आने वाले सत्र कुकी के लिए सत्र मौजूद है या नहीं।

सत्र के लिए डिफ़ॉल्ट कॉन्फ़िगरेशन रेल ऐप में इस तरह दिखता है:

Rails.application.config.session_store :cookie_store, key: "_funkygames_session"

कुंजी _funkygames_session सत्र कुकी के नाम के रूप में उपयोग किया जाएगा और इसका मान सत्र आईडी होगा।

कुकीज़ प्राइमर

डिफ़ॉल्ट रूप से, कुकीज़ अनुरोध के डोमेन पर ब्राउज़र द्वारा सेट की जाती हैं। तो अगर हम अपने आवेदन को app.funkygames.co . से मार रहे हैं तब सत्र कुकी app.funkygames.co . के विरुद्ध सेट की जाएगी . प्रत्येक उप डोमेन अपनी स्वयं की सत्र कुकीज़ सेट करेगा, इसलिए उपयोगकर्ता सत्र डिफ़ॉल्ट रूप से उप डोमेन में साझा नहीं किया जाएगा।

विभिन्न उप डोमेन के बीच सत्र साझा करना

यदि हम उप डोमेन में उपयोगकर्ता सत्र साझा करना चाहते हैं, तो हमें सत्र कुकी को funkygames.co पर सेट करना होगा डोमेन ही ताकि सभी उप डोमेन उस तक पहुंच सकें। इसे domain . पास करके हासिल किया जा सकता है सत्र स्टोर सेटिंग का विकल्प।

Rails.application.config.session_store :cookie_store, key: "_funkygames_session", domain: :all

domain passing पास करके :all . के रूप में , हम मूल रूप से रेल को एप्लिकेशन के शीर्ष-स्तरीय डोमेन जैसे funkygames.co पर सत्र कुकी सेट करने के लिए कह रहे हैं। अनुरोध होस्ट के बजाय जिसमें अलग-अलग उप डोमेन शामिल हो सकते हैं। एक बार जब हम ऐसा कर लेते हैं, तो सत्र को विभिन्न उप डोमेन के बीच साझा किया जा सकता है।

हम domain . को डोमेन की सूची भी पास कर सकते हैं एकाधिक डोमेन का समर्थन करने के लिए एक सरणी प्रारूप में विकल्प।

एक और विकल्प है जिसे सभी उप डोमेन के लिए कुकीज़ को ठीक से सेट करने के लिए कॉन्फ़िगर करने की आवश्यकता है। यह tld_length है विकल्प। domain: :all . का उपयोग करते समय , यह विकल्प निर्दिष्ट कर सकता है कि डोमेन के TLD की व्याख्या करने के लिए डोमेन को कैसे पार्स किया जाए। हमारे मामले में, app.funkygames.co . के लिए , हमें tld_length . सेट करना चाहिए TLD को funkygames.co . के रूप में व्याख्या करने के लिए रेल के लिए 2 तक कुकीज़ सेट करते समय। तो कई उप डोमेन के लिए अंतिम सत्र स्टोर कॉन्फ़िगरेशन इस तरह दिखता है:

Rails.application.config.session_store :cookie_store,
                                       key: "_funkygames_session",
                                       domain: :all,
                                       tld_length: 2

tld_length सेशन स्टोर का विकल्प config.action_dispatch.tld_length . से अलग है पहले चर्चा की गई।

एकाधिक उप डोमेन के लिए परीक्षण लिखना

चूंकि मार्ग उपडोमेन विशिष्ट हैं, यदि परीक्षण अनुरोध में उचित उपडोमेन नहीं है, तो अनुरोध विनिर्देश या एकीकरण परीक्षण के परिणामस्वरूप 404 त्रुटियां होती हैं। रेल एकीकरण परीक्षण एक host! . प्रदान करते हैं सहायक जो एक परीक्षण फ़ाइल में किए गए सभी अनुरोधों के लिए उचित उप डोमेन सेट कर सकता है।

# Configuring subdomain in Rails integration tests
setup do
  host! 'dev.example.com'
end
 
# # Configuring subdomain in RSpec request specs
before do
 host! 'dev.example.com'
end

इसके बाद, अनुरोधों को routes.rb में उपडोमेन रूटिंग के अनुसार नियंत्रक क्रियाओं के लिए सही ढंग से रूट किया जाएगा फ़ाइल।

ध्यान दें कि यहां डोमेन कोई मायने नहीं रखता, हम जिस कोड का परीक्षण कर रहे हैं उसके आधार पर केवल उचित उप डोमेन मायने रखता है।

विकास के लिए स्थानीय रूप से अनेक उप डोमेन सेट करना

स्थानीय रूप से उप डोमेन सेट करने के कई तरीके हैं। सबसे आसान है /etc/hosts का संपादन फ़ाइल।

127.0.0.1 dev.funkygames.local
127.0.0.1 app.funkygames.local
127.0.0.1 api.funkygames.local

यह सुनिश्चित करता है कि उप डोमेन सेटअप स्थानीय वातावरण में काम करेगा। हम स्थानीय रूप से उप डोमेन प्रबंधित करने के लिए pow जैसे टूल का भी उपयोग कर सकते हैं।

बाधाओं पर आधारित सबडोमेन रूटिंग के साथ गोचस

हालांकि बाधाओं पर आधारित सबडोमेन रूटिंग ज्यादातर मामलों में काम करती है, लेकिन कुछ स्थितियों में यह एक दर्द हो सकता है।

बाहरी API से निपटना

जब हम तृतीय-पक्ष API और बिल्डिंग इंटीग्रेशन के साथ काम कर रहे होते हैं, तो स्थानीय विकास TLD जैसे .local या .dev की अनुमति नहीं है। हमें ngrok जैसे टूल का उपयोग करना होगा। उपडोमेन आधारित रूटिंग ऐसे मामलों में काम नहीं करती है और हमें कुछ मार्गों को श्वेतसूची में डालना होगा ताकि वे एनग्रोक के माध्यम से भी पहुंच सकें।

उप डोमेन की सीमाओं से बाहर के मार्ग

कुछ मार्गों को उपडोमेन बाधाओं के अंदर नहीं रखा जा सकता है। एक सामान्य उदाहरण है healthcheck या ping समापन बिंदु। यदि हम अपने रेल ऐप के सामने लोड बैलेंसर का उपयोग कर रहे हैं, तो लोड बैलेंसर को समय-समय पर यह जांचना होगा कि ऐप चालू है या नहीं। healthcheck ऐसे मामलों में इस्तेमाल किया जाने वाला एंडपॉइंट सबडोमेन बाधाओं के तहत नहीं हो सकता क्योंकि लोड बैलेंसर को शायद अनुरोध होस्ट का ज्ञान नहीं होगा।

रूट रूट का अभाव

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

निष्कर्ष

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

पी.एस. यदि आप रूबी मैजिक की पोस्ट प्रेस से छूटते ही पढ़ना चाहते हैं, तो हमारे रूबी मैजिक न्यूजलेटर की सदस्यता लें और एक भी पोस्ट मिस न करें!