Перехід із cPanel на Enhance: що зміниться для вас

cPanel був стандартною панеллю керування хостингом протягом двадцяти років, тому більшість людей, які переходять із нього, насправді не порівнюють функції — їх більше хвилює, що станеться наступного дня після переїзду. Ось що справді змінюється.

Змінюється сама модель — і в цьому весь сенс

cPanel надає вам один обліковий запис, усередині якого знаходиться все: файли, бази даних, пошта, cron — і все це використовує спільні ліміти акаунта. Enhance надає окремий контейнер для кожного сайту. П’ять ваших сайтів — це п’ять ізольованих середовищ зі своїми лімітами CPU, RAM та I/O. Те саме стосується реселер-хостингу на Enhance і віртуального хостингу на Enhance: один сайт — один контейнер.

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

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

Куди перемістилися звичні функції

Ті самі завдання, просто знаходяться в інших місцях. Нічого з цього списку в Enhance не зникло — воно просто перемістилося.

Але дві речі справді відрізняються.

На рівні акаунта більше немає спільного public_html — кожен сайт має власний web root. Також немає директорії .cpanel із конфігурацією всього акаунта: цим станом керує сама панель. Саме тому перенесення сайту між серверами виконується засобами панелі, а не простим перенесенням tar-архіву.

Дві звички, від яких доведеться відмовитися

Перестаньте мислити «акаунтами» та почніть мислити «сайтами». У cPanel додавання другого проєкту зазвичай означало створення addon-домену всередині того самого акаунта зі спільною версією PHP та спільними лімітами. В Enhance ви додаєте окремий сайт, який отримує власну версію PHP, власні ліміти та власні резервні копії. Бази даних теж належать сайту: MySQL або, де хостинг це підтримує, PostgreSQL для проєктів, яким він потрібен.

Під час міграції користувачі іноді намагаються відтворити стару структуру — один сайт із п’ятьма додатковими доменами — а потім дивуються, куди зникла ізоляція.

Перестаньте встановлювати окремі плагіни безпеки на кожен сайт. WAF, сканування шкідливого ПЗ та захист від brute-force працюють нижче рівня сайту — безпосередньо на сервері. WordPress-плагін безпеки поверх цього здебільшого лише витрачає CPU, повторно скануючи вже перевірені файли, а його функція блокування спроб входу починає дублювати серверний захист.

Як насправді відбувається переїзд

Грамотна міграція — це не tar-архів і надія на краще. Ось порядок дій, який дозволяє уникнути простою:

1. Копіювати, а не переносити. Сайти відтворюються на новій платформі, поки старі продовжують обслуговувати відвідувачів. На цьому етапі DNS взагалі не змінюється.
2. Перевірити кожен сайт через тимчасовий URL. Enhance надає кожному сайту тимчасове ім’я хоста. Перевірте оформлення замовлення, контактну форму, авторизацію та інші важливі функції. Саме цей етап часто пропускають, а потім виявляють, що платіжний шлюз був прив’язаний до IP старого сервера.
3. Зменшити TTL DNS. Встановіть його на 300 секунд приблизно за добу до перемикання. Тоді в разі необхідності відкат займе хвилини, а не години.
4. Синхронізувати останні зміни. Перенесіть зміни бази даних і файлів, які з’явилися під час тестування нового сервера.
5. Перемкнути DNS. Протягом години спостерігайте за обома серверами. Старий сервер краще вимикати через тиждень, а не того ж вечора.

П’ять кроків, які дозволяють виконати міграцію без простою. DNS не змінюється аж до п’ятого кроку. Перенесення клієнтів із реселер-хостингу Namecheap — ті самі п’ять кроків, повторені для кожного акаунта.

# до перемикання: скільки часу займе відкат?
dig +short example.com A
dig example.com A | awk '/^example/ {print "TTL", $2}'

# після перемикання: чи справді сайт уже працює на новому хостингу?
curl -sI https://example.com | grep -iE 'server|x-litespeed'

Що справді може зламатися

• Жорстко прописані шляхи. Усе, що посилається на /home/olduser/public_html — наприклад, WP_CONTENT_DIR у WordPress, include у старому PHP-застосунку або команда cron, — необхідно змінити відповідно до нового шляху.
• Списки дозволених IP-адрес. Платіжні шлюзи, поштові реле та сторонні API можуть бути прив’язані до IP старого сервера. Знайдіть і перевірте такі налаштування до міграції — це одна з найпоширеніших причин проблем після перемикання.
• Пошта. Перенесення пошти — окреме завдання, не пов’язане безпосередньо з перенесенням сайтів. Якщо MX-записи домену вказують на інший поштовий сервіс, залиште їх без змін і спочатку перенесіть сайти.
• Дуже старі версії PHP. Код, якому потрібен PHP 5.6, не працюватиме на сучасній платформі. Це вже не міграція, а необхідність доопрацювання або переписування коду — і краще дізнатися про це до початку переїзду.

В inSave міграцією займаються інженери, які обслуговують саму платформу, а не автоматичний скрипт: ми копіюємо сайти, надаємо вам тимчасові URL для перевірки, і лише після підтвердження кожного сайту перемикається DNS.

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

Коротко

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

Міграція безпечна, коли виконується за принципом «скопіювати → перевірити → перемкнути», і стає ризикованою, коли стару систему вимикають одразу в момент переїзду.

Більшість проблем під час міграції пов’язана не із самою панеллю. Зазвичай винен жорстко прописаний шлях або список дозволених IP-адрес, про який ніхто заздалегідь не згадав.