Як керувати кількома Linux-серверами: робочі інструменти

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

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

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

Передумови та реалістичні застереження

На кожному сервері вже має працювати SSH з автентифікацією за ключем. Якщо ви досі вводите паролі, спочатку виправте це. Це займає десять хвилин, а все нижче передбачає використання ключів. Також потрібен користувач із правами sudo, але не root, і сервери з актуальною версією ОС. Команди нижче розраховані на Ubuntu 24.04, але Ubuntu-специфічним є лише apt.

Перед використанням інструментів врахуйте два важливі застереження. По-перше, надмірна кількість інструментів сама стає проблемою адміністрування. Кожен встановлений agent — це ще один daemon, який потрібно оновлювати на кожному сервері. Тому додавати новий інструмент варто лише тоді, коли він замінює ручну роботу, яку ви виконували цього тижня, а не просто здається корисним. По-друге, усе описане тут є вільним програмним забезпеченням, а справжня вартість полягає в часі налаштування. Саме тому для кожного інструмента наведено оцінку в хвилинах. Якщо в оцінці зазначено цілий робочий день, так і плануйте.

Від 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 не потрібне, як і команди ProxyCommand, а приватним серверам взагалі не потрібні публічні SSH-порти (докладніше про це в наскрізному розділі). ControlMaster auto разом із ControlPersist мультиплексує з’єднання через один TCP-сеанс. Тому другий і кожен наступний ssh, scp або rsync до того самого хоста підключається миттєво, без повторного узгодження параметрів. Коли з’являється Ansible, ця різниця стає особливо помітною. Оскільки scp, rsync і Ansible читають той самий файл, кожне визначене тут ім’я працює всюди.

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

mux_client_request_session: session request failed: Session open refused

В обох випадках рішення однакове: ssh -O exit web1 завершує master-процес, а наступне з’єднання створює новий. Іноді ви також можете побачити 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-з’єднання.

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

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

Після п’яти серверів підхід «зроблю це на кожному сервері» перестає бути методом і стає самообманом. Усі інструменти цього рівня борються з однією проблемою: дрейфом конфігурації.

Ansible замінює shell-цикл за іменами хостів, сторінку wiki під назвою «налаштування нового сервера», яка вже застаріла на три кроки, і невпевненість у тому, чи справді web3 отримав виправлення. Витрати на налаштування: 30 хвилин до першого робочого playbook, sudo apt install -y ansible на вашому ноутбуці або management-сервері (apt встановлює старішу версію Ansible, але для всього описаного тут цього достатньо; маршрут tutorial через pipx встановлює актуальні версії), без агентів на серверах, усе працює через уже налаштовану конфігурацію SSH. Це найбільше окреме покращення на цій сторінці. Повний опис наведено в tutorial про перший 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, працював би взагалі без vars. Наведені вище vars роблять 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 на обох кінцях з’єднання. Тому справді мінімальний образ може повернути /usr/bin/python3: not found, після чого достатньо один раз виконати apt install python3, і ця проблема більше не виникатиме.

unattended-upgrades замінює адміністратора, який застосовує security patches до N серверів. Stock Ubuntu Server 24.04 постачається з ним попередньо встановленим і зазвичай уже ввімкненим для security updates, тому тут потрібно перевірити налаштування, а не встановлювати пакет:

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

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

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

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

20+ серверів: де цей посібник чесно завершується

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

Шар, про який ніхто не записує

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

Файл інвентаризації, навіть текстовий. Щойно у вас з’являється три сервери, запишіть: ім’я, IP-адресу, провайдера, що на сервері працює і навіщо він потрібен. servers.md у git-репозиторії достатньо; наведений вище інвентар Ansible кращий, оскільки це виконувана документація. Він замінює запитання о другій ночі: «Зачекайте, що таке 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 всюди, а не після цього.

Резервні копії потрібно перевіряти відновленням. Неперевірена резервна копія — це лише припущення. Незалежно від механізму — snapshot провайдера, restic, rsync на другий сервер — насправді важливим є запис у календарі, за яким ви відновлюєте один сервер на чистому VPS і перевіряєте, що він завантажується та обслуговує запити. У кожній історії про проблеми з резервними копіями, яку я чув за п’ятнадцять років хостингу, була фраза: «У нас були резервні копії».

Помилки

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

Сервери-сніжинки. Кожен сервер налаштований вручну, трохи відрізняється від інших, і ніхто не може відтворити його конфігурацію. Це з’ясовується під час відмови диска. Рішення нецікаве: кожна зміна має проходити через Ansible або щонайменше додаватися до розділу цього сервера в документі інвентаризації. Сервер, який ви не змогли б відновити за нотатками сьогодні вдень, є технічним боргом із терміном погашення, який ви не можете обрати.

«Тимчасові» отвори у 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 в іншого провайдера. Щонайменше використовуйте зовнішню перевірку на безкоштовному тарифі, яка стежить за системою моніторингу.

SSH під root усюди. Один спільний ключ root для всього парку серверів означає, що один викрадений ноутбук дає доступ до всіх систем. Крім того, в журналі аудиту не буде видно, хто що зробив. Створіть окремих користувачів для кожної людини, налаштуйте sudo і PermitRootLogin no у /etc/ssh/sshd_config на кожному хості. Це знову лише три рядки в задачі Ansible замість цілого вечора ручного введення команд.

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

FAQ

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

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

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

Так. Якщо серверів менше приблизно п’яти, достатньо правильно налаштованого SSH, спільного файлу alias і дисципліни. Багато адміністраторів працюють так роками. Коли серверів стає більше, альтернативою Ansible є не «нічого», а ненадокументовані відмінності: 18 серверів, кожен із трохи іншими ручними налаштуваннями. Якщо Ansible здається надто складним, почніть з одного playbook, який керує лише authorized_keys і unattended-upgrades. Цього вже достатньо, щоб виправдати час на навчання.

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

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

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

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

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

За ручного адміністрування якість починає знижуватися, коли серверів стає менше десяти. Якщо використовувати конфігурацію як код, автоматичне встановлення оновлень і централізований моніторинг, одна уважна людина може обслуговувати 20–50 серверів як частину робочого часу. Обмеженням стає не регулярне обслуговування, а частота нових непередбачених збоїв. Важлива не кількість серверів на одного адміністратора, а кількість унікально налаштованих серверів на одного адміністратора: якщо наблизити її до нуля, верхня межа буде високою.