Міграція PrestaShop з Hestia на DirectAdmin

Міграція PrestaShop з Hestia на DirectAdmin

Міграція PrestaShop не обов'язково означає перенесення всього стеку. У цьому випадку я переніс бекенд зі старої налаштування Hestia на новий хостинг на базі DirectAdmin за один вечір. Фронтенд залишився на своїй існуючій платформі. Сервіси розсилки новин та CRM також залишилися на своїх місцях. Обсяг робіт був вужчим: зробити так, щоб новий бекенд обробляв REST API, кешування та cron-завдання для системи електронної комерції з кількома магазинами.

Активна робота зайняла близько трьох-чотирьох годин. Передача файлів була легкою частиною. Справжня робота полягала в тому, щоб довести, що маршрутизація, Redis, cron, інвалідація кешу та відповіді API для конкретного магазину продовжують працювати після перенесення.

Що я переніс під час міграції PrestaShop

Бекенд було розміщено на сучасному тарифі спільного хостингу з NVMe-сховищем, виділеним процесором та виділеною оперативною пам'яттю. Панель хостингу звітувала про очікуваний пакет та квоту на диску.

Я переніс не все, і це було навмисно.

Перенесено:

Залишено на місці:

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

Маршрутизація була першою проблемою

PrestaShop працює як бекенд з підтримкою кількох магазинів (multishop). Це означає, що один бекенд має коректно відповідати за два магазини. На старому хостингу правила панелі та існуюча поведінка URL приховували частину складності. На новому хості REST-запити мали зберігати контекст магазину перед тим, як PrestaShop перенаправить або канонізує запит.

Рішення полягало в правильній маршрутизації REST-викликів з префіксом магазину:

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

Redis допоміг, але очищення кешу було важливішим

Redis було увімкнено через Unix-сокет:

text /home/account/.redis/redis.sock

Після цього PrestaShop використовував Redis як бекенд для кешування. Відповіді API покращилися, але кеш має значення лише тоді, коли він очищається у потрібний час.

Бек-офіс є джерелом істини. Коли хтось змінює ціну, опис продукту, блок PageBuilder, категорію або кампанію в PrestaShop, API фронтенду має надавати актуальні дані. Самостійного увімкнення кешу недостатньо. Мені також довелося підключити очищення кешу до відповідних хуків PrestaShop.

Я перевіряв поведінку безпосередньо:

Це різниця між «кеш увімкнено» та «кешу можна довіряти». В електронній комерції ця різниця має миттєве значення.

Cron-завдання потребували ретельної фільтрації

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

Відповідні завдання PrestaShop були на старому робочому сервері Hestia:

Я не мігрував призупинене завдання CRM. Також я пропустив внутрішні системні завдання Hestia. DirectAdmin має власний потік обслуговування та резервного копіювання, тому копіювання сміття панелі створило б лише плутанину.

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

Результати продуктивності після перенесення бекенду

Я тестував одну й ту саму публічну кінцеву точку REST 12 разів для кожного магазину:

text /rest/pagebuilder/placements

Ось результати:

Сервер stage був простим еталонним сервером і відповідав стабільно. Новий хост все одно відповідав швидше для обох магазинів.

Новий хост також показав вищий середній рівень завантаження сервера, близько 10-13. SSH виявив більше потоків CPU на фізичному хості, ніж виділено для облікового запису, тому це число саме по собі не було тривожним. Обліковий запис виглядав спокійним: Redis був майже неактивним, воркери PHP не навантажували CPU, а база даних мала низьке активне навантаження запитами, коли я перевіряв.

Саме тому я обережно ставлюся до середнього навантаження на спільному хостингу. Воно відображає стан хоста, а не лише одного облікового запису. Якщо ваш провайдер продає тариф з чіткими специфікаціями CPU та RAM, все одно варто запитати, як ці обмеження забезпечуються через CloudLinux або LVE.

Мій робочий процес зі ШІ для міграції

Я використовував Codex як операційного агента для роботи з SSH, API DirectAdmin, перевірок сервера, змін у crontab, тестів часу та роботи з перевизначеннями PrestaShop.

Для огляду я використовую свій відкритий робочий процес ai-collab-bridge. Ідея проста: один ШІ впроваджує зміну, потім інший ШІ отримує пакет для огляду з diff, контекстом та сфокусованими запитаннями. Claude Code може тоді переглянути роботу як другий технічний читач, замість того щоб реагувати на розпливчасте резюме.

Це важливо в міграції PrestaShop, оскільки є багато малих рішень:

ШІ допомагає, коли він має показувати свої перевірки. «Це працює» недостатньо. Корисний прогон міграції показує команди, коди статусу, поведінку кешу, стан cron та частини, які навмисно не були перенесені.

Уроки, які я виніс з цієї міграції

Не копіюйте поведінку панелі сліпо. Hestia та DirectAdmin по-різному вирішують питання обслуговування хостингу. Cron панелі Hestia не належить до DirectAdmin.

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

Перевіряйте кеш з точки зору бек-офісу. Зміни в електронній комерції відбуваються через редагування цін, запасів, текстів та кампаній. Кеш, який не очищається, стає бізнес-проблемою.

Вимірюйте одну й ту саму кінцеву точку багаторазово. Один запит `curl` мало про що говорить. Дванадцять прогонів для кожного магазину дали мені набагато чіткіший сигнал.

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

Результат

Після перенесення бекенд відповідав швидше, ніж і старий робочий сервер, і еталонний сервер stage у моїх тестах. Redis та LiteSpeed допомогли. API DirectAdmin було достатньо для потрібних мені налаштувань панелі. Виявилося, що пам'ять OPcache є налаштуванням на рівні хоста, тому це питання до підтримки хостингу, а не до коду додатка.

Головним результатом було не нижче TTFB. Важливим результатом було те, що бекенд все ще поводився як бекенд електронної комерції: бек-офіс володіє даними, API відповідає для кожного магазину, кеш очищається при змінах, а cron запускає лише ті завдання, які належать новому хосту.

FAQ

Скільки часу зайняла міграція?

Активна міграція бекенду зайняла близько трьох-чотирьох годин. З урахуванням тестів часу, інвентаризації cron, перевірки кешу та нотаток для підтримки, робота наблизилася до чотирьох-п'яти годин.

Чому ви не перенесли все?

Фронтенд вже працював в іншому місці. Автоматизація розсилок та CRM мали власні середовища. Вузьке перенесення бекенду зменшило ризики.

Чому Redis був важливим?

Redis покращив швидкість кешування бекенду, але справжня цінність з'явилася, коли очищення кешу було підключено до хуків PrestaShop. Без цього зміни в бек-офісі можуть не дійти до API.

Чому середнє навантаження важко читати на спільному хостингу?

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

Навіщо використовувати ШІ під час міграції сервера?

ШІ корисний, коли він працює з доказами: читання конфігурації, тести часу, порівняння cron, перевірки API та документовані зміни. Рецензування колегами через відкритий робочий процес полегшує залучення іншої моделі для перевірки ризиків.