একাধিক Linux server পরিচালনা: কোন টুল কাজের

আপনি কী তৈরি করছেন

এটি একটি মাত্র টুল নয়, বরং একটি সংক্ষিপ্ত স্ট্যাক। আপনার প্রকৃত সার্ভারের সংখ্যার ভিত্তিতে এটি নির্বাচন করা হয়েছে। এই সংখ্যাটিই একমাত্র গুরুত্বপূর্ণ ইনপুট। অথচ প্রতিটি "Linux server management tools" সংকলন এটি উপেক্ষা করে। সাধারণ ভুল হলো চারটি VPS-এর জন্য 200-সার্ভারের সমাধান গ্রহণ করা এবং সার্ভার পরিচালনার বদলে এক মাস টুলটিতে ডেটা সরবরাহ করা। দ্বিতীয় সাধারণ ভুল হলো, আঠারোটি সার্ভার থাকা সত্ত্বেও প্রতিটিতে হাতে SSH করে ঢুকে একই পরিবর্তন আঠারোটি সামান্য ভিন্ন উপায়ে প্রয়োগ করা।

তাই এই নির্দেশিকাটি সার্ভারের বহরের আকার অনুযায়ী সাজানো: 2 থেকে 5টি সার্ভার, 5 থেকে 20টি, এবং 20টির বেশি। এর সঙ্গে রয়েছে এমন একটি সাধারণ স্তর, যা প্রতিটি আকারের ক্ষেত্রেই প্রযোজ্য এবং যার কথা কেউ লিখে রাখে না: একটি ইনভেন্টরি, cryptographic key-এর সঠিক ব্যবস্থাপনা, প্রবেশের একটি নির্দিষ্ট পদ্ধতি, এবং বাস্তবে পুনরুদ্ধার করে পরীক্ষা করা backup। প্রতিটি টুলের জন্য আপনি তিনটি বিষয় পাবেন: এটি কোন কাজের বিকল্প, সেটআপ করতে কত মিনিট লাগে, এবং কোন একটি সমস্যায় বাস্তবে সবচেয়ে বেশি বিপাকে পড়তে হয়। আমি পনেরো বছর ধরে একটি VPS host পরিচালনা করেছি। নিচের তালিকায় 2 a.m.-এর outage সামলানোর পরও কার্যকর থাকা বিষয়গুলো রয়েছে, শুধু demo-তে ভালো দেখায় এমন বিষয় নয়।

পূর্বশর্ত এবং বাস্তব সীমাবদ্ধতা

প্রতিটি সার্ভারে key-based SSH আগে থেকেই কাজ করতে হবে। আপনি যদি এখনও password টাইপ করেন, আগে সেটি ঠিক করুন। এতে দশ মিনিট সময় লাগবে। নিচের সবকিছুই keys ব্যবহারের ওপর নির্ভর করে। root নয়—এমন একটি sudo user এবং current software চালানো সার্ভারও প্রয়োজন। এখানে দেওয়া commands Ubuntu 24.04 ধরে নেওয়া হয়েছে। তবে apt ছাড়া কিছুই Ubuntu-নির্দিষ্ট নয়।

Tools ব্যবহারের আগে দুটি বাস্তব সতর্কতা মনে রাখুন। প্রথমত, tool sprawl নিজেই একটি management problem। আপনি যে প্রতিটি agent install করবেন, প্রতিটি server-এ সেটি patch করার জন্য আরও একটি daemon যোগ হবে। তাই নতুন কোনো tool যোগ করার মানদণ্ড হওয়া উচিত: “এটি এই সপ্তাহে আমার করা manual work প্রতিস্থাপন করবে”—“এটি উপযোগী মনে হচ্ছে” নয়। দ্বিতীয়ত, এখানে ব্যবহৃত সবকিছু free software। প্রকৃত খরচ হলো setup time। তাই প্রতিটি tool-এর সঙ্গে minutes-এ একটি estimate দেওয়া আছে। Estimate-এ যদি afternoon লেখা থাকে, সেটিকে সত্যিই একটি afternoon হিসেবেই ধরুন।

2 থেকে 5টি সার্ভার: আপনার কাছে ইতিমধ্যেই থাকা সবচেয়ে অবমূল্যায়িত টুল হলো ~/.ssh/config

এটি যা প্রতিস্থাপন করে: IP address-এর text file, shell history ঘেঁটে কমান্ড খোঁজা (ssh 203.0, তারপর Ctrl-R চাপা এবং আশা করা), এবং বারবার -p 2222 -i ~/.ssh/other_key টাইপ করা। সেটআপের সময়: একবারে 15 মিনিট। সমস্যার দিক: পুরোনো multiplexing socket, যা নিচে ব্যাখ্যা করা হয়েছে।

এই সংখ্যক সার্ভারের জন্য আপনার আলাদা software দরকার নেই; আপনার কাছে থাকা client-টিকেই সঠিকভাবে configure করতে হবে। ~/.ssh/config প্রতিটি সার্ভারকে একটি এক-শব্দের নাম দেয় এবং routing এমনভাবে নির্ধারণ করে যে পরে আপনাকে আর এটি নিয়ে ভাবতে হয় না:

Host *
    ServerAliveInterval 30
    ControlMaster auto
    ControlPath ~/.ssh/cm-%r@%h-%p
    ControlPersist 10m

Host bastion
    HostName 10.0.0.10
    User matt

Host web1
    HostName 10.8.0.11
    User matt
    ProxyJump bastion

Host db1
    HostName 10.8.0.12
    User matt
    Port 2222
    ProxyJump bastion

তিনটি setting-ই মূল কাজ করে। ProxyJump এক ধাপে bastion-এর মাধ্যমে connection পাঠায়। তাই café থেকে ssh db1 চালালে connection স্বচ্ছভাবে bastion-এর মাধ্যমে tunnel হয়। এতে agent forwarding বা ProxyCommand-এর কোনো incantation দরকার হয় না। Private server-গুলোর public SSH port রাখারও প্রয়োজন হয় না (cross-cutting section-এ এ বিষয়ে আরও বলা হয়েছে)। ControlMaster auto এবং ControlPersist মিলে একটি TCP session-এর ওপর connection multiplex করে। ফলে একই host-এ দ্বিতীয় এবং পরবর্তী প্রতিটি ssh, scp বা rsync তাৎক্ষণিকভাবে connect করে, নতুন করে negotiation করার প্রয়োজন হয় না। Ansible ব্যবহার করলে এই পার্থক্যটি বিশেষভাবে স্পষ্ট হয়। scp, rsync এবং Ansible একই file পড়ে। তাই এখানে নির্ধারিত প্রতিটি নাম সব জায়গায় কাজ করে।

সমস্যার দিক হলো, master connection প্রয়োজন শেষ হওয়ার পরও চালু থাকতে পারে। এই সমস্যার দুটি failure mode দেখতে আলাদা। Server reboot হলে বা Wi-Fi connection বিচ্ছিন্ন হলে master process একটি মৃত TCP session ধরে রাখে, কিন্তু তাৎক্ষণিকভাবে বিষয়টি বুঝতে পারে না। এরপরের ssh web1 এমন একটি socket-এ নীরবে আটকে থাকে, যেটি কোনো কার্যকর endpoint-এ পৌঁছায় না। আলাদাভাবে, sshd প্রতি connection-এ সর্বোচ্চ 10টি session অনুমোদন করে (MaxSessions-এ sshd_config)। তাই একটি host-এ multiplex করা একাদশ session চালালে এটি দেখায়:

mux_client_request_session: session request failed: Session open refused by peer

দুটি সমস্যার সমাধান একই: ssh -O exit web1 master process বন্ধ করে দেয়, এবং পরবর্তী connection নতুন master connection তৈরি করে। মাঝে মাঝে ControlSocket /home/matt/.ssh/cm-matt@10.8.0.11-22 already exists, disabling multiplexing-ও দেখা যেতে পারে। এটি ক্ষতিকর নয়। দুটি session একই সময়ে শুরু হয়েছে, এবং connection কাজ করছে; শুধু সেটি multiplex করা হয়নি।

এই সংখ্যক সার্ভারের জন্য আরও দুটি সহায়ক tool আছে। প্রতিটি সার্ভারে tmux ব্যবহার করলে nohup, Wi-Fi বিচ্ছিন্ন হলে কাজ হারানো এবং “একটি migration চলছে, তাই laptop বন্ধ করতে পারছি না”—এই সমস্যাগুলো দূর হয়। সেটআপের সময়: sudo apt install -y tmux, অর্থাৎ দুই মিনিট। এর সঙ্গে tmux new -s work এবং tmux attach -t work ব্যবহারের অভ্যাস তৈরি করতে হবে। সমস্যার দিক হলো nesting: tmux-এর ভিতরে tmux চালালে prefix key কাজ নাও করতে পারে। তাই এটি server-এ অথবা laptop-এ চালান, উভয় জায়গায় নয়। দীর্ঘ সময় চলা agent session চালালে এটি আরও গুরুত্বপূর্ণ। এটি VPS-এ Claude Code tmux-এ চালানোর একই প্যাটার্ন, যেখানে session-কে SSH connection-এর চেয়ে বেশি সময় চালু থাকতে হয়।

একটি shared alias file প্রতিটি box-এ আপনার পছন্দের বারোটি one-liner আবার টাইপ করার প্রয়োজন দূর করে। একটি .bash_aliases git repo-তে রাখুন এবং প্রতিটি server-এ pull করুন। সমস্যার দিক হলো, repo-তে পরিবর্তন না করে কোনো একটি server-এ সরাসরি edit করলেই এটি আলাদা হয়ে যেতে শুরু করে। পরবর্তী tier কেন আছে, সেটি বোঝার প্রথম অভিজ্ঞতাও এখান থেকেই হয়।

5 থেকে 20টি সার্ভার: config as code না হলে drift জয়ী হয়

পাঁচটির বেশি সার্ভারে গিয়ে “প্রতিটি box-এ আলাদাভাবে করে দেব” আর কোনো পদ্ধতি থাকে না; এটি নিজের কাছেই বলা একটি মিথ্যা হয়ে যায়। এই স্তরের সব tool একই সমস্যার বিরুদ্ধে কাজ করে: drift।

Ansible hostname-এর ওপর shell loop, “new server setup” শিরোনামের এমন wiki page যা তিনটি ধাপ পুরোনো, এবং web3 সত্যিই fix পেয়েছে কি না না জানার উদ্বেগ—সবকিছুর বিকল্প দেয়। Setup cost: প্রথম কার্যকর playbook তৈরি করতে 30 মিনিট, আপনার laptop বা একটি management box-এ sudo apt install -y ansible (apt আপনাকে পুরোনো Ansible release দেয়, যা এখানে ব্যবহৃত সব কিছুর জন্য যথেষ্ট; tutorial-এর pipx পদ্ধতিতে বর্তমান version পাওয়া যায়), সার্ভারে কোনো agent লাগে না, এবং আপনার ইতিমধ্যে তৈরি করা SSH config ব্যবহার করেই সব চলে। এই page-এ এটি সবচেয়ে বড় একক উন্নতি। সম্পূর্ণ ধাপ Ansible-এর প্রথম playbook tutorial-এ আছে। কাজ করার মতো inventory-এর কাঠামো হলো:

[web]
web1 ansible_host=10.8.0.11
web2 ansible_host=10.8.0.12

[db]
db1 ansible_host=10.8.0.21 ansible_port=2222

[all:vars]
ansible_user=matt
ansible_ssh_common_args='-o ProxyJump=bastion'

Ansible OpenSSH binary ব্যবহার করে shell command চালায়। তাই আগের section-এ লেখা ~/.ssh/config ইতিমধ্যে প্রযোজ্য। web1-এর মতো শুধু নামের inventory কোনো vars ছাড়াই কাজ করবে। উপরের vars inventory-কে স্বয়ংসম্পূর্ণ করে। আপনি যেদিন নিজের laptop নয় এমন কোনো machine থেকে এটি চালাবেন, সেদিন এর সুবিধা পাবেন।

ansible all -i inventory.ini -m ping দিয়ে পরীক্ষা করুন। সঠিক ফলাফলে প্রতিটি host-এর জন্য সবুজ রঙে "ping": "pong" দেখা যাবে। প্রথম যে failure-টির মুখোমুখি হবেন, সেটি এমন হবে:

web1 | UNREACHABLE! => {
    "changed": false,
    "msg": "Failed to connect to the host via ssh: matt@10.8.0.11: Permission denied (publickey).",
    "unreachable": true
}

এটি Ansible-এর সমস্যা নয়। সাধারণ ssh matt@10.8.0.11 একইভাবে ব্যর্থ হবে। সবসময় আগে SSH ঠিক করুন। এর নিচের layer যতটা সুস্থ, Ansible-ও ততটাই নির্ভরযোগ্য। আরেকটি গুরুত্বপূর্ণ বিষয় হলো, Ansible-এর আপনার machine-এ Python প্রয়োজন। ping-সহ প্রায় সব module-এর জন্য server-এও Python প্রয়োজন। তাই অত্যন্ত minimal image /usr/bin/python3: not found দিতে পারে। একবার apt install python3 চালালেই পরে আর সমস্যা হবে না। পুরো fleet-এর bare image হলে raw module ব্যবহার করে এই installation করানো যায়। এটি remote machine-এ Python ছাড়াই কাজ করতে পারে এমন অল্প কয়েকটি module-এর একটি।

unattended-upgrades Nটি সার্ভারে security patch প্রয়োগ করার কাজটি আপনার বদলে করে। Stock Ubuntu Server 24.04-এ এটি আগে থেকেই installed থাকে এবং সাধারণত security update-এর জন্য enabled থাকে। তাই এখানে কাজ হলো verify করা, install করা নয়:

cat /etc/apt/apt.conf.d/20auto-upgrades

দুটি line-ই "1" দিয়ে শেষ হওয়া উচিত। কিছু minimal এবং cloud image-এ এটি disabled থাকে। আপনার ক্ষেত্রে এমন হলে sudo dpkg-reconfigure -plow unattended-upgrades ওই file-টি আবার লিখে দেয়। Setup cost: প্রতিটি server পরীক্ষা করতে দুই মিনিট, অথবা সবার জন্য একটি Ansible task। গুরুত্বপূর্ণ সীমাবদ্ধতা হলো, default অবস্থায় এটি কখনও reboot করে না। ফলে kernel security update প্রয়োগ অসম্পূর্ণ অবস্থায় থাকে, যতক্ষণ না আপনি reboot করেন। নির্দিষ্ট unattended-upgrades guide-এ automatic reboot, কোন update প্রয়োগ হবে তা নির্বাচন এবং log পড়ার পদ্ধতি ব্যাখ্যা করা হয়েছে।

Centralized monitoring-এর মাধ্যমে customer-এর কাছ থেকে জানতে হয় না যে সমস্যা হয়েছে। এটিই এখন পর্যন্ত তৈরি সবচেয়ে ব্যয়বহুল monitoring system। দুটি tool আছে। প্রতিটির কাজ এক লাইনে: Uptime Kuma “এটি কি চালু আছে?” প্রশ্নের উত্তর দেয়। এটি HTTP, TCP এবং ping check চালায়, যেকোনো জায়গায় alert পাঠাতে পারে এবং Docker-এ চালু করতে দশ মিনিট লাগে। Zabbix “এটি কি শিগগিরই ব্যর্থ হবে?” প্রশ্নের উত্তর দেয়। প্রতিটি host-এ agent ব্যবহার করে disk, memory এবং CPU-এর trend দেখায়, এবং বাস্তবে setup করতে একটি বিকেল লাগে। Kuma দিয়ে শুরু করুন। “চালু আছে, কিন্তু কার্যকারিতা কমে গেছে” ধরনের সমস্যা আপনার অর্থনৈতিক ক্ষতি করতে শুরু করলে Zabbix যোগ করুন। উভয়ের ক্ষেত্রেই মূল সমস্যা হলো placement। এটি এত গুরুত্বপূর্ণ যে নিচের mistakes section এটি দিয়ে শুরু হয়েছে।

শুধু প্রয়োজন হলে web panel ব্যবহার করুন। Webmin Ubuntu-এ কোন জিনিস কোথায় রাখা আছে তা মনে রাখার প্রয়োজন কমায়। বিভিন্ন দক্ষতার team বা বছরে দুবার যেসব server-এ কাজ করতে হয়, সেসব ক্ষেত্রে এটি সত্যিই উপকারী। Setup করতে দশ মিনিট লাগে। তবে মনে রাখবেন, এটি root-এর সমতুল্য ক্ষমতাসম্পন্ন web application এবং port 10000-এ listening করে। Internet থেকে এটি নিয়মিত scan করা হয়। ব্যবহার করলে এটিকে localhost বা কোনো VPN address-এ bind করুন। কোনো public interface-এ কখনও 0.0.0.0-এ bind করবেন না। SSH ধীর মনে হওয়ায় যদি panel ব্যবহারের কথা ভাবেন, আগে আগের section আবার পড়ুন। Configured ~/.ssh/config এবং Ansible একসঙ্গে ব্যবহার করলে যেকোনো panel-এর চেয়ে দ্রুত কাজ করা যায়।

20+ সার্ভার: এই গাইড যেখানে বাস্তবভাবে শেষ

20টির বেশি সার্ভার হলে আপনি একটি ফ্লিট পরিচালনা করছেন। তখন টুলচেইনের ধরন বদলে যায়: সার্ভারগুলোকে পুনরুৎপাদনযোগ্য করতে Terraform বা OpenTofu, একটি সার্ভার মেরামতযোগ্য না রেখে বাতিলযোগ্য করতে cloud-init বা golden images, push-from-a-laptop পদ্ধতি আর স্কেল না করায় আপনার Ansible চালানোর জন্য pull-based configuration বা CI pipelines, এবং বাস্তব secrets management। 20টি সার্ভারে Ansible নিজে ব্যর্থ হয়ে যায় না। অনেক প্রতিষ্ঠান শত শত node-এর বিরুদ্ধে এটি চালায়। তবে এর আশপাশের প্রক্রিয়াগুলোকে আরও কঠোর করতে হয়, আর সেটি এই সাইটে লেখা এই ধরনের নিবন্ধের বিষয় নয়। আপনি যদি এই স্কেলে থাকেন, নিচের অংশটি তবুও আপনার জন্য প্রযোজ্য। কারণ inventory, keys এবং access discipline হলো fleet tooling যে বিষয়গুলো আপনার আগে থেকেই থাকা আছে বলে ধরে নেয়।

কেউ লিখে রাখে না এমন স্তর

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

একটি inventory file, এমনকি একটি text file হলেও। আপনার তিনটি সার্ভার হওয়ার সঙ্গে সঙ্গে নাম, IP, provider, এতে কী চলে এবং এটি কেন আছে—এসব লিখে রাখুন। একটি git repo-তে থাকা servers.md যথেষ্ট; তবে উপরের Ansible inventory আরও ভালো, কারণ এটি executable documentation। এটি যে সমস্যার সমাধান করে: রাত 2টার প্রশ্ন, “এক মিনিট, 10.0.0.40 কী?” সেটআপের সময়: দশ মিনিট। গুরুত্বপূর্ণ বিষয়: এটি তখনই কাজ করে, যখন সার্ভার তৈরি করা এবং সেই লাইন যোগ করা একই কাজ হয়, কখনো দুটি আলাদা কাজ নয়।

Key hygiene: এখন rotation করুন, সমস্যা হলে SSH CA ব্যবহার করুন। আপনার key কোথায় আছে তা তালিকাভুক্ত করুন (আপনার পাশে cat ~/.ssh/*.pub, প্রতিটি সার্ভারের পাশে ~/.ssh/authorized_keys), পুরোনো laptop এবং সাবেক সহকর্মীদের access সরিয়ে দিন, এবং যেকোনো পুরোনো key rotate করুন—যে key কোথায় ব্যবহৃত হয়েছে তা বলতে না পারলে সেটি পুরোনো। SSH certificate authority, অর্থাৎ static key-এর পরিবর্তে স্বল্পমেয়াদি signed certificate, দীর্ঘমেয়াদে পরিণত সমাধান। তবে বাস্তব পরামর্শ হলো, দশটির কম সার্ভারের ক্ষেত্রে Ansible-এর মাধ্যমে নিয়ন্ত্রিত authorized_keys management ব্যবহার করলে 10% আনুষ্ঠানিকতায় 90% সুবিধা পাওয়া যায়।

প্রবেশের একটি পথ রাখুন, বিশটি নয়। প্রতিটি public SSH port-এর কারণে attack surface N গুণ বাড়ে। যে নকশা বড় পরিসরেও কার্যকর: একটি bastion host, অথবা আরও ভালো, আপনার নিয়ন্ত্রণাধীন VPS-এ একটি WireGuard VPN, এবং অন্য প্রতিটি সার্ভারের SSH শুধু তার private address-এ bind করা। উপরের config-এর ProxyJump লাইনগুলো ইতিমধ্যে এই কাঠামো ধরে নিয়েছে। যা public রাখতেই হবে, তাতে নিয়মিতভাবে fail2ban ব্যবহার করুন। সেটআপের সময়: একবারে এক ঘণ্টা। গুরুত্বপূর্ণ বিষয়: সর্বত্র port 22 বন্ধ করার আগে আপনার fallback—provider-এর console access—কাজ করছে কি না যাচাই করুন, পরে নয়।

Restore করে backup পরীক্ষা করুন। পরীক্ষা না করা backup কেবল একটি অনুমান। আপনি যে mechanism-ই ব্যবহার করুন—provider snapshot, restic, অথবা দ্বিতীয় box-এ rsync—বাস্তবে গুরুত্বপূর্ণ হলো calendar entry, যেখানে একটি server নতুন VPS-এ restore করে সেটি boot হয় এবং service দেয় কি না নিশ্চিত করবেন। পনেরো বছরের hosting অভিজ্ঞতায় শোনা প্রতিটি backup বিপর্যয়ের গল্পে এই বাক্যটি ছিল: “আমাদের backup ছিল।”

ভুলগুলো

একাধিক সার্ভারের ক্ষেত্রে ব্যর্থতার কারণ টুল নয়; অভ্যাস। এর মধ্যে 4টি কারণ প্রায় সব সমস্যার জন্য দায়ী।

Snowflake servers। প্রতিটি সার্ভার হাতে কনফিগার করা, সামান্য হলেও একে অন্যের থেকে আলাদা, এবং কেউই সেটি পুনর্নির্মাণ করতে পারে না। ডিস্ক নষ্ট হওয়ার সময় বিষয়টি জানা যায়। সমাধানটি একঘেয়ে: প্রতিটি পরিবর্তন Ansible-এর মাধ্যমে করতে হবে, অথবা অন্তত inventory নথিতে সংশ্লিষ্ট সার্ভারের অংশে যোগ করতে হবে। যে সার্ভারটি আজ বিকেলে নোট দেখে পুনর্নির্মাণ করতে পারবেন না, সেটি নির্ধারিত সময়সীমাসহ technical debt।

"Temporary" firewall holes। কোনো কিছু ডিবাগ করতে ufw allow 5432 ব্যবহার করা হয়, এবং 18 মাস পরেও Postgres ইন্টারনেটে উন্মুক্ত থাকে। প্রতিটি সার্ভারে sudo ufw status numbered দিয়ে অডিট করুন, অথবা একসঙ্গে ansible all -i inventory.ini -a "ufw status numbered" --become চালান। যেসব নিয়মের বর্তমান কারণ আপনি বলতে পারবেন না, সেগুলো মুছে দিন। কোনো নিয়ম সত্যিই অস্থায়ী হলে, সংযোগ বন্ধ করার আগে একই tmux window-তে সংশ্লিষ্ট ufw delete যোগ করুন।

পর্যবেক্ষণাধীন সার্ভারেই monitoring চালানো। Uptime Kuma যে সার্ভার পর্যবেক্ষণ করে, সেটিতেই চললে “সবকিছু বন্ধ” জানানো alert-টিও বন্ধ হয়ে যাবে। এতে বিশ্বের সবচেয়ে অদক্ষ datacenter-এর ছোট এবং হাস্যকর সংস্করণ তৈরি হয়। Monitoring-কে আলাদা failure domain-এ রাখতে হবে। অন্য provider-এর একটি সস্তা VPS এ ক্ষেত্রে প্রচলিত সমাধান। অন্তত একটি বাইরের free-tier check ব্যবহার করুন, যা monitoring ব্যবস্থাকেই পর্যবেক্ষণ করবে।

সর্বত্র Root SSH। পুরো fleet-এ একটি shared root key ব্যবহার করলে একটি ফাঁস হওয়া laptop-ই সবকিছুর নিয়ন্ত্রণ পেয়ে যায়। কে কী করেছে, তার কোনো audit trail থাকে না। প্রতিটি ব্যক্তির জন্য আলাদা user, sudo, এবং প্রতিটি host-এ PermitRootLogin no-কে /etc/ssh/sshd_config-এ ব্যবহার করুন। আবারও, এটি typing করে একটি সন্ধ্যা ব্যয় করার বদলে Ansible-এর তিন লাইনের task।

Fleet কয়েকটি সার্ভারের সীমা ছাড়ালে, আপনার প্রথম Ansible playbook পুনরাবৃত্তিমূলক কাজগুলো স্বয়ংক্রিয় করবে।

FAQ

একাধিক Linux server পরিচালনার জন্য সেরা বিনামূল্যের tool কোনটি?

2 থেকে 5টি server-এর জন্য, ভালোভাবে লেখা ~/.ssh/config এবং tmux আপনি install করতে পারেন এমন যেকোনো tool-এর চেয়ে কার্যকর। প্রায় 5টি server থেকে শুরু করে Ansible-ই standard সমাধান: এতে agent লাগে না, এটি free, আপনার ইতিমধ্যে থাকা SSH-এর মাধ্যমে চলে এবং server setup-কে git-এর file-এ রূপান্তর করে। up/down alerting-এর জন্য Uptime Kuma যোগ করুন; এই guide-এ উল্লেখ করা প্রতিটি tool free software।

Ansible ছাড়া কি একাধিক Linux server পরিচালনা করা যায়?

হ্যাঁ। প্রায় 5টির কম server হলে ভালো SSH config, shared alias file এবং নিয়ম মেনে চলাই যথেষ্ট। অনেকেই বছরের পর বছর এভাবেই server পরিচালনা করেন। এর বেশি হলে Ansible-এর বিকল্প "কিছুই নয়" নয়; সেটি হলো undocumented drift: হাতে করা configuration-এর কারণে 18টি server-এ সামান্য ভিন্ন ভিন্ন setup থাকা। Ansible ভারী মনে হলে এমন একটি playbook দিয়ে শুরু করুন, যা শুধু authorized_keys এবং unattended-upgrades পরিচালনা করে; এটিই শেখার সময়ের যথেষ্ট প্রতিদান দেবে।

একসঙ্গে একাধিক Linux server-এ একই command কীভাবে চালাব?

ansible all -i inventory.ini -a "uptime" হলো পরিষ্কার সমাধান এবং এর জন্য playbook দরকার নেই, শুধু inventory file দরকার। পাশাপাশি interactive কাজের জন্য tmux setw synchronize-panes on ব্যবহার করে প্রতিটি pane-এ keystroke broadcast করতে পারে। তবে এটিকে শুধু প্রদর্শনী হিসেবে ব্যবহার করুন, কারণ production server-এ interactive command broadcast করলে একটি typo থেকে N গুণ server-এ outage হতে পারে।

Linux server পরিচালনার জন্য কি Webmin-এর মতো control panel দরকার?

দরকার নেই। কোনো panel যা করে, SSH এবং Ansible তা আরও পুনরুৎপাদনযোগ্যভাবে করতে পারে। একই server-এ ভিন্ন দক্ষতার মানুষ প্রশাসনিক কাজ করলে, অথবা এত বিরতিতে server পরিচালনা করলে যে config path আবার খুঁজে বের করতে বাস্তব সময় লাগে, তখন Webmin ব্যবহার করা যুক্তিযুক্ত। এটি ব্যবহার করলে একে root-এর সমতুল্য web app হিসেবে বিবেচনা করুন: localhost অথবা VPN address-এ bind করুন, কখনো public interface-এ নয়।

একজন ব্যক্তি বাস্তবে কতটি Linux server পরিচালনা করতে পারেন?

হাতে administration করলে 10টির কম server-এর মধ্যেই কাজের মান কমে যায়। config as code, automated patching এবং centralized monitoring ব্যবহার করলে একজন সতর্ক ব্যক্তি part-time কাজ হিসেবে 20 থেকে 50টি server পরিচালনা করতে পারেন। সীমাবদ্ধতা routine maintenance নয়, বরং কত ঘন ঘন নতুন ধরনের সমস্যা দেখা দেয়। গুরুত্বপূর্ণ সংখ্যা হলো প্রতি admin-এ server-এর সংখ্যা নয়, প্রতি admin-এ snowflake-এর সংখ্যা: এটি প্রায় শূন্য রাখতে পারলে সীমা অনেক বেশি থাকে।