Информация о переносе Битрикс. Предполагается что нужно перенести тестовый сайт с сервера на локальную виртуальную машину для разработки. Возможна такая сложность, что если база очень большая то стандартный бэкап Битрикс зависнет. Тогда нужно другим способом переносить.
Допустим есть удалённый сервер, который через ssh доступен по адресу abc.def.ghi (адрес вымышленный), или по ip 192.168.167.166 (вымышленный ip, причём из локального диапазона, на всякий случай), через порт 1234, от имени пользователя bitrix. Тогда удобно в файл ~/.ssh/config внести строки:
Host server
Hostname abc.def.ghi
Port 1234
User bitrix
Если доступ известен только по ip, в конфиге вместо abc.def.ghi нужно будет напечатать 192.168.167.166 (нужный ip). Если файл ~/.ssh/config отсутствует, его можно создать.
Это очень удобная настройка, после которой можно логиниться на сервер командой ssh server и передавать файлы с сервера на локальный компьютер через удобный синтаксис rsync -a server:log.txt log.txt. Если же конфиг не настроен, то нужно будет в командной строке указывать целый ряд параметров, и в случае rsync придётся использовать крайне неудобный синтаксис. Поэтому лучше настроить кофиг.
Возможно в базе есть какие-то слишком большие таблицы, информация из которых не понадобится при разработке. Размер таблиц можно проверить запросом:
SELECT
table_schema as `Database`,
table_name AS `Table`,
round(((data_length + index_length) / 1024 / 1024), 2) `Size in MB`
FROM information_schema.TABLES
ORDER BY (data_length + index_length) DESC;
Запрос можно выполнить например в административно разделе сайта, в Настройки->Инструменты->SQL запрос.
Потом нужно залогиниться на сервер, на котором размещён сайт, ssh server. Выполнить дамп структуры базы:
mysqldump -u bitrix0 -p --single-transaction --no-data --routines sitemanager > dump.sql
При этом будет запрошен пароль. Пароль можно узнать в файле bitrix/.settings.php, ближе к завершению файла.
Если ранее выяснилось, например, что таблица b_mail_message занимает слишком много места, и её содержимое не важно для разработки, то далее можно выполняя дамп содержимого таблиц исключить b_mail_message:
mysqldump -u bitrix0 -p sitemanager --no-create-info --skip-triggers --ignore-table=sitemanager.b_mail_message >> dump.sql
Если нужно исключить вторую таблицу, например b_search_content_stem, то нужно повторить ключ --ignore-table ещё раз, то есть получится mysqldump -u bitrix0 -p sitemanager --no-create-info --skip-triggers --ignore-table=sitemanager.b_mail_message --ignore-table=sitemanager.b_search_content_stem >> dump.sql.
Дамп может занять продолжительное время, зависит от размера базы. Не рекомендуется использовать ключи для вывода информации в терминал, это только замедлит процесс. Лучше заранее посмотреть размер базы запросом:
SELECT
round(SUM((data_length + index_length) / 1024 / 1024), 2) `Size in MB`
FROM information_schema.TABLES where table_name NOT IN ('b_mail_message', 'b_search_content_stem');
если нужно исключить таблицы b_mail_message и b_search_content_stem, после чего в другой вкладке терминала зайти на сервер и время от времени проверять размер дампа командой ls -lh, чтобы примерно ориентироваться как идёт процесс дампа.
Во время дампа по умолчанию команда mysqldump блокирует операции с базой данных, поэтому сайт работать не будет. Конечно можно использовать ключ который отменит блокировку, но тогда во время дампа база будет меняться, и данные будут не консистентны, во время использования сайта с базой из этого дампа будут возникать дополнительные неожиданные ошибки. Если выполняется дамп тестового сервера, то временная недоступность сайта будет не критична.
Виртуальную машину для Битрикс можно создать согласно инструкции из репозитория https://github.com/abicorios/bitrix_vagrant, но потом не устанавливать сайт через веб-интерфейс, и пропустить оставшуюся часть инструкции. При повторном клонировании для создания другой виртуальной машины, нужно в Vagrantfile поменять ip 192.168.33.10 на немного другой (немного, без использования крайних значений, как описано в инструкции к репозиторию), чтобы можно было одновременно пользоваться несколькими виртуальными машинами. Также может быть полезно изменение размера оперативной памяти в строке vb.memory = "1024", изменение размера жесткого диска в строке config.disksize.size = "80GB". Вообще можно редактировать Vagrantfile и скрипты в нём если есть понимание, но лучше предварительно экспериментировать на минимальных виртуальных машинах которые быстро разворачиваются, чтобы оперативно провести большое количество экспериментов. Команда vagrant init centos/7 создаст в текущей директории самую простую конфигурацию Vagrantfile виртуальной машины Centos 7, она разворачивается намного быстрее чем виртуальная машина для Битрикс. Каждый Vagrantfile нужно создавать в отдельной пустой директории. То есть, если нужно отредактировать Vagrantfile для Битрикс, то лучше убедиться что аналогичное изменение не выводит из строя простую виртуальную машину, чтобы потом зря долго не ждать. В виртуальной машине для Битрикс больше всего времени занимает автоматическая установка VirtualBox Guest Additions через плагин vagrant-vbguest, и выполнение скрипта bitrix-env.sh, с медленным интернетом это ещё дольше. Для того чтобы не работал плагин vagrant-vbguest нужно убрать его из строки config.vagrant.plugins = ["vagrant-reload", "vagrant-vbguest", "vagrant-disksize"], но тогда не будет работать общая папка VirtualBox. Также не рекомендуется устанавливать плаги vagrant-vbguest глобально, иначе замедлится разворачивание каждой виртуальной машины в системе, даже минимальная экспериментальная машина будет устанавливаться дольше. Если плагин прописан в Vagrantfile то он устанавливается локально для отдельной виртуальной машины, для которой необходим.
После клонирования репозитория для создания виртуальной машины будет легко найти папку c7 с конфигом Vagrantfile, и папку www. В терминале находясь в папке c7 нужно выполнять команды адресованные одной виртуальной машине, конфиг которой находится в этой папке. Папка www будет общая для основной системы локального компьютера и для виртуальной машины. Такое решение используется, потому что содержимое папки c7 автоматически копируется на виртуальную машину, но однонаправленно и однократно при включении виртуальной машины, если бы папка www находилась внутри c7 то настройки общей папки работали бы не корректно. Конечно, автоматическое копирование из с7 можно отключить, но эта возможность иногда тоже очень удобна.
При создании виртуальной машины автоматически создана база данных для Битрикс, а также пользователь с паролем. Информацию о доступе к базе лучше сохранить таким способом:
cd c7
vagrant ssh
sudo -i
cd /home/bitrix
rsync -az www/ www.bac2/
exit
exit
Находясь в папке c7 можно в эту же папку загружать дамп базы командой:
rsync -az --info=progress2 server:dump.sql dump.sql
Ключ --info=progress2 выводит удобный прогресс-бар. Можно без него, будет даже быстрее. Тогда просто размер локального дампа можно проверить чтобы сориентироваться на какой стадии процесс.
Если файл дампа не находится в домашнем каталоги пользователя сервера, то вместо dump.sql лучше указать полный путь, например rsync -az server:/home/bitrix/dumps/dump.sql dump.sql. Можно указать относительный путь, но так можно запутаться. Для определения полного пути будет полезно на сервере выполнить команду pwd которая напечатает полный путь нынешнего каталога. Ключ -z командый rsync сжимает данные при передаче, поэтому не обязательно их архивировать и распаковывать. Ключ -a по сохраняет права и по возможности владельца (если владелец существует в начальной и конечной точке передачи, то он сохранится). Ключ -a не важен в данном случае, но он полезен почти всегда, лучше и печатать его всегда чтобы не забыть когда нужно. Вместо комбинации ключей -a -z сокращенно можно писать -az. Вообще rsync хорошо работает при нестабильном соединении, продолжает загрузку дальше при перебоях сети.
Содержимое папки c7 локального компьютера в которой находится Vagranfile во время включения виртуальной машины однократно однонаправленно передаётся в папку /vagrant виртуальной машины. Поэтому, если в нынешней папке c7 есть дамп базы, достаточно перезагрузить виртуальную машину:
vagrant reload
В дальнейшем, когда файл окажется на виртуальной машине, дамп лучше переместить из c7, или удалить, чтобы он не перемещался повторно. Хотя перемещение происходит автоматической комадой rsync которая не передаёт лишние данные, но всё равно потратится время на некоторую дополнительную проверку соответствия данных.
Заходим на виртуальную машину:
vagrant ssh
Теперь мы залогинены как пользователь vagrant, без ввода пароля логинимся дальше как root:
sudo -i
Узнаём пароль базы пользователя bitrix0 базы данных sitemanager:
tail /home/bitrix/www.bac2/bitrix/.settings.php
Переходим в папку с дампом:
cd /vagrant
Импортируем базу из дампа:
mysql -u bitrix0 -p sitemanager < dump.sql
Импортирование может занять много времени, лучше параллельно делать что-то другое. Здесь, опять же, лучше не использовать различные ключи вывода дополнительной информации, иначе терминал будет перегружен большим потоком данных и может совсем зависнуть. Лучше открыть другую вкладку терминала и вручную следить за процессом при необходимости. Другая вкладка тоже откроется в папке c7, из неё можно залогиниться на виртуальную машину vagrant ssh и повысить права sudo -i. Команда top запускает консольный менеджер задач, можно видеть что mysqld нагружает процессор, значит импорт продолжается. Клавиша q позволяет выйти из диспетчера задач. Стадию импорта можно определить перейдя в папку /var/lib/mysql/sitemanager. Командой ls -htl | less можно увидеть список таблиц базы отсортированный по дате последнего изменения, с указанием размера. less это консольная утилита для постраничной навигации, клавиша f повзоляет перейти на страницу вперёд, клавиша b возвращает на страницу назад, g открывает первую страницу, G открывает последнюю страницу, h открывает справку, q закрывает справку и при повторном нажати закрывает less. Собственно сама справка тоже открывается через less, там те же команды работают. Комбинация ls -htl | less отобразит информацию верную на момент запуска, то есть автоматическое обновление не происходит, чтобы увидеть изменения нужно выйти через q и снова выполнить команду ls -htl | less. Для отображения введённой ранее команды можно нажать стрелку вверх на клавиатуре. Также может быть полезна клавиша табуляции для дополнения команд и путей (иногда нужно нажать два раза подряд, если нет однозначного варианта дополнения). Бывает удобно открыть историю команд history | less. Когда импорт базы завершится, в первой вкладке терминала отобразится строка приглашения ввода новых команд. Если же импорт не завершен, можно перейти во вторую вкладку и проверить что происходит на виртуальной машине. Сам процесс может занять и пол дня, или больше. Команда du -sh /var/lib/mysql/sitemanager также поможет определить суммарный размер всех таблиц базы, чтобы оценить стадию процесс импорта. При импорте данных из файла dump.sql в базу /var/lib/mysql/sitemanager размер может вырасти примерно в полтора-два раза за счет создания дополнительных таблиц индекса. Эта информация поможет ориентироваться.
Предполагается что есть репозиторий проекта на git. Для начала нужно очистить папку www от файлов по умолчанию. Эти файлы уже скопированы в www.bac2. Для удаления используйте команду:
rm -rf /home/bitrix/www/*
Обратите внимание, что эта команда удаляет данные. Хорошая практика - использовать полный путь, и ссылаться на поддиректории, чтобы не ошибиться при удалении. Если бы в папке были скрытые папки и файлы, то их можно было бы удалить отдельно комадой rm -rf /home/bitrix/www/.*, при это уведомление о том что не удалены папки . и .. не является ошибкой, . ссылается на нанешний каталог, а .. ссылается на родительский каталог, эти ссылки используются в файловой системе в качестве низкоуровневого инструмента навигации. Скрытые файлы нынешнего каталога можно увидеть командой ls -a, либо можно указать путь для просмотра ls -a /home/bitrix/www. По умолчанию скрытых файлов и папок в /home/bitrix/www нет. Если репозиторий сайта расположен по адресу https://gitlab.com/companyname/sites/abc.def.ghi (вымышленны адрес) то его можно склонировать:
cd /home/bitrix/www
sudo -u bitrix git clone https://gitlab.com/companyname/sites/abc.def.ghi.git .
Точка в конце команды значит что клонирование происходит в нынешний каталог и не создаётся лишний подкаталог с неподходящим в данной ситуации именем. Ведь главным каталогом сайта должен быть именно /home/bitrix/www. При клонировании нужно будет ввести логин и пароль от аккаунта. Могут быть ещё нюансы когда нужно ключ настроить, но чаще всего для клонирования это не нужно. Можно проверить сколько занимают файлы сайта командой du -sh /home/bitrix/www.
Выйдите из root виртуальной машины комадной exit. Выйдите из виртуальной машины командой exit. Можно на другой вкладке тоже выйти, хотя при перезагрузки автоматически произойдёт выход. Перезагрудите виртуальную машину vagrant reload. Во время перезагрузки файлы сайта скопируются в общую папку (там вообще условие используется, если файлы сайиа занимают больше 10 Мб то происходит копирование), это займёт какое-то время. Пори перезагрузке в консоль печатаются состояния прогрес-бара rsync, проценты могут показывать неверную информацию, лучше ориентироваться по переданному размеру и сравнивать с проверенным ранее размером сайта. Если копирование файлов не целесообразно в связи с очень большим размером сайта, и нужно вместо копирования применить перемещение, то можно до создания виртуальной машины отредактировать c7/Vagrantfile, и поменять rsync на необходимые команды, если есть в этом опыт или понимание. Либо можно позже залогиниться и удалить бэкап /home/bitrix/www.bac. Также может быть интересно отредактировать c7/Vagrantfile таким образом чтобы папка /home/bitrix/www изначально работала как общая, сейчас такая настройка не используется потому что при стандартной установке Битрикс через веб-интерфейс загружается слишком большой для общей папки VirtualBox архив, который не может распаковаться, пришлось использовать обходной путь с автоматическим копированием сайта в общую папку после установки. Если папка /home/bitrix/www занимает более 10 Мб, симлинк /home/bitrix/www не существует, каталог /home/bitrix/www.sync существует и каталог /home/bitrix/www.bac не существует то при перезагрузке или включении виртуальной машины в папке /home/bitrix содержимое каталога www копируется в www.sync, www переименовывается в www.bac, и создаётся мягкая ссылка (симлинк, или софтлинк) www указывающая на www.sync.
После того как сайт скопировался в общую папку, можно открыть её в удобной IDE. Это папка www рядом с c7 на основной системе. Тогда будет удобнее редактировать конфиги без консольных редакторов.
Проверьте файл .gitignore. Обычно он находится в основном каталоге сайта. Но, также могут находится вспомогательные файлы .gitignore в других каталогах. Можно либо в IDE использовать поиск по имени файла, либо в консоли перейти в главный каталог сайта и использовать команду:
find -name .gitignore
Обычно, чем больше глубина вложения каталогав на пути к файлу, тем менее он важен. Может есть на сайте какая-то библиотека разработанная с использованием git, и случайным образом сохранился .gitignore. Но файлы в основном каталоге, в bitrix, в bitrix/admin, и других с небольшим уровнем вложения, это важные файлы, нужно их прочитать, посмотреть какие важные файлы исключены. Там могут быть такие конфиги, без которых сайт не будет работать. Такие конфиги нужно перенести с сервера, и при необходимости отредактировать, в зависимости от того какие ошибки будут возникать при использовании локального сайта.
Если не сохранён пароль к базе данных, можно снова его посмотреть:
vagrant ssh
sudo -i
tail /home/bitrix/www.bac2/bitrix/.settings.php
После чего в IDE нобходимо установить этот пароль в конфигах bitrix/.settings.php и bitrix/php_interface/dbconn.php.
ip виртуальной машины можно посмотреть в Vagrantfile в строке похожей на config.vm.network "private_network", ip: "192.168.33.10". Там есть и другие ip, нужно понимать что строки начинающиеся на решетку # закоментированы, не испльзуются при исполнении конфига. Нужно смотреть на раскоментированную строку. Можно было конечно удалить эти автоматические комментарии возникшие при выполнении команды vagrant init centos/7, но возможно они будут полезны. Также при включении виртуальной машины происходит печать ip в консоль. Кроме того, можно залогиниться в виртуальную машину vagrant ssh и посмотреть ip с помощью команды hostname -I. Правда тогда будет видно два ip. Первый ip, который начинается на 10, это служебный адрес присвоенный автоматически, он используется для взаимодействия vagrant с виртуальной машиной, им воспользоваться не получится, будет виден как несуществующий адрес. Второй адрес, это ip заданный в конфиге Vagrantfile, через него можно свободно обращаться к виртуальной машине, для того чтобы открыть сайт в браузере нужно использовать этот ip как адрес сайта (в адресной строке браузера). В конфиге используется настройка private_network в целях безопасности, это значит что сайт можно будет открыть только на одном локально компьютере на котором запущена виртуальная машина, другие компьютеры будут определять этот ip как не существующий. Например, если где-то на локальном сайтае будет использован слишком простой пароль, то скорее всего это не приведёт к проблеме, так как сайт будет доступен только одному разработчику на своём компьютере, хотя привычка вредная конечно. Но распространённая. Потому и применена дополнительная защита. Кроме того, разработчики не будут мешать друг-другу в локальной сети, если нечаянно используют одинаковый ip, это тоже очень удобно и полезно. Но вообще возможны и другие настройки, можно настроить и так что ip будет видимый в локальной сети. Как замену VPS для размещения сайта виртуальные машины обычно не используют. Но в принципе это возможно. Хотя нагрузка от потока посетителей создаст большие проблемы. Кроме того общая папка замедляет файловые операции производимые в ней и работу сайта.
Сайт может быть настроен таким образом, что разрешено определенное доменное имя сервера, и если домен отличается то происходит перенаправление на другой заданный сайт. Если при открытии сайта в браузере по ip происходит перенаправление то нужно в файле bitrix/modules/main/include.php закоментировать строки:
foreach (GetModuleEvents("main", "OnPageStart", true) as $arEvent)
ExecuteModuleEventEx($arEvent);
Потом нужно открыть сайт по ip, залогиниться как администратор сайта, перейти на страницу bitrix/admin/security_hosts.php, и отключить перенаправление убрав галочку Ограничивать. Если не удаётся сохранить новые настроки, то нужно ещё вместо доменов в списке разрешенных прописать ip виртуальной машины (и галочка тоже чтобы была выключенной), тогда настройки сохраняться успешно. Потом нужно снова раскоментировать недавно закоментированные строки в файле bitrix/modules/main/include.php, чтобы не вмешиваться в работу стандартного функционала.
Если на сайте серху возникает красная полоса с уведомлением Отсутствует соединение с сервером, то необходимо настроить модуль Push and Pull.
vagrant ssh
sudo -i
./menu.sh
Откроется консольное меню управления сервером. Нужно придумать и дважды ввести новый пароль для консольного Linux-пользователя bitrix. Потом выбрать пункт 1. Create Management pool of server введя цифру 1, при запросе сетевого интерфейса ввести соответствующий установленному ip, это eth1. В качестве имени сервера лучше не вводить известные наименования в особом формате, а просто написать короткое слово, например serv1 (если написать localhost то могут быть ошибки, если написать mydomain.com то тоже могут быть ошибки, serv1 нормально работает). Потом с помощью 0 нужно вернуться в основное меню, и выбрать пункт 9. Configure Push/RTC service for the pool. С помощью 1 перейти в меню установки сервиса, ввести выбранное ранее имя сервера (например serv1), подтвердить установку. Потом можно несколько раз вводить 0 и полностью выходить из меню. Через top можно проследить за установкой, подождать пока уменьшится нагрузка на процессор. Или, можно перейти в папку /opt/webdir/temp, в ней перейти в папку с префиксом pushserver_ (если таких несколько, можно по дате найти более новую с помощью ls -l), и смотреть обновление лога командой tail -f status. В финале может появится например строка:
serv1 : ok=54 changed=33 unreachable=0 failed=0
Выйти можно с помощью Ctrl+C.
После чего можно зайти на сайт в административный раздел, зайти в Настройки->Настройки продукта->Настройки модулей->Push and Pull, убедиться что в меню Использовать "Push server": выбран пункт Использовать сервер, установленный локально и далее самая новая версия виртуальной машины и Push сервера. Убедитесь что в строке Код-подпись для взаимодействия с сервером: появился автоматически сгенерированный ключ. Если при проверке пришлось изменить настройки, сохраните их. Теперь перезагрузите главную страницу сайта, сообщение об ошибке должно исчезнуть.
Иногда полезно знать что ключ пуш-сервера хранится в файле /etc/sysconfig/push-server-multi, это главный файл. Такой же ключ должен быть в bitrix/.settings.php и в настройках модуля в административном разделе. При копировании этого ключа легко ошибиться. Бывает нужно просто сохранить настройки модуля. Также выглядит естественным в настройках модуля отключить отправку уведомлений на мобильные телефоны.
Дополнительная информация доступна по ссылкам:
https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=37&LESSON_ID=8811
https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=37&LESSON_ID=9379