Допустим помещаю на Github репозиторий сайта.
Потом, на другом сервере:
cp -R myrepo/* .
rm -rf myrepo/
composer install
А если у меня в файлы settings.php, robots.txt, .htaccess исправлены, как сделать чтобы на новом сервере эти изменения не пропадали? Ну и при composer update файлы robots.txt и .htaccess не затирались.
Комментарии
Мы у нас в компании приняли решение добавлять settings.php в репозиторий, но хранить там только общие параметры для всех окружений. Например
include $app_root . '/' . $site_path . '/settings.local.php';
}
$config_directories['sync'] = '../config/sync';
$settings['skip_permissions_hardening'] = TRUE;
А специфичные параметры (подключение к БД, trusted_host_patterns, config_split) хранить в settings.local.php, который в репозиторий не добавляется. Преимущества этого подхода в том, что если нужно добавить новый параметр для всех окружений, то не нужно бегать по всем серверам и править settings.php. Достаточно добавить эти изменения в гит, остальное сделает CI
По поводу robots.txt и .htaccess. У нового скаффода есть такие параметры:
"locations": {
"web-root": "web/"
},
"file-mapping": {
"[web-root]/.htaccess": false
}
},
Так вот всё что будет добавлено в file-mapping, не будет перезаписываться скаффолдом. Следовательно, если добавить эти файлы в репозиторий, то они будут и деплоиться и не будут перезатираться при обновлении ядра
Распаковал репозитоиий с гитхаба на новом сервере. Выполнил composer install.
Файл
web/sites/example.settings.local.php
переименовал в
web/sites/settings.local.php
В файле
web/sites/default/settings.php
раскомментировал:
include $app_root . '/' . $site_path . '/settings.local.php';
}
Утановил Друпал. При установке указал имя пользователя и БД. Почему оно прописалось в settings.php? Должно же прописаться в settings.local.php. Или я не прав?
1. settings.local.php лучше делать чистым, без "левых" параметров. Только то, что нужно этому сайту
2.
Потому что, если ядро не обнаружило в settings.php или в settings.local.php параметров доступа к БД, то оно запросит их при установке и пропишет в settings.php
Чтобы этого не происходило, достаточно перед установкой вписать параметры подключения к БД в settings.local.php вручную
Round II - Fight!
Не получается
Скопировал
web/sites/default/default.settings.php
в
web/sites/default/settings.php
Раскомментировал в нем:
include $app_root . '/' . $site_path . '/settings.local.php';
}
Создал чистый файл settings.local.php, в нем прописал:
$databases['default']['default'] = array (
'database' => 'twodrupal',
'username' => 'twodrupal',
'password' => 'twodrupal',
'prefix' => '',
'host' => 'mariadb',
'port' => '3306',
'namespace' => 'Drupal\\Core\\Database\\Driver\\mysql',
'driver' => 'mysql',
);
Результат: при обращении к сайту происходит устновка Дрпуала, где предлагется ввести пароль к БД. Эти данные переносятся в web/sites/default/settings.php.
Что не так?
Значит что-то не так. Проверь и права доступа на всякий случай
Та вроде на Докере права не играют так сильно. Ошибся в
а надо было в web/sites/deafault/settings.local.php
Этот вариант нормальный (?):
settings.php (игнорируется git) - тут настройки соединения с БД и то что Друпал прописывает по умолчанию при устновке
settings.local.php (попадает в репозиторий) - тут специфические параметры типа:
$settings['file_public_path'] = 'files';
Нужно подправить немного файл .gitignore
Давай уже, начинай потихоньку сам думать)
Подправлю .gitignore. Уберу оттуда
/web/sites/*/settings.local.php
Вариант сверху нормальный?
Я пока принял, подключение к БД прописывать в settings.php, а настройки файловой системы в settings.local.php. Не вижу причин против. Как понимаю варирование этих параметров не принципиально.
Дак а ты будешь деплоить settings.php или нет?
Получается, что не буду.
На разных серверах же разные параметры подключения к БД. Поэтому settings.php будет разным. А настройки файловой системы - это уже не от сервера зависит, поэтому settings.local.php будет на разных серверах одинаковым.
Что не так?
Ты совсем не читаешь что я пишу. Именно потому что параметры БД везде разные их и выносят в settings.local.php
А одинаковым должен быть settings.php
Всё наоборот ты понял, кароч
Я читаю, просто не понимаю, почему нельзя наоборот: settings.php разный, а settings.local.php одинаковый? Работает же.
Можно. Но по логике названия файла LOCAL означает, что это файл локальный для этого сервера, то есть со специфичными параметрами
Спасибо!
Раз можно - хорошо. Не буду зацикливаться над тем что для меня пока не постижимо.
Можно и штаны через голову надевать)
Просто, когда я устанавливаю Дрпуал на новый сервер и при установке указываю параметры соединения с БД - я вижу что они прописываются в settings.php
Если этого не происходит, значит на сервере ошибка.
А когда руками в файле прописывать соединение с БД - я не могу оперативно выявить эти ошибки.
Потому что не надо устанавливать друпал на новый сервер. Нужно устанавливать его на локалке в докер, где параметры подключения к БД по умолчанию для всех контейнеров и поэтому их сразу можно вписать в settings.local.php
У тебя workflow неправильный, потому и ты логику мою не понимаешь
По поводу вопроса settings.php vs settings.local.php. В самом простом случае есть только два основных параметра, без которых ничего не будет работать - это доступ к базе и hash salt. И вот в таком случае вообще нет никакой нужды заводить отдельно settings.local.php, в котором будут переопределены все параметры.
settings.local.php нужен тогда, когда в settings.php значительно больше настроек и большая часть из них на локалке и продакшене одинаковые, но часть различается. Тогда одинаковые настройки остаются в settings.php, а разные идут в локал.
Если же лепить локал всегда и без разбору, то получается, что settings.php будет сам по себе практически пустой - он будет только инклюдить локал. Получается, что ты добавляешь лишний файл только ради того, чтобы он был.
PS: есть ещё один вариант, когда в репозитории лежат одновременно settings.local.php, settings.production.php и т.д. и инклюдятся в зависимости от переменной среды. Но это удобно, когда у тебя и локально, и в продакшене стоит докер, плюс настроена CI/CD-система, которая сама прогоняет тесты в своём окружении и ей надо откуда-то брать доступы к тестовой базе. Если же ты не запускаешь автоматические тесты, то вообще не вижу никакого смысла держать в репозитории доступы к базе.