بهترین ابزارهای مدیریت چندین سرور لینوکس

آنچه در حال ساخت آن هستید

این یک ابزار واحد نیست، بلکه یک پشته (stack) کوتاه است که بر اساس تعداد سرورهای واقعی شما انتخاب شده است. این عدد تنها ورودی مهم است و همان نکته‌ای است که تمام بررسی‌های «ابزارهای مدیریت سرور لینوکس» از آن غافل می‌شوند. اشتباه کلاسیک، استفاده از راهکاری مناسب برای 200 سرور برای تنها 4 سرور VPS است؛ که باعث می‌شود به‌جای رسیدگی به سرورها، یک ماه وقت خود را صرف تغذیهٔ آن ابزار کنید. دومین اشتباه کلاسیک، وضعیت کسی است که با 18 سرور، همچنان به‌صورت دستی به تک‌تک آن‌ها SSH می‌زند و «یک تغییر واحد» را به 18 روش کمی متفاوت اعمال می‌کند.

بنابراین، این راهنما بر اساس اندازهٔ ناوگان سرورها دسته‌بندی شده است: 2 تا 5 سرور، 5 تا 20 سرور، و بیش از 20 سرور. به‌علاوه، لایه‌ای که در تمام اندازه‌ها کاربرد دارد و هیچ‌کس آن را مکتوب نمی‌کند: موجودی (inventory)، بهداشت کلیدهای رمزنگاری، یک راه ورودی واحد، و پشتیبان‌هایی که واقعاً بازیابی‌شان کرده‌اید. برای هر ابزار، سه مورد را دریافت می‌کنید: چه چیزی را جایگزین می‌کند، هزینهٔ راه‌اندازی به دقیقه چقدر است، و آن نکتهٔ فنی (gotcha) که واقعاً دردسرساز می‌شود. من 15 سال است که یک میزبان VPS را اداره می‌کنم؛ لیست زیر شامل مواردی است که در مواجهه با قطعی‌های ساعت 2 بامداد دوام می‌آورند، نه مواردی که فقط در دموها خوب به نظر می‌رسند.

پیش‌نیازها و نکات مهم

شما باید از قبل دسترسی SSH مبتنی بر کلید را برای تمامی سرورها فعال کرده باشید (اگر هنوز از رمز عبور استفاده می‌کنید، ابتدا آن را اصلاح کنید؛ این کار 10 دقیقه زمان می‌برد و تمام مراحل زیر بر پایه استفاده از کلیدها هستند)، همچنین به یک کاربر sudo غیر از root نیاز دارید و سرورها باید از سیستم‌عامل‌های به‌روز استفاده کنند. دستورات این بخش بر پایه Ubuntu 24.04 هستند، اما هیچ‌کدام از آن‌ها به جز apt مختص Ubuntu نیستند.

پیش از معرفی ابزارها، دو هشدار صادقانه وجود دارد. نخست، پراکندگی ابزارها خود یک مشکل مدیریتی است: هر agent که نصب می‌کنید، یک daemon اضافه است که باید در تمام سرورها وصله (patch) شود؛ بنابراین معیار افزودن یک ابزار باید این باشد که «این ابزار کار دستی این هفته مرا جایگزین می‌کند»، نه اینکه «این ابزار مفید به نظر می‌رسد». دوم، تمام ابزارهای اینجا نرم‌افزار آزاد هستند و هزینه واقعی آن‌ها زمان راه‌اندازی است؛ به همین دلیل برای هر ابزار یک تخمین زمانی به دقیقه در نظر گرفته شده است، اگر در تخمین گفته شده «یک بعدازظهر»، آن را جدی بگیرید.

2 تا 5 سرور: فایل ~/.ssh/config دست‌کم‌گرفته‌شده‌ترین ابزاری است که همین حالا در اختیار دارید

جایگزین چه چیزی است: فایل متنی حاوی آدرس‌های IP، جستجو در تاریخچه دستورات (ssh 203.0 و سپس Ctrl-R و دعا کردن)، و تایپ همیشگی -p 2222 -i ~/.ssh/other_key. هزینه راه‌اندازی: 15 دقیقه، فقط یک بار. نکته مهم: سوکت‌های multiplexing قدیمی که در ادامه توضیح داده شده‌اند.

در این مقیاس، نیازی به نرم‌افزار اضافی ندارید؛ فقط باید کلاینتی که دارید را به‌درستی پیکربندی کنید. ~/.ssh/config هر سرور را به یک نام تک‌کلمه‌ای تبدیل کرده و مسیردهی را طوری کدگذاری می‌کند که دیگر هرگز نگران آن نباشید:

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

سه تنظیم اصلی کار را انجام می‌دهند. ProxyJump اتصالات را از طریق یک bastion در یک گام مسیردهی می‌کند، بنابراین ssh db1 از یک کافه به‌صورت شفاف از طریق bastion تونل می‌شود؛ بدون نیاز به agent forwarding، بدون وردخوانی‌های ProxyCommand، و سرورهای خصوصی اصلاً نیازی به پورت‌های عمومی SSH ندارند (در بخش‌های بعدی بیشتر به این موضوع می‌پردازیم). ControlMaster auto به همراه ControlPersist اتصالات را روی یک نشست TCP مالتی‌پلکس می‌کند، بنابراین دومین و هر ssh، scp یا rsync بعدی به همان میزبان، به‌جای مذاکره مجدد، بلافاصله متصل می‌شود؛ تفاوتی که هنگام استفاده از Ansible بسیار چشمگیر است. و از آنجا که scp، rsync و Ansible همگی همین فایل را می‌خوانند، هر نامی که اینجا تعریف کنید در همه جا کار می‌کند.

نکته مهم: اتصال اصلی (master) ممکن است بیش از حد لازم باقی بماند و دو حالت خرابی آن متفاوت به نظر می‌رسد. وقتی سرور ری‌بوت می‌شود یا Wi-Fi شما قطع می‌شود، پردازش اصلی یک نشست TCP مرده را نگه می‌دارد که هنوز متوجه آن نشده است، و ssh web1 بعدی در سوکتی که به هیچ‌جا نمی‌رسد، بی‌صدا معلق می‌ماند. به‌طور جداگانه، sshd تعداد نشست‌ها در هر اتصال را به 10 محدود می‌کند (MaxSessions در sshd_config)، بنابراین یازدهمین نشست مالتی‌پلکس‌شده به یک میزبان این خطا را چاپ می‌کند:

mux_client_request_session: session request failed: Session open refused by peer

هر دو یک راه‌حل دارند: ssh -O exit web1 اتصال اصلی را می‌کشد و اتصال بعدی یک نشست تازه ایجاد می‌کند. ممکن است گاهی ControlSocket /home/matt/.ssh/cm-matt@10.8.0.11-22 already exists, disabling multiplexing را ببینید؛ این مورد بی‌خطر است: دو نشست با هم رقابت کرده‌اند و اتصال همچنان کار می‌کند، فقط مالتی‌پلکس نشده است.

دو همراه در این مقیاس: tmux روی هر سرور جایگزین nohup می‌شود؛ کارهایی که هنگام قطع Wi-Fi از دست می‌روند و مشکل "نمی‌توانم لپ‌تاپم را ببندم چون یک migration در حال اجراست". هزینه راه‌اندازی: sudo apt install -y tmux، دو دقیقه، به‌علاوه عادت کردن به tmux new -s work و tmux attach -t work. نکته مهم، تودرتو بودن است: tmux داخل tmux کلید پیشوند شما را می‌بلعد، بنابراین آن را یا روی سرور اجرا کنید یا روی لپ‌تاپ، نه هر دو. اگر نشست‌های agent طولانی‌مدت دارید، این موضوع اهمیت دوچندان پیدا می‌کند؛ این همان الگویی است که در اجرای Claude Code در tmux روی یک VPS وجود دارد، جایی که نشست باید از اتصال SSH طولانی‌تر عمر کند.

یک فایل alias مشترک جایگزین تایپ مجدد دوازده دستور محبوب شما روی هر سرور می‌شود. یک .bash_aliases را در یک مخزن git نگه دارید و آن را روی هر سرور pull کنید. نکته مهم: به محض اینکه آن را مستقیماً روی یک سرور ویرایش کنید و نه در مخزن، دچار انحراف (drift) می‌شود؛ که این اولین تجربه شما از دلیل نیاز به سطح بعدی مدیریت سرور است.

5 تا 20 سرور: پیکربندی به عنوان کد، یا شکست در برابر انحراف تنظیمات

فراتر از 5 سرور، «من فقط روی هر دستگاه انجامش می‌دهم» دیگر یک روش نیست، بلکه دروغی است که به خود می‌گویید. ابزارهای این سطح، همگی با یک دشمن می‌جنگند: انحراف تنظیمات (drift).

Ansible جایگزین حلقه‌های shell روی نام میزبان‌ها، صفحه ویکی با عنوان «راه‌اندازی سرور جدید» که سه مرحله از واقعیت عقب است، و اضطراب ناشی از ندانستن اینکه آیا web3 واقعاً اصلاحیه را دریافت کرده یا نه، می‌شود. هزینه راه‌اندازی: 30 دقیقه تا اولین playbook کاری، sudo apt install -y ansible روی لپ‌تاپ یا یک سرور مدیریتی (apt نسخه قدیمی‌تری از Ansible را می‌دهد که برای تمام موارد اینجا مناسب است؛ روش pipx در این آموزش نسخه‌های به‌روز را در اختیار شما می‌گذارد)، بدون نیاز به agent روی سرورها، و همه چیز از طریق تنظیمات SSH که قبلاً ساخته‌اید اجرا می‌شود. این بزرگ‌ترین ارتقای تکی در این صفحه است و راهنمای کامل آن در آموزش اولین playbook با Ansible آمده است؛ در اینجا ساختار 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 استفاده می‌کند، ~/.ssh/config که در بخش قبل نوشتید از قبل اعمال شده است؛ یک inventory از نام‌های ساده مانند web1 بدون هیچ متغیری کار خواهد کرد. متغیرهای بالا در عوض باعث می‌شوند inventory مستقل باشد، که روزی که آن را از دستگاهی غیر از لپ‌تاپ خود اجرا می‌کنید، نتیجه‌بخش خواهد بود.

آن را با ansible all -i inventory.ini -m ping تست کنید؛ نتیجه صحیح برای هر میزبان، "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 تنها به اندازه لایه‌ای که زیر آن قرار دارد سالم است. تنها نکته فراتر از آن: Ansible به Python روی دستگاه شما و برای تقریباً هر ماژولی از جمله ping، روی سرور هم نیاز دارد، بنابراین یک image واقعاً مینیمال ممکن است /usr/bin/python3: not found پاسخ دهد. یک apt install python3 مشکل را برای همیشه حل می‌کند؛ برای مجموعه‌ای از imageهای خام، ماژول raw، که یکی از معدود ماژول‌هایی است که به Python در مقصد نیاز ندارد، می‌تواند آن نصب را برای شما انجام دهد.

unattended-upgrades جایگزین شما به عنوان شخصی می‌شود که وصله‌های امنیتی را روی N سرور اعمال می‌کند. نسخه پیش‌فرض Ubuntu Server 24.04 آن را از قبل نصب کرده و معمولاً برای به‌روزرسانی‌های امنیتی فعال دارد، بنابراین وظیفه شما در اینجا تأیید است، نه نصب:

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

هر دو خط باید به "1" ختم شوند. برخی imageهای مینیمال و ابری آن را غیرفعال دارند و sudo dpkg-reconfigure -plow unattended-upgrades در صورت غیرفعال بودن، آن فایل را بازنویسی می‌کند. هزینه راه‌اندازی: دو دقیقه بررسی برای هر سرور، یا یک task در Ansible برای همه آن‌ها. نکته: به‌طور پیش‌فرض هرگز reboot نمی‌کند، بنابراین به‌روزرسانی‌های امنیتی هسته تا زمانی که خودتان اقدام نکنید، نیمه‌کاره باقی می‌مانند. راهنمای اختصاصی unattended-upgrades rebootهای خودکار، انتخاب موارد قابل وصله و خواندن لاگ‌های آن را پوشش می‌دهد.

مانیتورینگ متمرکز جایگزین مطلع شدن از طریق مشتری می‌شود، که گران‌ترین سیستم مانیتورینگ ابداع‌شده است. دو ابزار، هر کدام یک خط در مورد زمان استفاده: Uptime Kuma به «آیا سرور بالاست؟» پاسخ می‌دهد، با بررسی‌های HTTP، TCP و ping همراه با هشدار به هر مقصدی، و در Docker ده دقیقه زمان می‌برد؛ Zabbix به «آیا سرور در آستانه سقوط است؟» پاسخ می‌دهد، با روندهای دیسک، حافظه و CPU از طریق یک agent روی هر میزبان، و صادقانه بگویم یک بعدازظهر زمان می‌برد. با Kuma شروع کنید؛ وقتی «بالا بودن اما با عملکرد ضعیف» شروع به هزینه کردن برای شما کرد، Zabbix را اضافه کنید. نکته برای هر دو، محل قرارگیری است و آن‌قدر مهم است که در بخش اشتباهات در ادامه به آن پرداخته شده است.

پنل وب، فقط اگر مجبورید. Webmin جایگزین به خاطر سپردن محل فایل‌های Ubuntu می‌شود و برای یک تیم با مهارت‌های ترکیبی یا سروری که سالی دو بار به آن دست می‌زنید، واقعاً مفید است؛ راه‌اندازی آن ده دقیقه است. نکته اینجاست که این یک برنامه وب با دسترسی معادل root است که روی پورت 10000 گوش می‌دهد و اینترنت دائماً آن را اسکن می‌کند. اگر آن را اجرا می‌کنید، آن را به localhost یا یک آدرس VPN محدود کنید، هرگز به 0.0.0.0 روی یک اینترفیس عمومی متصل نکنید. و اگر به خاطر کندی SSH به سراغ پنل می‌روید، ابتدا بخش قبلی را دوباره بخوانید؛ ~/.ssh/config به همراه Ansible پس از پیکربندی، سریع‌تر از هر پنلی است.

بیش از 20 سرور: جایی که این راهنما صادقانه به پایان می‌رسد

پس از 20 سرور، شما در حال مدیریت یک ناوگان هستید و ابزارهای مورد استفاده تغییر شکل می‌دهند: استفاده از Terraform یا OpenTofu برای اینکه سرورها قابل بازتولید باشند، استفاده از cloud-init یا golden images برای اینکه یک سرور به‌جای تعمیرشدن، قابل جایگزینی باشد، استفاده از پیکربندی مبتنی بر pull یا خط لوله‌های CI برای اجرای Ansible (چون اجرای push از روی لپ‌تاپ دیگر مقیاس‌پذیر نیست)، و مدیریت واقعی اسرار (secrets). خودِ Ansible در تعداد 20 سرور از کار نمی‌افتد و بسیاری از مجموعه‌ها آن را روی صدها گره اجرا می‌کنند، اما شیوه‌های استفاده از آن باید سخت‌گیرانه‌تر شود و این موضوع، مقاله‌ای متفاوت از آنچه در این سایت نوشته می‌شود را می‌طلبد. اگر در این مقیاس هستید، بخش زیر همچنان برای شما کاربرد دارد، زیرا موجودی (inventory)، کلیدها و انضباط دسترسی، دقیقاً همان مواردی هستند که ابزارهای مدیریت ناوگان فرض می‌کنند شما از قبل در اختیار دارید.

لایه‌ای که هیچ‌کس ثبت نمی‌کند

چهار رویه در هر مقیاس ناوگانی کاربرد دارند و نادیده گرفتن آن‌ها دلیل اصلی سنگین‌تر به نظر رسیدن تعداد سرورها نسبت به واقعیت است.

یک فایل موجودی، حتی یک فایل متنی. به محض اینکه سه سرور داشتید، این موارد را یادداشت کنید: نام، IP، ارائه‌دهنده، آنچه روی آن اجرا می‌شود و دلیل وجود آن. یک servers.md در یک مخزن git کافی است؛ موجودی Ansible که در بالا ذکر شد بهتر است، زیرا مستندات اجرایی محسوب می‌شود. این فایل جایگزین این پرسش در ساعت 2 بامداد می‌شود: «صبر کن، 10.0.0.40 چیست؟» هزینه راه‌اندازی: ده دقیقه. نکته مهم: این روش تنها زمانی کار می‌کند که ایجاد سرور و افزودن خط مربوطه به فایل، یک اقدام واحد باشند و نه دو اقدام جداگانه.

بهداشت کلیدها: چرخش کلیدها همین حالا، و استفاده از SSH CA وقتی کار سخت شد. مشخص کنید کلیدهای شما کجا قرار دارند (cat ~/.ssh/*.pub در سمت شما، ~/.ssh/authorized_keys در سمت هر سرور)، لپ‌تاپ‌های قدیمی و همکاران سابق را حذف کنید و هر کلیدی که آن‌قدر قدیمی است که نمی‌دانید کجا بوده را تغییر دهید. یک مرجع صدور گواهی SSH (SSH CA) که از گواهی‌های کوتاه‌مدت امضاشده به‌جای کلیدهای ایستا استفاده می‌کند، راهکار حرفه‌ای است؛ اما توصیه صادقانه این است که برای کمتر از 10 سرور، مدیریت منضبط authorized_keys از طریق Ansible، حدود 90 درصد مزایا را با 10 درصد تشریفات برای شما فراهم می‌کند.

یک راه ورودی، نه بیست راه. هر پورت SSH عمومی، سطح حمله را به تعداد N برابر می‌کند. الگویی که مقیاس‌پذیر است: یک bastion host، یا بهتر از آن، یک WireGuard VPN روی یک VPS که کنترلش می‌کنید، و اتصال SSH سایر سرورها فقط به آدرس خصوصی آن‌ها محدود شود. خطوط ProxyJump در پیکربندی بالا از قبل این ساختار را فرض گرفته‌اند. هر چیزی که باید عمومی باقی بماند، باید به‌طور پیش‌فرض fail2ban داشته باشد. هزینه راه‌اندازی: یک ساعت، برای یک بار. نکته مهم: پیش از بستن پورت 22 در همه جا، دسترسی جایگزین خود (کنسول ارائه‌دهنده) را تست کنید، نه بعد از آن.

بک‌آپ‌هایی که با بازیابی تست شده‌اند. بک‌آپ تست‌نشده فقط یک فرضیه است. از هر مکانیزمی که استفاده می‌کنید، اسنپ‌شات‌های ارائه‌دهنده، restic، یا rsync به یک سرور دوم، ابزاری که واقعاً اهمیت دارد، یادداشت تقویمی است که در آن یک سرور را روی یک VPS تازه بازیابی می‌کنید و مطمئن می‌شوید که بوت می‌شود و سرویس می‌دهد. هر داستان ترسناکی که در 15 سال میزبانی درباره بک‌آپ شنیده‌ام، شامل این جمله بوده است: «ما بک‌آپ داشتیم.»

اشتباهات

حالت‌های شکست در مقیاس چند سرور، ناشی از ابزارها نیستند؛ بلکه ناشی از عادت‌ها هستند. چهار مورد از آن‌ها تقریباً عامل همه مشکلات هستند.

سرورهای دانه‌برفی (Snowflake servers). هر سرور به‌صورت دستی پیکربندی شده، تفاوت‌های جزئی دارد و هیچ‌کس نمی‌تواند آن را دوباره بسازد. شما این موضوع را هنگام خرابی دیسک متوجه می‌شوید. درمان آن خسته‌کننده است: هر تغییری باید از طریق Ansible اعمال شود یا حداقل به بخش مربوط به آن سرور در مستندات inventory اضافه گردد. هر سروری که نتوانید همین امروز بر اساس یادداشت‌ها دوباره بسازید، یک بدهی فنی است که تاریخ سررسید آن را شما تعیین نمی‌کنید.

حفره‌های «موقت» در فایروال. ufw allow 5432 برای عیب‌یابی چیزی باز شده و هجده ماه بعد، Postgres همچنان در دسترس اینترنت است. با sudo ufw status numbered روی هر سرور یا در یک مرحله با ansible all -i inventory.ini -a "ufw status numbered" --become، وضعیت را بازرسی کنید و هر موردی که دلیل فعلی برای آن ندارید، حذف کنید. اگر قانونی واقعاً موقت است، دستور ufw delete متناظر با آن را پیش از بستن پنجره tmux، در همان‌جا وارد کنید.

میزبانی مانیتورینگ روی سروری که مانیتور می‌شود. اگر Uptime Kuma روی سروری اجرا شود که خودش آن را نظارت می‌کند، هشداری که می‌گوید «همه چیز از کار افتاده است» نیز از کار می‌افتد؛ شما نسخه کوچک‌تر و خنده‌دارتری از کم‌بازده‌ترین دیتاسنتر جهان ساخته‌اید. مانیتورینگ باید در دامنه شکست متفاوتی قرار داشته باشد: یک VPS ارزان در یک ارائه‌دهنده دیگر، پاسخ کلاسیک برای این مشکل است یا حداقل یک سرویس رایگان خارجی که ناظر را نظارت کند.

دسترسی root SSH در همه جا. یک کلید root مشترک در کل ناوگان سرورها به این معنی است که با لو رفتن یک لپ‌تاپ، همه چیز در اختیار مهاجم قرار می‌گیرد و هیچ ردپای حسابرسی برای تشخیص اینکه چه کسی چه کاری انجام داده وجود ندارد. از کاربران شخصی، sudo و PermitRootLogin no در فایل /etc/ssh/sshd_config روی هر میزبان استفاده کنید که این کار نیز، باز هم، یک تسک سه خطی در Ansible است و نه یک شب وقت گذاشتن برای تایپ کردن.

وقتی تعداد سرورها از چند عدد فراتر رفت، اولین Ansible playbook شما بخش‌های تکراری را خودکار می‌کند.

FAQ

بهترین ابزار رایگان برای مدیریت چندین سرور لینوکسی چیست؟

برای 2 تا 5 سرور، یک ~/.ssh/config خوب نوشته‌شده به همراه tmux از هر ابزار دیگری که نصب کنید، کارآمدتر است. از حدود 5 سرور به بالا، Ansible پاسخ استاندارد است: بدون نیاز به agent، رایگان، اجرا بر بستر SSH که از قبل دارید، و تبدیل پیکربندی سرور به فایل‌های موجود در git. برای هشدار وضعیت بالا/پایین بودن سرورها، Uptime Kuma را اضافه کنید؛ تمام ابزارهای نام‌برده در این راهنما، نرم‌افزار آزاد هستند.

آیا می‌توانم بدون Ansible چندین سرور لینوکسی را مدیریت کنم؟

بله، برای کمتر از 5 سرور، یک فایل پیکربندی SSH مناسب، یک فایل alias مشترک و نظم شخصی کافی است و بسیاری از افراد سال‌ها به همین روش کار می‌کنند. فراتر از آن، جایگزین Ansible «هیچ» نیست، بلکه ایجاد تفاوت‌های ثبت‌نشده (drift) است: هجده سروری که هر کدام به‌صورت دستی و کمی متفاوت پیکربندی شده‌اند. اگر Ansible سنگین به نظر می‌رسد، با یک playbook شروع کنید که فقط authorized_keys و unattended-upgrades را مدیریت می‌کند؛ همین کار به‌تنهایی ارزش یادگیری آن را دارد.

چگونه یک دستور مشابه را همزمان روی چندین سرور لینوکسی اجرا کنم؟

ansible all -i inventory.ini -a "uptime" پاسخ تمیزی است و نیازی به playbook ندارد، فقط به فایل inventory نیاز دارد. برای کارهای تعاملی کنار هم، tmux می‌تواند کلیدهای فشرده‌شده را با setw synchronize-panes on به تمام paneها ارسال کند، اما آن را فقط یک ترفند بدانید؛ چرا که ارسال دستورات تعاملی به سرورهای عملیاتی (production) باعث می‌شود یک اشتباه تایپی ساده، منجر به قطعی در N سرور شود.

آیا برای مدیریت سرورهای لینوکسی به کنترل‌پنلی مانند Webmin نیاز دارم؟

خیر، هر کاری که یک پنل انجام می‌دهد، SSH و Ansible به‌صورت تکرارپذیرتر انجام می‌دهند. Webmin زمانی جایگاه خود را پیدا می‌کند که افرادی با سطوح مهارتی متفاوت، سرورهای یکسانی را مدیریت کنند، یا زمانی که آن‌قدر دیر به سرور سر می‌زنید که پیدا کردن مجدد مسیرهای پیکربندی زمان‌بر است. اگر از آن استفاده می‌کنید، با آن مانند یک اپلیکیشن وب با دسترسی root رفتار کنید: آن را فقط به localhost یا یک آدرس VPN محدود کنید و هرگز روی اینترفیس عمومی قرار ندهید.

یک نفر به‌طور واقع‌بینانه چند سرور لینوکسی را می‌تواند مدیریت کند؟

با مدیریت دستی، کیفیت کار زیر 10 سرور افت می‌کند. با استفاده از پیکربندی به عنوان کد (config as code)، وصله‌گذاری خودکار و مانیتورینگ متمرکز، یک فرد دقیق می‌تواند 20 تا 50 سرور را به عنوان یک شغل پاره‌وقت اداره کند؛ محدودیت اصلی در اینجا تعداد دفعاتی است که یک مشکل جدید و غیرمنتظره رخ می‌دهد، نه کارهای روتین. عددی که اهمیت دارد، تعداد سرور به ازای هر مدیر نیست، بلکه تعداد «سرورهای خاص و منحصربه‌فرد» (snowflakes) به ازای هر مدیر است: آن را نزدیک به صفر نگه دارید تا سقف توانایی شما بالا برود.