একাধিক 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 ঠিকানার টেক্সট ফাইল, shell history খুঁজে বের করার প্রত্নতাত্ত্বিক কাজ (ssh 203.0 তারপর Ctrl-R চাপা এবং আশা করা), এবং চিরকাল -p 2222 -i ~/.ssh/other_key টাইপ করা। সেটআপের সময়: একবার, 15 মিনিট। সমস্যাটি: পুরোনো multiplexing socket, যা নিচে ব্যাখ্যা করা হয়েছে।

এই পরিসরে আপনার নতুন সফটওয়্যার দরকার নেই; আপনার কাছে থাকা 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 এক hop-এ bastion-এর মাধ্যমে connection route করে। তাই ক্যাফে থেকে ssh db1 স্বচ্ছভাবে bastion-এর মাধ্যমে tunnel হয়। এতে agent forwarding বা কোনো ProxyCommand কমান্ডের প্রয়োজন হয় না। Private server-গুলোর public SSH port-এরও প্রয়োজন থাকে না (cross-cutting section-এ আরও তথ্য আছে)। ControlMaster auto-এর সঙ্গে ControlPersist ব্যবহার করলে একটি TCP session-এর মাধ্যমে connection multiplex হয়। ফলে একই host-এ দ্বিতীয় এবং পরবর্তী প্রতিটি ssh, scp, বা rsync renegotiation না করেই তাৎক্ষণিকভাবে সংযুক্ত হয়। Ansible ব্যবহার শুরু হলে এই পার্থক্য আরও স্পষ্ট হয়। scp, rsync এবং Ansible একই file পড়ে। তাই এখানে নির্ধারিত প্রতিটি নাম সব জায়গায় কাজ করে।

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

mux_client_request_session: session request failed: Session open refused

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

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

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

5 থেকে 20টি সার্ভার: কোড হিসেবে কনফিগারেশন, নইলে ড্রিফট জয়ী হবে

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

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

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

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 ঠিক করুন। Ansible তার নিচের layer যতটা নির্ভরযোগ্য, ততটাই নির্ভরযোগ্য। এর বাইরে একটি বিষয় মনে রাখুন: Ansible-এর উভয় প্রান্তে Python দরকার। তাই অত্যন্ত minimal image /usr/bin/python3: not found উত্তর দিতে পারে, একটি apt install python3, এবং এরপর আর এটি আপনাকে বিরক্ত করবে না।

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

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

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

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

একটি web panel, কেবল প্রয়োজন হলে। Webmin Ubuntu কোথায় বিভিন্ন সেটিং রাখে তা মনে রাখার প্রয়োজন কমায়। বিভিন্ন দক্ষতার সদস্য থাকা দল বা বছরে দুবার ব্যবহার করা সার্ভারের ক্ষেত্রে এটি সত্যিই কার্যকর; সেটআপে দশ মিনিট লাগে। গুরুত্বপূর্ণ ঝুঁকি হলো, এটি root-এর সমতুল্য ক্ষমতাসম্পন্ন একটি web application, যা port 10000-এ listening করে। Internet নিয়মিতভাবে এই port স্ক্যান করে। এটি ব্যবহার করলে localhost বা VPN address-এ bind করুন, কোনো public interface-এ 0.0.0.0-এ নয়। SSH ধীর মনে হওয়ার কারণে panel ব্যবহার করতে চাইলে আগের section-টি আবার পড়ুন। কনফিগার করা ~/.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-এর সংখ্যা: এটি প্রায় শূন্য রাখতে পারলে সীমা অনেক বেশি থাকে।