Кілька клієнтських сайтів на одному сервері: як це організувати без хаосу

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

 

Ізоляція — перше, про що варто подбати

Кожен сайт має працювати під власним системним користувачем, із власною текою й власною базою. Це не формальність: при такому розділенні зламаний застосунок на одному проєкті не дає доступу до файлів сусіднього. Поширена помилка початківців — тримати все під одним обліковим записом, бо так простіше роздавати права.

Рівненська студія, яка веде близько п'ятнадцяти корпоративних сайтів, прийшла до цієї схеми після випадку, коли застарілий плагін на одному з проєктів дозволив завантажити сторонній скрипт — і той обійшов усі сусідні теки за лічені хвилини.

Розподіл ресурсів

Другий ризик — не безпека, а конкуренція за процесор і пам'ять. Один клієнтський магазин запускає імпорт прайсу, і решта сайтів починає відповідати повільніше. Лікується обмеженнями на рівні обробників: кожному сайту виділяється максимальна кількість одночасних процесів, щоб жоден не міг забрати всі ресурси.

Для такої схеми має сенс брати VPS-сервер для кількох сайтів із запасом пам'яті: економія на конфігурації тут обертається регулярними скаргами, бо навантаження сумується непередбачувано.

Доступи й передача проєктів

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

Окремо продумайте доступи для розробників: окремий обліковий запис із правами лише на потрібний проєкт, а не спільний адміністраторський пароль у переписці. Після завершення співпраці такий доступ вимикається одним рухом.

Резервні копії по проєктах

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

Де схема перестає працювати

Коли серед клієнтів з'являється магазин із серйозним трафіком, тримати його поруч із десятком візиток стає ризиковано: його піки відчують усі. Так само виносити окремо варто проєкти з підвищеними вимогами до доступу — ті, де обробляються персональні дані або де замовник вимагає окреме середовище за договором.

Моніторинг як страховка від дзвінків

У схемі з багатьма проєктами особливо помітна різниця між тим, щоб дізнатися про збій від системи моніторингу, і тим, щоб почути про нього від клієнта. Налаштуйте перевірку доступності кожного сайту окремо, а не лише сервера загалом: машина може відповідати, тоді як конкретний проєкт віддає помилку.

Другий корисний сигнал — контроль вільного місця на диску. Непомітно зростаючі журнали або забуті архіви заповнюють розділ, і тоді одночасно перестають працювати всі сайти. Це найчастіша причина масового падіння на спільному сервері, і вона повністю передбачувана.

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

Следующая >