Перенос конфигураций с drush config

Тип материала: 
Версия Drupal: 
Ключевые слова: 
Модули и темы: 
Пт, 14/10/2016 - 22:41

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

Решение.
Не нужно трогать продакшн сервер, не нужно заморачиваться с дампами БД ради переноса конфигурации,
все намного проще.

В Drupal8 проще - появилась система управления конфигурациями, Configuration Management.

Работая с Drupal8-сайтом, возникает необходимость сохранять и переносить следующее:
Конфигурации, Контент, Сессии, Состояния.

Короткий разговор пойдет именно о переносе конфигураций.

Конфигурация, это настройки сайта: название и слоган, активная тема, активные модули, типы материалов и поля, вьюсы, и прочие настройки.
Грубо говоря то, что "накликано" )))

Хранение настроек в БД - полохо.
Хорошо то, что Drupal8 может хранить множество своих настроек в .yaml файлах.

Инструменты для работы с конфигурациями - модуль configure из ядра Drupal 8 (имеющий ui) и drush.

Прошу рассмотреть пример работы над проектом work_with_conf с использованием drush.

Создадим каталог для проекта, содержащий каталог для хранения своих конфигураций,
загрузим свежий drupal:
mkdir -p work_with_conf/config && cd work_with_conf && drush dl drupal

Получили следующую структуру:

work_with_conf/
├── config
└── drupal-8.2.1
    ├── autoload.php
    ├── composer.json
    ├── composer.lock
    ├── core
    ├── example.gitignore
    ├── index.php
    ├── LICENSE.txt
    ├── modules
    ├── profiles
    ├── README.txt
    ├── robots.txt
    ├── sites
    ├── themes
    ├── update.php
    ├── vendor
    └── web.config

Инсталлируем drupal-сайт,
активируем модуль configure,
сделаем попроще пароль (не делайте так в продакшн),
подкорректируем права для внесения изменений в файлы,
скопируем из примера файл локальных настроек:

drush si minimal --db-url=sqlite://sites/default/files/.ht.sqlite
drush en config
drush upwd admin --password='12345'
chmod 0755 sites/default && chmod 0644 sites/default/settings.php
cp sites/example.settings.local.php sites/default/settings.local.php

Отредактируем settings.php и settings.local.php файлы следующим образом:

# Файл settings.php
# Эта конструкция позволит нам использовать файл локальных настроек, в продакшн это лишнее
# Достаточно просто снять комментарий с этих строк
#
if (file_exists(__DIR__ . '/settings.local.php')) {
  include __DIR__ . '/settings.local.php';
};
#
# При установке сайта, создается следующая строка,
# определяющая путь к каталогу sync
# тут имеет смысл хранить конфигурации, когда сайт в продакшн
#
$config_directories['sync'] = 'sites/default/files/config_ХЕШ_СТРОКА/sync';
# Файл  settings.local.php
# Так мы указали каталоги, в которые будем сохранять свои конфигурации
#
$config_directories = array(
  'active' => '../config/active',
  'staging' => '../config/staging'
);

Восстановим нужные права для файлов и каталогов:
chmod 0555 sites/default && chmod 0444 sites/default/settings.php

Теперь мы можем это использовать.
В случае продакшн, мы синхронизируем настройки из sync каталога
При локальной разработки мы оперируем active и staging каталогами.
В active мы храним то, к чему в случае чего хотим вернуться.
В staging мы храним нашу работу

Пример использования:

# Запустим свой drupal-сайт локально, он будет доступен по адресу http://0.0.0.0:8888
#
drush rs

# Экспортируем изначальное состояние в active
#
drush config-export active

# Активируем тему, к примеру Bartik
# Добавим тип материала foo
# Изменим имя сайта, слоган, добавим вьюс...

# Экспортируем измененное состояние в staging
#
drush config-export staging

# Вернемся к варианту active
#
drush config-import active
# в выводе наблюдаем - какие настройки будут добавлены, удалены или обновлены,
# примерно так:
 Collection  Config                            Operation                
             core.extension                    update
             system.theme                      update
             block.block.bartik_login          delete  
             block.block.bartik_tools          delete  
             block.block.bartik_admin          delete  
             block.block.bartik_branding       delete  
             block.block.bartik_messages       delete  
             block.block.bartik_page_title     delete  
             block.block.bartik_local_tasks    delete  
             block.block.bartik_local_actions  delete
Import the listed configuration changes? (y/n):

# Вернемся к варианту staging
#
drush config-import staging

На этом пример завершен.

Возможности drush config не ограничиваются рассмотренными,
подробная информация в документации:
https://drushcommands.com/drush-8x/config/
прошу сразу обратить ваше внимание на аргумент --partial для экспорта/импорта.

P.S
хотя у модуля config и есть отличный ui,
я надеюсь, что приведенные мною примеры, как минимум пробудят интерес к drush у тех, кто его еще не использует.

и как само собой разумеющееся:
код храним в git, который не стесняемся изучать.

Всем добра ;-)

5 Спасибо

Комментарии

Аватар пользователя Studio VIZA
7 months 1 неделя назад Studio VIZA #

Спасибо большое за информацию, нужен ещё без-консольный вариант.
Ну я вот, одного человека знаю кто пилит сайты на Восьмёрке на продажу. Это же жуть какая для разработчика и клиента. Чем же Семёрка то не устраивает?

0 Спасибо
Аватар пользователя multpix
7 months 1 неделя назад multpix #

Привет Костян)
"безконсольный вариант" это по адресу admin/config/development/configuration
если тема интересна: ISBN 978-1-78398-520-3 | Drupal 8 Configuration Management

И дело тут не в том, что меня устраивает - просто составил небольшой ман, чтоб было куда отсылать, если что)))

1 Спасибо
Аватар пользователя ХулиGUN
7 months 6 дней назад ХулиGUN #

Респект, только те, кто пилят сразу на продакшене скорее всего даже не имеют понятия о стейдженге, дев, локал и продакшн))) Но как по мне тут что-то запутано, ИМХО. Объясни, плз.
Вот смотри. Сайт на продакшене в drush config-import active. Веду локальную разработку, по завершении делаю конфиг экспорт актив, деплою на продакшн и там уже конфиг импорт актив, так? Получается я изначально на продакшене сделал конфиг импорт, заменил файлы(yml) и заного сделал конфиг импорт. Как он сравнивает изменения? или просто накатывает поверх?
Ну а так в принципе норм. Не хватает, правда, хранения доступов не в файлах, а например в переменных окружения. Как думаешь на php такое ваще реально?

0 Спасибо
Аватар пользователя multpix
7 months 6 дней назад multpix #
Х улиGUN написал:
а например в переменных окружения. Как думаешь на php такое ваще реально?

Примерно вот так:
установили

# ~/.bashrc
export PHP_EXEMPL="foo"

получили

#!/usr/bin/php7.0
<?php
echo 'PHP_EXEMPL: ' . $GLOBALS['_SERVER']['PHP_EXEMPL'] . "\n";
?>

А по configам:
там по умолчанию один sync (в settings.php его настройки), и соответственно вызывать:

drush config-import sync
drush config-export sync

Но мы при желании можем наклепать любые (хотя вполне хватает одного - два удобно для роллбэка)
(как пример active и staging - просто эти имена в оф.доках мелькают и константы у дру есть такие).

Пример экспорта configа:

uuid: 03b9b481-e37d-4868-bc92-d8d52c7ff422
langcode: en
status: true
dependencies:
  module:
    - system
  theme:
    - seven
id: breadcrumbs
theme: seven
region: breadcrumb
weight: 0
provider: null
plugin: system_breadcrumb_block

settings:
  id: system_breadcrumb_block
  label: Breadcrumbs
  provider: system
  label_display: '0'
visibility: {  }

Заинсталили Дру
Сделали экспорт в active (у каждого configа uuid)
Чего-то нащелкали - самим не понравилось - импорт из active, и все как было
Чего-то нащелкали - надо показать - экспорт в staging - и показали
Устраивает - на продакшн импорт из staging и экспорт в active - конец итерации разработки и по новой))

Получается, что одна инсталляция дру как-бы эволюционирует от итерации до итерации.

При каждом импорте - сравнивает новое с предыдущим - на каждый чих - config, а у configа уникальный id.

Для одиночных configов удобно сделать каталог single и тут нужен флаг --partial
иначе один config применит, а остальные удалит)))

Сравнивает, и выводит что обновляем, что новое создаем, а что удаляем.
Главно - перед первым экспортом drush en config
И никаких ключей -y
Лучше лишний раз почитать что сейчас произойдет)))

Система - ниппель, но уж лучше так чем никак)))

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

Вобщем как-т так))
С рельсовыми миграциями это и рядом не лежало.

P/S
Это ППц
Фильт "мат слов" реагирует на никнейм))))

0 Спасибо
Аватар пользователя ХулиGUN
7 months 6 дней назад ХулиGUN #
multpix написал:
Это ППц

Фильт "мат слов" реагирует на никнейм))))

Я те больше скажу - я не могу вставить ссылку на свой гитхаб)))) приходится через сервисы коротких урлов))) Опять забили на друпал)))

0 Спасибо
Аватар пользователя bumble
7 months 5 дней назад bumble #

Пользуем эту либу для фильтрации ругательств.
Сорри, твой ник она никак не пропустит... ))

0 Спасибо
Аватар пользователя bumble
7 months 5 дней назад bumble #

На главной

2 Спасибо
Аватар пользователя ХулиGUN
7 months 5 дней назад ХулиGUN #
bumble написал:
Сорри, твой ник она никак не пропустит... ))

Мне норм))) Меньше меня цитировать будут, а у подгорающих ещё больше бомбить будет, когда отвечать будут)))

1 Спасибо