프로덕션 환경에 Devel 모듈이 설치되지 않도록하는 방법

새로운 Drupal 8 Configuration Manager를 사용하여 특정 환경에 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

방법 : 모듈

• 다음을 수행 할 수있는 구성 분할 모듈을 사용할 수 있습니다.

  1. 일부 구성을 전용 폴더로 분리
  2. 블랙리스트 구성
  3. 일련의 구성 무시
  4. 구성 엔터티로 구성

• 구성 읽기 전용 모드 모듈

  이 모듈은 Drupal 관리 UI를 통해 수행 된 모든 구성 변경을 잠글 수 있습니다. 이는 프로덕션 환경에서 구성 변경을 수행하지 말고 스테이징 또는 로컬 환경에서만 수행해야하는 시나리오에서 유용 할 수 있습니다.

  $settings['config_readonly'] = TRUE;

• 또 다른 모듈은 환경 별 구성 을 무시할 수 있는 환경 구성 입니다.

업데이트 : 아래에 설명 된 기능이 최근 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의 구성 모듈 필터 사용에 대한 자세한 내용을 읽을 수 있습니다 .

drush cex --skip-modules이 문제 에서 설명한대로 config_split을 위해 제거 되었으므로 drush를 기반으로 한 여기의 솔루션은 효과가 없었습니다.

다음은 config_exclude 모듈을 사용하는 Duncanmoo 솔루션 기반 솔루션입니다

1. Composer require --dev를 사용하여 config_exclude를 설치하고 구성하십시오

$ 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

이로 인해 이러한 종속성이 require-dev 아래 composer.json 파일에 추가됩니다.

...
    "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 모듈의 내부

: 드루팔 8.3.x에 대한 흥미로운 문제가있어 개발 모듈 설정 수출을 거부 할 수 있도록 허용는 . 일반적인 의견은 구성 분할 이 현재 최상의 솔루션이라는 것입니다.

swentel의 댓글 :

config_split의 작동 방식을 간단히 설명하고 싶었습니다. config split config 엔티티는 차단 된 대상을 정의하여 모듈 및 / 또는 구성 객체를 차단할 수 있습니다. 정식 예제 인 devel은 이미 흥미로운 유스 케이스를 가지고 있습니다 : system.menu.devel과 함께 제공됩니다 .devel을 블랙리스트에 올리면 메뉴 구성 파일은 종속성이 없으므로 제거되지 않습니다. 큰 문제는 아니지만 구성 분할을 사용하면 개별적으로 선택할 수 있으므로 환경에서 제거됩니다.

geerlingguy의 댓글 :

환경 특정 구성을 관리하는 몇 가지 다른 방법을 시도했지만 config_split은 지금까지 최고의 사용률과 추가 오버 헤드 균형을 올바르게 사용하는 것으로 보입니다. 간단하고 가벼우 나 특정 환경에서만 특정 구성을 표시하고 계속 사용할 수 있습니다.

구성 분할 은 일부에게는 실용적인 솔루션 일 수 있습니다.

Drupal 8 구성 관리는 전체 사이트 구성 세트를 가져오고 내보낼 때 가장 잘 작동합니다. 그러나 개발자는 CM의 견고성을 선택하지 않고 개발 시스템에서 활성화 된 수퍼 구성을 보유하고 하위 집합 만 배포하는 경우가 있습니다. 이에 대한 일반적인 예는 개발 환경에서 devel 모듈을 사용하도록 설정하거나 블록 배치 또는 뷰를 몇 개 배치 한 다음 배치 할 구성 세트로 내 보내지 않고 여전히 개발 구성을 동료와 공유 할 수있는 것입니다.

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

이 작업을 수행하는 깔끔한 방법이 있습니다. 편의를 위해 작곡가에 헌신 한 dev 모듈로 끝나고 해당 모듈의 구성이 구성 내보내기에 추가되지 않습니다 (2 부분이 있음).

1. Composer에는 --dev 가 필요 합니다 개발을위한 모듈을 활성화 할 때는 --dev 플래그를 사용하십시오.

$ composer require --dev drupal/devel

이로 인해 이러한 종속성이 require-dev 아래 composer.json 파일에 추가됩니다.

...
    "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. 스테이징 구성 (개발 및 스테이징에서 사용 가능)- 리 라우트 이메일 모듈 포함
3. Dev config-개발, 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.settings가 변경되어 피곤하십니까?

이를 위해 배치 대체 모듈을 사용할 수 있습니다. 자세한 설명은 다음 링크를 읽으십시오.

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