Как настроить default.settings.php, чтобы использовать его для разработки, тестирования и производства сайтов?

8

Я использую среды dev , tst и prd для настройки своего сайта в Drupal 7. Я использую Git для контроля версий.

Я хотел бы исключить один ручной шаг, который мне нужно сделать при перемещении сайта с dev на tst и с tst на prd .

Теперь я должен обновить settings.php отдельно для сайтов dev, tst и prd.

Я хотел бы настроить файл default.settings.php, чтобы все настройки для dev, tst и prd были сохранены в одном файле default.settings.php и. после копирования в settings.php, Drupal выберет правильные настройки в зависимости от среды.

Я ищу что-то вроде псевдокода ниже:

common.settings 

if environment = dev then
   ...
   dev.settings
   ...
else if environment = tst then
   ...
   tst.settings
   ...
else if environment = prd then
   ...
   prd.settings
   ...
end if

Вы точно знаете, как это сделать для Drupal 7?

Refineo
источник

Ответы:

11

Не используйте тот же файл настроек, который вы предлагаете в псевдокоде. Вместо этого используйте три разных файла настроек в трех разных папках, каждая папка соответствует имени домена каждого из ваших экземпляров.

Как минимум, как правило, каждая среда будет использовать отдельный хост базы данных. Другие параметры, которые могут отличаться от среды к среде, могут включать хост Apache Solr, настройки memcached, временную папку и папку с файлами. Вы можете разместить все это там. Когда вы переносите базу данных из PROD в TEST в DEV, она автоматически выбирает указанные вами настройки.

Представьте, что мой сайт называется myfoobarsite.com. Вот как будет выглядеть моя структура настроек:

/htdocs
../sites
..../default
....../default.settings.php
..../dev.myfoobarsite.com (DEV)
....../settings.php
..../qa.myfoobarsite.com (TEST)
....../settings.php
..../myfoobarsite.com (PROD)
....../settings.php

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

/htdocs
../sites
..../default
..../dev.myfoobarsite.com (DEV)
..../qa.myfoobarsite.com (TEST)
..../myfoobarsite.com (PROD)
..../mfbs.local (LOCAL ONE)
....../settings.php
..../mfbs2.local (LOCAL TWO)
....../settings.php

Что касается ваших локальных экземпляров, не забудьте сделать соответствующие записи в /etc/hostsфайле и изменить настройки хоста Apache.

На всякий случай я также поместил фрагмент из settings.php для руководства:

<?php
$databases['default']['default'] = array(
    'database' => 'myfoobarsite',
    'username' => 'foo',
    'password' => 'bar',
    'host' => '127.0.0.1',
    'port' => '3306',
    'driver' => 'mysql',
    'prefix' => '',
);

/**
 * Apache Solr settings.
 * Use the acquia_identifier/acquia_key when hosting w/ Acquia.
 * Specify only the apachesolr_path key for your local instance
 * or instances that do not use Acquia.
 */
//$conf["acquia_identifier"] = "ABCD-12345";
//$conf["acquia_key"] = "1234f05ab12345dc1234a1234bbc1c12";
$conf["apachesolr_path"] = "http://localhost:8983/solr";

/**
 * Filesystem settings (MAC OS X, LOCAL)
 */
$conf["file_public_path"] = "sites/default/files";
$conf["file_temporary_path"] = "/Users/amateurbarista/tmp";
$conf["file_private_path"] = "/Users/amateurbarista/Sites/tfk/private";

Наконец, если вы используете хостинг с Acquia, вам нужно будет переходить http://myfoobarsite.com/admin/config/system/acquia-agentи нажимать «очистить ключи» каждый раз при переносе базы данных. Это заставит Drupal отбросить ключи, которые пришли с импортированной базой данных, и забрать те, которые указаны в файле настроек.

любитель бариста
источник
Я, наверное, упускаю суть, но как это лучше, чем псевдокод в вопросе?
Рэнделл
1
Конфиденциальность, безопасность, микроуправление. Размещение параметров в разных файлах позволяет разным ролям (локальный разработчик, системный администратор) иметь разные разрешения для разных файлов. Системный администратор также может запретить доступ к настройкам prod / qa / dev, используя мое предложение, в то время как местный разработчик всегда сохраняет свои локальные настройки. Также сложнее все испортить, с подходом «все в одном файле», проще испортить всю вашу среду сразу. С моим предложением вы даже можете настроить разные модули для каждого сайта.
бариста-любитель
0

Вы также можете использовать модули среды, которые позволяют использовать разные модули для каждой среды.

инструкции

Во-первых, вам нужно настроить свои dev / staging / production сайты с их собственными уникальными settings.php (для этого обычно требуется settings.local.php из settings.php). Если у вас нет такой настройки, то вам не нужен этот модуль.

Для staging / dev добавьте что-то вроде этого в settings.php, после того как environment_modules включены, эти модули также будут включены.

Например

$conf['environment_modules'] = array(
  'devel' => 'sites/all/modules/devel/devel.module',
);

Вы также можете использовать один файл settings.php, используя следующий пример:

$env = $_ENV['AH_SITE_ENVIRONMENT']; // Acquia way: environment name
$env = $_SERVER['SERVER_NAME']; // or your server name, or whatever
$envModules = array(
    'default' => array( // By default it is development environment
      'devel' => 'sites/all/modules/contrib/devel/devel.module',
      'coder_review' => 'sites/all/modules/contrib/coder/coder_review/coder_review.module',
    ),
    'dev' => array(
      'devel' => 'profiles/mp_singapore/modules/devel/devel.module',
      'coder_review' => 'sites/all/modules/contrib/coder/coder_review/coder_review.module',
    ),
    'test' => array(
      'diff' => 'sites/all/modules/contrib/diff/diff.module',
    ),
    'prod' => array(
      'diff' => 'sites/all/modules/contrib/diff/diff.module',
    ),
);
$conf['environment_modules'] = $envModules[$env] ?: $envModules['default'];
kenorb
источник
Нет версии d8 этого модуля до даты.
Вишал Кумар Саху