পাঠ ৩৮ · ৫৭-এর মধ্যে · মডিউল ৯
Home / Courses / Cloud Computing & DevOps / কনফিগারেশন ম্যানেজমেন্ট

কনফিগারেশন ম্যানেজমেন্ট পরিচিতি

Configuration management intro (Ansible / Chef / Puppet)
৮ মিনিট পড়া মধ্যবর্তী · Intermediate Python কোডসহ সম্পূর্ণ বাংলায়

এই পাঠে যা শিখবেন

  • কনফিগারেশন ম্যানেজমেন্ট কী এবং এটি IaC (M5) থেকে কীভাবে আলাদা কাজ করে অথচ একসাথে ব্যবহৃত হয়
  • এজেন্টলেস বনাম এজেন্ট-বেসড টুলের মধ্যে পার্থক্য ও ট্রেড-অফ
  • কেন একটি ভালো কনফিগারেশন ম্যানেজমেন্ট প্লেবুক অবশ্যই ইডেমপোটেন্ট হতে হবে
  • Python দিয়ে একটি ইডেমপোটেন্ট প্লেবুক সিমুলেশন লিখে দেখানো যে দ্বিতীয়বার চালালে কোনো পরিবর্তন হয় না

১ · কনফিগারেশন ম্যানেজমেন্ট কী ও কেন দরকার

M5-এর Infrastructure as Code (Terraform-স্টাইল) একটি VM, স্টোরেজ বা নেটওয়ার্ক প্রভিশন করে — কিন্তু একবার একটি VM তৈরি হয়ে গেলে, তার ভেতরে কী সফটওয়্যার প্যাকেজ ইনস্টল থাকবে, কোন কনফিগ ফাইলে কী সেটিং থাকবে, কোন ইউজার/পারমিশন থাকবে — এসব ব্যবস্থাপনা করে কনফিগারেশন ম্যানেজমেন্টConfiguration Managementপ্রভিশন করা সার্ভারের ভেতরের সফটওয়্যার প্যাকেজ, কনফিগ ফাইল ও সেটিংস স্বয়ংক্রিয়ভাবে ব্যবস্থাপনা করার টুল — উদাহরণ: Ansible, Chef, Puppet। টুল। এটি IaC-কে প্রতিস্থাপন করে না, বরং সম্পূরক করে — একটি খুবই সাধারণ বিভাজন হলো "Terraform VM প্রভিশন করে, তারপর Ansible সেই VM-এর ভেতরে কী ইনস্টল ও কনফিগার হবে তা ঠিক করে।"

২ · এজেন্টলেস বনাম এজেন্ট-বেসড

কনফিগারেশন ম্যানেজমেন্ট টুলগুলো মূলত দুই ধরনের —

  • এজেন্টলেস (Ansible-স্টাইল) — কন্ট্রোল মেশিন থেকে সরাসরি SSH-এর মাধ্যমে সংযোগ করে কমান্ড চালায়; ম্যানেজড মেশিনে আগে থেকে কিছু ইনস্টল করে রাখতে হয় না — সেটআপ সহজ, শুরু করা দ্রুত।
  • এজেন্ট-বেসড (Chef/Puppet-স্টাইল) — প্রতিটি ম্যানেজড মেশিনে একটি স্থায়ী এজেন্ট প্রক্রিয়া চলে, যা পর্যায়ক্রমে কেন্দ্রীয় সার্ভার থেকে কনফিগারেশন টেনে নিয়ে নিজে থেকেই প্রয়োগ করে — এই ধারাবাহিক "pull" মডেলের কারণে কনফিগারেশন ড্রিফট (L39) স্বয়ংক্রিয়ভাবে ও নিয়মিত সংশোধন হতে থাকে, কিন্তু প্রতিটি মেশিনে এজেন্ট চালানো ও ম্যানেজ করার বাড়তি ওভারহেড থাকে।
ট্রেড-অফ

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

৩ · ইডেমপোটেন্ট প্লেবুক — বারবার চালালেও নিরাপদ

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

Python
# একটি এজেন্টলেস "প্লেবুক" রান সিমুলেট করা — প্রতিটি টাস্ক ইডেমপোটেন্ট
# (fake in-memory সার্ভার স্টেট — real SSH/Ansible কল নয়)

server_state = {
    "packages_installed": set(),
    "config_settings": {},
}

def ensure_package_installed(state, package_name):
    if package_name in state["packages_installed"]:
        return f"প্যাকেজ '{package_name}' — কোনো পরিবর্তন লাগেনি (ইতিমধ্যে ইনস্টল আছে)"
    state["packages_installed"].add(package_name)
    return f"প্যাকেজ '{package_name}' — ইনস্টল করা হলো"

def ensure_config_setting(state, key, desired_value):
    if state["config_settings"].get(key) == desired_value:
        return f"সেটিং '{key}' — কোনো পরিবর্তন লাগেনি (ইতিমধ্যে '{desired_value}')"
    state["config_settings"][key] = desired_value
    return f"সেটিং '{key}' — '{desired_value}'-এ সেট করা হলো"

def run_playbook(state):
    results = []
    results.append(ensure_package_installed(state, "nginx"))
    results.append(ensure_package_installed(state, "python3"))
    results.append(ensure_config_setting(state, "firewall_enabled", True))
    results.append(ensure_config_setting(state, "max_connections", 1000))
    return results

print("প্রথম রান —")
for line in run_playbook(server_state):
    print(" ", line)

print("\nদ্বিতীয় রান (একই প্লেবুক, একই সার্ভার) —")
for line in run_playbook(server_state):
    print(" ", line)

    
লক্ষ্য করুন — প্রথম রানে প্রতিটি টাস্ক প্রকৃত পরিবর্তন করে ("ইনস্টল করা হলো", "সেট করা হলো"), কিন্তু দ্বিতীয় রানে একই server_state-এর উপর চালানোর ফলে প্রতিটি টাস্ক "কোনো পরিবর্তন লাগেনি" রিপোর্ট করে — এটিই ইডেমপোটেন্সির ব্যবহারিক প্রমাণ, এবং এই গ্যারান্টি ছাড়া একটি প্লেবুক প্রতিবার চালানোর সময় অপ্রত্যাশিত সাইড-এফেক্ট তৈরি করতে পারত (যেমন একটি সার্ভিস অপ্রয়োজনীয়ভাবে বারবার রিস্টার্ট হওয়া)।
মূল কথা · Key takeaway

IaC (M5) ইনফ্রাস্ট্রাকচার প্রভিশন করে, কনফিগারেশন ম্যানেজমেন্ট তার ভেতরের সফটওয়্যার/সেটিংস ব্যবস্থাপনা করে — দুটোই ইডেমপোটেন্সির একই মূলনীতি মেনে চলে যাতে বারবার প্রয়োগ করা নিরাপদ থাকে। L39-এ আমরা দেখব এই ইডেমপোটেন্সি না মানলে কী হয় — কনফিগারেশন ড্রিফট।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ একটি টিম কেন Terraform (IaC) দিয়ে VM-এর ভেতরের সফটওয়্যার প্যাকেজও ম্যানেজ করার চেষ্টা না করে আলাদা করে Ansible ব্যবহার করে?

Terraform মূলত ইনফ্রাস্ট্রাকচার রিসোর্স (VM, নেটওয়ার্ক, স্টোরেজ) তৈরি/ধ্বংস করার জন্য ডিজাইন করা — একবার একটি VM তৈরি হয়ে গেলে তার ভেতরের অবস্থা (কোন প্যাকেজ ইনস্টল, কোন ফাইল কী কনটেন্ট) ক্রমাগত পরিবর্তন ও ব্যবস্থাপনা করার জন্য এটি উপযুক্ত টুল নয়। Ansible-এর মতো টুল বিশেষভাবে এই "ভেতরের অবস্থা ব্যবস্থাপনা" কাজের জন্য তৈরি — দুটো টুল তাদের নিজ নিজ শক্তির জায়গায় ব্যবহার করাই স্বাভাবিক ও কার্যকর।

প্র ০২ একটি বিশাল প্রতিষ্ঠান, যাদের হাজার হাজার সার্ভার আছে এবং ক্রমাগত কমপ্লায়েন্স যাচাই প্রয়োজন, কেন এজেন্ট-বেসড টুল (Chef/Puppet-স্টাইল) বেছে নিতে পারে?

এত বিশাল স্কেলে ম্যানুয়ালি বা নির্দিষ্ট সময়ে প্লেবুক চালিয়ে ড্রিফট ধরা কঠিন ও ধীর — এজেন্ট-বেসড মডেলে প্রতিটি মেশিনের এজেন্ট নিয়মিত (যেমন প্রতি ৩০ মিনিটে) নিজে থেকেই কনফিগারেশন যাচাই ও সংশোধন করে, ফলে কমপ্লায়েন্স লঙ্ঘন (যেমন একটি নিরাপত্তা সেটিং কেউ ম্যানুয়ালি বদলে দিয়েছে) স্বয়ংক্রিয়ভাবে ও দ্রুত ধরা পড়ে ও সংশোধন হয় — এই ধারাবাহিক নিশ্চয়তা এজেন্ট চালানোর বাড়তি খরচকে ন্যায্যতা দেয়।

প্র ০৩ উপরের কোডে যদি ensure_package_installed ফাংশনটি প্রতিবার শর্ত ছাড়াই state["packages_installed"].add(...) কল করত (কোনো if-চেক ছাড়াই), তাহলে কি সেটি এখনো ইডেমপোটেন্ট থাকত?

হ্যাঁ, এই নির্দিষ্ট ক্ষেত্রে থাকত — কারণ Python-এর set.add() নিজেই ইডেমপোটেন্ট (একই আইটেম বারবার যোগ করলেও সেটে একটিই কপি থাকে)। কিন্তু বাস্তব প্লেবুক টাস্কে (যেমন একটি সার্ভিস রিস্টার্ট করা, বা একটি ফাইলে লাইন অ্যাপেন্ড করা) শর্ত ছাড়া বারবার চালালে প্রতিবারই একটি সাইড-এফেক্ট (রিস্টার্ট, ডুপ্লিকেট লাইন) ঘটতে পারে — তাই সাধারণভাবে if-চেক ছাড়া ইডেমপোটেন্সি নিশ্চিত করা যায় না, এই উদাহরণটি একটি সুরক্ষিত বিশেষ ক্ষেত্র মাত্র।

অনুশীলন

  1. পরীক্ষা করুন: উপরের কোড সেলে দ্বিতীয় রানের আগে server_state["config_settings"]["max_connections"] = 500 চালিয়ে একটি ম্যানুয়াল ("বাইরের") পরিবর্তন সিমুলেট করুন, তারপর run_playbook আবার চালান — কী হয়?

    এবার max_connections টাস্কটি দেখবে বর্তমান মান (৫০০) কাঙ্ক্ষিত মানের (১০০০) সাথে মেলে না, তাই এটি আবার পরিবর্তন করে ১০০০-এ ফিরিয়ে দেবে এবং "সেট করা হলো" রিপোর্ট করবে — এটিই দেখায় প্লেবুক ম্যানুয়াল ড্রিফট শনাক্ত করে সংশোধন করতে পারে, যদি কেউ সেটি চালায় (এজেন্টলেস মডেলে এটি স্বয়ংক্রিয় নয়, কাউকে চালাতে হয়)।

  2. চিন্তা করুন: আপনার পরিচিত কোনো একটি ম্যানুয়াল, বারবার করা সার্ভার-সেটআপ কাজ (উদাহরণ: একটি নতুন ডেভেলপার মেশিনে প্রয়োজনীয় সফটওয়্যার ইনস্টল করা) ভাবুন — কীভাবে সেটিকে একটি ইডেমপোটেন্ট প্লেবুক হিসেবে লিখতেন?

    উদাহরণ: একটি নতুন ডেভেলপার মেশিন সেটআপের জন্য একটি প্লেবুক হতে পারে — "চেক করো Python 3.11 ইনস্টল আছে কিনা, না থাকলে ইনস্টল করো; চেক করো Git কনফিগার করা আছে কিনা, না থাকলে কনফিগার করো; চেক করো প্রয়োজনীয় VS Code এক্সটেনশনগুলো ইনস্টল আছে কিনা, না থাকলে ইনস্টল করো" — প্রতিটি ধাপ শর্তসাপেক্ষ, তাই একবার সঠিকভাবে সেটআপ হয়ে গেলে প্লেবুক আবার চালালেও কিছুই বদলাবে না।

আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ

পূর্ববর্তী পাঠ
L37 · ডিপ্লয়মেন্ট স্ট্র্যাটেজি — ব্লু-গ্রিন, ক্যানারি, রোলিং