Jak zapobiec instalowaniu modułu Devel w środowiskach produkcyjnych

Używając nowego Menedżera konfiguracji Drupal 8, jak mogę zapobiec instalacji modułu Devel w niektórych środowiskach? O ile wiem, instalowanie go na moim komputerze lokalnym oznacza, że ​​następnym razem, gdy wyeksportuję konfigurację i przeniosę ją do innych środowisk (programistycznych, testowych, prod), zostanie ona automatycznie włączona.

Metoda: Drush

• Drush może zignorować włączone stany rozszerzeń podczas synchronizacji konfiguracji.

  drush cex --skip-modules=devel

  drush cim --skip-modules=devel

• Za pomocą narzędzi Drush CMI możesz pracować z listą konfiguracji do zignorowania.

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

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

Metoda: moduły

• Możesz użyć modułu Split konfiguracji , który pozwala:

  1. Rozdziel część konfiguracji na dedykowany folder
  2. Konfiguracja czarnej listy
  3. Zignoruj ​​zestaw konfiguracji
  4. Konfigurowane przez jednostki konfiguracji

• Konfiguracja Moduł trybu tylko do odczytu

  Ten moduł pozwala zablokować wszelkie zmiany konfiguracji dokonane za pomocą interfejsu użytkownika Drupal. Może to być przydatne w scenariuszach, w których na przykład zmiany konfiguracji nie powinny być wprowadzane w środowisku produkcyjnym, ale tylko w środowisku pomostowym lub lokalnym.

  $settings['config_readonly'] = TRUE;

• Kolejnym modułem jest konfiguracja środowiska, która umożliwia zastąpienie konfiguracji dla poszczególnych środowisk.

Aktualizacja : Funkcja opisana poniżej została niedawno usunięta https://www.drupal.org/project/config_split/issues/2926505

Jeśli używasz drush w procesie wdrażania, możesz wykonać następujące czynności:

Utwórz drushrc.phpplik w tym samym katalogu co Twój settings.php(na przykład docroot/sites/default:) i umieść następujące elementy:

$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;

Oznacza to, że możesz manipulować poleceniami drush cex/ drush cim, aby pomijać moduły podczas ich przetwarzania.

Możesz przeczytać więcej o korzystaniu z filtra modułu konfiguracji w Drush 8 .

drush cex --skip-moduleszostał usunięty na korzyść config_split, jak wyjaśniono w tym numerze, więc tutaj rozwiązania oparte na drushie nie zadziałały dla mnie.

Oto rozwiązanie oparte na rozwiązaniu Duncanmoo wykorzystującym moduł config_exclude

1. Zainstaluj config_exclude za pomocą Composera --dev i skonfiguruj go

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

zezwól na użycie pliku settings.php w lokalnym środowisku programistycznym

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

Dodaj ustawienia config_exclude do pliku lokalnego

$ nano sites/default/setting.local.php

oto kilka przykładowych ustawień

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

UWAGA 1: config_filter jest zależnością config_exclude, więc jeśli nie potrzebujesz jej produkcji, możesz wykluczyć ją powyżej

UWAGA 2: Nie settings.local.phpjest to wymóg. Zależy to od tego, czy jest kontrolowany przez VCS, czy nie.

2. Kompozytor wymaga --dev

Włączając moduł przeznaczony wyłącznie do programowania, użyj flagi --dev:

$ composer require --dev drupal/devel

Powoduje to dodanie tych zależności do pliku composer.json w ramach wymagania-dev:

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

Więc jeśli zainstalujesz witrynę BEZ modułów deweloperskich, których używasz:

$ composer install --no-dev

UWAGA: W środowiskach inscenizacyjnych i prod powinieneś zawsze robić --no-dev

3. używaj drush cex jak zwykle

$ drush cex 

nie wyeksportuje żadnego z wykluczonych ustawień modułów

UWAGA: Zauważyłem, że ustawienia core.extension wydają się zostać zmodyfikowane po uruchomieniu powyższej komendy, ale odpowiedni plik .yml nigdy nie jest zapisywany na dysku twardym (nawet po potwierdzeniu will be deleted and replaced with the active config), więc nie ma nic do zatwierdzenia , myślę, że zależy to od elementy wewnętrzne modułu config_exclude

Jest interesujący problem dla Drupal 8.3.x: Zezwól modułom programistycznym na rezygnację z config-export . Ogólny wniosek jest taki, że Configuration Split jest obecnie najlepszym rozwiązaniem.

Komentarz swentel :

Chciałem tylko krótko udokumentować, jak działa config_split: encja config split config definiuje, co jest na czarnej liście, pozwalając na czarną listę modułów i / lub obiektów konfiguracji. Przykład kanoniczny, będący devel, ma już interesujący przypadek użycia: pochodzi z system.menu.devel, który w przypadku czarnej listy devel plik konfiguracyjny menu nie zostanie usunięty, ponieważ nie ma zależności. Chociaż nie jest to poważny problem, podział konfiguracji pozwala również indywidualnie to wybrać, więc jest usuwany w środowisku.

Komentarz geerlingguy :

Wypróbowałem kilka różnych metod zarządzania konfiguracją specyficzną dla środowiska i wydaje się, że config_split osiąga właściwą użyteczność w porównaniu do dodatkowej równowagi kosztów ogólnych, jak dotąd najlepszą. Jest prosty i lekki, ale pozwala mi zaznaczyć (i nadal używać) określoną konfigurację tylko w określonych środowiskach.

Podział konfiguracji może być dla niektórych realnym rozwiązaniem.

Zarządzanie konfiguracją Drupal 8 działa najlepiej podczas importowania i eksportowania całego zestawu konfiguracji witryn. Czasami jednak programiści lubią rezygnować z niezawodności CM i mają na swoim komputerze programistycznym aktywny zestaw konfiguracji i wdrażają tylko podzbiór. Kanonicznym przykładem tego jest włączenie modułu deweloperskiego lub posiadanie kilku bloków umieszczeń lub widoków w środowisku programistycznym, a następnie nie eksportowanie ich do zestawu konfiguracji do wdrożenia, ale nadal możliwość udostępniania konfiguracji programistycznej współpracownikom.

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

Jest fajny sposób na zrobienie tego, w którym kończysz z modułami deweloperskimi zatwierdzonymi w kompozytorze, a konfiguracja tych modułów nie jest dodawana do eksportu konfiguracji (są 2 części):

1. Kompozytor wymaga opcji --dev Włączając moduł przeznaczony wyłącznie do programowania, należy użyć flagi --dev:

$ composer require --dev drupal/devel

Powoduje to dodanie tych zależności do pliku composer.json w ramach wymagania-dev:

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

Jeśli więc zainstalujesz witrynę BEZ modułów programistycznych, powiesz:

$ composer install --no-dev

NB: W środowisku inscenizacyjnym i produkcyjnym powinieneś zawsze robić --no-dev

2. Użyj modułu config_split

Moduł podziału konfiguracji umożliwia tworzenie grup eksportu konfiguracji, które można włączyć lub wyłączyć w środowisku.

Mam 3 podziały:

1. Konfiguracja głównej witryny (włączona wszędzie; tworzenie i tworzenie i produkcja)
2. Konfiguracja przejściowa (włączona w programowaniu i przemieszczaniu) - zawiera moduł przekierowania wiadomości e-mail
3. Konfiguracja dewelopera - obejmuje programowanie, kint ... ale nie przekierowywanie wiadomości e-mail, ponieważ ma to włączone włączenie konfiguracji pomostowej w programie dev.

Zrobiłem mały skrypt, aby zrobić to wszystko za jednym razem.

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

Możesz także zobaczyć moduł Config Ignore .

Ten moduł jest narzędziem pozwalającym zachować pożądaną konfigurację.

Powiedzmy, że chcesz, aby konfiguracja system.site (która zawiera nazwę witryny, hasło, adres e-mail itp.) Pozostała niezmieniona w Twojej witrynie bez względu na konfigurację w folderze eksportu.

A może masz już dość zmieniania ustawień devel.set za każdym razem, gdy importujesz konfigurację?

W tym celu można użyć modułu zastępowania wdrożenia. Przeczytaj poniższy link, aby uzyskać szczegółowy opis:

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

Jednakże , najlepszym sposobem na to zrobić byłoby wyłączyć moduł na lokalny, a następnie wyeksportować konfigurację.

Drupal umożliwia zastąpienie ustawień konfiguracji settings.php, ale nie są one odpowiednie do wyłączania / włączania modułów.

Od 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.
 */