Як керувати кількома Linux серверами

Що ви створюєте

Це не один інструмент, а набір технологій, обраний залежно від реальної кількості ваших серверів. Кількість серверів — це єдиний важливий показник, який ігнорують у більшості підбірок «інструментів для керування Linux-серверами». Класична помилка — впровадження рішення для 200 серверів на чотирьох VPS, що призводить до витрат місяця на налаштування інструменту замість обслуговування серверів. Друга класична помилка — коли адміністратор із вісімнадцятьма серверами все ще підключається до кожного через SSH вручну, застосовуючи «однакові» зміни вісімнадцятьма різними способами.

Цей посібник структуровано за розміром парку серверів: від 2 до 5, від 5 до 20 та понад 20. Також додано загальні рівні, які актуальні для будь-якої кількості серверів, але про які ніхто не пише: інвентаризація, гігієна ключів, єдиний спосіб доступу та бекапи, які ви дійсно успішно відновлювали. Для кожного інструмента наведено три параметри: що він замінює, час налаштування у хвилинах та реальна проблема, з якою ви зіткнетеся. Я керую VPS-хостингом протягом 15 років; наведений нижче список — це те, що працює під час аварій о 2 годині ночі, а не те, що гарно виглядає на демо.

Prerequisites and honest gotchas

Вам потрібен робочий доступ до кожного сервера через SSH за допомогою ключів (якщо ви все ще вводите паролі, спочатку налаштуйте ключі — це займе 10 хвилин, а всі наступні кроки передбачають наявність ключів). Також потрібен користувач із правами sudo (не root) та сучасні версії ОС на серверах. Наведені команди розраховані на Ubuntu 24.04, але всі інструменти універсальні, окрім apt.

Два попередження перед оглядом інструментів. По-перше, надмірне використання інструментів створює проблеми з адмініструванням: кожен встановлений агент — це ще один демон, який потрібно оновлювати на кожному вузлі. Додавайте новий інструмент лише якщо він замінює ручну роботу, яку ви виконували цього тижня, а не просто тому, що він здається корисним. По-друге, все наведено у форматі free software, тому справжньою ціною є час на налаштування. Саме тому для кожного інструмента вказано приблизний час у хвилинах — якщо вказано "після обіду", так воно і буде.

2–5 серверів: ~/.ssh/config — найбільш недооцінений інструмент, який у вас вже є

Що він замінює: текстові файли з IP-адресами, пошук у shell-history (ssh 203.0, потім Ctrl-R і сподівання на удачу) та постійне введення -p 2222 -i ~/.ssh/other_key. Вартість налаштування: 15 хвилин, один раз. Нюанс: застарілі сокети мультиплексування, описано нижче.

При такому масштабі вам не потрібне нове ПЗ; вам потрібен клієнт, який вже налаштований належним чином. ~/.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 читають один і той самий файл, кожне визначене тут ім'я працює всюди.

Нюанс: основне з'єднання може залишатися активним після того, як воно стало непотрібним, і має два різні сценарії відмови. Коли сервер перезавантажується або зникає Wi-Fi, основний процес залишається з мертвою TCP-сесією, яку він ще не помітив, і наступний ssh web1 беззвучно зависає на сокеті, що веде в нікуди. Окремо, sshd обмежує кількість сесій на одне з'єднання до 10 (MaxSessions у sshd_config), тому одинадцята мультиплексована сесія до одного хоста видасть:

mux_client_request_session: session request failed: Session open refused

Обидва випадки вирішуються однаково: ssh -O exit web1 завершує основний процес, і наступне з'єднання створює нове. Іноді ви також можете побачити ControlSocket ~/.ssh/cm-matt@web1-22 already exists, disabling multiplexing — це нешкідливо: дві сесії змагалися за з'єднання, і воно все ще працює, але вже без мультиплексування.

Два супутники для такого масштабу. tmux на кожному сервері замінює nohup, втрату роботи при розриві Wi-Fi та ситуації на кшталт "я не можу закрити ноутбук, зараз триває міграція". Вартість налаштування: sudo apt install -y tmux, дві хвилини, плюс навичка використання tmux new -s work та tmux attach -t work. Нюанс — вкладеність: tmux всередині tmux поглинає ваш префіксний ключ, тому запускайте його або на сервері, або на ноутбуці, але не обидва одночасно. Якщо ви використовуєте довготривалі сесії agent, це стає ще важливішим — це той самий принцип, що й у запуску Claude Code в tmux на VPS, де сесія має передувати SSH-з'єднанню.

Спільний файл аліасів замінює повторне введення ваших дванадцяти улюблених команд на кожній машині. Зберігайте .bash_aliases у git-репозиторії та робіть pull на кожному сервері. Нюанс: дані стають неактуальними, щойно ви редагуєте файл безпосередньо на одному сервері замість репозиторію — це ваш перший досвід розуміння, чому існує наступний рівень масштабування.

Від 5 до 20 серверів: конфігурація як код, або перемога дрейфу

Коли серверів стає більше п'яти, підхід «я просто зроблю це на кожній машині» перестає бути методом і стає самообманом. Інструменти цього рівня борються з одним ворогом: дрейфом конфігурації (drift).

Ansible замінює цикли shell по хостнеймах, сторінки у wiki під назвою «налаштування нового сервера», які завжди застаріли на три кроки, та тривогу через невідомість, чи отримав web3 необхідне виправлення. Вартість налаштування: від 30 хвилин до першого робочого playbook — sudo apt install -y ansible на вашому ноутбуці або керуючому вузлі (apt надає старішу версію Ansible, що цілком припустимо для цього завдання; шлях через pipx у туторіалі надає актуальні версії), без агентів на серверах, все працює через вже налаштований SSH. Це найважливіше оновлення на цій сторінці; повний посібник доступний у туторіалі з першого playbook для Ansible; ось структура інвентарю, яка забезпечує його роботу:

[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, написаний у попередньому розділі, вже діє — інвентар з простими іменами на кшталт web1 працюватиме навіть без змінних. Змінні вище роблять інвентар самодостатнім, що стане перевагою, коли ви запустите його з іншої машини, ніж ваш ноутбук.

Перевірте це за допомогою 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 на обох кінцях, тому мінімальний образ може відповісти на /usr/bin/python3: not found — один apt install python3, і проблема зникне.

unattended-upgrades замінює вас у процесі встановлення патчів безпеки на N серверах. Стандартний Ubuntu Server 24.04 постачається з уже встановленим і зазвичай увімкненим пакетом для оновлень безпеки, тому завдання полягає у перевірці, а не в інсталяції:

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

Обидва рядки мають закінчуватися на "1". Деякі мінімальні та хмарні образи постачаються з вимкненим пакетом, і sudo dpkg-reconfigure -plow unattended-upgrades перезапише цей файл, якщо він був вимкнений. Вартість налаштування: дві хвилини на перевірку кожного сервера або одне завдання Ansible для всіх серверів. Нюанс: за замовчуванням він ніколи не перезавантажує систему, тому оновлення ядра залишаються частково застосованими, доки ви не зробите це вручну — спеціальний посібник з unattended-upgrades охоплює автоматичне перезавантаження, вибір пакетів для оновлення та читання логів.

Централізований моніторинг замінює отримання інформації від клієнта, що є найдорожчою системою моніторингу з усіх існуючих. Два інструменти, по одному рядку про призначення: Uptime Kuma відповідає на питання «чи працює сервіс?» — перевірка HTTP, TCP та ping з оповіщеннями на будь-який ресурс — і налаштовується за десять хвилин у Docker; Zabbix відповідає на питання «чи скоро він впаде?» — тренди використання диска, пам'яті та CPU через агент на кожному хості — і фактично потребує цілого дня налаштування. Починайте з Kuma; додавайте Zabbix, коли стан «працює, але деградовано» почне коштувати вам грошей. Нюанс для обох систем — це місце їхнього розміщення, що є настільки важливим, що винесено в розділ помилок нижче.

Веб-панель, тільки якщо дуже потрібно. Webmin замінює необхідність пам'ятати, де Ubuntu зберігає файли; для команди з різним рівнем кваліфікації або сервера, до якого ви звертаєтеся двічі на рік, він дійсно корисний; налаштування займає десять хвилин. Нюанс полягає в тому, що це веб-додаток з правами root, який слухає порт 10000, і інтернет постійно сканує його. Якщо ви запускаєте його, прив'яжіть його до localhost або VPN-адреси — ніколи не використовуйте 0.0.0.0 на публічному інтерфейсі. І якщо ви шукаєте панель через те, що SSH працює повільно, спочатку перечитайте попередній розділ; ~/.ssh/config плюс Ansible працюють швидше за будь-яку панель після налаштування.

20+ servers: межа застосування цього посібника

Після двадцяти серверів ви керуєте парком обладнання, і інструментарій змінюється: використовується Terraform або OpenTofu для відтворюваності серверів, cloud-init або golden images для можливості швидкої заміни вузла замість його ремонту, pull-based конфігурація або CI pipelines для запуску Ansible, оскільки запуск команд з локального ноутбука не масштабується, а також впроваджується повноцінне керування секретами. Сам Ansible не має обмежень на двадцяти вузлах — багато компаній використовують його для сотень нод — але методи роботи з ним мають стати суворішими, що є темою для окремої статті. Якщо ваш парк досяг такого масштабу, наступний розділ все ще буде корисним, оскільки інвентаризація, ключі та дисципліна доступу є базовими вимогами, які передбачають інструменти для керування парком серверів.

Рівень, про який ніхто не пише

Ці чотири практики актуальні для будь-якої кількості серверів. Якщо їх ігнорувати, кількість серверів здаватиметься більшою, ніж вона є насправді.

Інвентарний файл — навіть у вигляді тексту. Як тільки у вас з'являється три сервери, запишіть: назву, IP, провайдера, що на ньому запущено та для чого він потрібен. Файл servers.md у git repo — це прийнятно; Ansible inventory наведено вище є кращим варіантом, оскільки це виконувана документація. Що він замінює: запитання о 2 годині ночі «зачекайте, а що таке 10.0.0.40?». Витрати на налаштування: десять хвилин. Підступ: це працює лише якщо створення сервера та додавання рядка в файл є однією дією, а не двома окремими.

Гігієна ключів: ротація зараз, SSH CA — коли стає складно. Перелічіть, де зберігаються ваші ключі (cat ~/.ssh/*.pub на вашій стороні, ~/.ssh/authorized_keys на кожному сервері), видаляйте ключі з розібраних ноутбуків та колишніх колег, і ротуйте все, що застаріло настільки, що ви не можете відстежити шлях використання. SSH certificate authority (короткострокові підписані сертифікати замість статичних ключів) — це професійне рішення. Проте чесна порада: якщо у вас менше десяти серверів, дисципліноване authorized_keys керування через Ansible дасть 90% переваг при 10% витрат на процедури.

Один шлях доступу замість двадцяти. Кожен відкритий SSH порт — це поверхня атаки, помножена на N. Масштабована схема: один bastion host — або, що краще, WireGuard VPN на VPS під вашим контролем — і SSH на всіх інших серверах прив'язаний лише до приватної адреси. Рядки ProxyJump у конфігурації вище вже передбачають таку структуру. Все, що має залишатися публічним, обов'язково повинно мати fail2ban. Витрати на налаштування: один раз за годину. Підступ: перевірте, чи працює ваш резервний метод (консоль провайдера), перш ніж закривати порт 22 всюди, а не після цього.

Беккапи, перевірені відновленням. Неперевірений беккап — це лише гіпотеза. Який би механізм ви не використовували — snapshots провайдера, restic, rsync на другий вузол — реально важливим є запис у календарі, коли ви відновлюєте один сервер на новому VPS і підтверджуєте, що він завантажується та працює. Кожна жахлива історія про втрату даних, яку я чув за 15 років хостингу, містить фразу «у нас були бекапи».

Помилки

При масштабуванні до декількох серверів причиною збоїв є не інструменти, а звички. Чотири з них становлять майже всі проблеми.

Snowflake servers. Кожен сервер налаштовувався вручну, він має незначні відмінності, і його неможливо відновити. Ви помітите це лише під час виходу з ладу диска. Рішення просте: усі зміни мають проходити через Ansible — або принаймні додаватися до відповідного розділу в inventory doc — будь-який сервер, який неможливо відновити за нотатками сьогодні вдень, є технічним боргом з терміном погашення, який ви не обираєте.

"Тимчасові" дірки у firewall. Ви відкриваєте 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 key на весь парк серверів означає, що витік одного ноутбука дає доступ до всього, а аудит не покаже, хто саме що зробив. Створюйте індивідуальних користувачів, використовуйте sudo та PermitRootLogin no у /etc/ssh/sshd_config на кожному хості — це знову ж таки три рядки в Ansible замість вечора друку.

Коли парк серверів стає більшим за кілька одиниць, ваш перший Ansible playbook автоматизує повторювані дії.

FAQ

Який безкоштовний інструмент найкращий для керування кількома Linux-серверами?

Для 2–5 серверів добре написаний ~/.ssh/config разом із tmux кращий за будь-яке встановлене ПЗ. Починаючи приблизно з п'яти серверів, стандартом є Ansible: він не потребує агентів, є безкоштовним, працює через наявний SSH і перетворює налаштування сервера на файли в git. Додайте Uptime Kuma для сповіщень про стан системи; кожна програма, згадана в цьому посібнику, є вільним програмним забезпеченням.

Чи можна керувати кількома Linux-серверами без Ansible?

Так — якщо у вас менше п'яти серверів, достатньо мати хороший SSH config, спільний файл alias та дисципліну; багато людей працюють саме так роками. Якщо серверів більше, альтернативою Ansible є не "нічого", а неконтрольовані відхилення (drift): вісімнадцять серверів, кожен з яких налаштований вручну дещо інакше. Якщо Ansible здається занадто складним, почніть з одного playbook, який керує лише authorized_keys та unattended-upgrades; це вже окупить час, витрачений на навчання.

Як одночасно запустити одну й ту саму команду на кількох Linux-серверах?

ansible all -i inventory.ini -a "uptime" — це правильне рішення, яке не потребує playbook, лише файлу inventory. Для інтерактивної роботи у кількох вікнах можна використовувати tmux для трансляції натискань клавіш у кожне вікно за допомогою setw synchronize-panes on — але сприймайте це лише як цікаву функцію, оскільки трансляція інтерактивних команд на production-сервери призводить до того, що одна помилка перетворюється на збій на N серверах.

Чи потрібно використовувати панель керування на кшталт Webmin для керування Linux-серверами?

Не обов'язково — SSH та Ansible забезпечують вищу відтворюваність усього, що робить панель. Webmin доцільний, коли одна й та сама машина адмініструється людьми з різним рівнем кваліфікації, або коли ви звертаєтеся до сервера так рідко, що пошук шляхів конфігурації витрачає забагато часу. Якщо ви використовуєте таку панель, ставте до неї ставлення як до веб-додатка з правами root: прив'яжіть її до localhost або VPN-адреси, але ніколи не виставляйте на публічний інтерфейс.

Скільки Linux-серверів реально може обслуговувати одна людина?

При ручному адмініструванні якість роботи падає, коли серверів стає менше десяти. При використанні підходу config as code, автоматичного оновлення та централізованого моніторингу, одна людина може обслуговувати від 20 до 50 серверів у режимі часткової зайнятості — обмеженням стає частота виникнення непередбачуваних помилок, а не рутинний догляд. Важлива не кількість серверів на одного адміністратора, а кількість унікальних конфігурацій ("сніжинок") на одного адміністратора: тримайте цей показник близьким до нуля, і ви зможете масштабуватися.