অ্যাপ্লিকেশন কনফিগারেশন সঞ্চয় করার পছন্দের উপায় কী?

Question

বেশিরভাগ সময়, আমি প্রকল্পের মূল ডিরেক্টরিতে ডেভলপমেন্ট অ্যাপ্লিকেশন কনফিগারেশন সঞ্চয় করি:

app
|-- config.json

তবে এটি সর্বোত্তম পন্থা বলে মনে হচ্ছে না, যেহেতু এই কনফিগারেশনটি সংস্করণ নিয়ন্ত্রণ সিস্টেমে সঞ্চিত রয়েছে - সম্ভবত ফলস্বরূপ ব্যবহারকারীর নাম, পাসওয়ার্ড এবং অন্যান্য সংবেদনশীল স্টাফের ফলস্বরূপ।

12 ফ্যাক্টর অ্যাপ্লিকেশন গাইড কনফিগারেশন ফাইলগুলি পুরোপুরি বাদ দেওয়ার এবং কনফিগারেশন সেটআপের জন্য পরিবেশ পরিবর্তনশীলগুলি ব্যবহার করার পরামর্শ দেয়:

... পরিবেশের ভেরিয়েবলগুলিতে কনফিগার স্টোর। এনভ ভার্সগুলি কোনও কোড পরিবর্তন না করেই মোতায়েনের মধ্যে পরিবর্তন করা সহজ; কনফিগারেশন ফাইলের বিপরীতে, এগুলি ঘটনাক্রমে কোড রেপোতে চেক হওয়ার খুব কম সম্ভাবনা রয়েছে; এবং কাস্টম কনফিগারেশন ফাইলগুলি, বা জাভা সিস্টেমের বৈশিষ্ট্যগুলির মতো অন্যান্য কনফিগারেশনের মতো নয়, এগুলি একটি ভাষা- এবং ওএস-অজোনস্টিক স্ট্যান্ডার্ড।

এটি আমার কাছে সত্যিই দুর্দান্ত লাগছে, তবে একটি স্টোর কীভাবে পরিবেশের পরিবর্তনশীলগুলিকে উত্স নিয়ন্ত্রণে পরীক্ষা না করে বলেছে? এবং অ্যাপগুলিতে এই পরিবর্তনগুলি পাস করার জন্য আমি কোন সরঞ্জামগুলি ব্যবহার করতে পারি? এখানে কয়েক ডজন কনফিগার বিকল্প থাকতে পারে এবং আপনি যখন অ্যাপটি চালু করেন ততবার হাত দিয়ে এগুলি টাইপ করা খুব ভাল না - তাই এগুলি কোথাও কোথাও কোনও ধরণের ফাইলে সংরক্ষণ করতে হবে। এইভাবে বলা ফাইলটি উত্স নিয়ন্ত্রণে শেষ হবে এবং আমরা যেখানে শুরু করেছি সেখানে ফিরে আসি।

কনফিগারেশন বিকল্পগুলি পরিচালনা করার জন্য কি সর্বজনীনভাবে গৃহীত উপায় আছে, যার উত্স নিয়ন্ত্রণে স্থানীয় কনফিগারেশন সংরক্ষণ করার ঝুঁকি নেই?

Comments

ভাল, গিটের অন্তত এমন কিছু আছে .gitignoreযেখানে আমি ফাইল বা ফোল্ডারগুলি সংজ্ঞায়িত করতে পারি যা সংস্করণ নিয়ন্ত্রণে পরীক্ষা করা উচিত নয়। যেমনটি আপনি বলেছিলেন যে এনভ ভার্সগুলি সত্যই সহায়তা করবে সেদিকে আমি দেখতে পাচ্ছি না, তবে এগুলি স্থাপনের জন্য আপনার কাছে একটি স্ক্রিপ্ট রয়েছে এবং প্রকল্পের সাথে একত্রে সংরক্ষণ করা উচিত বা আপনার সিস্টেমে এটি 'কোথাও' রয়েছে (হোম ডিরেক্টরি বা মেশিনগুলির প্রারম্ভকালেও স্ক্রিপ্টগুলি) যা নিজেরাই পুরোপুরি সমস্যা তৈরি করে বলে মনে হয়, বিশেষত যদি প্রচুর কনফিগারেশন প্রয়োজন হয়। যে কোনও ক্ষেত্রে আমি কনফিগার ফাইলগুলিকে বিভক্ত করব যাতে গোপনীয় তথ্য বিভিন্ন ফাইলে যায়।

— থারস্টেন মুলার

@ থারস্টেনমেলার - কেবলমাত্র বেস / টেমপ্লেট কনফিগারেশনটি .Gitignore সঞ্চিত থাকতে হবে যার অর্থ অ্যাপ্লিকেশনটিকে দুটি কনফিগার - একটি বেস পড়তে হবে - ডিফল্ট বিকল্পগুলি (স্কেমে সঞ্চিত) এবং স্থানীয় একটি, যা বেসকে ওভাররাইড করে (এবং স্কেমে সংরক্ষণ করা হয় না)। এনভ ভার্সের সাহায্যে, আমি কল্পনা করেছি যে গণ স্থাপনা আরও সহজ হয়ে যায় - কিছু ভারসাম্যহীন ফাইলে কিছু লেখার চেয়ে নতুন ভার্চুয়াল মেশিন সেটআপের জন্য পরিবেশের পরিবর্তনগুলি নির্দিষ্ট করা সহজ।

— রোগাচ

ভাল প্রশ্ন, আমি এর জন্য সাধারণ ব্যবহারকারী-নির্দিষ্ট অ্যাপ্লিকেশন ডেটা স্টোরটি ব্যবহার করা শুরু করার পরে, জীবন আরও সহজ হয়ে উঠল ;-)

— ওল্ফ

আপনি কি "রেডিস" redis.io চেষ্টা করেছেন ? এটি কেবলমাত্র মূল-মান কাঠামোর সঞ্চয় করার জন্য বোঝানো হয়েছে।

— করণ

@jporcenaluk - আমি কী-মূল্যের স্টোরগুলি পছন্দ করি তবে কনফিগার পরিচালনার জন্য হ্যান্ডেল করার জন্য অ্যাপ্লিকেশনটিতে একটি পূর্ণ বর্ধিত রেডিস যুক্ত করা কিছুটা ওভারকিলের মতো মনে হয়। অন্যদিকে, সম্ভবত আমি কখনও বড় পর্যাপ্ত প্রকল্পে কাজ করিনি।

— রোগাচ

Answer 1

সম্ভবত এটির উত্তম উত্তর নেই is দেখে মনে হচ্ছে আপনার নিরাপদে কোথাও এই ডেটা সংরক্ষণ করা দরকার, কারণ একদিন দুর্যোগ পুনরুদ্ধারের উদ্দেশ্যে এটির প্রয়োজন হবে। এটি বৈশিষ্ট্য ফাইল এবং স্ক্রিপ্টগুলির ক্ষেত্রে সমানভাবে প্রযোজ্য যা পরিবেশ ভেরিয়েবল সেট করে।

• উত্স কোড সহ (এসভিএন / জিআইটি ইত্যাদিতে) একটি সত্যই খারাপ ধারণা, কারণ এই ডেটাতে প্রোডাকশন ডাটাবেস পাসওয়ার্ড এবং এর মতো থাকবে।
• আপনার কর্পোরেট রাত্রে ব্যাকআপ যথেষ্ট হতে পারে, তবে পরিবর্তনের সহজেই অ্যাক্সেসযোগ্য ইতিহাস রাখার সম্ভাবনা নেই।
• গ্রাহক সফ্টওয়্যারটিতে ডেটা আলাদাভাবে সংস্করণ করা দরকার। আমাদের বর্তমান সিস্টেমে, কনফিগারেশন পরিবর্তনের ফলে একটি নতুন অ্যাপ্লিকেশন তৈরি হয় এবং এটি কেবল সাধারণ ভুল।

আমরা বর্তমানে এই সমস্যার সমাধান খুঁজছি, এবং সীমাবদ্ধ অ্যাক্সেস সহ একটি কোড সংগ্রহের দিকে ঝুঁকছি। এই সংগ্রহস্থলটিতে কেবল বর্ণনামূলক ডেটা থাকবে। অন্যদের ভাগ করার অভিজ্ঞতা আছে?

Comments

একটি প্রকল্পের জন্য দুটি পৃথক সংগ্রহস্থল থাকা ভাল ধারণা বলে মনে হচ্ছে না - আপনি পরিষ্কার রোলব্যাক করতে পারবেন না বা শাখাগুলি নিয়ে কাজ করতে পারবেন না, কারণ তখন আপনাকে একই সাথে দুটি ভাণ্ডার পরিচালনা করতে হবে (উদাহরণস্বরূপ অন্যান্য শাখায় কিছু নতুন কনফিগার বিকল্পের প্রয়োজন হবে এবং আপনি যখন কনফিগার সংগ্রহস্থল স্যুইচ না করেই সেই নতুন শাখায় স্যুইচ করুন, জিনিসগুলি অদ্ভুত উপায়ে বিভক্ত হয়)

— রোগাচ

@ রোগাচ আমি আপনার বক্তব্য গ্রহণ করি কোডটির সাথে কিছু কনফিগারেশন রাখার বৈধ কারণ রয়েছে, তবে আপনি আপনার প্রশ্নে যেমন সংবেদনশীল জিনিসগুলি অন্য কোথাও যেতে হবে। সুতরাং দুটি ভান্ডার অপরিহার্য বলে মনে হচ্ছে। এছাড়াও, আমি উল্লেখ করি নি যে অ্যাপ সার্ভারগুলি প্রায়শই এখানে সহায়তা করে। ডেটা উত্স এবং জেএনডিআই ভেরিয়েবলগুলি প্রশাসক সেট আপ করতে পারেন এবং এটি সর্বজনীন হবে না।

— কিউইরন

দ্বিতীয় স্টোরটি বোঝায়। গোপনীয় এছাড়াও গোপনীয় অন্যান্য ধরণের তথ্য থাকতে পারে (উদাহরণস্বরূপ গ্রাহকদের সমস্যা সমাধানের জন্য বিশ্লেষণধীন উত্পাদন ডেটা)।

— নেকড়ে

@ রোগাচ তারা মনে করে যে তারা প্রচুর ঘৃণা পোষণ করে তবে গিট সাবমোডিয়ুলগুলি এটি ঠিকঠাক করে দেবে, আমি মনে করি - যদি প্রধানটি সঠিকভাবে স্থাপন করা হয় এবং সীমাবদ্ধ-অ্যাক্সেসের রেপো কেবল তার ভিতরেই থাকতে পারত।

— সেলডমনিডি

Answer 2

সমস্যা এবং সম্ভাব্য সমাধানগুলি পরীক্ষা করার ক্ষেত্রে, এটি আমাকে জেফ অ্যাটউড দ্বারা জনপ্রিয় একটি পদ্ধতি ব্যবহার করতে সহায়তা করে : God শ্বর যদি সংবেদনশীল কনফিগারেশন তথ্য সংরক্ষণের জন্য কোনও উপায় তৈরি করেন, তবে তিনি কীভাবে করবেন?

ঠিক আছে, তিনি জানতেন যে কারা কনফিগারেশন তথ্য প্রয়োজন এবং কেবল সেই ব্যক্তিদেরই তা দেবেন এবং তথ্যটি অন্য কারও দ্বারা অ্যাক্সেস করতে সক্ষম হবে না।

প্রথম অংশটি ইতিমধ্যে যত্ন নেওয়া উচিত: আপনার উত্স নিয়ন্ত্রণ সিস্টেমটি ব্যবহারকারীদের প্রমাণীকরণ করা উচিত। এবং ট্রয় হান্টের সোর্স কন্ট্রোলের 10 কমান্ডের " 10 অনুসারে এই পদ্ধতিরও বৈধতা দেওয়া হয়েছে ," নির্ভরতা উত্স নিয়ন্ত্রণে থাকা দরকার "।

তবে এটি ফাঁস হলে কীভাবে সুরক্ষিত রাখা যায়? ঠিক আছে, এটি সরল পাঠ্যে সংরক্ষণ করার প্রয়োজন নেই! এনক্রিপশন ব্যবহার করুন। .NET- এ, আপনার কনফিগার ফাইলগুলিতে সংযোগ স্ট্রিং ডেটা এনক্রিপ্ট করতে আপনি নিতে পারেন এমন পদক্ষেপ রয়েছে । আপনার পছন্দের নির্দিষ্ট প্রযুক্তি ব্যবহারের জন্য আপনাকে সমতুল্য পদ্ধতিগুলি খুঁজে পেতে হবে।

Comments

কেবল স্পষ্ট করে বলতে চেয়েছিলেন - এনক্রিপ্ট করার কনফিগারেশন কীভাবে সহায়তা করবে? যেহেতু আমি এটি বুঝতে পেরেছি, আপনাকে সমস্ত বিকাশকারীদের মধ্যে একই ডিক্রিপশন পাসওয়ার্ড ভাগ করতে হবে এবং এটি সমস্যার জন্য আহ্বান করার মতো শোনাচ্ছে।

— রোগাচ

যদি আপনার সংস্থার বাইরের কেউ আপনার ভাণ্ডারে অ্যাক্সেস পান তবে আপনার পাসওয়ার্ডগুলি অবরুদ্ধ। যদি কেউ কোনও প্রকল্প থেকে ফাইলগুলি একটি ইউএসবি ড্রাইভে অনুলিপি করে এবং কোথাও ছেড়ে যায়, একই জিনিস। এটি অবশ্যই বজায় রাখা আরও কাজ হবে work আরও সুরক্ষা সাধারণত সুবিধার দামে আসে। এই সমাধানটি কিছুটা অপ্রয়োজনীয়, আমি আপনাকে এটি দেব। আমি ওপি'র প্রশ্ন সমাধানের আরও ভাল উপায়ে উন্মুক্ত!

— jporcenaluk

Answer 3

অনেকে আপনার উত্স কোডের সাথে নিয়মিত ফাইলগুলিতে কনফিগারেশন সংরক্ষণের সমালোচনা করে থাকেন তবে আমার অভিজ্ঞতায় এটি আসলে একটি খুব ভাল সমাধান:

• যে কোনও ভাষায় প্রয়োগ করা সহজ। অনেকগুলি, আপনি বাক্সের বাইরে জটিল কনফিগারেশন ফাইলগুলির জন্য সমর্থন পান। যেমন স্প্রিং বুটের সাথে জাভার ক্ষেত্রে, আপনি ওয়াইএএমএল সমর্থন পাবেন যা কোনও গাছের মতো কাঠামো প্রকাশ করতে পারে এবং বিভিন্ন পরিবেশের জন্য পৃথক কনফিগারেশন ফাইল পাশাপাশি পরিবেশ-নির্দিষ্ট ফাইলগুলি উত্তরাধিকারী হতে পারে এমন একটি বেসলাইন কনফিগারেশন রাখা সহজ।
• আপনার সফ্টওয়্যারটি চালানোর জন্য কনফিগারেশন প্রয়োজন, এবং কোড পরিবর্তন করার জন্য প্রায়শই কনফিগারেশন সেটিংস যুক্ত / সংশোধন করা প্রয়োজন, তাই কনফিগারেশন এবং কোড একসাথে রাখা স্বাভাবিক।
• উত্সটির সাথে কনফিগারেশন সংরক্ষণের মাধ্যমে উত্স নিয়ন্ত্রণের সমস্ত সুবিধা দেয় যেমন কোন নিয়মিত কোড পর্যালোচনা চলাকালীন কোনটি সেটিংটি কখন পরিবর্তন করেছে এবং কখন কনফিগারগুলি চেক করতে সক্ষম হবেন তা জানা।
• আপনি যদি সিআইএর পক্ষে কাজ না করেন তবে সুরক্ষার যুক্তি আমার কাছে বয়ে গেছে। সুতরাং আপনার অ্যাপ্লিকেশনটি চালিত করে এমন মেশিনে থাকা কোনও ফাইলে আপনার ডাটাবেসের পাসওয়ার্ড সংরক্ষণ করা হয়। ঠিক আছে, যদি কেউ আপনার অ্যাপ্লিকেশনটির সাথে মেশিনে অ্যাক্সেস পান তবে আপনি সম্ভবত ইতিমধ্যে অনেক সমস্যায় পড়েছেন - তারা উদাহরণস্বরূপ আপনার অ্যাপটি নামিয়ে নিতে এবং একই বন্দরে তার জায়গায় নিজস্ব অ্যাপ্লিকেশন শুরু করতে পারে। এই জাতীয় পরিস্থিতিতে, ডিবি পাসওয়ার্ড অ্যাক্সেস থাকা এত বড় সমস্যা নাও হতে পারে। আপনার সমস্ত সংযোগগুলি সম্পূর্ণরূপে এনক্রিপ্ট করা না থাকলে, আপনার মেশিনে অ্যাক্সেস থাকা না থাকলে তারা নেটওয়ার্ক ইন্টারফেস থেকে আকর্ষণীয় ডেটা বেশিরভাগই স্নিগ্ধ করতে পারে।
• আপনি পাঠ্য কনফিগারেশন ফাইল রাখতে হিয়েরার মতো একটি সরঞ্জাম ব্যবহার করতে পারেন তবে এর মধ্যে পাসওয়ার্ড বা অন্যান্য সংবেদনশীল ডেটা সংরক্ষণ করবেন না।

সুতরাং, অনেক ক্ষেত্রে কোডের সাথে উত্স নিয়ন্ত্রণে সঞ্চিত পাঠ্য কনফিগারেশন একটি ভাল শুরু।

আপনি যদি বিতরণ সিস্টেমে থাকেন বা আপনার অ্যাপ্লিকেশনগুলিকে পুনরায় প্রচার না করে আপনার কনফিগারেশনটি হট-সোপ করতে সক্ষম হতে চান তবে আপনি একটি কনফিগারেশন সার্ভারের উপর ভিত্তি করে সমাধানটি আরও ভালভাবে পেতে পারেন। স্প্রিং ক্লাউড যেমন ব্যবস্থাগুলির জন্য সমর্থন করে এবং ব্যাকএন্ড পরিবেশন কনফিগারেশনগুলি গিট সংগ্রহস্থল বা ইউরেকা হতে পারে । উদাহরণস্বরূপ চিড়িয়াখানা ব্যবহার করে আপনি নিজের রোলও করতে পারেন । এই পদ্ধতির যে কোনওটি আপনার সফ্টওয়্যারটিকে পুনর্নির্মাণ এবং পুনরায় প্রচার না করে কনফিগারেশন আপডেট করার জন্য অনেক সার্ভারে সামঞ্জস্যপূর্ণ কনফিগারেশন পরিচালনা করা সহজ করে তুলবে। এটি অবশ্যই ব্যয় করে আসে, যা কনফিগার সার্ভারটি শিখছে এবং কীভাবে এটি আপনার অ্যাপ্লিকেশনগুলি থেকে ব্যবহার করতে হবে পাশাপাশি আরও একটি সিস্টেম মোতায়েন ও রক্ষণাবেক্ষণ করতে পারে।

Comments

কোডটি এমন কাউকে হাত বদলে দেয় যার কনফিগারেশনের ফাইলগুলিতে গোপনীয়তা নেই, সেখানে সত্যিকারের জগাখিচুড়ি হতে চলেছে।

— টিম লুডভিনস্কি

@ টিমলডউইনস্কি কী / গোপনীয়তা কোম্পানির অন্তর্ভুক্ত, পৃথক বিকাশকারী নয়, তাই তাদের এমনভাবে বজায় রাখা উচিত যাতে কোনও একক ব্যক্তি চলে গেলে তারা যাতে হারিয়ে না যায়। এগুলি অ্যাডমিন / সুরক্ষা দল দ্বারা ইস্যু এবং রক্ষণাবেক্ষণ হতে পারে উদাহরণস্বরূপ, যাতে একটি কেন্দ্রীয় রেজিস্ট্রি থাকে।

— মিশা কোসমুলস্কি

Answer 4

আমি যেখানে কাজ করি সেখানেও আমরা একই সমস্যার সাথে লড়াই করছি। এই মুহুর্তে আমাদের সমস্ত কনফিগারেশন ফাইল-ভিত্তিক এবং উত্স দ্বারা ব্যবহৃত পৃথক অ্যাপ্লিকেশনগুলির সাথে নিয়ন্ত্রিত। এটি সদৃশ হয়ে যায় এবং বিকাশকারীদের কেবল উন্নয়নের পরিবর্তে উত্পাদন / কিউ পাসওয়ার্ড অ্যাক্সেস করে।

এটি বলেছিল আমি মনে করি আমরা এগিয়ে যাওয়ার একটি ভাল সমাধান নিয়ে এসেছি। আমরা আমাদের কনফিগারেশন ফাইলগুলিকে একটি পৃথক গিট রেপোতে স্থানান্তরিত করছি (কনফিগার রেপির লেবেলযুক্ত)। তারপরে আমরা একটি স্প্রিং-ক্লাউড-কনফিগার (জাভা) সার্ভার সেটআপ করি যা এটির মধ্যে দেওয়া প্রোফাইলগুলির উপর ভিত্তি করে কনফিগার রেপো থেকে ফাইলগুলি সরবরাহ করে। এটি জাভা অ্যাপ্লিকেশনগুলির জন্য দুর্দান্ত যা ক্লায়েন্টটি ব্যবহার করতে এবং প্রারম্ভকালে এগুলি ডাউনলোড করতে পারে। আমাদের পিএইচপি / জাভাবিহীন অ্যাপগুলির জন্য আমরা সরাসরি ফাইলটি নীচে নামিয়ে দেব। (আদর্শ নয়) ভবিষ্যতে আমরা এমন কিছু লিখতে পারি যা পিএইচপি অ্যাপ্লিকেশনটিকে নিজস্ব কনফিগারেশনগুলি ডাউনলোড করতে দেয় এবং সেগুলি কোথাও ক্যাশে করে দেয়, তবে এটি প্রথম রানের পক্ষে উচ্চ অগ্রাধিকার নয়। আমি এই সমাধানটিকে কনফিগার-এ-এ-পরিষেবা হিসাবে মনে করি যা 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। এটি একই প্যাটার্ন দেখায়।

সিক্রেটস ম্যানেজমেন্ট হ'ল আলাদা জন্তু। আপনি ছোট থাকাকালীন এগুলিকে ম্যানুয়াল পদক্ষেপ হিসাবে পরিচালনা করতে পারেন। আপনি চিড়িয়াখানার মতো জিনিস ব্যবহার করতে পারেন। এমনকি আপনি এনক্রিপ্ট করা আকারে একটি ভিসিএসে গোপনীয়তাগুলি পরীক্ষা করে দেখতে পারেন এবং এটিকে একটি মোতায়েনের পদক্ষেপ হিসাবে ডিক্রিপ্ট করতে পারেন। অন্যান্য অনেকগুলি বিকল্প বিদ্যমান।

(এছাড়াও, একটি মতামত টুকরা: জেএসএন একটি ভাল কনফিগার ফাইল ফর্ম্যাট নয়, কারণ এটি মন্তব্যগুলিকে অনুমতি দেয় না; মন্তব্যগুলি গুরুত্বপূর্ণ ML

Answer 6

আমি মনে করি আপনার অপশনগুলি কিছুটা ওএস দ্বারা সংজ্ঞায়িত করা হয়েছে যা আপনি মোতায়েন করছেন

আমি পরামর্শ দেব, হ্যাঁ মানগুলিকে উত্স নিয়ন্ত্রণে রাখুন। তবে কেবল 'দেব' সংস্করণ। আপনি আপনার উত্স কোডটি সংকলন করতে এবং কাজ করতে চান! অতিরিক্ত গোপন পদক্ষেপ অন্তর্ভুক্ত না

আপনার বিল্ড এবং মোতায়েন প্রক্রিয়াটি তখন মোতায়েনের সময় পরিবেশ অনুযায়ী এই মানগুলি অদলবদল করে। (অক্টোপাসের এই ধরণের মডেল রয়েছে)

Answer 7

অ্যাপাচি চিড়িয়াখানা বিতরণকারী সিস্টেমগুলির জন্য অ্যাপ্লিকেশন কনফিগারেশনগুলি সঞ্চয় করার জন্য দুর্দান্ত বিকল্প দেয়। চিড়িয়াখানায় করা পরিবর্তনগুলি অ্যাপ্লিকেশন শেষে কিউরেটর বা চিড়িয়াখানার শ্রোতা পেয়ে ক্যাপচার এবং প্রক্রিয়াজাত করা যায়।

Comments

বিকল্প গুলো কি? এটা কিভাবে কাজ করে? এটি কোথায় রাখে? একজনকে কি অন্যের চেয়ে বেশি পছন্দ করা হয়? প্রতিটি বিকল্পের বিভিন্ন সুবিধা এবং অসুবিধাগুলি কী কী? এটি কীভাবে বিভিন্ন অপারেটিং সিস্টেমে ইন্টারেক্ট করে?

@ গাংজ - আমি আরও বিস্তারিত উত্তরে আগ্রহী হব, দয়া করে নিম্নবিত্তরা নিরুৎসাহিত হন না এবং আপনার উত্তরটি উন্নত করুন যাতে এটি সহায়ক হতে পারে।

— জে এলস্টন