В работе программиста много времени отнимают процессы, к программированию относящиеся лишь косвенно. Лично у меня каждый новый, либо надолго забытый проект начинается с продолжительного разворачивания локального окружения, которое состоит не только в клонировании гит-репозитория на локальный компьютер, но также копировании не содержащихся в гите статичных файлов и базы данных. Со временем актуальность локального окружения падает, и часть процесса приходится повторять заново. Еще несколько лет назад я неизменно заходил на сервер, делал дамп БД и архив файлов, которые выкачивал и разворачивал локально. Сейчас появились некоторые инструменты, которые хоть и требуют определенной начальной настройки, но в дальнейшем сильно упрощают жизнь.
1. Подключение к удаленному серверу.
Итак, вы получили доступы к серверу, на котором работает сайт. Первым делом надо озаботиться тем, чтобы раз и навсегда забыть пароль к нему и осуществлять доступ исключительно с помощью SSH-ключа. Поэтому заходим к себе в каталог ~/.ssh и смотрим ранее сгенерированные ключи. Там их, как водится, одна или более пар - закрытый и открытый ключ в каждой. Всего скорее вы найдете что-то вроде id_rsa и id_rsa.pub. Если вы ничего не увидели, то ключ можно сгенерировать командой ssh-keygen. Вам надо будет выбрать название для файла ключа и, если вы поборник безопасности, придумать для него пароль (что я бы не рекомендовал делать в целях упрощения пользования им).
Итак, теперь у нас есть ключ, и нам надо закинуть его публичную часть на сервер, а точнее - дописать содержимое ключа в файл ~/.ssh/authorized_keys. Публичную - это ту, что имеет расширение .pub, всё, что без него, - это ваша личная собственность, и за пределы вашего компьютера уходить не должно. Раньше я делал это через файл-менеджер, однако иногда права доступа настроены таким образом, что сделать это проблематично. Безотказный вариант - использовать специальную команду в консоли. Пусть наш логин на сервере будет username, а домен - servername.ru, тогда команда будет выглядеть следующим образом:
ssh-copy-id -i ~/.ssh/id_rsa.pub username@servername.ruЕсли вы подключаетесь по нестандартному порту, добавьте в конце --p[номер порта] (например, -p22222).
Меняете имя файла ключа на свой, а логин и url сервера на нужные, отправляете и, если все верно, единожды вводите пароль. Все - ключ скопирован, и вы можете проверить, как всё работает, попытавшись подключиться: ssh username@servername.ru.
Про пароль теперь можно забыть, что уже хорошо, но запоминать имя пользователя и домен (а то и ip-адрес) тоже не очень бы хотелось, к тому же через пару лет работы таких записей соберется не один десяток и хранить это в голове или где бы то ни было станет невыносимо.
Значительно проще было бы запоминать короткий алиас подключения, а про остальное забыть, как про страшный сон. Например, username@servername.ru обозвать srv. И это возможно - заходим в файл ~/.ssh/config (если нет, то создаем его) и добавляем в него следующие строчки:
host srv
hostname servername.ru
user username
port 22222 # это только если порт нестандартный
Сохраняем, выполняем в консоли ssh srv и - профит! Есть и иные параметры подключения, но они далеко за пределами обычной работы и всего скорее после краткого гугления вы найдете свой особенный вариант настройки, если стандартный не подойдет.
Главное здесь - называть подключения так, чтобы они были максимально коротки, но при этом чётко ассоциировались с проектом. Наверняка у вас будут подключения к рабочему сайту и его варианту для разработки. Какой бы домен/поддомен не имел последний, наиболее логичным будет назвать его, добавив к алиасу основного подключения суффикс _dev. Так, если у нас srv - это алиас для прода, то к деву будет логично подключаться через srv_dev. Адреса девов меняются, а краткое слово "дев" всегда будет однозначно характеризовать нам то, что... что оно должно характеризовать).
2. Настройка удаленных алиасов для консольной утилиты drush
Drupal поддерживает мультисайтинг. То есть на одной кодовой базе может работать более одного сайта. Для обеспечения возможности работы с несколькими сайтами на уровне утилиты drush были внедрены алиасы сайтов. В режиме мультисайтинга они позволяют из одного рабочего каталога выполнять команды для разных сайтов, в этом каталоге работающих. Но помимо этого, мы можем также указывать среди алиасов удаленные сайты, что открывает нам дополнительные возможности.
В версиях Drupal 7 и Drupal 8/9 настройка осуществляется немного по-разному, что приводит в особенностям при разворачивании локального окружения.
Настройка алиасов drush Для Drupal 7
Алиасы сайтов для Drupal 7 настраиваются глобально для текущего пользователя ОС и по сути не имеют отношения к конкретному проекту, так как описываются за его пределами.
В папке пользователя создаем папку .drush, и в нем - файл aliases.drushrc.php примерно со следующим содержимым:
<?php
$aliases['prod'] = array(
'remote-host' => 'servername.ru', // адрес для подключения
'remote-user' => 'username', // имя пользователя
'root' => '/home/username/web/servername.ru/html', // каталог установки сайта
'uri' => 'https://servername.ru', // URL сайта
'ssh-options' => '-p 22222' // дополнительные опции для подключения, например, порт
);
Это вариант для идеальных условий, который, тем не менее, срабатывает для большинства случаев. Иногда требуются дополнительные параметры, как, например, пути к каталогу установки drush, к статичным файлам и т.п. Пример файла настроек алиасов со всеми возможными значениями можно посмотреть здесь.
Казалось бы, всё легко, но если локально вы работаете с docker-окружением (а это наверняка так), то вам надо пробросить этот файл в контейнер. Я пользуюсь Lando и для проброса использую следующую инструкцию. Аналогично можно сделать для docksal. Адепты docker4drupal, думаю, разберутся и без дополнительных пояснений - им в конфигах копаться не впервой.
Настройка алиасов drush Для Drupal 8
Здесь всё стало логичнее: конфигурация алиасов - это уже часть проекта. В каталоге проекта создается папка drush/sites, и в ней - файл self.sites.yml с соответствующим содержимым:
prod:
host: servername.ru
user: username
root: /home/username/web/servername.ru/html
uri: https://servername.ru
Полный пример файла, как всегда - в репозитории проекта.
3. Использование алиасов drush
Итак, мы сконфигурировали алиасы сайтов для drush и теперь можем попробовать их в деле. Сбрасываем кэш drush, выполнив drush cc drush (если вы используете docker, предварительно зайдите в контейнер), и пытаемся получить информацию от удаленного сайта drush @prod st. В ответ мы должны увидеть то, что обычно видим при выполнении привычного drush st, но уже в контексте удаленного сайта. Также пробуем получить ссылку для авторизации (вы ведь уже забыли пароль?) - drush @prod uli. Работает? Переходим к самому интересному.
Пока вы были в отпуске, сайт ушёл далеко вперёд? Пора актуализировать БД. Сделаем это по-модному. Для начала раз и навсегда запоминаем, что в стандартной односайтовой установке текущий сайт обозначается алиасом @self. Теперь выполняем
drush sql-sync @prod @selfЕсли нам повезёт, то мы увидим процесс авторизации, создания дампа на удаленном сайте, скачивания его и разворачивания на локальной установке. Если этого не произошло - что-то в вашей конфигурации алиаса не так и всего скорее придётся немного погуглить. Часто проблема возникает, если в настройках не указаны пути к папке и к исполняемому файлу drush.
Мы актуализировали БД и обнаружили, что все последние новости с пустыми картинками - нет новых файлов. Не беда, выполняем
drush rsync @prod:%files @self:%filesКак вы поняли, %files - это переменная, в которой хранится путь к каталогу public:// удаленного сайта (который обычно /sites/default/files/). Порой эту переменную надо особо определить, о чём выше, но обычно всё происходит без лишних сложностей. Впрочем, вместо %files может быть любой каталог сайта.
Теперь о страшном. С самого начала я думал, что произойдёт, если случайно перепутать алиасы местами и запустить drush sql-sync @self @prod. И вот как-то я попробовал это сделать. Ничего не вышло, Drush отказал мне. Не знаю, сделано ли это ограничение для алиаса @prod, или вообще нельзя выкатить свой дамп на удаленную БД, но по крайней мере в этой фобии можно себя успокоить.
4. Хитрости при дампе БД
Порой нам встречаются сайты, база данных которых разрослась до многих гигабайт, и скачивание и разворачивание такого гиганта занимает много ценного рабочего (или не очень) времени. Причём значительную часть этого объема занимают таблицы, где хранится кэш.
Решаем вопрос следующим образом (рецепт для Drupal 7). В папке .drush на сайте создаем файл .drushrc.php (если его там еще нет), где прописываем список таблиц, которые надо пропускать при создании дампа. Например:
<?php
$options['structure-tables']['common'] = array('cache', 'cache_admin_menu', 'cache_block', 'cache_bootstrap', 'cache_commerce_shipping_rates', 'cache_entity_comment', 'cache_entity_commerce_customer_profile', 'cache_entity_commerce_line_item', 'cache_entity_commerce_order', 'cache_entity_commerce_product', 'cache_entity_field_collection_item', 'cache_entity_file', 'cache_entity_node', 'cache_entity_taxonomy_term', 'cache_entity_taxonomy_vocabulary', 'cache_entity_user', 'cache_features', 'cache_feeds_http', 'cache_field', 'cache_filter', 'cache_form', 'cache_hacked', 'cache_image', 'cache_libraries', 'cache_menu', 'cache_metatag', 'cache_page', 'cache_path', 'cache_rules', 'cache_session_cache', 'cache_token', 'cache_ultimate_cron', 'cache_update', 'cache_variable', 'cache_views', 'cache_views_data');
Впрочем, всего скорее, сейчас уже должна быть доступна запись с wildcard:
$options['structure-tables']['common'] = array('cache', 'cache_*');Теперь при синхронизации (да и просто при создании дампа) добавляем ссылку на этот список: --structure-tables-key=common, например:
drush sql-sync @prod_ru @ru --structure-tables-key=commonЗаключение
Это лишь небольшая часть ухищрений, к которым можно прибегнуть для автоматизации ежедневной рутины. Порой может показаться, что для малых и нерегулярных проектов игра не стоит свеч и потерянного на настройку времени, но если проект большой, и вы часто к нему обращаетесь, в будущем это сэкономит вам много нервов и к тому же подарит новые навыки, которые в нашем деле никогда не бывают лишними.
Добавить комментарий