১৭ সেপ, ২০২৫·8 মিনিট
কেন থম্পসনের UNIX নীতিসমূহ: কন্টেইনার ও ক্লাউড OS-এর পেছনের ধারণা
Ken Thompson-এর UNIX নীতিগুলো—ছোট টুল, পাইপ, ফাইল ও পরিষ্কার ইন্টারফেস—কিভাবে কন্টেইনার, লিনাক্স, ও ক্লাউড অবকাঠামো গঠনে প্রভাব ফেলেছে তা অন্বেষণ করুন।
Ken Thompson-এর UNIX নীতিগুলো—ছোট টুল, পাইপ, ফাইল ও পরিষ্কার ইন্টারফেস—কিভাবে কন্টেইনার, লিনাক্স, ও ক্লাউড অবকাঠামো গঠনে প্রভাব ফেলেছে তা অন্বেষণ করুন।
Ken Thompson কখনই “চিরন্তন অপারেটিং সিস্টেম” বানাতে চেয়েছিলেন না। Dennis Ritchie এবং Bell Labs-এর অন্যদের সঙ্গে তিনি এমন একটি ছোট, ব্যবহারযোগ্য সিস্টেম বানাতে চেয়েছিলেন যা ডেভেলপাররা বুঝতে পারে, উন্নত করতে পারে, এবং মেশিন বদলালে স্থানান্তর করতে পারে। UNIX বাস্তবিক লক্ষ্য দিয়ে গড়ে উঠেছিল: কোরকে সোজা রাখো, টুলগুলোকে একত্রে ভালভাবে কাজ করতে দাও, এবং ব্যবহারকারীকে এক কম্পিউটার মডেলে আটকে রাখো না।
অবাক করার বিষয় হল—যে প্রথম সিদ্ধান্তগুলো নেওয়া হয়েছিল, সেগুলো আধুনিক কম্পিউটিংয়ের সঙ্গে কতটা ভালো মিল খায়। আমরা টার্মিনাল বদলে ওয়েব ড্যাশবোর্ড পেয়েছি এবং একক সার্ভার বদলে ভার্চুয়াল মেশিনের ফ্লিট, কিন্তু একই প্রশ্নগুলো বারবার উঠে আসে:
নির্দিষ্ট UNIX ফিচারগুলো বদলায় (বা প্রতিস্থাপিত হয়েছে), কিন্তু নকশার নীতিগুলো কার্যকর থেকেছে কারণ সেগুলো বর্ণনা করে কিভাবে সিস্টেম বানাতে হয়:
এসব ধারণা সর্বত্র দেখা যায়—Linux ও POSIX কম্প্যাটিবিলিটি থেকে শুরু করে এমন কন্টেইনার রানটাইম পর্যন্ত যা প্রসেস আইসোলেশন, নেমস্পেস এবং ফাইলসিস্টেম ট্রিকসের ওপর নির্ভর করে।
আমরা Thompson-জমানার UNIX ধারণাগুলোকে আজকের বাস্তবে যেভাবে দেখা যায় তার সঙ্গে যোগ করব:
এটি একটি ব্যবহারিক গাইড: কম জড়িত শব্দ, বাস্তব উদাহরণ, এবং “কেন এটা কাজ করে”–এর ওপর জোর—ট্রিভিয়ার ওপর নয়। যদি আপনি কন্টেইনার ও ক্লাউড OS আচরণ বোঝার জন্য দ্রুত মানসিক মডেল চান, আপনি সঠিক স্থানে এসেছেন।
আপনি যখন প্রস্তুত থাকবেন, তখন সরাসরি /blog/how-unix-ideas-show-up-in-containers-এ লাফ দিতে পারেন।
UNIX কোনো ভুগর্ভ প্ল্যাটফর্ম কৌশল হিসেবে শুরু হয়নি। এটি Ken Thompson (Dennis Ritchie এবং Bell Labs-এর অন্যান্যদের গুরুত্বপূর্ণ অবদান সহ) তৈরি করা একটি ছোট, কাজ করে এমন সিস্টেম হিসেবে শুরু হয়েছিল যা স্বচ্ছতা, সাদাসিধে এবং কার্যকর কাজকে অগ্রাধিকার দেয়।
প্রারম্ভিক দিনে অপারেটিং সিস্টেমগুলো প্রায়শই নির্দিষ্ট কম্পিউটার মডেলের সাথে গভীরে গেঁথে থাকত। হার্ডওয়্যার বদলালে আপনাকে কার্যত আপনার OS (এবং প্রায়ই আপনার সফটওয়্যার) ও পরিবর্তন করতে হত।
একটি পোর্টেবল OS দরকারি অর্থে এমন কিছু: একই অপারেটিং সিস্টেমের ধারণা এবং কোড অনেকটা একই রকম বিভিন্ন মেশিনে আবারো লেখা ছাড়াই চালানো যায়। UNIX-কে C-এ প্রকাশ করে, দলটি যেকোনো এক CPU-র ওপর নির্ভরতা কমিয়ে দিল এবং অন্যদের কাছে UNIX গ্রহণ ও অভিযোজন করা বাস্তবসম্মত করে তুলল।
যখন লোকজন “UNIX” বলে, তারা হয়তো মূল Bell Labs সংস্করণ, একটি বাণিজ্যিক ভ্যারিয়েন্ট, অথবা আধুনিক UNIX-সদৃশ সিস্টেম (যেমন Linux বা BSD) বোঝায়। সাধারণ সূত্রটি একক ব্র্যান্ডের চেয়ে কম—এটি একটি সাধারণ নকশা পছন্দ ও ইন্টারফেসের সেট।
এখানেই POSIX গুরুত্বপূর্ণ: এটি অনেক UNIX আচরণ (কমান্ড, সিস্টেম কল, ও রীতিনীতি) কোডিফাই করে, যাতে সফটওয়্যার বিভিন্ন UNIX এবং UNIX-সদৃশ সিস্টেমে কম অবাঞ্ছিত পরিবর্তন নিয়ে কাজ করতে পারে।
UNIX একটি প্রতারণাক্রমে সহজ নিয়ম প্রচলিত করেছিল: এমন প্রোগ্রাম তৈরি করো যা একটি কাজ ভালভাবে করে, এবং এগুলোকে একত্রে ব্যবহার করা সহজ করো। Ken Thompson ও প্রাথমিক UNIX দল টিকে বড়, অল-ইন-ওয়ান অ্যাপ্লিকেশন বানানোর লক্ষ্য রাখেননি। তারা ছোট ইউটিলিটিস লক্ষ্য করেছিলেন যাদের আচরণ স্পষ্ট—তাহলে সেগুলোকে একত্রে স্ট্যাক করে বাস্তব সমস্যা সমাধান করা যায়।
একটি টুল যা একটি কাজ ভালো করে, তা বোঝা সহজ কারণ কম চলমান অংশ থাকে। এটি টেস্টও করা সহজ: আপনি একটি পরিচিত ইনপুট খাইয়েই আউটপুট পরীক্ষা করতে পারেন পুরো পরিবেশ সেটআপ না করেই। যখন চাহিদা বদলায়, আপনি পুরো কিছু পুনরায় না লিখে একটি অংশ প্রতিস্থাপন করতে পারেন।
এই পদ্ধতি “প্রতিস্থাপনযোগ্যতা”ও উৎসাহিত করে। যদি একটি ইউটিলিটি ধীরগতি, সীমাবদ্ধ বা কোন ফিচার নেই, আপনি এটিকে একটি ভাল বিকল্প দিয়ে বদলে দিতে পারেন (বা একটি নতুন লিখে ফেলতে পারেন) যদি এটি একই বেসিক ইনপুট/আউটপুট প্রত্যাশা বজায় রাখে।
UNIX টুলগুলোকে LEGO ইটের মতো ভাবুন। প্রতিটি ইট সহজ। শক্তি আসে কীভাবে সেগুলো একে অপরের সাথে জোড়া যায়।
একটি ক্লাসিক উদাহরণ হল টেক্সট প্রসেসিং, যেখানে আপনি ধাপে ধাপে ডাটা ট্রান্সফর্ম করেন:
cat access.log | grep \" 500 \" | sort | uniq -c | sort -nr | head
যদি আপনি কমান্ডগুলো মনে না রাখেন, ধারণা স্পষ্ট: ডাটা দিয়ে শুরু করে সেটি ফিল্টার করো, সারসংক্ষেপ করো, এবং শীর্ষ ফলাফল দেখাও।
মাইক্রোসার্ভিসগুলো “নেটওয়ার্কের ওপর UNIX টুল” নয়, এবং সেই তুলনা জোর করলে বিভ্রান্তি বাড়ে। কিন্তু অন্তর্নিহিত প্রবণতা পরিচিত: উপাদানগুলোকে কেন্দ্রীভূত রাখো, পরিষ্কার সীমানা নির্ধারণ করো, এবং ছোট অংশগুলোর সমন্বয় থেকে বড় সিস্টেম গঠন করো যাতে তারা স্বাধীনভাবে বিকশিত হতে পারে।
UNIX একটি সহজ রীতিনীতি থেকে অনেক শক্তি পেয়েছিল: প্রোগ্রামগুলোকে একটি নির্দিষ্ট জায়গা থেকে ইনপুট পড়া এবং আরেক জায়গায় আউটপুট লেখা উচিত। সেই রীতিনীতি ছোট টুলগুলোকে পুনঃলিখন ছাড়াই বড় “সিস্টেম”ে মিলাতে পারার পথ দেয়।
একটি পাইপ একটি কমান্ডের আউটপুটকে সরাসরি আরেকটি কমান্ডের ইনপুটে বয়ে নিয়ে যায়। এটি এমন যেন একটি টুল টেক্সট তৈরি করে, পরবর্তী টুল সেটি গ্রহণ করে।
UNIX টুলগুলো সাধারণত তিনটি স্ট্যান্ডার্ড চ্যানেল ব্যবহার করে:
এই চ্যানেলগুলো সঙ্গতিপূর্ণ হওয়ায়, আপনি প্রোগ্রামগুলোকে তাদের একে অপরকে না জেনে “ওয়্যার” করতে পারেন।
পাইপ টুলগুলোকে ছোট ও ফোকাসড থাকতে উৎসাহিত করে। যদি একটি প্রোগ্রাম stdin গ্রহণ করতে পারে এবং stdout ইমিট করতে পারে, এটি অনেক প্রসঙ্গে পুনঃব্যবহারযোগ্য হয়ে ওঠে: ইন্টারঅ্যাকটিভ ব্যবহার, ব্যাচ জব, নির্ধারিত কাজ, ও স্ক্রিপ্ট। এই কারণেই UNIX-সদৃশ সিস্টেম স্ক্রিপ্ট-বন্ধুভাবাপন্ন: অটোমেশন প্রায়ই “এই অংশগুলোকে সংযুক্ত কর” মাত্র।
এই কম্পোজিবিলিটি সরাসরি প্রাথমিক UNIX থেকে আজকের ক্লাউড ওয়ার্কফ্লো তৈরির ধারায় চলে এসেছে।
UNIX একটি সাহসী সরলীকরণ করেছে: অনেক ভিন্ন রিসোর্সকে ফাইল হিসেবে আচরণ করাও। এটা নয় যে ডিস্ক ফাইল এবং কীবোর্ড একই, বরং তাদের একটি শেয়ার্ড ইন্টারফেস (open, read, write, close) দিলে সিস্টেম বোঝা ও অটোমেট করা সহজ হয়।
/dev/-এ দেখা যায়। /dev/urandom থেকে পড়া ফাইল পড়ার মতোই লাগে, যদিও এটা ডিভাইস ড্রাইভার যা বাইট তৈরি করছে।\n- সকেট ও পাইপ: নেটওয়ার্ক কানেকশন ও ইন্টার-প্রসেস কমিউনিকেশন ফাইল ডিসক্রিপ্টরের মাধ্যমে প্রকাশ পেতে পারে—আপনার প্রোগ্রাম বাইট লিখে, OS এগুলোকে রুট করে দেয়।\n- কনফিগারেশন: প্লেইন টেক্সট কনফিগ ফাইল একই টুলস ব্যবহার করে সম্পাদনা, ভ্যালিডেট ও Git-এ ট্র্যাক করা যায়।\n- লগস: লগগুলো প্রায়শই অ্যাপেন্ড-ওনলি ফাইল। তাই সেগুলো রোটেট, grep, tail, আর্কাইভ ও শিপ করা সহজ।যখন রিসোর্সগুলো একটি ইন্টারফেস শেয়ার করে, আপনি লিভারেজ পান: ছোট টুলের সেট অনেক প্রসঙ্গে কাজ করতে পারে। যদি “আউটপুট বাইট” এবং “ইনপুট বাইট” হয়, তাহলে সরল ইউটিলিটিস অনন্ত পথে মিলিত হতে পারে—প্রতিটি টুলকে ডিভাইস, নেটওয়ার্ক, বা কের্নেলের বিশেষ জ্ঞান দরকার নেই।
এটি স্থিতিশীলতাও উৎসাহিত করে। টিমগুলো কয়েকটি প্রিমিটিভ (read/write স্ট্রিম, ফাইল পথ, অনুমতি) নিয়ে স্ক্রিপ্ট ও অপারেশনাল অভ্যাস গড়ে তুলতে পারে এবং বিশ্বাস করতে পারে যে সেই প্রিমিটিভগুলো underlying প্রযুক্তি বদলালেও বারবার বদলাবে না।
আধুনিক ক্লাউড অপারেশনগুলো এখনও এই ধারণার ওপর নির্ভর করে। কন্টেইনার লগ সাধারণত এমন স্ট্রিম হিসেবে দেখা হয় যা আপনি টেইল করে ফরওয়ার্ড করতে পারেন। Linux-এর /proc প্রসেস ও সিস্টেম টেলিমেট্রি ফাইল হিসেবে প্রকাশ করে, তাই মনিটরিং এজেন্টগুলো CPU, মেমরি ও প্রসেস স্ট্যাটস “পড়তে” পারে যেন সেগুলো সাধারণ টেক্সট। সেই ফাইল আকৃতির ইন্টারফেস অপজার্ভেবিলিটি ও অটোমেশনে গ্রহণযোগ্যতা বাড়ায়—এছাড়াও বড় স্কেলে।
UNIX-এর পারমিশন মডেল দেখায় দৈবহীনভাবে ছোট: প্রতিটি ফাইল (এবং অনেক সিস্টেম রিসোর্স যা ফাইলের মতো আচরণ করে) একটি মালিক, একটি গ্রুপ, এবং তিনটি শ্রোতার জন্য একটি অনুমতি সেট—ইউজার, গ্রুপ, এবং অন্যরা—থাকে। মাত্র কিছু read/write/execute বিট দিয়ে UNIX এমন একটি সাধারণ ভাষা স্থাপন করেছে যার মাধ্যমে বলা যায় কে কী করতে পারে।
যদি আপনি কখনও -rwxr-x--- এর মতো কিছু দেখেন, আপনি এক লাইনে পুরো মডেলই দেখেছেন:
এই কাঠামো স্কেলে ভালো কাজ করে কারণ এটি সহজে বিচার্য এবং অডিটযোগ্য। এটি টিমগুলোকে একটি পরিষ্কার অভ্যাসের দিকে ধাক্কা দেয়: কাজ করার জন্য সবকিছু “ওপেন” করে দেওয়া উচিত নয়।
Least privilege মানে কোনো ব্যক্তি, প্রসেস, বা সার্ভিসকে শুধুমাত্র সেই অনুমতিগুলো দেওয়া যা তার কাজ করার জন্য দরকার—আর কিছু নয়। বাস্তবে সেটা প্রায়ই মানে:
ক্লাউড প্ল্যাটফর্মগুলো এবং কন্টেইনার রানটাইমগুলো একই ধারণা বিভিন্ন টুল দিয়ে মেলায়:
UNIX অনুমতিগুলো মূল্যবান—কিন্তু সম্পূর্ণ নিরাপত্তা কৌশল নয়। এগুলো সব ডেটা লিক প্রতিরোধ করে না, দুর্বল কোডের শোষণ ঠেকায় না, বা নেটওয়ার্ক নিয়ন্ত্রণ ও সিক্রেট ম্যানেজমেন্টকে প্রতিস্থাপন করে না। এগুলোকে ভিত্তি হিসেবে দেখুন: প্রয়োজনীয়, বোঝার যোগ্য, এবং কার্যকর—কিন্তু একা যথেষ্ট নয়।
UNIX একটি প্রসেস—কোনো জিনিসের চলমান ইনস্ট্যান্স—কে একটি কেন্দ্রিয় বিল্ডিং ব্লক হিসেবে দেখে, পেছনের দিকে ফেলে রাখা ধারণা নয়। এটা বিমূর্ত শোনালেও থাকার থেকে বোঝা যায় কীভাবে এটি নির্ভরযোগ্যতা, মাল্টিটাস্কিং, এবং modernen সার্ভার (এবং কন্টেইনার) একটি মেশিন শেয়ার করে তা গঠিত করে।
একটি প্রোগ্রাম হলো একটি রেসিপি কার্ড: এটা কি করতে হবে তা বর্ণনা করে।
একটি প্রসেস হলো সেই রেসিপি থেকে কার্যকরীভাবে রান করা রাঁধুনি: তার কাছে চলমান ধাপ, বস্তুপত্র সাজানো, স্টোভ, এবং টাইমার আছে। একই রেসিপি থেকে একাধিক রাঁধুনি রান করতে পারে—প্রতিটি প্রসেস আলাদা স্টেট রাখে, যদিও তারা একই প্রোগ্রাম থেকেই শুরু করেছে।
UNIX সিস্টেমগুলো এমনভাবে ডিজাইন করা যে প্রতিটি প্রসেসের নিজস্ব “বাবল” থাকে: নিজের মেমরি, ওপেন ফাইলগুলোর নিজস্ব ভিউ, এবং স্পষ্ট সীমা যা তা স্পর্শ করতে পারে।
এই আইসোলেশন গুরুত্বপূর্ণ কারণ ব্যর্থতাগুলো আটকে যায়। একটি প্রসেস ক্র্যাশ করলে সাধারণত অন্যগুলোকে নিয়ে নেয় না। এজন্যই এক মেশিনে অনেক সার্ভিস চালানো স্বাভাবিক: একটি ওয়েব সার্ভার, একটি ডেটাবেস, একটি ব্যাকগ্রাউন্ড শিডিউলার, লগ শিপার—প্রত্যেকটি আলাদা প্রসেস হিসেবে শুরু, বন্ধ, পুনরায় শুরু ও মনিটর করা যায়।
শেয়ার্ড সিস্টেমে আইসোলেশন আরও নিরাপদ রিসোর্স শেয়ারিং সমর্থন করে: অপারেটিং সিস্টেম CPU টাইম বা মেমরির মতো সীমা আরোপ করে এবং একটি রানের প্রসেস পুরো সিস্টেমকে ক্ষুধা না দেয় তা প্রতিরোধ করে।
UNIX এছাড়াও সিগন্যাল প্রদান করে, সিস্টেম (বা আপনি) একটি প্রসেসকে হালকাভাবে জানাতে পারে—এক ধরণের কাঁধে ট্যাপের মতো:
ইন্টারঅ্যাকটিভ ব্যবহারে জব কন্ট্রোল এই ধারণার ওপর দাঁড়ায়: আপনি একটি টাস্ক পজ, রেজিউম, বা ব্যাকগ্রাউন্ডে চালিয়ে দিতে পারেন। বিষয়টি কেবল সুবিধার নয়—এটা বোঝায় যে প্রসেসগুলো জীবন্ত ইউনিট হিসেবে পরিচালিত হওয়ার জন্যই তৈরি।
একবার প্রসেস তৈরি করা, আইসোলেট করা, এবং নিয়ন্ত্রণ করা সহজ হলে এক মেশিনে অনেক ওয়ার্কলোড নিরাপদে চালানো স্বাভাবিক হয়ে ওঠে। সেই মানসিক মডেল—ছোট ইউনিট যেগুলো পরিদর্শনযোগ্য, পুনরায় চালানো যায়, এবং সীমাবদ্ধ—আজকের সার্ভিস ম্যানেজার ও কন্টেইনার রানটাইমের সরাসরি পূর্বপুরুষ।
UNIX জিতেনি কারণ এতে প্রথমে সব ফিচার ছিল। এটি টিকে আছে কারণ এটি কয়েকটি ইন্টারফেসকে বিরক্তিকরভাবে ব্যাকরণগতভাবে অপরিবর্তিত করে রেখেছিল। যখন ডেভেলপাররা একই সিস্টেম কল, একই কমান্ড-লাইন আচরণ, এবং একই ফাইল রীতিনীতি বছরের পর বছর বিশ্বাস করতে পারে, তখন টুলগুলো জমে যায় পুনরায় লেখা না হয়ে।
একটি ইন্টারফেস হলো একটি প্রোগ্রাম এবং তার চারপাশের সিস্টেমের মধ্যে চুক্তি: “তুমি যদি X চাও, তুমি Y পাবে।” UNIX কয়েকটি মূল চুক্তি স্থিতিশীল রাখায় (প্রসেস, ফাইল ডিসক্রিপ্টর, পাইপ, অনুমতি) নতুন ধারণাগুলো পুরনো সফটওয়্যার ভাঙা ছাড়াই তাদের উপরে বেড়ে উঠতে দিয়েছে।
লোকেরা প্রায়ই “API কম্প্যাটিবিলিটি” বলে, কিন্তু এখানে দুইটি স্তর আছে:
স্থিতিশীল ABI ইকোসিস্টেমগুলো দীর্ঘস্থায়ী হয়: এগুলো আগে-থাকা বিল্ট সফটওয়্যারকে রক্ষা করে।
POSIX এমন একটি স্ট্যান্ডার্ড প্রচেষ্টা যা একটি সাধারণ “UNIX-সদৃশ” ইউজার-স্পেস ধরেছে: সিস্টেম কল, ইউটিলিটিস, শেল আচরণ, এবং রীতিনীতি। এটি প্রতিটি সিস্টেমকে একরকম করে না, কিন্তু একটি বড় ওভারল্যাপ তৈরি করে যেখানে একই সফটওয়্যার Linux, BSDs, এবং অন্যান্য UNIX-উৎপন্ন সিস্টেমে তৈরি ও ব্যবহার করা যায়।
কন্টেইনার ইমেজগুলো নীরবে স্থিতিশীল UNIX-সদৃশ আচরণের ওপর নির্ভর করে। অনেক ইমেজ ধারণা করে:
কন্টেইনারগুলো পোর্টেবল মনে হয় না কারণ সেগুলো “সবকিছু” নিয়ে আসে, বরং কারণ এগুলো একটি ব্যাপকভাবে শেয়ার করা, স্থিতিশীল চুক্তির ওপর বসে। সেই চুক্তি UNIX-এর একটি সবচেয়ে স্থায়ী অবদান।
কন্টেইনার আধুনিক মনে হলেও মানসিক মডেল খুবই UNIX: একটি রানিং প্রোগ্রামকে প্রসেস হিসেবে দেখো যার ফাইল, অনুমতি, এবং রিসোর্স সীমা স্পষ্টভাবে নির্ধারিত।
একটি কন্টেইনার হল একটি সেট স্বাভাবিক প্রসেস হোস্টে যা প্যাকেজড (একটি অ্যাপ্লিকেশন প্লাস তার লাইব্রেরি ও কনফিগ) এবং আইসোলেট করা হয়েছে যাতে সেগুলো একা যেন আচরণ করে। বড় পার্থক্য: কন্টেইনারগুলো হোস্ট কের্নেল শেয়ার করে, যেখানে VM-গুলো তাদের নিজস্ব কের্নেল চালায়।
অনেক কন্টেইনার ফিচার সরাসরি UNIX ধারণার সম্প্রসারণ:
দুইটি কের্নেল মেকানিজম প্রায় সব ভারি কাজ করে:
কারণ কন্টেইনারগুলো কের্নেল শেয়ার করে, আইসোলেশন সম্পূর্ণ নয়। একটি কের্নেল দুর্বলতা সব কন্টেইনারকে প্রভাবিত করতে পারে, এবং ভুল কনফিগারেশন (root হিসেবে চালানো, অত্যাধিক capabilities, সংবেদনশীল হোস্ট পাথ মাউন্ট করা) সীমানায় ছিদ্র করতে পারে। “এস্কেপ” ঝুঁকি বাস্তব—কিন্তু প্রায়শই ভাল ডিফল্ট, সর্বনিম্ন অনুমতি, এবং চৌকস অপারেশনাল হাইজিন দ্বারা প্রতিরোধ করা যায়।
UNIX ছোট টুল বানানোর, পরিষ্কার ইন্টারফেসে সংযুক্ত করার, এবং পরিবেশকে ওয়্যারিং হ্যান্ডেল করতে দেওয়ার একটি সহজ অভ্যাস প্রচলিত করেছিল। ক্লাউড-নেটিভ সিস্টেম বাইরের দিক থেকে আলাদা দেখালেও, একই ধারণা বিতরণ কাজের সঙ্গে আশ্চর্যজনকভাবে ভাল মিল খায়: সেবাগুলো ফোকাসড থাকে, ইন্টিগ্রেশন পয়েন্টগুলো স্পষ্ট থাকে, এবং অপারেশনগুলো পূর্বানুমেয় থাকে।
একটি ক্লাস্টারে, “ছোট টুল” প্রায়ই মানে “ছোট কন্টেইনার”। একটি বড় ইমেজ যা সবকিছু করে দেওয়ার বদলে টিমগুলো দায়িত্বগুলো কবে কন্টেইনারে ভাগ করে: সংক্ষিপ্ত, টেস্টযোগ্য আচরণ এবং স্থিতিশীল ইনপুট/আউটপুট।
কিছু সাধারণ উদাহরণ ক্লাসিক UNIX কম্পোজিশনের অনুরূপ:
প্রতিটি অংশের একটি পরিষ্কার ইন্টারফেস আছে: একটি পোর্ট, একটি ফাইল, একটি HTTP এন্ডপয়েন্ট, বা stdout/stderr।
পাইপ প্রোগ্রামগুলোকে সংযুক্ত করেছিল; আধুনিক প্ল্যাটফরমগুলো টেলিমেট্রি স্ট্রিম সংযুক্ত করে। লগ, মেট্রিক, এবং ট্রেসগুলি এজেন্ট, কালেক্টর, এবং ব্যাকএন্ডের মধ্য দিয়ে পাইপলাইনের মতো প্রবাহিত হয়:
application → node/sidecar agent → collector → storage/alerts.
জিতাটা একই: আপনি ধাপে ধাপে স্টেজ (ফিল্টারিং, স্যাম্পলিং, এনরিচমেন্ট) প্রবেশ করাতে, বদলে দিতে বা সরাতে পারেন টিউল পুনরায় লেখা ছাড়াই।
কম্পোজেবল বিল্ডিং ব্লকগুলো ডিপ্লয়মেন্টকে পুনরাবৃত্তিমূলক করে: “কিভাবে এটা চালাবো” যুক্তি ডিক্লারেটিভ ম্যানিফেস্ট ও অটোমেশনে থাকে, কারো স্মৃতিতে নয়। স্ট্যান্ডার্ড ইন্টারফেস আপনাকে পরিবর্তন রোল আউট, ডায়াগনস্টিক যোগ, এবং নীতিমালা জোরদার করতে দেয় সার্ভিসগুলোর উপর—একটি ছোট ইউনিটে করে।
এক কারণ যে UNIX নীতি বারবার উঠছে হল এগুলো টিমগুলো কীভাবে কাজ করে তার সাথে মেলে: ছোট ধাপে করতে পুনরাবৃত্তি, ইন্টারফেস স্থিতিশীল রাখা, এবং যখন বিস্ময় ঘটে তখন রোলব্যাক করা।
আপনি আজ ওয়েব সার্ভিস বা অভ্যন্তরীণ টুল বানালে, প্ল্যাটফর্মগুলোর মধ্যে Koder.ai এই মাইন্ডসেটকে কম ঘর্ষণ দিয়ে প্রয়োগ করার একটি মতামতপূর্ণ উপায়—আপনি চ্যাটে সিস্টেম বর্ণনা করেন, ছোট উপাদানগুলোতে পুনরাবৃত্তি করেন, এবং সীমানা স্পষ্ট রাখেন (ফ্রন্টএন্ড React-এ, ব্যাকএন্ড Go-তে PostgreSQL-এ, মোবাইল Flutter-এ)। planning mode, snapshots and rollback, এবং source code export এর মতো ফিচার UNIX উৎসাহিত অপারেশনাল অভ্যাসগুলো (নিরাপদে পরিবর্তন করুন, ফলাফল পর্যবেক্ষণ করুন, এবং সিস্টেম ব্যাখ্যাযোগ্য রাখুন) সহায়ক।
UNIX ধারণাগুলো কের্নেল ডেভেলপারের জন্যই সীমাবদ্ধ নয়। এগুলো ব্যবহারিক অভ্যাস যা দৈনন্দিন ইঞ্জিনিয়ারিংকে শান্ত করে: কম বিস্ময়, পরিষ্কার ব্যর্থতা, এবং এমন সিস্টেম যা পুনর্লিখন ছাড়া বিকাশ পায়।
ছোট ইন্টারফেস বোঝা, ডকুমেন্ট করা, টেস্ট করা, এবং প্রতিস্থাপন করা সহজ। যখন আপনি একটি সার্ভিস এন্ডপয়েন্ট, CLI ফ্ল্যাগ সেট, বা অভ্যন্তরীণ লাইব্রেরি ডিজাইন করেন:
UNIX টুলগুলো সাধারণত স্বচ্ছ: আপনি কি করে তা দেখতে পারেন এবং কি তৈরি করছে পরীক্ষা করতে পারেন। সার্ভিস ও পাইপলাইনের জন্য একই মানদন্ড প্রয়োগ করুন:
আপনার টিম যদি কন্টেইনারাইজড সার্ভিস বানায়, তাহলে বেসিকগুলো পুনর্বিবেচনা করুন: /blog/containers-basics।
অটোমেশন ঝুঁকি কমাতে হবে, বাড়াতে নয়। কাজের জন্য সর্বনিম্ন অনুমতি ব্যবহার করুন:
অনুমতি এবং কেন এটা গুরুত্বপূর্ণ সম্পর্কে একটি ব্যবহারিক রিফ্রেশের জন্য দেখুন: /blog/linux-permissions-explained।
কোনো নতুন ডিপেন্ডেন্সি গ্রহণের আগে (ফ্রেমওয়ার্ক, ওয়ার্কফ্লো ইঞ্জিন, প্ল্যাটফর্ম ফিচার), তিনটি প্রশ্ন জিজ্ঞাসা করুন:
যদি কোনোটির উত্তর “না” হয়, আপনি কেবল টুল কিনছেন না—আপনি লক‑ইন ও লুকানো জটিলতাও কিনছেন।
UNIX দুটি বিপরীত মিথকে আকৃষ্ট করে—যা উভয়ই বিষয়টি মিস করে।
UNIX একটি ইনস্টলযোগ্য প্রোডাক্ট নয়—এটি ইন্টারফেস সম্পর্কে ধারণার একটি সেট। বিশদ অংশ বদলেছে (Linux, POSIX, systemd, কন্টেইনার), কিন্তু সেই অভ্যাসগুলো যেগুলো UNIX-কে ব্যবহারযোগ্য করেছিল সেগুলো এখনো যেখানে বোঝা, ডিবাগ ও বিস্তৃত করা লাগবে সেখানে দেখা যায়। যখন আপনার কন্টেইনার লগ স্ট্যান্ডার্ড আউটপুটে যায়, যখন একটি টুল পাইপ থেকে ইনপুট গ্রহণ করে, বা যখন অনুমতিগুলো বিস্তার সীমাবদ্ধ করে—আপনি একই মানসিক মডেল ব্যবহার করছেন।
ছোট টুলের কম্পোজিবিলিটি টিমগুলোকে কেবল “চতুর” না করে “স্পষ্ট” তৈরি করার লোভে ফেলতে পারে। কম্পোজিশন একটি শক্তিশালী টুল: এটি শক্তিশালীভাবে কাজ করে যখন শক্ত রীতিনীতি ও সাবধান সীমা থাকে।
অতিরিক্ত বিভাজন সাধারণ: কাজগুলোকে ডজনখানেক মাইক্রোসার্ভিস বা ক্ষুদ্র স্ক্রিপ্টে বণ্টন করা “ছোট ভালো” হওয়ার নামে, পরে সমন্বয়, ভার্সনিং, এবং ক্রস‑সার্ভিস ডিবাগিংয়ে ব্যয় বহন করতে হয়।
শেল-স্ক্রিপ্ট বিস্মৃতি আরেকটি: দ্রুত গ্লু কোড প্রোডাকশন-ক্রিটিক্যাল হয়ে পড়ে বিনা টেস্ট, এরর হ্যান্ডলিং, অবজার্ভেবিলিটি, বা মালিকানা—ফলাফল: সরলতা নয়, ভঙ্গুর একটিimplicit নির্ভরতার জাল।
ক্লাউড প্ল্যাটফর্ম UNIX-এর শক্তি (স্থিতিশীল ইন্টারফেস, আইসোলেশন, অটোমেশন) বাড়িয়ে দেয়, কিন্তু তারা বিমূর্ততার স্তরও বাড়ায়: কন্টেইনার রানটাইম, অর্কেস্ট্রেটর, সার্ভিস মেশ, ম্যানেজড DB, IAM লেয়ার—প্রত্যেক স্তর লোকাল চেষ্টা কমায় কিন্তু বিশ্বব্যাপী “কোথায় ব্যর্থ হলো?” অনিশ্চয়তা বাড়ায়। নির্ভরযোগ্যতা কাজ কোড লেখা থেকে সীমা, ডিফল্ট, ও ব্যর্থতার মোড বোঝার দিকে সরে যায়।
Ken Thompson-এর UNIX নীতি এখনও গুরুত্বপূর্ণ কারণ সেগুলো সিস্টেমগুলোকে ছোট ইন্টারফেস, কম্পোজেবল বিল্ডিং ব্লক, এবং least privilege-এর প্রতি পক্ষপাতিত করে। বিবেচনাপূর্ণভাবে প্রয়োগ করলে এগুলো আধুনিক অবকাঠামো পরিচালনা সহজ ও নিরাপদ করে। কড়া ভাবে পালন করলে এগুলো অনাবশ্যক বিভাজন ও ডিবাগ করতে কষ্টকর জটিলতা তৈরি করে। লক্ষ্য 1970-এর UNIX অনুকরণ করা নয়—বজ্রপাতের সময় সিস্টেমটিকে ব্যাখ্যাযোগ্য রাখা।
Ken Thompson এবং Bell Labs-এর দল বোঝার যোগ্য, পরিবর্তনযোগ্য সিস্টেম নিয়ে কাজ করেছিল: একটি ছোট কোর, সহজ রীতিনীতি, এবং এমন টুলস যা পুনঃকম্পোজ করা যায়। সেই সিদ্ধান্তগুলো আজও অটোমেশন, আইসোলেশন এবং বড় সিস্টেম বজায় রাখার মতো আধুনিক চাহিদার সাথে স্পষ্টভাবে মিলে যায়।
UNIX-কে C-এ পুনরায় লেখা করলে নির্দিষ্ট CPU বা হার্ডওয়্যার মডেলের উপর নির্ভরতা অনেক কমে যায়। এর ফলে OS (এবং তার উপর নির্মিত সফটওয়্যার) বিভিন্ন মেশিনে চালানো বাস্তবসম্মত হয়ে ওঠে—এটি পরে POSIX-এর মতো পোর্টেবিলিটি প্রত্যাশার ওপর বড় প্রভাব ফেলে।
POSIX একটি সাধারণ UNIX-সদৃশ আচরণ (সিস্টেম কল, ইউটিলিটিস, শেল রীতিনীতি) সংজ্ঞায়িত করে। এটি প্রতিটি সিস্টেমকে অভিন্ন করে না, কিন্তু একটি বড় কম্প্যাটিবিলিটি অঞ্চল তৈরি করে যাতে বিভিন্ন UNIX ও UNIX-সদৃশ সিস্টেমে সফটওয়্যার কম বিস্ময়ে তৈরি ও চালানো যায়।
ছোট টুল মানে সহজে বোঝা যায়, টেস্ট করা যায় এবং প্রতিস্থাপন করা যায় এমন উপাদান। যখন প্রতিটি টুলের ইনপুট/আউটপুট চুক্তি পরিষ্কার থাকে, তখন বড় সমস্যা সমাধান করা যায় সেগুলোকে একসাথে জুড়ে—প্রায়ই টুলগুলোর নিজেই পরিবর্তন না করেই।
একটি পাইপ (|) একটি প্রোগ্রামের stdout কে পরবর্তী প্রোগ্রামের stdin-এ সংযুক্ত করে, যা আপনাকে একটি রুপান্তর পাইপলাইন বানাতে দেয়। stderr আলাদা রাখা অটোমেশনের জন্য সাহায্য করে: সাধারণ আউটপুট প্রক্রিয়াকরণ করা যায় রেখেই ত্রুটিগুলো আলাদাভাবে দেখা বা রিডাইরেক্ট করা যায়।
UNIX অনেক রিসোর্সকে ফাইল হিসাবে উপস্থাপন করার একটি সার্বজনীন ইন্টারফেস ব্যবহার করে—open, read, write, close—আর তাই একই টুল ও অভ্যাস বিভিন্ন প্রসঙ্গে কাজ করে।
সাধারণ উদাহরণ: /dev-এর ডিভাইস ফাইল এবং /proc-র টেলিমেট্রি-সদৃশ ফাইলগুলো।
মালিক/গ্রুপ/অন্যান্য এবং পড়া/লেখা/চালানোর বিটগুলো অনুমতিগুলোকে সহজে বিচারযোগ্য ও অডিটযোগ্য করে তোলে। লিস্ট প্রিভিলেজ মানে কাজটুকুই করতে যথেষ্ট অনুমতি দেওয়া—আর কিছু নয়।
প্রায়োগিক ধাপগুলো:
একটি প্রোগ্রাম স্থির কোড; একটি প্রসেস হলো চলমান ইনস্ট্যান্স যার নিজস্ব অবস্থা রয়েছে। UNIX-এ প্রসেস আইসোলেশন নির্ভরযোগ্যতা বাড়ায় কারণ একটি প্রসেস ক্র্যাশ করলে সাধারণত অন্যগুলো ক্ষতিগ্রস্ত হয় না, এবং প্রসেসগুলো সিগন্যাল ও exit কোড দিয়ে পরিচালনা করা যায়।
এই মডেলটি আধুনিক সেবা সুপারভিশন ও ম্যানেজমেন্টের (স্টার্ট/স্টপ/রিস্টার্ট/মনিটর) ভিত্তি।
স্থিতিশীল ইন্টারফেসগুলো হল দীর্ঘমেয়াদি চুক্তি (সিস্টেম কল, স্ট্রিম, ফাইল ডেসক্রিপ্টর, সিগন্যাল) যা টুলগুলোকে বারবার পুনর্লিখনের বদলে জমতে দেয়।
কন্টেইনার ইমেজগুলো এই ধরনের UNIX-সদৃশ আচরণে নির্ভর করে।
কন্টেইনারকে লাইটওয়েট VM না বলে বরং প্রসেস আইসোলেশন প্লাস প্যাকেজিং হিসেবে দেখাই ভালো। কন্টেইনারগুলো হোস্ট কের্নেল শেয়ার করে; VM-গুলো আলাদা কের্নেল চালায়।
মুখ্য কের্নেল মেকানিজম:
কিন্তু কন্টেইনার শেয়ারেড কের্নেল হওয়ার কারণে আইসোলেশন সম্পূর্ণ নয়—কনফিগারেশন ভুল (root হিসেবে চালানো, প্রশস্ত capabilities, হোস্ট-পাথ মাউন্ট করা ইত্যাদি) সীমা দুর্বল করে।