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

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

নতুন সার্ভারের কমিশনিং কঠোরভাবে একটি সময়সীমার সাথে আবদ্ধ ছিল। এবং এটি সরানোর অর্থ হল এক বিলিয়ন উপহারের চালান এবং সিস্টেমের স্থানান্তর উভয়কেই বিপদে ফেলা। এমনকি ফাদার ফ্রস্ট এবং সান্তা ক্লজের সমন্বয়ে গঠিত একটি দল তারিখ পরিবর্তন করতে পারেনি - আপনি বছরে শুধুমাত্র একবার গুদাম ব্যবস্থাপনার জন্য SAP সিস্টেম স্থানান্তর করতে পারেন। 31 ডিসেম্বর থেকে 1 জানুয়ারি পর্যন্ত, খুচরা বিক্রেতার বিশাল গুদাম, মোট 20টি ফুটবল মাঠের আকার, 15 ঘন্টা তাদের কাজ বন্ধ করে দেয়। এবং এটি সিস্টেম সরানোর জন্য একমাত্র সময়কাল। সার্ভার প্রবর্তন করার সময় আমাদের ত্রুটির জন্য কোন জায়গা ছিল না।

আমাকে পরিষ্কার করা যাক: আমার গল্প আমাদের দল ব্যবহার করে সরঞ্জাম এবং কনফিগারেশন পরিচালনার প্রক্রিয়া প্রতিফলিত করে।

কনফিগারেশন ম্যানেজমেন্ট কমপ্লেক্স বিভিন্ন স্তর নিয়ে গঠিত। মূল উপাদান হল CMS সিস্টেম। শিল্প অপারেশনে, একটি স্তরের অনুপস্থিতি অনিবার্যভাবে অপ্রীতিকর অলৌকিক ঘটনা ঘটবে।

ওএস ইনস্টলেশন ব্যবস্থাপনা

প্রথম স্তরটি শারীরিক এবং ভার্চুয়াল সার্ভারে অপারেটিং সিস্টেমের ইনস্টলেশন পরিচালনার জন্য একটি সিস্টেম। এটি মৌলিক ওএস কনফিগারেশন তৈরি করে, মানব ফ্যাক্টরকে দূর করে।

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

ইনস্টলেশন ম্যানেজমেন্ট সিস্টেমের জন্য "সর্বোচ্চ" টাস্ক হল স্বয়ংক্রিয়ভাবে BIOS/ফার্মওয়্যার স্তর থেকে OS পর্যন্ত সার্ভারগুলি কনফিগার করা৷ এখানে অনেক কিছু নির্ভর করে সরঞ্জাম এবং সেটআপ কাজের উপর। ভিন্নধর্মী সরঞ্জামের জন্য, আপনি বিবেচনা করতে পারেন REDFISH API. যদি সমস্ত হার্ডওয়্যার এক বিক্রেতার কাছ থেকে হয়, তবে প্রায়শই তৈরি ব্যবস্থাপনার সরঞ্জামগুলি ব্যবহার করা আরও সুবিধাজনক (উদাহরণস্বরূপ, এইচপি আইএলও অ্যামপ্লিফায়ার, ডেল ওপেনম্যানেজ, ইত্যাদি)।

ফিজিক্যাল সার্ভারে OS ইনস্টল করার জন্য, আমরা সুপরিচিত Cobbler ব্যবহার করেছি, যা অপারেশন পরিষেবার সাথে সম্মত ইনস্টলেশন প্রোফাইলের একটি সেট সংজ্ঞায়িত করে। পরিকাঠামোতে একটি নতুন সার্ভার যোগ করার সময়, ইঞ্জিনিয়ার সার্ভারের MAC ঠিকানাটি Cobbler-এ প্রয়োজনীয় প্রোফাইলের সাথে বেঁধে দেন। প্রথমবারের জন্য নেটওয়ার্ক বুট করার সময়, সার্ভার একটি অস্থায়ী ঠিকানা এবং একটি নতুন OS পেয়েছে। তারপর এটি লক্ষ্য VLAN/IP ঠিকানায় স্থানান্তরিত হয় এবং সেখানে কাজ চালিয়ে যায়। হ্যাঁ, VLAN পরিবর্তন করতে সময় লাগে এবং সমন্বয় প্রয়োজন, কিন্তু এটি একটি উত্পাদন পরিবেশে সার্ভারের দুর্ঘটনাজনিত ইনস্টলেশনের বিরুদ্ধে অতিরিক্ত সুরক্ষা প্রদান করে।

আমরা HashiSorp প্যাকার ব্যবহার করে প্রস্তুত টেমপ্লেটের উপর ভিত্তি করে ভার্চুয়াল সার্ভার তৈরি করেছি। কারণটি একই ছিল: ওএস ইনস্টল করার সময় সম্ভাব্য মানবিক ত্রুটিগুলি প্রতিরোধ করা। কিন্তু, ফিজিক্যাল সার্ভারের বিপরীতে, প্যাকার PXE, নেটওয়ার্ক বুটিং এবং VLAN পরিবর্তনের প্রয়োজনীয়তা দূর করে। এটি ভার্চুয়াল সার্ভার তৈরি করা সহজ এবং সহজ করে তুলেছে।

ভাত। 1. অপারেটিং সিস্টেমের ইনস্টলেশন পরিচালনা করা।

গোপনীয়তা পরিচালনা

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

আপনি যদি প্রথম থেকেই এই গোপনীয়তাগুলি কোথায় এবং কীভাবে সংরক্ষণ করবেন তা নির্ধারণ না করেন, তবে তথ্য সুরক্ষা প্রয়োজনীয়তার তীব্রতার উপর নির্ভর করে, নিম্নলিখিত স্টোরেজ পদ্ধতিগুলি সম্ভবত:

• সরাসরি কনফিগারেশন কন্ট্রোল কোডে বা সংগ্রহস্থলের ফাইলগুলিতে;
• বিশেষ কনফিগারেশন পরিচালনার সরঞ্জামগুলিতে (উদাহরণস্বরূপ, উত্তরযোগ্য ভল্ট);
• CI/CD সিস্টেমে (Jenkins/TeamCity/GitLab/etc.) অথবা কনফিগারেশন ম্যানেজমেন্ট সিস্টেমে (Ansible Tower/Ansible AWX);
• গোপনীয়তাও "ম্যানুয়ালি" স্থানান্তর করা যেতে পারে। উদাহরণস্বরূপ, এগুলি একটি নির্দিষ্ট স্থানে রাখা হয় এবং তারপরে সেগুলি কনফিগারেশন ম্যানেজমেন্ট সিস্টেম দ্বারা ব্যবহৃত হয়;
• উপরের বিভিন্ন সমন্বয়।

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

আমরা কেন্দ্রীয় গোপন স্টোরেজ HashiCorp ভল্ট ব্যবহার করেছি। এটি আমাদের অনুমতি দিয়েছে:

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

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

আমরা আমাদের সিস্টেমে আরেকটি স্তর যোগ করি: গোপনীয়তা ব্যবস্থাপনা এবং কেন্দ্রীয় প্রমাণীকরণ/অনুমোদন:

ভাত। 2. গোপন ব্যবস্থাপনা।

কনফিগারেশন ব্যবস্থাপনা

আমরা মূলে পৌঁছেছি - CMS সিস্টেম। আমাদের ক্ষেত্রে, এটি Ansible এবং Red Hat Ansible AWX এর সংমিশ্রণ।

Ansible এর পরিবর্তে Chef, Puppet, SaltStack ব্যবহার করা যেতে পারে। আমরা বেশ কয়েকটি মানদণ্ডের উপর ভিত্তি করে Ansible বেছে নিয়েছি।

• প্রথমত, এটি বহুমুখীতা। নিয়ন্ত্রণের জন্য প্রস্তুত মডিউলগুলির একটি সেট এটা চিত্তাকর্ষক. এবং যদি আপনার কাছে এটি যথেষ্ট না থাকে তবে আপনি গিটহাব এবং গ্যালাক্সিতে অনুসন্ধান করতে পারেন।
• দ্বিতীয়ত, পরিচালিত সরঞ্জামগুলিতে এজেন্ট ইনস্টল এবং সমর্থন করার প্রয়োজন নেই, প্রমাণ করুন যে তারা লোডের সাথে হস্তক্ষেপ করে না এবং "বুকমার্ক" এর অনুপস্থিতি নিশ্চিত করুন।
• তৃতীয়ত, Ansible এর প্রবেশে কম বাধা রয়েছে। একজন দক্ষ প্রকৌশলী পণ্যটির সাথে কাজ করার প্রথম দিনে আক্ষরিক অর্থে একটি কার্যকরী প্লেবুক লিখবেন।

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

এই ধরনের সমস্যার সিংহভাগই রেড হ্যাট দ্বারা সমাধান করা হয়েছে উত্তরযোগ্য টাওয়ার, অথবা তার ওপেন সোর্স আপস্ট্রিম প্রকল্প উত্তরযোগ্য AWX. এজন্য আমরা এটিকে গ্রাহকের জন্য পছন্দ করেছি।

এবং আমাদের CMS সিস্টেমের প্রতিকৃতিতে আরও একটি স্পর্শ। উত্তরযোগ্য প্লেবুক কোড রিপোজিটরি ম্যানেজমেন্ট সিস্টেমে সংরক্ষণ করা উচিত। আমাদের এটা আছে গিটল্যাব সিই.

সুতরাং, কনফিগারেশনগুলি নিজেই Ansible/Ansible AWX/GitLab এর সমন্বয় দ্বারা পরিচালিত হয় (চিত্র 3 দেখুন)। অবশ্যই, AWX/GitLab একটি একক প্রমাণীকরণ সিস্টেমের সাথে সমন্বিত, এবং Ansible প্লেবুক HashiCorp ভল্টের সাথে একত্রিত করা হয়েছে। কনফিগারেশনগুলি শুধুমাত্র উত্তরযোগ্য AWX-এর মাধ্যমে উত্পাদন পরিবেশে প্রবেশ করে, যেখানে সমস্ত "গেমের নিয়ম" নির্দিষ্ট করা আছে: কে কী কনফিগার করতে পারে, CMS-এর জন্য কনফিগারেশন ম্যানেজমেন্ট কোড কোথায় পেতে হবে ইত্যাদি।

ভাত। 3. কনফিগারেশন ব্যবস্থাপনা।

পরীক্ষা ব্যবস্থাপনা

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

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

• প্রতিটি ভূমিকা ইউনিট পরীক্ষা দ্বারা আচ্ছাদিত করা হয়;
• যখনই কনফিগারেশনগুলি পরিচালনা করে এমন কোডে কোনও পরিবর্তন হয় তখন পরীক্ষাগুলি স্বয়ংক্রিয়ভাবে চালানো হয়;
• কনফিগারেশন ম্যানেজমেন্ট কোডের পরিবর্তনগুলি সমস্ত পরীক্ষা এবং কোড পর্যালোচনা সফলভাবে পাস করার পরেই উৎপাদন পরিবেশে প্রকাশ করা হয়।

কোড ডেভেলপমেন্ট এবং কনফিগারেশন ম্যানেজমেন্ট শান্ত এবং আরও অনুমানযোগ্য হয়ে উঠেছে। ক্রমাগত পরীক্ষার আয়োজন করতে, আমরা গিটল্যাব সিআই/সিডি টুলকিট ব্যবহার করেছি এবং নিয়েছি উত্তরযোগ্য অণু.

যখনই কনফিগারেশন ম্যানেজমেন্ট কোডে পরিবর্তন হয়, গিটল্যাব সিআই/সিডি অণুকে কল করে:

• এটি কোড সিনট্যাক্স চেক করে,
• ডকার কন্টেইনার বাড়ায়,
• তৈরি করা পাত্রে পরিবর্তিত কোড প্রয়োগ করে,
• বুদ্ধিমত্তার জন্য ভূমিকা পরীক্ষা করে এবং এই কোডের জন্য পরীক্ষা চালায় (এখানে গ্রানুলারিটি দায়বদ্ধ ভূমিকার স্তরে, চিত্র 4 দেখুন)।

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

ভাত। 4. গিটল্যাব সিআই/সিডি-তে ভূমিকাগুলির স্বয়ংক্রিয় পরীক্ষা।

উৎপাদন ব্যবস্থার অপারেশনের সাথে যুক্ত একটি সমস্যাও রয়েছে। বাস্তব জীবনে, একা সিএমএস কোডের মাধ্যমে কনফিগারেশন পরিবর্তন করা খুব কঠিন। জরুরী পরিস্থিতি দেখা দেয় যখন একজন প্রকৌশলীকে কোড এডিটিং, টেস্টিং, অনুমোদন ইত্যাদির জন্য অপেক্ষা না করে "এখানে এবং এখন" কনফিগারেশন পরিবর্তন করতে হবে।

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

অতএব, ক্রমাগত পরীক্ষার পাশাপাশি, আমরা কনফিগারেশনের অসঙ্গতির জন্য উত্পাদন পরিবেশ পরীক্ষা করি। আমরা সবচেয়ে সহজ বিকল্পটি বেছে নিয়েছি: "ড্রাই রান" মোডে CMS কনফিগারেশন কোড চালানো, অর্থাৎ পরিবর্তনগুলি প্রয়োগ না করে, কিন্তু পরিকল্পিত এবং প্রকৃত কনফিগারেশনের মধ্যে সমস্ত অসঙ্গতির বিজ্ঞপ্তি সহ। আমরা প্রোডাকশন সার্ভারে “—চেক” বিকল্প সহ সমস্ত উত্তরযোগ্য প্লেবুকগুলিকে পর্যায়ক্রমে চালিয়ে এটি বাস্তবায়ন করেছি। বরাবরের মতো, প্লেবুক চালু এবং আপ টু ডেট রাখার জন্য Ansible AWX দায়ী (চিত্র 5 দেখুন):

ভাত। 5. উত্তরযোগ্য AWX-এ কনফিগারেশনের অসঙ্গতির জন্য পরীক্ষা করে।

চেক করার পরে, AWX প্রশাসকদের কাছে একটি বৈষম্য প্রতিবেদন পাঠায়। তারা সমস্যাযুক্ত কনফিগারেশন অধ্যয়ন করে এবং তারপর সামঞ্জস্যপূর্ণ প্লেবুকের মাধ্যমে এটি ঠিক করে। এইভাবে আমরা উত্পাদন পরিবেশে কনফিগারেশন বজায় রাখি এবং CMS সর্বদা আপ টু ডেট এবং সিঙ্ক্রোনাইজ হয়। এটি অপ্রীতিকর "অলৌকিক ঘটনা" দূর করে যখন CMS কোড "উৎপাদন" সার্ভারে ব্যবহার করা হয়।

আমাদের কাছে এখন উত্তরযোগ্য AWX/GitLab/Molecule সমন্বিত একটি গুরুত্বপূর্ণ টেস্টিং স্তর রয়েছে (চিত্র 6)।

ভাত। 6. পরীক্ষা ব্যবস্থাপনা।

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

সার্ভার এবং পরিবেশের সেটিংসে আজ কোন "গোপন জ্ঞান" নেই। সমস্ত প্রয়োজনীয় বৈশিষ্ট্য প্লেবুকে প্রতিফলিত হয়। আর সৃজনশীলতা এবং অস্পষ্ট নির্দেশাবলী নেই: "এটিকে নিয়মিত ওরাকলের মতো ইনস্টল করুন, তবে আপনাকে কয়েকটি sysctl সেটিংস নির্দিষ্ট করতে হবে এবং প্রয়োজনীয় UID সহ ব্যবহারকারীদের যোগ করতে হবে। অপারেশন বলছি জিজ্ঞাসা, তারা জানে».

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

এবং অবশ্যই, আমরা বেশ কয়েক দিন থেকে কয়েক ঘন্টা পর্যন্ত সার্ভার চালু করার প্রক্রিয়াটিকে ত্বরান্বিত করেছি।

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

PS আমাদের দল প্রায়ই এই সত্যের মুখোমুখি হয় যে গ্রাহকরা যতটা সম্ভব সহজভাবে কনফিগারেশন পরিচালনার সমস্যাগুলি সমাধান করতে চান। আদর্শভাবে, যেন জাদু দ্বারা - একটি টুল দিয়ে। তবে জীবনে সবকিছু আরও জটিল (হ্যাঁ, সিলভার বুলেটগুলি আবার বিতরণ করা হয়নি): আপনাকে গ্রাহকের দলের জন্য সুবিধাজনক সরঞ্জামগুলি ব্যবহার করে একটি সম্পূর্ণ প্রক্রিয়া তৈরি করতে হবে।

লেখক: সের্গেই আর্টেমভ, বিভাগের স্থপতি DevOps সমাধান "জেট ইনফোসিস্টেমস"

উত্স: www.habr.com