সিস্টেমড সহ মাইক্রো-ডেভঅপস: যেকোনো সাধারণ লিনাক্স সার্ভারকে সুপারচার্জ করুন

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

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

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

একটি সিস্টেমড প্রাইমার

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

উদাহরণস্বরূপ, এই সাধারণ .service বিবেচনা করুন যা একটি সাধারণ ওয়েব পরিষেবা কীভাবে চালাতে হয় তা সংজ্ঞায়িত করে:

 [Unit] Description=a simple web service [Service] ExecStart=/usr/bin/python3 -m http.server 8080

যখন /etc/systemd/system/webapp.service এর মতো একটি ফাইলে স্থাপন করা হয়, এটি এমন একটি পরিষেবা তৈরি করে যা আপনি systemctl মাধ্যমে নিয়ন্ত্রণ করতে পারেন:

• systemctl start webapp প্রক্রিয়া শুরু করবে।
• systemctl status webapp পরিষেবাটি চলছে কিনা, এর আপটাইম এবং stderr এবং stdout থেকে আউটপুট, সেইসাথে প্রক্রিয়াটির আইডি এবং অন্যান্য তথ্য প্রদর্শন করবে।
• systemctl stop webapp পরিষেবাটি শেষ করবে।

উপরন্তু, stderr এবং stdout এ মুদ্রিত সমস্ত আউটপুট জার্নাল্ড দ্বারা একত্রিত হবে এবং সিস্টেম জার্নালের মাধ্যমে অ্যাক্সেসযোগ্য হবে ( journalctl সহ) বা বিশেষভাবে --unit পতাকা ব্যবহার করে লক্ষ্যবস্তু করা হবে:

 journalctl --unit webapp

যেহেতু জার্নাল্ড ডিফল্টরূপে তার সঞ্চয়স্থান ঘোরায় এবং পরিচালনা করে, জার্নালের মাধ্যমে লগ সংগ্রহ করা লগ স্টোরেজ পরিচালনার জন্য একটি ভাল কৌশল।

এই নিবন্ধটির বাকি অংশটি এইরকম একটি পরিষেবা উন্নত করার বিকল্পগুলি অন্বেষণ করবে৷

সিক্রেটস

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

LoadCredential=systemd বিকল্পটি ডিস্কে থাকা ফাইল থেকে সংবেদনশীল মান লোড করা এবং একটি নিরাপদ উপায়ে পরিষেবাগুলিকে উন্মুক্ত করা সমর্থন করে। হোস্ট করা প্ল্যাটফর্মের মতো যেগুলি দূরবর্তীভাবে গোপনীয়তাগুলি পরিচালনা করে, সিস্টেমড শংসাপত্রগুলিকে নিরাপদ রাখা নিশ্চিত করতে পরিবেশের ভেরিয়েবলের মতো মানগুলির চেয়ে আলাদাভাবে ব্যবহার করবে।

একটি সিস্টেমড পরিষেবাতে একটি গোপন তথ্য ইনজেক্ট করতে, ফাইল সিস্টেমের একটি পাথে গোপন মান ধারণকারী একটি ফাইল স্থাপন করে শুরু করুন। উদাহরণস্বরূপ, একটি .service ইউনিটে একটি API কী প্রকাশ করতে, ফাইলটি রিবুট জুড়ে টিকে থাকার জন্য /etc/credstore/api-key এ একটি ফাইল তৈরি করুন বা ফাইলটি স্থায়ীভাবে টিকে থাকা এড়াতে /run/credstore/api-key এ একটি ফাইল তৈরি করুন ( path নির্বিচারে হতে পারে, কিন্তু systemd এই credstore পাথগুলিকে ডিফল্ট হিসাবে বিবেচনা করবে)। উভয় ক্ষেত্রেই, chmod 400 /etc/credstore/api-key এর মতো একটি কমান্ড ব্যবহার করে ফাইলটিতে সীমাবদ্ধ অনুমতি থাকা উচিত।

.service ফাইলের [Service] বিভাগের অধীনে, LoadCredential= বিকল্পটি সংজ্ঞায়িত করুন এবং এটিকে একটি কোলন ( : ): শংসাপত্রের নাম এবং এর পথ দ্বারা পৃথক দুটি মান দিন। উদাহরণস্বরূপ, আমাদের /etc/credstore/api-key ফাইলটিকে "টোকেন" কল করতে, নিম্নলিখিত সিস্টেমড পরিষেবা বিকল্পটি সংজ্ঞায়িত করুন:

 LoadCredential=token:/etc/credstore/api-key

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

 from os import environ from pathlib import Path credentials_dir = Path(environ["CREDENTIALS_DIRECTORY"]) with Path(credentials_dir / "token").open() as f: secret = f.read().strip()

তারপরে আপনি আপনার গোপন বিষয়বস্তুর সাথে secret ভেরিয়েবলটি ব্যবহার করতে পারেন যেকোন লাইব্রেরির জন্য একটি API টোকেন বা পাসওয়ার্ডের প্রয়োজন হতে পারে।

পুনরায় চালু হয়

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

Restart= systemd বিকল্পটি নিয়ন্ত্রণ করে যে systemd একটি চলমান প্রক্রিয়া স্বয়ংক্রিয়ভাবে পুনরায় আরম্ভ করবে কিনা। এই বিকল্পের জন্য বেশ কয়েকটি সম্ভাব্য মান রয়েছে, তবে মৌলিক পরিষেবাগুলির জন্য, on-failure সেটিংটি বেশিরভাগ ব্যবহারের ক্ষেত্রে সন্তুষ্ট করার জন্য উপযুক্ত।

স্বয়ং-পুনঃসূচনা কনফিগার করার সময় বিবেচনা করার জন্য আরেকটি সেটিং হল RestartSec RestartSec= বিকল্প , যা নির্দেশ করে যে পরিষেবাটি আবার শুরু করার আগে systemd কতক্ষণ অপেক্ষা করবে। সাধারণত, এই মানটি একটি আঁটসাঁট লুপে ব্যর্থ পরিষেবাগুলি পুনরায় আরম্ভ না করা এবং পুনরায় চালু করার প্রক্রিয়াগুলিতে খুব বেশি CPU সময় ব্যয় করা এড়াতে কাস্টমাইজ করা উচিত। একটি সংক্ষিপ্ত মান যা 5s মতো খুব বেশি অপেক্ষা করে না সাধারণত যথেষ্ট।

অবশেষে, অন্য দুটি বিকল্প নির্দেশ করে যে শেষ পর্যন্ত হাল ছেড়ে দেওয়ার আগে সিস্টেমড কতটা আক্রমণাত্মকভাবে ব্যর্থ ইউনিট পুনরায় চালু করার চেষ্টা করবে। StartLimitIntervalSec= এবং StartLimitBurst= একটি নির্দিষ্ট সময়ের মধ্যে কত ঘন ঘন একটি ইউনিট শুরু করার অনুমতি দেওয়া হয় তা নিয়ন্ত্রণ করবে। উদাহরণস্বরূপ, নিম্নলিখিত সেটিংস:

 StartLimitBurst=5 StartLimitIntervalSec=10

এটি শুধুমাত্র একটি ইউনিটকে 10 সেকেন্ডের মধ্যে সর্বাধিক 5 বার শুরু করার চেষ্টা করার অনুমতি দেবে। যদি কনফিগার করা পরিষেবাটি 10 সেকেন্ডের মধ্যে একটি ষষ্ঠ বার শুরু করার চেষ্টা করে, systemd ইউনিটটি পুনরায় চালু করার প্রচেষ্টা বন্ধ করবে এবং পরিবর্তে এটিকে failed হিসাবে চিহ্নিত করবে।

এই সমস্ত সেটিংস একত্রিত করে, আপনি স্বয়ংক্রিয় পুনঃসূচনা কনফিগার করার জন্য আপনার .service ইউনিটের জন্য নিম্নলিখিত বিকল্পগুলি অন্তর্ভুক্ত করতে পারেন:

 [Unit] StartLimitBurst=5 StartLimitIntervalSec=10 [Service] Restart=on-failure RestartSec=1

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

সার্ভিস হার্ডনিং

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

আপনি অনুরূপ বিধিনিষেধ প্রয়োগ করার জন্য বেশ কয়েকটি সিস্টেমড বিকল্প সক্রিয় করতে পারেন যা একটি অন্তর্নিহিত হোস্টকে অপ্রত্যাশিত কাজের চাপের আচরণ থেকে রক্ষা করতে সাহায্য করতে পারে:

• ProtectSystem= /boot এবং /usr এর মতো সংবেদনশীল সিস্টেম পাথে লেখার অ্যাক্সেস সীমাবদ্ধ করতে পারে। এই বিকল্পের জন্য ডকুমেন্টেশন সমস্ত উপলব্ধ বিকল্পগুলি গণনা করে, কিন্তু সাধারণভাবে বলতে গেলে, এই বিকল্পটি full সেট করা এই ফাইল সিস্টেম পাথগুলিকে সুরক্ষিত করার জন্য একটি যুক্তিসঙ্গত ডিফল্ট।
• ProtectHome= /home , /root , এবং /run/user ডিরেক্টরিগুলিকে শুধুমাত্র- read-only সেটিং দিয়ে সেট করতে পারে অথবা, true সেট করা হলে, খালি ডিরেক্টরি হিসাবে পরিষেবার ফাইলসিস্টেমে মাউন্ট করতে পারে। এই ডিরেক্টরিগুলিতে অ্যাক্সেস করার জন্য আপনার অ্যাপ্লিকেশনের নির্দিষ্ট প্রয়োজন না থাকলে, এটিকে true সেট করে সেই ডিরেক্টরিগুলিতে অবৈধ অ্যাক্সেসের বিরুদ্ধে সিস্টেমটিকে নিরাপদে শক্ত করতে পারে।
• PrivateTmp= কনফিগার করা পরিষেবার জন্য একটি পৃথক /tmp এবং /var/tmp বজায় রাখে যাতে এই পরিষেবা এবং অন্যান্য প্রক্রিয়াগুলির জন্য অস্থায়ী ফাইলগুলি ব্যক্তিগত থাকে। অস্থায়ী ফাইলগুলির মাধ্যমে তথ্য ভাগ করার প্রক্রিয়াগুলির জন্য একটি বাধ্যতামূলক কারণ না থাকলে, এটি সক্ষম করার জন্য একটি দরকারী বিকল্প।
• NoNewPrivileges= একটি পরিষেবাকে কঠোর করার আরেকটি নিরাপদ এবং সরল উপায় নিশ্চিত করে যে সম্পাদিত প্রক্রিয়াটি তার বিশেষাধিকারগুলিকে উন্নত করতে পারে না। আপনি যদি অন্যান্য শক্ত করার বিকল্পগুলি ব্যবহার করার ক্ষমতা সম্পর্কে অনিশ্চিত হন তবে এটি সাধারণত সক্ষম করার জন্য সবচেয়ে কম সমস্যাযুক্ত।

systemd.exec-এর ম্যানুয়াল পৃষ্ঠাটি পরিষেবার মতো এক্সিকিউটেবল ওয়ার্কলোডের জন্য প্রযোজ্য বিভিন্ন বিকল্পগুলি অন্বেষণ করার জন্য একটি সহায়ক সংস্থান।

আরও পড়া

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