एप्लिकेशन कॉन्फ़िगरेशन को संग्रहीत करने का पसंदीदा तरीका क्या है?

Question

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

app
|-- config.json

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

12 फैक्टर ऐप गाइड कॉन्फ़िगरेशन फ़ाइलों को पूरी तरह से छोड़ने और कॉन्फ़िगरेशन सेटअप के लिए पर्यावरण चर का उपयोग करने की सलाह देता है:

... पर्यावरण चर में विन्यास संग्रहीत करता है। Env var किसी भी कोड को बदले बिना deploys के बीच बदलना आसान है; कॉन्फिग फाइलों के विपरीत, गलती से कोड रेपो में उनकी जांच किए जाने की बहुत कम संभावना है; और कस्टम कॉन्फिग फाइलों के विपरीत, या जावा सिस्टम प्रॉपर्टीज जैसे अन्य कॉन्फिग मैकेनिज्म, वे एक भाषा हैं- और OS- एग्नोस्टिक स्टैंडर्ड।

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

क्या कॉन्फ़िगरेशन विकल्पों को संभालने का कुछ सार्वभौमिक रूप से स्वीकृत तरीका है, जिसमें स्थानीय कॉन्फ़िगरेशन को स्रोत नियंत्रण में संग्रहीत करने का जोखिम नहीं है?

Comments

खैर, कम से कम कुछ ऐसा है .gitignoreजहां मैं उन फ़ाइलों या फ़ोल्डरों को परिभाषित कर सकता हूं जिन्हें संस्करण नियंत्रण में नहीं जांचना चाहिए। जैसा कि आप कहते हैं कि मैं नहीं देखता कि Env vars को वास्तव में कहाँ मदद करनी चाहिए, eith आपके पास उन्हें सेट करने के लिए एक स्क्रिप्ट है और इसे प्रोजेक्ट के साथ एक साथ संग्रहित किया जाना चाहिए या आपके सिस्टम (होम डायरेक्टरी या यहां तक ​​कि मशीनों में) पर उन्हें 'कहीं' होना चाहिए स्क्रिप्ट) जो अपने आप में बहुत सारी समस्याएँ पैदा करता है, खासकर अगर बहुत सारे कॉन्फ़िगरेशन आवश्यक हैं। किसी भी स्थिति में मैं कॉन्फिग फाइलों को अलग कर दूंगा ताकि गोपनीय जानकारी अलग-अलग फाइलों में चली जाए।

— थोरस्टेन मुलर

@ थोरस्टेमुलर - केवल समस्या के साथ .gitignore कि बेस / टेम्प्लेट कॉन्फिगर को अभी भी स्टोर किया जाना है, जिसका अर्थ है कि ऐप को दो कॉन्फिग पढ़ने हैं - बेस एक, डिफॉल्ट ऑप्शंस (scm में संग्रहीत), और लोकल वन, उस बेस को ओवरराइड करता है (और scm में संग्रहीत नहीं है)। Env vars के साथ, मुझे लगता है कि बड़े पैमाने पर तैनाती आसान हो जाती है - नए वर्चुअल मशीन सेटअप के लिए पर्यावरण चर को निर्दिष्ट करने के लिए कुछ गैर-मानक फ़ाइल के लिए कुछ लिखना आसान है।

— रोज

अच्छा सवाल है, जब मैंने इसके लिए सामान्य उपयोगकर्ता-विशिष्ट एप्लिकेशन डेटा स्टोर का उपयोग करना शुरू किया, तो जीवन आसान हो गया ;-)

— वुल्फ

क्या आपने " रेडिस " redis.io की कोशिश की है । यह विशेष रूप से केवल कुंजी-मूल्य संरचना भंडारण के लिए है।

— करण

@jporcenaluk - मुझे की-वैल्यू स्टोरेज पसंद है, लेकिन कॉन्फिग मैनेजमेंट को संभालने के लिए सिर्फ फुल-ब्लोइड रेडिस को अप्लाई करना थोड़ा ओवरकिल की तरह लगता है। दूसरी ओर, शायद मैंने कभी बड़े प्रोजेक्ट पर काम नहीं किया।

— रोज़

Answer 1

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

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

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

Comments

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

— रोज

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

— कीवारोन

एक दूसरी दुकान समझ में आती है। हो सकता है कि अन्य प्रकार के डेटा, भी गोपनीय हों, जिन्हें कॉन्फ़िगरेशन के साथ संग्रहीत किया जा सकता है (उदाहरण के लिए उत्पादन डेटा जो ग्राहकों की समस्याओं को ठीक करने के लिए विश्लेषण के तहत है)।

— वुल्फ

@ रॉगच वे बहुत नफ़रत को आकर्षित करने लगते हैं, लेकिन गिट सबमॉडल्स इसे ठीक से संभालेंगे, मुझे लगता है - अगर मुख्य सही स्थापित किया गया था, और प्रतिबंधित-पहुंच रेपो बस इसके अंदर रह सकता है।

— सेलडोमनैडी

Answer 2

समस्याओं और संभावित समाधानों की जांच करने में, यह मुझे जेफ एटवुड द्वारा प्रचलित एक विधि का उपयोग करने में मदद करता है : यदि भगवान को संवेदनशील कॉन्फ़िगरेशन जानकारी संग्रहीत करने का एक तरीका बनाया गया था , तो वह कैसे करेगा?

ठीक है, वह जानता होगा कि कॉन्फ़िगरेशन जानकारी की आवश्यकता किसको है और यह केवल उन लोगों को देता है, और जानकारी कभी भी किसी अन्य व्यक्ति तक नहीं पहुंच पाएगी।

पहले भाग पर पहले से ही ध्यान देना चाहिए: आपके स्रोत नियंत्रण प्रणाली को उपयोगकर्ताओं को प्रमाणित करना चाहिए। और इस दृष्टिकोण को ट्रॉय हंट के 10 कमांड ऑफ़ सोर्स कंट्रोल में # 10 के अनुसार वैधता दी गई है , "निर्भरता को स्रोत नियंत्रण में रहने की आवश्यकता है"।

लेकिन लीक होने पर इसे सुरक्षित कैसे रखा जाए? खैर, यह वहाँ सादे पाठ में संग्रहीत करने की आवश्यकता नहीं है! एन्क्रिप्शन का उपयोग करें। .NET में, ऐसे चरण हैं जो आप अपनी कॉन्फ़िगरेशन फ़ाइलों में कनेक्शन स्ट्रिंग डेटा एन्क्रिप्ट करने के लिए ले सकते हैं । आपको अपनी पसंद की विशेष तकनीक के साथ ऐसा करने के लिए समान तरीके खोजने होंगे।

Comments

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

— रोजा

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

— जोंपसेनलुक

Answer 3

बहुत से लोग आपके स्रोत कोड के साथ नियमित रूप से फाइलों में कॉन्फ़िगरेशन को संग्रहीत करने की आलोचना करते हैं लेकिन मेरे अनुभव में, यह वास्तव में एक बहुत अच्छा समाधान है:

• किसी भी भाषा में लागू करने के लिए सरल। कई में, आपको बॉक्स से बाहर जटिल कॉन्फ़िगरेशन फ़ाइलों के लिए समर्थन मिलता है। उदाहरण के लिए, स्प्रिंग बूट के साथ जावा के मामले में, आपको YAML समर्थन मिलता है जो किसी भी पेड़ जैसी संरचना को व्यक्त कर सकता है, और विभिन्न वातावरणों के लिए अलग-अलग कॉन्फ़िगरेशन फ़ाइलों के साथ-साथ एक बेसलाइन कॉन्फ़िगरेशन होना आसान है, जिसमें से पर्यावरण-विशिष्ट फाइलें विरासत में मिल सकती हैं।
• आपके सॉफ़्टवेयर को चलाने के लिए कॉन्फ़िगरेशन की आवश्यकता होती है, और कोड में परिवर्तन के लिए अक्सर कॉन्फ़िगरेशन सेटिंग्स को जोड़ने / संशोधित करने की आवश्यकता होती है, इसलिए कॉन्फ़िगरेशन और कोड को एक साथ रखना स्वाभाविक है।
• स्रोत के साथ कॉन्फ़िगरेशन को संग्रहीत करने से आपको स्रोत नियंत्रण के सभी लाभ मिलते हैं, जैसे कि कौन कौन से सेटिंग को संशोधित करता है और कब या नियमित कोड समीक्षा के दौरान कॉन्फ़िगरेशन की जांच करने में सक्षम है।
• जब तक आप सीआईए के लिए काम नहीं करते हैं, सुरक्षा तर्क मुझे भारी लगता है। इसलिए आपका डेटाबेस पासवर्ड मशीन पर एक फ़ाइल में संग्रहीत किया जाता है जहां आपका ऐप चलता है। ठीक है, अगर किसी को आपके ऐप के साथ मशीन तक पहुंच मिलती है, तो आप शायद पहले से ही बहुत परेशानी में हैं - वे आपके ऐप को नीचे ले जा सकते हैं और उसी पोर्ट पर अपनी जगह पर अपना ऐप शुरू कर सकते हैं। ऐसे परिदृश्य में, DB पासवर्ड तक पहुंच होना इतना बड़ा मुद्दा नहीं हो सकता है। जब तक आपके सभी कनेक्शन पूरी तरह से एन्क्रिप्ट नहीं किए जाते हैं, आपकी मशीन तक पहुंच होती है, वे वैसे भी नेटवर्क इंटरफेस से बहुत दिलचस्प डेटा को सूँघ सकते हैं।
• आप एक उपकरण का उपयोग कर सकते हैं जैसे कि Hiera के पास एक पाठ विन्यास फ़ाइल है, लेकिन इसके अंदर पासवर्ड या अन्य संवेदनशील डेटा संग्रहीत नहीं है।

इसलिए, कई मामलों के लिए, कोड के साथ स्रोत नियंत्रण में संग्रहीत पाठ विन्यास एक अच्छी शुरुआत है।

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

Comments

लेकिन कोड किसी ऐसे व्यक्ति के हाथों में बदल जाता है जो कॉन्फिग फाइलों में रहस्यों का मालिक नहीं है, वहां एक वास्तविक गड़बड़ होने वाली है।

— टिम लुडविंस्की

@TimLudwinski Keys / सीक्रेट्स कंपनी के हैं, न कि व्यक्तिगत डेवलपर्स के, इसलिए उन्हें इस तरह से बनाए रखा जाना चाहिए कि अगर कोई एकल व्यक्तिगत पत्तियां नहीं मिलती हैं तो वे खो नहीं जाते हैं। उदाहरण के लिए उन्हें प्रवेश / सुरक्षा टीम द्वारा मुद्दे और बनाए रखा जा सकता है, ताकि एक केंद्रीय रजिस्ट्री हो।

— माइकल कोस्मुलस्की

Answer 4

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

उन्होंने कहा कि मुझे लगता है कि हम आगे बढ़ने वाले एक अच्छे समाधान के साथ आए हैं। हम अपनी कॉन्फिग फाइल को एक अलग git रेपो (config repo) के रूप में ले जा रहे हैं। इसके बाद हमने एक स्प्रिंग-क्लाउड-कॉन्फिग (जावा) सर्वर स्थापित किया, जो केवल उस पर दिए गए प्रोफाइल के आधार पर कॉन्फिग रेपो की फाइलों को परोसता है। यह जावा अनुप्रयोगों के लिए बहुत अच्छा है जो क्लाइंट का उपयोग कर सकते हैं और उन्हें स्टार्टअप समय पर डाउनलोड कर सकते हैं। हमारे PHP / नॉन-जावा ऐप के लिए हम सीधे फाइल को नीचे खींचेंगे। (आदर्श नहीं)। भविष्य में हम कुछ ऐसा लिख ​​सकते हैं जो पीएचपी एप्लिकेशन को स्वयं पर कॉन्फिग को डाउनलोड करने और उन्हें कहीं कैश करने की सुविधा देता है, लेकिन यह पहले रन के लिए उच्च प्राथमिकता नहीं है। मुझे लगता है कि यह समाधान config-as-a-service के रूप में है जो स्पष्ट रूप से 12 कारक एप्लिकेशन सिफारिशों का उल्लंघन नहीं करता है।

मेरा मानना ​​है कि ज़ुकीपर का उपयोग उसी चीज़ के लिए किया जा सकता है (मैंने कुबेरनेट्स + ज़ुकीपर के साथ एक सेटअप देखा) तो मुझे यकीन नहीं है कि उस उत्तर को -1 से ऊपर क्यों मिला।

लिंक:

https://spring.io/guides/gs/centralized-configuration/

https://cloud.spring.io/spring-cloud-config/

Answer 5

पूरे कॉन्फ़िगरेशन को एक फ़ाइल में संग्रहीत करने के बजाय, इसे कई फ़ाइलों में संग्रहीत करें।

• कॉन्फ़िगरेशन निर्देशिका है । हो सकता है कि सभी फ़ाइलों को कॉन्फ़िगरेशन फ़ाइलों के रूप में व्याख्या की गई हो, शायद छोड़कर README*।
• सभी फ़ाइल नाम वर्णानुक्रम में सॉर्ट किए जाते हैं, और फ़ाइलें उस क्रम में लोड की जाती हैं। यही कारण है कि ऐसे मामलों में फाइलें अक्सर एक या दो अंकों के साथ शुरू होती हैं 01-logging.json:। 02-database.json, आदि।
• सभी फाइलों के डेटा को एप्लिकेशन के लिए उपलब्ध समान कॉन्फ़िगरेशन संरचना में लोड किया गया है। यह है कि कितनी फाइलें एक-दूसरे की सेटिंग्स को पूरक कर सकती हैं, और यहां तक ​​कि उन्हें पूर्वानुमानित तरीके से ओवरराइड भी कर सकती हैं।
• केवल वीसीएस में वाई-फाई फ़ाइलों को सुरक्षित-से-देखने के मूल्यों या डिफ़ॉल्ट मानों के साथ संग्रहीत करें। तैनाती के दौरान रहस्यों के साथ कॉन्फ़िगर फ़ाइलों को जोड़ें, या, बेहतर अभी तक, एक प्रमाणित रहस्य भंडारण सेवा का उपयोग करें।

अपने निकटतम लिनक्स बॉक्स पर, एक नज़र डालें /etc/sudoers.dया /etc/nginx/conf.d। यह एक ही पैटर्न दिखाता है।

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

(इसके अलावा, एक राय टुकड़ा: JSON एक अच्छा विन्यास फ़ाइल प्रारूप नहीं है, क्योंकि यह टिप्पणियों की अनुमति नहीं देता है; टिप्पणियाँ महत्वपूर्ण हैं। TOML, YAML और यहां तक ​​कि INI प्रारूप व्यावहारिक उपयोग में बेहतर हैं।)

Answer 6

मुझे लगता है कि आपके विकल्प ओएस द्वारा परिभाषित किए गए हैं जिन्हें आप तैनात कर रहे हैं

मैं सुझाव दूंगा कि हां, स्रोत नियंत्रण में मान डालें। लेकिन केवल 'देव' संस्करण। आप अपने स्रोत कोड को संकलन और काम करना चाहते हैं! अतिरिक्त गुप्त कदम शामिल नहीं हैं

आपकी निर्माण और परिनियोजन प्रक्रिया को तब परिनियोजन के दौरान इन मानों को प्रति वातावरण में स्वैप करना चाहिए। (ऑक्टोपस का इस तरह का मॉडल है)

Answer 7

Apache zookeeper वितरित सिस्टम के लिए एप्लिकेशन कॉन्फ़िगरेशन को संग्रहीत करने के लिए अद्भुत विकल्प देता है। ज़ुकीपर में किए गए बदलावों को एप्लिकेशन के अंत में क्यूरेटर या ज़ुकीपर श्रोता के द्वारा कैप्चर और संसाधित किया जा सकता है।

Comments

विकल्प क्या हैं? यह कैसे काम करता है? यह उन्हें कहाँ संग्रहीत करता है? क्या एक को दूसरे पर पसंद किया जाता है? प्रत्येक विकल्प के विभिन्न फायदे और नुकसान क्या हैं? यह विभिन्न ऑपरेटिंग सिस्टम पर कैसे इंटरैक्ट करता है?

@ गंगज़ - मुझे और अधिक विस्तृत उत्तर में दिलचस्पी होगी, कृपया नीचे की ओर निराश न हों, और अपने उत्तर में सुधार करें ताकि यह मदद का हो सके।

— जे एलस्टन