Как перенести сайт Magento 2 с локального хоста на сервер?

Процесс переноса сайта на Magento 2 с одного локального хоста на другой не занимает много времени. Тем не менее, он имеет ряд мельчайших деталей и особенностей, которые следует принять во внимание, прежде чем погрузиться в процесс.

В этом сообщении блога мы сделаем перенос сайта Magento 2 с локального хоста на сервер таким же простым, как Lego. Давайте иметь представление.

Основные шаги

Для начала рассмотрим основные этапы переноса:

1. Проверка работоспособности сайта Magento 2 на текущем хосте (A);
2. Подготовка удаленного хоста (B);
3. Проверка удаленного хоста (B);
4. Подготовка данных к передаче; 4.1. Дамп файла; 4.2. Дамп базы данных;
5. Передача данных;
6. Распаковка данных; 6.1. Распаковка файлов; 6.2. Импорт баз данных;
7. Коррекция данных доступа на удаленном хосте (B);
8. Исправление прав доступа к файлам и каталогам;
9. Стандартные процедуры перед запуском Magento;
10. Проверка производительности Magento на удаленном хосте (B);
11. Решение частых вопросов.

Просто как Лего: пошаговые инструкции

1. Проверка работоспособности сайта Magento 2 на текущем хосте

Тут все просто: запускай и проверяй. Обычно для таких целей должен быть создан заказ (полный цикл). Затем проверьте:

• поиск;
• страницы продукта,
• категории,
• аккаунт клиента.

Это важный этап, так как он позволяет вам не задаваться вопросами о том, когда именно что-то перестало работать после переезда на новый хост. Кроме того, это избавит вас от необходимости разбираться с основными проблемами хоста, которые можно решить заранее (А).

Я призываю вас НЕ передавать наполовину работающую Magento без крайней необходимости. Гораздо проще решить все вопросы на текущем хосте (А) до начала процесса переноса. Доказано и проверено ― это сэкономит вам время и нервы.

2. Подготовка удаленного хоста (B)

Сервер, на котором развернута копия Magento, должен соответствовать минимальным требованиям для вашей версии Magento.

Изучите официальную документацию, чтобы узнать больше об этих требованиях: https://devdocs.magento.com/guides/v2.3/install-gde/system-requirements-tech.html.

Среда должна быть настроена, прежде чем переходить к следующим шагам процесса переноса (веб-сервер с виртуальным хостом, PHP, база данных).

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

Рекомендую обратить особое внимание на наличие необходимых расширений PHP.

Если у вас есть какие-либо вопросы по какому-либо шагу этого руководства, пожалуйста, оставьте комментарий. Я сделаю все возможное, чтобы ответить на все из них.

3. Проверка удаленного хоста (B)

Перед переносом Magento убедитесь, что он работает на новом хосте, а сам хост работает исправно. Сначала проверяем, отвечает ли веб-сервер по указанному адресу (мы предполагаем, что хост уже настроен).

В моем примере я использую стандартный путь, доступный сразу после установки Apache2 на сервер Linux:

> /var/www/html

 sudo -u apache echo "<?php phpinfo();?>" > /var/www/html/index.php

*Здесь и далее при необходимости команды будут выполняться от соответствующих пользователей. Если команда запускается без имени пользователя, то следует понимать выполнение команды как от текущего пользователя и наличие каких-либо соответствующих разрешений.

Если после выполнения этой команды ошибок не появилось, значит все прошло успешно и ваш файл `index.php` должен быть доступен по следующему адресу: {host}/index.php. Результат в вашем браузере должен выглядеть примерно так (хотя многое еще зависит от вашей версии PHP):

Если что-то пошло не так и вы не видите информацию о своей версии PHP, обратитесь к соответствующему руководству по настройке нужного вам веб-сервера.

Также рекомендую заранее изучить логи — это сэкономит кучу вашего времени.

Затем проверьте, что служба базы данных запущена и работает правильно:

 mysql -u root -p

В результате вы должны успешно подключиться к MySQL. Используйте команду `exit` для выхода.

* Введите логин и пароль, которые вы использовали при настройке MySQL.

Кроме того, после успешного подключения к MySQL вам необходимо проверить существующие базы данных.

 SHOW databases;

Имена баз данных, которые вы планируете перенести, не должны совпадать с уже существующими на новом сервере. В случае наличия похожих баз данных эту проблему следует решить вручную, например, удалив существующую, но не используемую базу данных, или переименовав базу данных Magento, которую вы собираетесь перенести. Обратите внимание, что вы должны обязательно ввести измененное имя в конфигурационный файл среды Magento `app/etc/env.php`.

Ваш результат должен выглядеть примерно следующим образом:

Также вам нужно будет проверить, запущена ли сама служба и слушает ли она стандартный порт с помощью утилиты netstat :

 netstat -vulntp | grep -i mysql

Ваш результат будет выглядеть примерно следующим образом:

 > tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 3366/mysqld

4. Подготовка данных к передаче

4.1. Дамп файла

Перед созданием файлового дампа настоятельно рекомендую убрать из директории Magento все ненужные файлы, если таковые имеются, т.е. старые дампы, кеш, логи и т.д.

 rm -rf var/cache/* var/page_cache/* var/generation/* var/composer_home/cache/* var/log/* pub/static/*

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

* НЕ удаляйте принудительно `.htaccess` и другие скрытые файлы, если вы используете веб-сервер Apache2 (команда `rf` не удаляет их по умолчанию). Эти файлы необходимы для корректной работы Magento.

Теперь перейдите в каталог, где находится наш Magento на локальном сервере (A). В моем примере это:

 > /Users/sergei/PhpstormProjects

Каталог с Magento называется aws-botapi .

Создадим архив для его дальнейшей передачи на удаленный хост (Б):

 tar -zcf aws-botapi.tar.gz aws-botapi

Вы должны проверить, что архив был создан:

 ls -la aws-botapi.tar.gz

4.2. Дамп баз данных

Если на вашем Magento-сайте есть несколько отдельных баз данных, которые размещены локально, то их необходимо перенести все. В моем примере используются две базы данных. Вы можете найти их в настройках среды Magento `app/etc/env.php` в разделе `db => connection => `.

Теперь сделайте дамп всех баз данных:

 mysqldump -u root -p db1 | gzip > ./db1.sql.gz mysqldump -u root -p db2 | gzip > ./db2.sql.gz

* Используйте такую ​​информацию, как имя пользователя базы данных и имя базы данных.

5. Передача данных

Перенесите дамп файлов Magento с помощью утилиты `scp` (копирование по ssh) или любым другим удобным для вас способом (например, копирование по `ftp`):

 scp -i ~/.ssh/myprivatekey.pem aws-botapi.tar.gz [email protected]:/home/ec2-user

Где,

а) -i ~/.ssh/myprivatekey.pem — путь к приватному ключу для подключения (игнорируйте, если используете только пароль);

б) ec2-user — имя пользователя для подключения;

в) 52.12.187.98 — адрес сервера;

г) /home/ec2-user — абсолютный путь на сервере, куда мы копируем файлы.

*Если вы используете порт, отличный от стандартного, не забудьте указать его отдельным параметром (например, `-P 6000` для порта 6000).

После завершения копирования вы увидите строку вида:

 > aws-botapi.tar.gz 100% 312MB 4.3MB/s 01:11

Повторите те же действия для дампа файлов:

 scp -i ~/.ssh/myprivatekey.pem db1.sql.gz [email protected]:/home/ec2-user scp -i ~/.ssh/myprivatekey.pem db2.sql.gz [email protected]:/home/ec2-user

6. Распаковка данных

6.1. Распаковка файлов

На сервере (B) перейдем в каталог, в который мы скопировали архивы. Распаковываем файлы Magento в каталог локального хоста:

 > tar -zxf aws-botapi.tar.gz -C /var/www/html/

Обязательно проверьте правильность распаковки файлов:

 ls -la /var/www/html

Если файлы Magento были распакованы в подкаталог, перенесите их с помощью команд `mv` или `cp`.

6.2. Импорт баз данных

Подключиться к MySQL на сервере (B):

 mysql -u root -p

Теперь давайте создадим новую базу данных:

 CREATE DATABASE IF NOT EXISTS db1 CHARACTER SET utf8 COLLATE utf8_general_ci;

*Результат должен выглядеть примерно так:

 > Query OK, 1 row affected (0.01 sec)

Сделайте аналогичные действия, если у вас есть другие базы данных.

Затем импортируйте базы данных из дампа:

 gunzip < /home/ec2-user/db1.sql.gz | mysql -u root -p db1 gunzip < /home/ec2-user/db2.sql.gz | mysql -u root -p db2

Подключиться к MySQL:

 mysql -u root -p

и проверьте наличие всех баз данных:

 SHOW databases;

Должен получиться список всех баз, включая нашу:

 +--------------------+ | Database | +--------------------+ | db1 | | db2 | | information_schema | | mysql | | performance_schema | +--------------------+ 5 rows in set (0.00 sec)

Выберите базу данных, которую мы только что импортировали:

 USE db1;

и проверяем наличие таблиц:

 SHOW tables;

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

7. Исправление доступа к данным на удаленном хосте (B)

Основные данные, которые должны быть изменены в Magento после переноса, это 1) базовые URL и 2) ключи доступа к MySQL:

Изменение основных URL-адресов

Вам нужно будет изменить все старые пути в таблице `core_config_data`. Для начала давайте локализуем эти поля с помощью запроса «значение», включающего старый адрес. Предположим, что старый адрес сайта был «1001101010.com», тогда команда поиска будет выглядеть следующим образом:

 SELECT * FROM core_config_data WHERE `value` LIKE '%1001101010.com%' \G

*`\G` в конце запроса вместо `;` улучшит читаемость записей.

** Не забудьте использовать table_prefix перед именами таблиц, если он был установлен.

Результат будет выглядеть примерно так:

 mysql> SELECT * FROM core_config_data WHERE `value` LIKE '%1001101010.com%' \G *************************** 1. row *************************** config_id: 2 scope: default scope_id: 0 path: web/unsecure/base_url value: http://1001101010.com/

 *************************** 12. row *************************** config_id: 2401 scope: default scope_id: 0 path: web/secure/base_url value: https://1001101010.com/ *************************** 13. row *************************** config_id: 2402 scope: default scope_id: 0 path: web/secure/base_link_url value: https://1001101010.com/ 13 rows in set (0.00 sec)

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

 UPDATE `core_config_data` SET `value` = replace(value, '1001101010.com', 'mynewdomain.com') WHERE `value` LIKE '%1001101010.com%';

Он заменит все вхождения строк «1001101010.com» в поле «значение» на строку «mynewdomain.com».

Результат должен быть примерно таким (количество строк должно быть равным):

 > Query OK, 13 rows affected (0.00 sec) > Rows matched: 13 Changed: 13 Warnings: 0

Следующий запрос:

 SELECT * FROM core_config_data WHERE `value` LIKE '%1001101010.com%' \G

Теперь пришло время перейти к редактированию файла окружения `app/etc/env.php` (из корня Magento; в примере это было `/var/www/html/`).

Откроем его в текстовом редакторе (я использую Nano , хотя это, конечно, вопрос личных предпочтений).

 nano /var/www/html/app/etc/env.php

Затем отредактируйте данные в `'db' => 'connection'`, указав точные данные с нового сервера в полях 'username' и 'password'.

* ВАЖНО! Если ваша база данных находится на удаленном сервере, менять данные не нужно. Единственное, что вам нужно сделать, это убедиться, что с текущего сервера есть доступ к этой удаленной базе данных. (Например, что он был добавлен в белый список брандмауэра на сервере базы данных).

Используйте значение «localhost» в поле «host», чтобы понять, является ли подключение локальным или нет.

Далее сохраните файл.

8. Исправление прав доступа к файлам и каталогам

Чтобы точно настроить права доступа, вам нужно знать, от какого пользователя и с какой группой работает ваш веб-сервер.

Чаще всего это либо «apache» для CentOS, либо «www-data» в Ubuntu. Как правило, имя пользователя совпадает с именем группы. Однако на разных серверах это может отличаться.

Следующая команда поможет вам разобраться:

 ps aux | egrep '(apache|httpd)'

В результате в первом столбце вы увидите имя пользователя (название группы, скорее всего, будет таким же. Однако, если вы не уверены, используйте команду `groups apache`, где `apache` — имя пользователя, чтобы проверьте это).

Первым делом после этого нам нужно будет передать все файлы и каталоги внутри Magento пользователю веб-сервера (в примере это `apache`. Для пользователя `www-data` просто замените `apache:apache` на ` www-data:www-data` и аналогично для других):

 sudo chown -R apache:apache /var/www/html

Далее проверяем, применились ли изменения или нет:

 ls -la /var/www/html

Все файлы и каталоги (кроме родительского, отмеченного как `..`, должны иметь пользователя и группу `apache` (если `www-data` является пользователем веб-сервера в вашей системе, то он должен быть помечен как владелец):

Теперь необходимо точно настроить права доступа к файлам и каталогам Magento. Согласно документации, настоятельно рекомендуется следующая установка:

*Все команды должны запускаться от root Magento!, последовательно 1 после 1. В примере корневой каталог Magento на сервере — `/var/www/html`.

Используйте команду `pwd`, чтобы проверить текущее местоположение.

 find var generated vendor pub/static pub/media app/etc -type f -exec chmod u+w {} + find var generated vendor pub/static pub/media app/etc -type d -exec chmod u+w {} + chmod u+x bin/magento

* Если текущему пользователю не хватает прав для запуска этих команд, используйте команду `root` (команда `sudo`, например `sudo find…`)

9. Стандартные процедуры перед запуском Magento

Пришло время проверить, запускается ли Magento из командной строки. Для начала давайте проверим стандартный вывод команд, к которым у вас есть доступ:

*Теперь, после настройки разрешений, любой доступ к Magento будет осуществляться от того же пользователя веб-сервера, который генерирует файлы, файлы кеша, статику и т. д. Если вы проигнорируете это, Magento может перестать работать, и вы будете вынуждены восстановить разрешения еще раз (предыдущий шаг в этих рекомендациях).

**Для корректной работы вам необходимо найти правильный интерпретатор php на вашем сервере. Обычно псевдоним `php` относится к актуальной версии. Однако вам часто потребуется указать полный путь, например, `/usr/bin/php72`.

***Здесь и далее все команды Magento будут выполняться из корневого каталога Magento на сервере (B).

 sudo -u apache php bin/magento list

Это сделает список с командами доступными в командной строке:

Если все прошло успешно, можно переходить к дальнейшим командам:

*Если перед переносом вы не очистили каталоги с кешем и сгенерированными файлами, сейчас самое время сделать это с помощью следующей команды:

 sudo rm -rf var/cache/* var/page_cache/* var/generation/*

 sudo -u apache php bin/magento setup:upgrade

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

Выполните компиляцию, чтобы сгенерировать необходимые файлы Magento:

 sudo -u apache php bin/magento setup:di:compile

* На этом этапе очень важно обнаружить все возникшие ошибки. В противном случае Magento будет работать неправильно. Если ошибок не обнаружено, то все просто идеально. ?

Затем сгенерируйте статические данные (если рабочий режим включен. Чтобы проверить текущий режим, используйте следующую команду:

 sudo -u apache php bin/magento deploy:mode:show

 sudo -u apache php bin/magento setup:static-content:deploy

*Чтобы сгенерировать статистику для конкретной локали, укажите ее в качестве параметра после команды. Например, для русской локали будет использоваться sudo -u apache php bin/magento setup:static-content:deploy ru_RU.

Поздравляем! Вы успешно перенесли свой магазин Magento2 с локального хоста для правильной работы на новом сервере. Теперь откройте его в браузере, введя новый адрес!

10. Устранение неполадок: частые проблемы

Выпуск №1

Проблема:

Если при копировании архива вы получаете сообщение вида:

 scp: /var/www/html/aws-botapi.tar.gz: Permission denied

Затем вы должны проверить, куда вы скопировали архив на сервере в первую очередь. Весьма вероятно, что пользователю, который намеревается подключиться, не хватает прав для создания записи в этом каталоге (`/var/www/html` в примере).

Решение:

Это можно решить, изменив каталог, в который вы пытаетесь выполнить копирование, при запуске команды `scp` или подключении к серверу и настроив права доступа к этому каталогу для текущего пользователя:

`sudo chown -R ec2-user /var/www/html` (сделать пользователя владельцем каталога `/var/www/html` и всех включенных файлов и каталогов), или

`sudo chmod -R o+w /var/www/html` (разрешает всем (`другим`) делать записи (`w-rite`) в каталоге `/var/www/html`).

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

Выпуск №2

Проблема:

Если при импорте баз данных возникает следующая ошибка `ОШИБКА 1049 (42000): Неизвестная база данных 'db1'` (где `db1` — имя базы данных), то ваша база данных не создана.

Решение:

Попробуйте получить доступ к mysql и заново создать эту базу данных.

Выпуск №3

Проблема:

Если при смене владельца файлов и каталогов вы видите команду `chown: invalid user: …`, то, скорее всего, вы неправильно указали пользователя веб-сервера на своем сервере.

Решение:

Обратитесь к соответствующим руководствам по настройке сервера в вашей системе или используйте утилиту `ps aux`, чтобы определить нужного пользователя.

Выпуск №4

Проблема:

Если при запуске Magento на новом сервере возникают ошибки PHP (как правило, это означает отсутствие некоторых расширений PHP)…

Решение:

Это можно решить установкой отсутствующих расширений.

а) `Для использования Monolog's NormalizerFormatter требуется расширение json для PHP` ―

расширение *php-json* отсутствует;

б) `Неустранимая ошибка PHP: необработанная ошибка: класс 'DOMDocument' не найден в…` ―

расширение *php-xml* отсутствует;

c) `Неустранимая ошибка PHP: класс 'IntlDateFormatter' не найден в…` ―

Расширение *php-intl* отсутствует.

Выпуск №5

Проблема:

Если расширения PHP отсутствуют при выполнении команды `composer update`, вы увидите следующие ошибки:

Например,

`phpunit/phpunit 6.5.14 требует ext-mbstring * -> запрошенная mbstring расширения PHP отсутствует в вашей системе.`

Решение:

Чтобы справиться с такими ошибками, вам нужно просто установить расширения PHP, на которые ссылается композитор. Например, `yum install php-mbstring`.

Полный список необходимых расширений для вашей версии Magento 2 можно найти в официальной документации.

Нижняя линия

У вас все настроено! В этой статье я сделал все возможное, чтобы представить простые шаги по переносу вашего сайта Magento 2 с локального хоста на сервер.

Если у вас все еще есть вопросы или вы хотите поделиться своим мнением, не стесняйтесь использовать раздел комментариев ниже. Постараюсь ответить на все вопросы и пожелания!