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

কুবারনেটস, নোম্যাড বা যেকোনো ক্লাউড-হোস্টেড প্ল্যাটফর্ম-এ-সার্ভিস (পাস) এর মতো প্ল্যাটফর্মগুলি বিভিন্ন ধরনের শক্তিশালী ক্ষমতা প্রদান করে। কাজের চাপ স্কেল করা থেকে শুরু করে গোপন ব্যবস্থাপনা থেকে শুরু করে স্থাপনার কৌশল পর্যন্ত, এই কাজের চাপ অর্কেস্ট্রেটরদের বিভিন্ন উপায়ে পরিকাঠামো স্কেল করতে সাহায্য করার জন্য অপ্টিমাইজ করা হয়েছে। কিন্তু অপারেটরদের কি সর্বদা সর্বাধিক মাপযোগ্যতার জন্য খরচ দিতে হবে? কখনও কখনও, জটিলতা এবং বিমূর্ততার খরচ তাদের সুবিধাগুলি অতিক্রম করে। অনেক নির্মাতা এর পরিবর্তে পরিচালনার সহজতার জন্য আমূল সহজ স্থাপনার আর্কিটেকচারের উপর নির্ভর করতে আসে। একটি লোড ব্যালেন্সারের পিছনে দুটি ভার্চুয়াল প্রাইভেট সার্ভার একটি কন্টেইনার হোস্টের বহর জুড়ে মাইক্রোসার্ভারগুলির একটি বিস্তৃত ক্লাস্টারের তুলনায় পরিচালনা করার জন্য একটি অত্যন্ত সহজ স্ট্যাক। এটি লভ্যাংশ প্রদান করা শুরু করতে পারে যখন ডিবাগ করার জন্য কম চলমান অংশ থাকে যখন সমস্যা দেখা দেয় বা যখন সেগুলি বজায় রাখার সময় আসে তখন আপগ্রেড করা হয়। অনেক আধুনিক লিনাক্স ডিস্ট্রিবিউশনের ভিত্তি হল , এবং এটি একটি শক্তিশালী বৈশিষ্ট্যের সাথে আসে যা প্রায়ই কন্টেইনার অর্কেস্ট্রেটর বা PaaS সিস্টেমের সাথে তুলনীয়। এই নিবন্ধে, আমরা অন্বেষণ করব কীভাবে আপনি ব্যবস্থাপনার মাথাব্যথা ছাড়াই সেই অন্যান্য বৃহৎ সিস্টেমের অনেক ক্ষমতা অর্জনের জন্য সর্বশেষ সিস্টেমড বৈশিষ্ট্যগুলি ব্যবহার করতে পারেন এবং যে কোনও সাধারণ সার্ভারকে একটি খুব সক্ষম অ্যাপ্লিকেশন প্ল্যাটফর্ম হতে সুপারচার্জ করতে পারেন। সিস্টেমড লিনাক্স একটি সিস্টেমড প্রাইমার একটি একক হোস্টে, একটি systemd ফাইল লেখা একটি পরিচালিত প্রক্রিয়া চালানোর একটি আদর্শ উপায়। বেশিরভাগ সময়, আপনাকে এমনকি অ্যাপ্লিকেশনটি পরিবর্তন করতে হবে না: systemd বিভিন্ন ধরণের পরিষেবা সমর্থন করে এবং সেই অনুযায়ী মানিয়ে নিতে পারে। .service উদাহরণস্বরূপ, এই সাধারণ বিবেচনা করুন যা একটি সাধারণ ওয়েব পরিষেবা কীভাবে চালাতে হয় তা সংজ্ঞায়িত করে: .service [Unit] Description=a simple web service [Service] ExecStart=/usr/bin/python3 -m http.server 8080 সিস্টেমড পরিষেবাগুলির জন্য ডিফল্টগুলি মনে রাখবেন: অবশ্যই একটি পরম পথ হতে হবে, প্রক্রিয়াগুলি পটভূমিতে প্রবেশ করা উচিত নয় এবং আপনাকে বিকল্পের সাথে প্রয়োজনীয় পরিবেশের ভেরিয়েবল সেট করতে হতে পারে। ExecStart= Environment= যখন এর মতো একটি ফাইলে স্থাপন করা হয়, এটি এমন একটি পরিষেবা তৈরি করে যা আপনি মাধ্যমে নিয়ন্ত্রণ করতে পারেন: /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 বিকল্পটি শংসাপত্রগুলিকে একটি সিস্টেমড পরিষেবাতে একটি গোপন তথ্য ইনজেক্ট করতে, ফাইল সিস্টেমের একটি পাথে গোপন মান ধারণকারী একটি ফাইল স্থাপন করে শুরু করুন। উদাহরণস্বরূপ, একটি ইউনিটে একটি API কী প্রকাশ করতে, ফাইলটি রিবুট জুড়ে টিকে থাকার জন্য এ একটি ফাইল তৈরি করুন বা ফাইলটি স্থায়ীভাবে টিকে থাকা এড়াতে এ একটি ফাইল তৈরি করুন ( path নির্বিচারে হতে পারে, কিন্তু systemd এই পাথগুলিকে ডিফল্ট হিসাবে বিবেচনা করবে)। উভয় ক্ষেত্রেই, এর মতো একটি কমান্ড ব্যবহার করে ফাইলটিতে সীমাবদ্ধ অনুমতি থাকা উচিত। .service /etc/credstore/api-key /run/credstore/api-key credstore chmod 400 /etc/credstore/api-key ফাইলের বিভাগের অধীনে, বিকল্পটি সংজ্ঞায়িত করুন এবং এটিকে একটি কোলন ( ): শংসাপত্রের নাম এবং এর পথ দ্বারা পৃথক দুটি মান দিন। উদাহরণস্বরূপ, আমাদের ফাইলটিকে "টোকেন" কল করতে, নিম্নলিখিত সিস্টেমড পরিষেবা বিকল্পটি সংজ্ঞায়িত করুন: .service [Service] LoadCredential= : /etc/credstore/api-key LoadCredential=token:/etc/credstore/api-key যখন systemd আপনার পরিষেবা শুরু করে, তখন গোপনটি ফর্মের একটি পাথের অধীনে চলমান পরিষেবার কাছে উন্মোচিত হয় যেখানে হল systemd দ্বারা জনবহুল একটি পরিবেশ পরিবর্তনশীল৷ আপনার অ্যাপ্লিকেশন কোড প্রতিটি গোপনে এইভাবে সংজ্ঞায়িত লাইব্রেরি বা কোডে ব্যবহারের জন্য পড়তে হবে যার জন্য API টোকেন বা পাসওয়ার্ডের মতো সুরক্ষিত মান প্রয়োজন। উদাহরণস্বরূপ, পাইথনে, আপনি নিম্নলিখিতগুলির মতো কোড সহ এই গোপনীয়তাটি পড়তে পারেন: ${CREDENTIALS_DIRECTORY}/token ${CREDENTIALS_DIRECTORY} 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() তারপরে আপনি আপনার গোপন বিষয়বস্তুর সাথে ভেরিয়েবলটি ব্যবহার করতে পারেন যেকোন লাইব্রেরির জন্য একটি API টোকেন বা পাসওয়ার্ডের প্রয়োজন হতে পারে। secret পুনরায় চালু হয় মতো অর্কেস্ট্রেটরদের আরেকটি ক্ষমতা হল ক্র্যাশ হওয়া কাজের চাপ স্বয়ংক্রিয়ভাবে ক্ষমতা। একটি আন-হ্যান্ডেলড অ্যাপ্লিকেশন ত্রুটি বা অন্য কোনও কারণে হোক না কেন, ব্যর্থ অ্যাপ্লিকেশনগুলি পুনরায় চালু করা একটি খুব দরকারী ক্ষমতা যা প্রায়শই একটি অ্যাপ্লিকেশনকে স্থিতিস্থাপক হওয়ার জন্য ডিজাইন করার সময় প্রতিরক্ষার প্রথম লাইন। নোম্যাডের পুনরায় চালু করার systemd নিয়ন্ত্রণ করে যে systemd একটি চলমান প্রক্রিয়া স্বয়ংক্রিয়ভাবে পুনরায় আরম্ভ করবে কিনা। এই বিকল্পের জন্য বেশ কয়েকটি সম্ভাব্য মান রয়েছে, তবে মৌলিক পরিষেবাগুলির জন্য, সেটিংটি বেশিরভাগ ব্যবহারের ক্ষেত্রে সন্তুষ্ট করার জন্য উপযুক্ত। Restart= বিকল্পটি on-failure স্বয়ং-পুনঃসূচনা কনফিগার করার সময় বিবেচনা করার জন্য আরেকটি সেটিং হল , যা নির্দেশ করে যে পরিষেবাটি আবার শুরু করার আগে systemd কতক্ষণ অপেক্ষা করবে। সাধারণত, এই মানটি একটি আঁটসাঁট লুপে ব্যর্থ পরিষেবাগুলি পুনরায় আরম্ভ না করা এবং পুনরায় চালু করার প্রক্রিয়াগুলিতে খুব বেশি CPU সময় ব্যয় করা এড়াতে কাস্টমাইজ করা উচিত। একটি সংক্ষিপ্ত মান যা মতো বেশি অপেক্ষা করে না সাধারণত যথেষ্ট। RestartSec RestartSec= বিকল্প 5s খুব এর মতো বিকল্পগুলি যা সময়কাল বা সময়-ভিত্তিক মানগুলি গ্রহণ করে আপনার প্রয়োজনের উপর নির্ভর করে বা মতো বিভিন্ন ফর্ম্যাট পার্স করতে পারে। অতিরিক্ত তথ্যের জন্য উল্লেখ করুন। RestartSec= 5min 10s 1hour systemd.time-এর ম্যানুয়াল অবশেষে, অন্য দুটি বিকল্প নির্দেশ করে যে শেষ পর্যন্ত হাল ছেড়ে দেওয়ার আগে সিস্টেমড কতটা আক্রমণাত্মকভাবে ব্যর্থ ইউনিট পুনরায় চালু করার চেষ্টা করবে। এবং একটি নির্দিষ্ট সময়ের মধ্যে কত ঘন ঘন একটি ইউনিট শুরু করার অনুমতি দেওয়া হয় তা নিয়ন্ত্রণ করবে। উদাহরণস্বরূপ, নিম্নলিখিত সেটিংস: 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