रेल्स डिप्लॉय करना: प्रोडक्शन कॉन्फ़िगरेशन के लिए चरण-दर-चरण मार्गदर्शिका

आप अपना पहला प्रोडक्शन ऐप लॉन्च करने के लिए तैयार हैं, और अब समय आ गया है कि इसे कुछ बाहरी सेवाओं से जोड़ा जाए। आपको अभी भी सब कुछ हुक अप करना है। तो प्रोडक्शन में अपनी सेवाओं को कॉन्फ़िगर करने का सबसे अच्छा तरीका क्या है, बिना अपने डेवलपमेंट मशीन को अधिक जटिल बनाए?

अपना एनवायरनमेंट सेट करें

आज के समय में प्रोडक्शन ऐप्स को कॉन्फ़िगर करने के लिए सबसे अच्छी प्रैक्टिस है एनवायरनमेंट वेरिएबल्स का उपयोग करना (वो ENV["REDIS_HOST"] जैसे दिखने वाले)।

लेकिन क्यों?

अपने प्रोडक्शन कीज़ को गलती से कमिट करना कठिन होता है।

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

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

हेरोकू के पास एनवायरनमेंट वेरिएबल्स सेट करने के लिए एक वेब UI और कमांड लाइन टूल है। और अगर आप अपना खुद का सर्वर बना रहे हैं, तो शेफ और डॉकर जैसे सर्वर मैनेजमेंट टूल्स एनवायरनमेंट वेरिएबल्स सेट करना आसान बनाते हैं।

रेल्स साइड पर यह कैसा दिखता है?

यह है कि एनवायरनमेंट वेरिएबल्स पर निर्भर ऐप खुद को कैसे कॉन्फ़िगर कर सकता है:

config/my_service.yml

production:
  host: <%= ENV["MY_SERVICE_HOST"] %>
  port: <%= ENV["MY_SERVICE_PORT"] %>

config/initializers/my_service.rb

my_service_config = Rails.application.config_for(:my_service)
my_service = MyService.new(my_service_config["host"], my_service_config["port"])

इनिशियलाइज़र रेल्स 4.2 के config_for मेथड का उपयोग करके सही .yml फाइल ढूंढता है और सही एनवायरनमेंट चुनता है।

फिर, config_for my_service.yml के अंदर के ERB कोड को चलाता है, और एनवायरनमेंट से MY_SERVICE_HOST और MY_SERVICE_PORT निकालता है। यह उन मानों को MyService में पास करता है।

आप इनिशियलाइज़र से सीधे ENV["MY_SERVICE_HOST"] भी पढ़ सकते हैं। लेकिन मैं उन्हें .yml फाइलों में रखना पसंद करता हूं, जिन कारणों से आप एक मिनट में देखेंगे।

डेवलपमेंट में आपके ऐप की कॉन्फ़िगरेशन

एनवायरनमेंट वेरिएबल्स प्रोडक्शन के लिए ठीक हैं। लेकिन एक बार जब आप अपना प्रोडक्शन कॉन्फ़िगरेशन सेट कर लेते हैं, तो आप डेवलपमेंट और टेस्ट मोड को कैसे संभालते हैं?

आपके पास कुछ विकल्प हैं। लेकिन मैं आमतौर पर रेल्स के config/secrets.yml में कन्वेंशन का पालन करता हूं: प्रोडक्शन में एनवायरनमेंट वेरिएबल्स का उपयोग करें, और डेवलपमेंट और टेस्ट में नॉन-सीक्रेट मानों को हार्डकोड करें।

डेवलपमेंट और टेस्ट एनवायरनमेंट्स के साथ, config/my_service.yml इस तरह दिख सकता है:

config/my_service.yml

production:
  host: <%= ENV["MY_SERVICE_HOST"] %>
  port: <%= ENV["MY_SERVICE_PORT"] %>
development:
  host: localhost
  port: 8081
test:
  host: localhost
  port: 8081

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

लेकिन आप इन मानों को हार्डकोड क्यों करेंगे?

कॉन्फ़िगरेशन मान देखना और बदलना आसान होता है।

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

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

आप शायद अपने डेवलपमेंट मशीन पर जितने ऐप्स पर काम करेंगे, उससे कहीं ज्यादा ऐप्स कभी भी एक ही प्रोडक्शन मशीन पर डिप्लॉय करेंगे। अगर आप उन सभी ऐप्स को कॉन्फ़िगर करने के लिए सिस्टम-वाइड एनवायरनमेंट वेरिएबल्स का उपयोग करते हैं, तो उनमें से दो के एक-दूसरे को ओवरराइट करने की अच्छी संभावना है।

तो, प्रोडक्शन में एनवायरनमेंट वेरिएबल्स और डेवलपमेंट में हार्डकोडेड .yml कॉन्फ़िगरेशन का उपयोग करने का प्रयास करें। यह आसान है, पढ़ने योग्य है, और रेल्स में ठीक ऐसे कॉन्फ़िगरेशन फाइलों से निपटने के लिए बिल्ट-इन सपोर्ट है।

डेवलपमेंट के लिए एक और विकल्प

डेवलपमेंट मोड में कॉन्फ़िगरेशन को संभालने का एक और तरीका है: डॉटएनवी (dotenv)। यह साफ दिखता है, लेकिन मैंने इसे अभी तक अपने ऐप में आजमाया नहीं है।

डॉटएनवी के साथ, आप अपने रेल्स ऐप के रूट डायरेक्टरी में .env नाम की फाइल में एनवायरनमेंट वेरिएबल्स डाल सकते हैं, और वे मान आपके ऐप द्वारा उठा लिए जाएंगे। यह अच्छा है, क्योंकि आपका डेवलपमेंट एनवायरनमेंट आपके प्रोडक्शन एनवायरनमेंट की तरह अधिक व्यवहार करता है। यह उन बग्स से बचने का एक अच्छा तरीका है जो केवल प्रोडक्शन में होते हैं।

यह कुछ ऐसा है जिसे मैं किसी दिन आजमाऊंगा। लेकिन अभी के लिए, मुझे .yml और config_for से अधिक सुविधाजनक कुछ नहीं मिला।

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

क्या आपके पास अपने प्रोडक्शन ऐप्स को कॉन्फ़िगर करने का कोई अलग तरीका है? एक कमेंट छोड़ें, मुझे इसके बारे में सुनना अच्छा लगेगा!