Как предотвратить установку модуля Devel в производственной среде


26

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


Является ли использование drushприемлемым? Я узнал на днях о drush config-export --skip-modules=devel. Может быть что-то подобное без использования drush, но я не знаю.
Мрадклифф

Так что мне придется делать это каждый раз, когда я экспортирую конфигурацию? Должен быть лучший способ: |
Cambraca

Может быть, вы можете добавить некоторые файлы конфигурации в ваш .gitignore.
digitaldonkey


2
Я думаю, что этот вопрос слишком широк в ретроспективе. Вероятно, есть много хороших ответов, потому что это зависит от процесса сборки и разработки сайта.
Мрадклифф

Ответы:


18

Метод: Drush

  • 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, который позволяет вам переопределять конфигурацию для каждой среды.


2
Мне действительно не нравится иметь все библиотечные зависимости для модуля devel на моих производственных серверах, поэтому я добавляю их в composer используя composer require --dev drupal/devel. Дополнительным бонусом является то, что установка композитора происходит быстрее, что ускоряет развертывание продукта.
Дунканму


6

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


Если вы используете drush в процессе развертывания, вы можете сделать следующее:

Создайте 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чтобы пропустить модули во время их обработки.

Вы можете прочитать больше об использовании фильтра модуля конфигурации в Drush 8 .


5

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

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

1. Установите config_exclude с помощью Composer require --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не требование. Это зависит от того, контролируется ли ваша VCS или нет.

2. Композитор требует --dev

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

$ composer require --dev drupal/devel

Это приводит к тому, что эти зависимости добавляются в файл composer.json под require-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


У меня был очень похожий опыт @GiorgosK, следуя предложениям выше. Это решение отлично сработало для меня и содержит также хорошо продуманные советы. Я также заметил ложные отрицания core.extension, но это действительно НЕ изменило статус для git, так что все хорошо. Спасибо
vrwired

2

В Drupal 8.3.x есть интересная проблема: разрешить модулям разработки отказаться от экспорта конфигурации . Общее мнение заключается в том, что Configuration Split в настоящее время является лучшим решением.

Комментарий от swentel :

Просто хотел кратко описать, как работает config_split: объект config config config определяет, что находится в черном списке, что позволяет вам занести в черный список модули и / или объекты конфигурации. Канонический пример, будучи devel, уже имеет интересный вариант использования: он поставляется с system.menu.devel, который, в случае если вы заносите в черный список devel, файл конфигурации меню не будет удален, так как нет зависимости. Несмотря на то, что это не является серьезной проблемой, разделение конфигурации позволяет вам также выбрать его отдельно, чтобы оно было удалено в среде.

Комментарий от geerlingguy :

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


2

Разделение конфигурации может быть жизнеспособным решением для некоторых.

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

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


+1 для разделения конфигурации, я всегда использую это для отключения Devel и других модулей, таких как Field UI и Views UI, в prod. См. Отключить модули с помощью config split .
leymannx

2

Есть отличный способ сделать это, когда вы в конечном итоге получите для вашего модуля модули dev, зафиксированные в composer для удобства, а конфигурация этих модулей не добавлена ​​в экспорт вашей конфигурации (есть 2 части):

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

$ composer require --dev drupal/devel

Это приводит к тому, что эти зависимости добавляются в файл composer.json под require-dev:

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

Поэтому, если вы устанавливаете сайт БЕЗ ваших модулей разработки, вы говорите:

$ composer install --no-dev

NB: В вашей промежуточной и рабочей среде вы всегда должны делать --no-dev

2. Используйте модуль config_split

Модуль разделения конфигурации позволяет создавать группы экспорта конфигурации, которые можно включить или отключить в среде.

У меня на самом деле есть 3 раскола:

  1. Конфигурация основного сайта (включена везде; разработка, подготовка и производство)
  2. Staging config (включен в dev и staging) - включает модуль переадресации электронной почты
  3. Конфигурация Dev - включает в себя devel, kint ... но не перенаправляет электронную почту, поскольку это связано с включением промежуточной конфигурации в dev.

1
Вы действительно не должны использовать зависимости dev таким образом. Они больше для инструментов, таких как сниффер кода, которые вам не нужно запускать в производстве. Если они включены, и Drupal ожидает, что модуль будет установлен, а кода нет, то это может привести к нестабильности сайта. Drupal / Composer может по-прежнему пытаться загрузить файл, который не находится в файловой системе, если это зависимость от dev.
Фрэнк Роберт Андерсон

@FrankRobertAnderson вы не предлагаете лучшего решения? Я не хочу, чтобы модуль devel или зависимые библиотеки были на моем рабочем сервере, что вы предлагаете?
Дунканму

Drupal на самом деле не предоставляет хороший вариант для этого. Ваш план не ужасен, но он приведет к проблемам, если вы не будете осторожны. У меня проблема с вашим планом - config_split становится пин-кодом, от которого зависит весь ваш сайт. Я бы проголосовал за тебя, если бы не вопрос о зависимости от разработчиков, который даже не затрагивался в ОП.
Фрэнк Роберт Андерсон

1

Я сделал небольшой сценарий, чтобы сделать все это одним выстрелом.

#!/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

1

Вы также можете увидеть модуль Config Ignore .

Этот модуль является инструментом, позволяющим вам сохранить конфигурацию, которую вы хотите, на месте.

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

Или, может быть, вы устали от изменений devel.settings при каждом импорте конфигурации?


Модуль Config Ignore в этом случае не подходит. Со страницы модуля: не игнорируйте конфигурацию core.extension, поскольку это не позволит вам включить новые модули с помощью импорта конфигурации. Используйте модуль Config Split для специфических для среды модулей.
bmunslow

1

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

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.
 */
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.