Как перенести сайт с хостинга на VPS. Кейс toy69.ru

Автор: Дмитрий Гузеев, веб-разработчик Ingate.

Перенос был необходим, так как на сайте настроен поиск с помощью системы полнотекстового поиска Sphinx, в то время как на хостинге нет возможности установить необходимые библиотеки для его работы по той причине, что это повлияло бы на всех пользователей хостинга.

Подготовка нового сервера

В качестве сервера был выбран Ubuntu 22.04, а также подключен ISPManager 6. За основу можно выбрать любую Linux-систему, например Debian или Cent OS.

Для подготовки сервера к переносу сайта были выполнены следующие шаги:

1. Был развёрнут MySQL версии 5.3, схожей с прошлым VDS в Docker-контейнере. В качестве сервера для БД использовалась MariaDB версии 10.3.38. На VPS Reg.ru желательно заменить стандартный сервер на сервер в Docker по той причине, что стандартный сервер MySQL невозможно восстановить после любых правок конфигурации сервера БД, например, изменения кодировки — см. Невозможность обновления конфигурации.
2. Из-за некорректной кодировки таблиц (см. — Некорректная кодировка) БД с хостинга была выгружена в виде строк-запросов, так как в таком виде таблицы не имеют установленной кодировки. Для того чтобы импортировать такой объём запросов, необходимо временно на период импорта увеличить тайм-аут Nginx. Импорт в виде запросов может помочь, если таблицы имеют разные или несовпадающие с сервером кодировки, тем самым импортируемый текст будет в формате UTF-8.
3. Выгружены почтовые ящики и вся почта со старого сервера и с хостинга в виде текстовых файлов. Как правило, почта располагается по пути /var/www/data/email/<mailbox_name>. На новом сервере созданы идентичные почтовые ящики, после чего содержимое архивов почты помещено внутрь них.
4. Установлены необходимые библиотеки и зависимости. По умолчанию на сервере отсутствовало то, что необходимо для корректной работы OpenCart и модулей сайта (напр., модуль оптимизации изображений). На сервер были установлены следующие библиотеки:
   <aside> ✅ Библиотеки для корректного соединения Sphinx с базой данных: libmysqlclient-dev, libpq-dev, unixodbc-dev, libmariadb-client-lgpl-dev-compat Библиотека для работы с cURL: php-curl - необходима для корректной работы панели администратора OpenCart Библиотека для работы с изображениями: php-gd
   </aside>
   
   

Процесс переноса

Распаковка сайта и редактирование конфигурации

В первую очередь после подготовки нового сервера были выгружены 2 последних backup’a сайта, а также 2 базы данных: с хостинга и со старого сервера. Это пожелание клиента.

Далее последний backup был залит по SFTP и распакован на сервере через WinSCP.

После распаковки необходимо было исправить файлы конфигурации, которые располагаются в корне и в папке admin: config.php

В файле конфигурации был небольшой костыль, который использовался для обхода ошибки, связанной с использованием XMLHttpRequest. Так как xhr-запросы по умолчанию используют HTTP-протокол, это выливается в ошибку “Mixed content”, в данном случае из-за которой не работали фильтры, пагинация, навигация в каталоге.

define('HTTP_SERVER', '<https://toy69.ru/>');

define('HTTPS_SERVER', '<https://toy69.ru/>');

Далее нужно было изменить данные для подключения к базе данных в тех же конфигурационных файлах:

// DB

define('DB_DRIVER',   'mysqli');

define('DB_HOSTNAME', '127.0.0.1:3310');

define('DB_USERNAME', 'your-user');

define('DB_PASSWORD', 'pAssw0rD');

define('DB_DATABASE', 'your-db-name');

define('DB_PORT',     '3310');

define('DB_PREFIX',   'oc_');

Работа с базой данных

После этого экспортированные запросы к базе данных с хостинга необходимо было импортировать через панель phpMyAdmin, восстановлением которой несколько дней занимался хостинг-провайдер. После импорта правился режим сопоставления некоторых таблиц, режим которых отличался от остальных — см. Некорректная кодировка.

Настройка и перенос почты

Настройки почтовых ящиков остались идентичные настройкам на хостинге.

Клиенту было важно не потерять старую почту с сервера на FirstVDS. Было решено выгрузить почту в формате архива и распаковать файлы писем в те же директории почтовых ящиков по пути /var/www/data/email/. После переноса файлов и списка писем в список ID писем почта со старого сервера появилась в панели Roundcube. Однако с письмами с хостинга возникли проблемы — Структура писем

Настройка сайта и восстановление модулей

Был выполнен ряд работ по восстановлению модулей, лицензионных ключей, обновлению кэша. С какими проблемами мы столкнулись на данном этапе, тут — Проблемы модулей

Настройка, доработка поиска на Sphinx

Был настроен файл конфигурации sphinx.conf, дописана выборка из базы данных, после чего настроен “маппинг” запросов в формате “искомое слово → реальный запрос”.

После подключения, обновления и настройки задача реиндексации поиска была добавлена в CRON.

Узнать о сложностях можно тут: Сложности настройки Sphinx 

Сложности при переносе

Невозможность обновления конфигурации

При свежей установке сервера на облачном хостинге Reg.ru одной из первых проблем “из коробки” являлась проблема с сервером MySQL. При попытке любых изменений параметров сервера (конкретно – кодировки) сервер отказывался перезагружаться. Поддержка Reg.ru не смогла найти проблему и решить её. Я решил данную задачу, запустив БД-сервер в Docker-контейнере, внутри которого была установлена MariaDB с типом MySQL. Данный сервер БД послужил отличной быстрой альтернативой стандартному серверу.

phpMyAdmin

Второй проблемой при свежей установке сервера на Reg.ru была проблема с phpMyAdmin: страница интерфейса вместо редиректа в панель управления базой данных отвечала таймаутом либо массой ошибок. Техподдержка Reg.ru в течение нескольких дней исправляла конфигурацию phpMyAdmin на сервере для устранения некорректных редиректов из ISPManager. К сожалению, во время работ не удалось использовать Adminer из-за невозможности импорта массива запросов.

Некорректная кодировка

При попытке импорта я потратил большую часть времени на то, чтобы понять, в чём проблема при импорте дампа базы данных. Экспортировать базу данных пробовал через ISPManager, Adminer, phpMyAdmin, SQL-командами – результаты постоянно отличались, но всегда имели плохой результат: либо на сайте все русские символы имели вид вопросительных знаков, либо в базе данных был ровно тот же эффект, когда на сайте всё было в порядке. Из чего я сделал вывод, что проблема базы данных – неправильная кодировка/режим сопоставления при переносе сайта на хостинг прошлым разработчиком.

Как оказалось впоследствии, база данных имела три кодировки сравнения (сопоставления) таблиц: utf8mb4_unicode_ci, utf8_general_ci, cp1251_general_ci, а сама база данных - utf8mb4_general_ci. При этом, сервер базы данных имел кодировку latin1_swedish_ci. Из-за совокупности этих нюансов невозможно было импортировать БД ни в каком виде: любые данные после импорта были “сломаны” либо на стороне БД, либо на стороне сайта.

Решением оказался экспорт в виде строк-запросов, так как запросы не имеют кодировки. Такой экспорт можно без труда произвести в phpMyAdmin в расширенном режиме.

Проблемы модулей

Первое, что было “сломано” после распаковки сайта и БД – панель администратора. Решилось путём установки библиотеки php-curl.

Далее проблемы появились на странице оформления заказа. При переходе на страницу выполнялось сразу два последовательных редиректа 301 и 302 на страницу /checkout2. Отследив редиректы, было выяснено, что они выполняются в кэше модуля Simple 4.9.7. Решение оказалось до неприличия простым. Так как мы выполняли работы по переносу на тестовом сервере, лицензионный ключ на модуль Simple 4.9.7 перестал действовать, потому что был приобретён для конкретного домена toy69.ru. После заказа ключа для тестового сервера проблема решилась.

Также идентичные проблемы с лицензионными ключами модулей наблюдались в модулях определения местоположения (подставлялся город по умолчанию при оформлении заказа) и модуле RetailCRM (отсутствие синхронизации, невозможность выполнить заказ).

После настройки модулей необходимо было сделать сброс модификаторов для очистки кэша сайта.

Структура писем 

Почта со старого сервера успешно была перенесена, в то время как с хостинга не отображалась в Roundcube. Виной тому – отличающаяся структура названий файлов и идентификаторов в списке писем. Перенос почты с хостинга был бы возможен только при условии ручной правки названия и ID каждого письма.

Сложности настройки Sphinx

Изначально на старом сервере FirstVDS Sphinx был настроен на “маппинг” поисковых запросов – список морфологизмов для замены “упрощённых” поисковых запросов на валидные. Список лежал в корне сайта в формате текстового документа.

Как оказалось, встроенная в Ubuntu версия Sphinx (sphinxsearch 2.2.11) не поддерживает морфологизмы, было решено заменить её на последнюю на момент переноса версию Sphinx 3.5.1.