आप अपना पहला प्रोडक्शन ऐप लॉन्च करने के लिए तैयार हैं, और यह कुछ बाहरी सेवाओं से बात करने का समय है। आपको अभी भी सब कुछ जोड़ना है। तो अपनी देव मशीन पर चीजों को अधिक जटिल किए बिना, उत्पादन में अपनी सेवाओं को कॉन्फ़िगर करने का सबसे अच्छा तरीका क्या है?
अपना परिवेश सेट करें
प्रोडक्शन ऐप्स को कॉन्फ़िगर करने के लिए, पर्यावरण चर (वे ENV["REDIS_HOST"]
) का उपयोग करना आज का सबसे अच्छा अभ्यास है। -दिखने वाली चीजें)।
लेकिन क्यों?
-
अपनी उत्पादन कुंजियां गलती से देना कठिन है।
यदि आप ध्यान नहीं दे रहे हैं, तो आप
git push
इसमें महत्वपूर्ण गुप्त कुंजियों वाली एक फ़ाइल। और यह एक महंगी गलती हो सकती है। -
कॉन्फ़िगरेशन वह है जिसके लिए पर्यावरण चर मौजूद हैं।
पर्यावरण चर लगभग हर तरह के सिस्टम पर ऐप्स को कॉन्फ़िगर करने का एक सामान्य तरीका है। कई अन्य प्रोग्राम (जैसे रूबी) कॉन्फ़िगरेशन के लिए पर्यावरण चर का उपयोग करते हैं, इसलिए यह केवल आपके अपने ऐप में प्रयास करने के लिए समझ में आता है।
-
पर्यावरण चरों को उत्पादन में स्थापित करना आसान है।
आसानी से पर्यावरण चर सेट करने के लिए हेरोकू में एक वेब यूआई और कमांड लाइन टूल है। और यदि आप अपना स्वयं का सर्वर बना रहे हैं, तो शेफ और डॉकर जैसे सर्वर प्रबंधन उपकरण पर्यावरण चर को सेट करना आसान बनाते हैं।
रेल की तरफ कैसा दिखता है?
इस प्रकार एक ऐप जो पर्यावरण चर पर निर्भर करता है, स्वयं को कॉन्फ़िगर कर सकता है:
production:
host: <%= ENV["MY_SERVICE_HOST"] %>
port: <%= ENV["MY_SERVICE_PORT"] %>
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
ERB
चलाता है my_service.yml
. के अंदर कोड , और पकड़ लेता है MY_SERVICE_HOST
और MY_SERVICE_PORT
पर्यावरण से बाहर। यह उन मानों को MyService
. के पास भेजता है ।
आप केवल प्रारंभकर्ता को ENV["MY_SERVICE_HOST"]
से भी पढ़ सकते हैं सीधे। लेकिन मैं उन्हें .yml
. में रखना पसंद करता हूं फ़ाइलें, जिन कारणों से आप एक मिनट में देखेंगे।
आपके ऐप का कॉन्फ़िगरेशन विकास में है
पर्यावरण चर उत्पादन के लिए ठीक हैं। लेकिन एक बार जब आप अपना प्रोडक्शन कॉन्फिगरेशन सेट कर लेते हैं, तो आप डेवलपमेंट और टेस्ट मोड को कैसे हैंडल करते हैं?
आपके पास कुछ विकल्प हैं। लेकिन मैं आमतौर पर रेल के config/secrets.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
विकास में config. यह आसान है, यह पठनीय है, और ठीक उसी प्रकार की कॉन्फिग फाइलों से निपटने के लिए रेल्स के पास अंतर्निहित समर्थन है।
विकास के लिए एक अन्य विकल्प
विकास मोड में कॉन्फ़िगरेशन को संभालने का एक और तरीका है:dotenv. यह साफ-सुथरा दिखता है, लेकिन मैंने अभी तक इसे अपने ऐप में नहीं आजमाया है।
dotenv के साथ, आप .env
. नामक फ़ाइल में पर्यावरण चर डाल सकते हैं आपके रेल ऐप की रूट निर्देशिका में, और वे मान आपके ऐप द्वारा उठाए जाएंगे। यह अच्छा है, क्योंकि आपका विकास परिवेश आपके उत्पादन परिवेश की तरह अधिक कार्य करता है। यह केवल उत्पादन में होने वाली बग से बचने का एक अच्छा तरीका है।
यह कुछ ऐसा है जिसे मैं किसी दिन कोशिश करूंगा। लेकिन अभी के लिए, मुझे .yml
. से अधिक सुविधाजनक कुछ नहीं लगा और config_for
।
अधिकांश उत्पादन ऐप्स को किसी प्रकार के कॉन्फ़िगरेशन की आवश्यकता होती है। इसलिए जब आप अपना अगला ऐप्लिकेशन परिनियोजित करें, तो .yml
का उपयोग करके देखें फ़ाइलें, इसे कॉन्फ़िगर करने के लिए, उत्पादन में पर्यावरण चर द्वारा पॉप्युलेट की जाती हैं। आपको वह लचीलापन, सरलता और विश्वसनीयता मिलेगी जिसकी आप उम्मीद कर रहे हैं।
क्या आपके पास अपने उत्पादन ऐप्स को कॉन्फ़िगर करने का एक अलग तरीका है? एक टिप्पणी छोड़ें, मुझे इसके बारे में सुनना अच्छा लगेगा!