Як запобігти встановленню модуля Devel у виробничих середовищах

Як за допомогою нового менеджера конфігурації Drupal 8 я можу запобігти встановленню модуля Devel у певних середовищах? Наскільки я знаю, встановлення його на моїй локальній означає, що наступного разу, коли я експортую конфігурацію та переміщую її в інші мої середовища (dev, test, prod), вона буде автоматично включена.

Метод: Друш

• Drush може ігнорувати включені стани розширень при синхронізації конфігурації.

  drush cex --skip-modules=devel

  drush cim --skip-modules=devel

• За допомогою інструментів Drush CMI ви можете працювати зі списком конфігурації, яку слід ігнорувати.

  drush cexy --ignore-list=/path/to/config-ignore.yml

  drush cimy --delete-list=/path/to/config-ignore.yml

Метод: Модулі

• Ви можете використовувати модуль Configuration Split, який дозволяє:

  1. Розділіть певну конфігурацію на виділену папку
  2. Конфігурація чорного списку
  3. Ігноруйте набір конфігурацій
  4. Конфігурується особами конфігурації

• Конфігурація Модуль режиму лише для читання

  Цей модуль дозволяє блокувати будь-які зміни конфігурації, здійснені через інтерфейс адміністратора Drupal. Це може бути корисно в сценаріях, коли, наприклад, зміни конфігурації не повинні проводитись у виробничому середовищі, а лише на етапах чи локальних середовищах.

  $settings['config_readonly'] = TRUE;

• Ще один модуль - це Config Environment, що дозволяє змінювати конфігурацію на основі середовища.

Оновлення : описана нижче функція була видалена останнім часом https://www.drupal.org/project/config_split/isissue/2926505

Якщо ви використовуєте друк у процесі розгортання, ви можете зробити наступне:

Створіть drushrc.phpфайл у тому самому каталозі, що і ваш settings.php(наприклад docroot/sites/default:), і поставте наступне:

$drush_ignore_modules = array(
  'devel',
  'webprofiler',
  'devel_generate',
  'kint',
  'yaml_editor',
);

$command_specific['config-export']['skip-modules'] = $drush_ignore_modules;
$command_specific['config-import']['skip-modules'] = $drush_ignore_modules;

Це означає, що ви можете маніпулювати командами drush cex/, drush cimщоб пропустити модулі під час їхнього процесу.

Докладніше про використання фільтра модуля конфігурації ви можете прочитати в друку 8 .

drush cex --skip-modulesбуло видалено на користь config_split, як пояснено в цьому питанні, тому рішення, засновані на барабані, не працювали для мене.

Ось рішення, засноване на рішенні Duncanmoo з використанням модуля config_exclude

1. Встановіть config_exclude за допомогою Composer need --dev та налаштуйте його

$ composer require --dev drupal/config_exclude
$ drush en config_exclude -y
$ nano sites/default/setting.php

дозволити використовувати settings.php у вашому локальному середовищі розробників

if (file_exists($app_root . '/' . $site_path . '/settings.local.php')) {
  include $app_root . '/' . $site_path . '/settings.local.php';
}

Додати параметри config_exclude у локальний файл

$ nano sites/default/setting.local.php

ось декілька прикладних налаштувань

$settings['config_exclude_modules'] = [
    'devel', 
    'config_exclude',
    'config_filter',
    ...
    'stage_file_proxy',
];

ПРИМІТКА1 : config_filter - це config_exclude залежність, тому якщо вам це не потрібно, ви можете виключити його вище

ПРИМІТКА2 . settings.local.phpЦе не є вимогою. Це залежить від того, контролюється він чи ні.

2. Композитор вимагає --дев

Увімкнувши модуль, призначений виключно для розробки, використовуйте прапор --dev:

$ composer require --dev drupal/devel

Це призводить до того, що ці залежності додаються до файлу composer.json під вимогою-dev:

...
    "require-dev": {
        "drupal/twig_xdebug": "^1.0",
        "drupal/devel": "^1.0@RC"
    }
}

Тож якщо ви встановлюєте сайт БЕЗ своїх розроблених модулів:

$ composer install --no-dev

ПРИМІТКА. У ваших середовищах постановки та продажі завжди слід робити --no-dev

3. використовуйте drush cex як звичайно

$ drush cex 

не експортує жодне з виключених параметрів модулів

ПРИМІТКА. Я помітив, що налаштування core.extension були змінені після запуску команди вище, але відповідний .yml ніколи не записується на жорсткий диск (навіть після підтвердження will be deleted and replaced with the active config), тому нічого не потрібно робити, я думаю, це залежить від внутрішній модуль config_exclude

Існує цікава проблема для Drupal 8.3.x: Дозволити модулі розробки вимкнути конфігурацію-експорт . Загальний консенсус полягає в тому, що конфігурація Split на даний момент є найкращим рішенням.

Коментар swentel :

Просто хотілося коротко задокументувати, як працює config_split: Суб'єкт config config split визначає, що є у чорному списку, що дозволяє створювати модулі чорного списку та / або конфігурувати об'єкти. Канонічний приклад, будучи devel, вже має цікавий випадок використання: він поставляється з system.menu.devel, який, у випадку, якщо ви розробити чорний список, конфігураційний файл меню не буде видалений, оскільки немає залежності. Незважаючи на те, що це не є основною проблемою, розбиття конфігурації дозволяє окремо вибирати це так, щоб він був видалений з оточення.

Коментар geerlingguy :

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

Конфігурація Split може бути життєздатним рішенням для деяких.

Управління конфігурацією Drupal 8 найкраще працює під час імпорту та експорту всього набору конфігурацій сайтів. Однак іноді розробникам подобається відмовитися від надійності CM та мати суперкомплект конфігурації, активний на своїй машині розробки та розгорнути лише підмножину. Канонічним прикладом цього є включення модуля розробки або наявність декількох блокових розміщень або представлень у середовищі розробки, а потім не експортувати їх у набір конфігурації для розгортання, але все ще в змозі поділитися конфігурацією розробки з колегами.

https://www.drupal.org/project/config_split

Існує акуратний спосіб зробити це, коли для зручності ви закінчите свої модулі розробки, виконані в композиторі, і конфігурація цих модулів не додається до експорту вашої конфігурації (є 2 частини):

1. Композитор вимагає --dev При ввімкненні модуля, призначеного виключно для розробки, використовуйте прапор --dev:

$ composer require --dev drupal/devel

Це призводить до того, що ці залежності додаються до файлу composer.json під вимогою-dev:

...
    "require-dev": {
        "drupal/twig_xdebug": "^1.0",
        "drupal/devel": "^1.0@RC"
    }
}

Тож якщо ви встановите сайт БЕЗ модулів розробника, ви скажете:

$ composer install --no-dev

Примітка: У ваших постановочних та продуктових середовищах ви завжди повинні робити - no-dev

2. Використовуйте модуль config_split

Модуль розділення конфігурації дозволяє створювати угруповання експорту конфігурації, які можна вмикати або вимикати в середовищі.

Я фактично маю 3 розколи:

1. Основний конфігурація сайту (увімкнено всюди; розробка та постановка та виробництво)
2. Конфігурація поетапної роботи (увімкнено у програмах розробки та інсценізації) - включає модуль електронної пошти для перестановки
3. Конфігурація Dev - включає в себе програму devel, kint ..., але не перенаправляє електронну пошту, як це стосується включення конфігурації постановки у програмі dev.

Я зробив невеликий сценарій, щоб зробити це все в один кадр.

#!/bin/bash

drush pm-uninstall devel -y
drush pm-uninstall field_ui -y
drush pm-uninstall field_name_prefix_remove -y

drush config-export

drush en devel -y
drush en field_ui -y
drush en field_name_prefix_remove -y

Ви також можете побачити модуль Налаштувати ігнорувати .

Цей модуль - це інструмент, який дозволяє вам зберігати потрібну конфігурацію.

Скажемо, що ви хотіли б, щоб конфігурація system.site (яка містить ім’я сайтів, слоган, електронна пошта тощо) залишалася недоторканою на вашому реальному веб-сайті, незалежно від конфігурації, в папці експорту.

А може, вам набридло змінювати параметри devel.set щоразу, коли ви імпортуєте конфігурацію?

Для цього можна використовувати модуль переопрацювання розгортання. Прочитайте наступне посилання для детального опису:

http://dcycleproject.org/blog/46/continuous-deployment-drupal-style

Однак найкращим способом зробити це було б відключити ваш модуль на локальному рівні та потім експортувати конфігурацію.

Drupal пропонує спосіб змінити настройки конфігурації settings.php, але вони не дійсні для відключення / включення модулів.

Від default.settings.php:

/**
 * Configuration overrides.
 *  * To globally override specific configuration values for this site,
 * set them here. 
 * 
 *
 * blah..blah...blah
 *
 *  
 * There are particular configuration values that are risky to override. For
 * example, overriding the list of installed modules in 'core.extension' is not
 * supported as module install or uninstall has not occurred. Other examples
 * include field storage configuration, because it has effects on database
 * structure, and 'core.menu.static_menu_link_overrides' since this is cached in
 * a way that is not config override aware. Also, note that changing
 * configuration values in settings.php will not fire any of the configuration
 * change events.
 */