Как управлять конфигурационными файлами версии?

Question

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

database_password=secret 
foo=bar 

становится

database_password=* 
foo=bar 

и другие пользователи ДУС могли бы также установить пароль на них самостоятельно. Чтобы игнорировать файл, это не очень хороший подход, разработчики должны знать, изменяется ли файл конфигурации.

Пример:

Локальная версия:

database_password=own_secret 
foo=bar 

конфигурационный файл в VCS:

database_password=* 
foo=bar 

Затем внезапно, изменения конфигурационных файлов:

database_password=* 
foo=bar 
baz=foo 

И местные версия будет ome для каждого разработчика:

database_password=own_secret 
foo=bar 
baz=foo 

Это мое решение. Как я мог добиться такого поведения? Как сохранить файлы конфигурации? Есть ли способ сделать это, или я должен что-то взломать?

Answer 1

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

Также see my answer похожий вопрос.

Answer 2

В моих проектах я использую каталог, в котором хранятся эти файлы, но он не загружается на сервер, поэтому мой конфигурационный файл db находится в этом каталоге и настроен для сервера, на котором размещен проект. Если кто-то изменит конфигурационный файл, он изменит конфигурационный файл сервера, и любой обновляющий ревизия увидит изменения в этом файле и ему придется вручную изменить его локальную конфигурацию.

Я не вижу способа сделать это, а не этого. Если вы найдете другой подход, пожалуйста, поделитесь.

Answer 3

У вас есть отдельный файл с ТОЛЬКО секретами, которые не находятся под контролем версии?

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

Answer 4

Я привык сделать txt-файл его со структурой конфигурационного файла. После этого я сделаю копию и изменю расширение, и пусть моя система контроля версий проигнорирует этот файл (ы).

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

Answer 5

Не знаете, как ваша конфигурация реализована, но с иерархическими переопределениями я бы справился с этим.

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

Я сделал это в .NET, но не PHP, поэтому не знаю, насколько это легко, я боюсь.

Answer 6

Что относительно крючка предварительной фиксации для удаления чувствительных полей? Это предполагает, что вам удобно отправлять файл по сети в первую очередь, конечно.

Обновления для другого конца задачи:
Для обработки обновления, вы либо хотите, чтобы заставить ручное слияние чувствительных файлов или изменить локальный процесс сборки, чтобы перезаписать чувствительные линии с содержимым с локальным/private/ignored file.

Answer 7

У меня было что-то похожее на это, хотя я не знаю, будет ли это работать для вас. У меня был каталог, содержащий файлы, содержащие пароли. Этот каталог не контролировался версией. Файлы были названы в честь приложений, которые использовали их и в файлах конфигурации, я «получил» соответствующий файл пароля в той точке, в которой это было необходимо. Это потребовало бы, чтобы ваш парсер конфигурации мог обрабатывать источники.

Answer 8

Создайте локальный файл переопределений, содержащий информацию о пользователе как переменные PHP.

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

$local_password = 'qUzaEAFK13uK2KHy'; 

Затем в файле, который включает в себя ваш DB пароля сделать что-то вроде этого

$overrides = 'local_overrides.php'; 

if (file_exists($overrides)) { 
    #include_once($overrides); 
    $db_password = $local_password; 
} else { 
    // perform appropriate action: set default? echo error message? log error?  
    $db_password = 'l1m1t3d!' 
} 

местного файла коррекция будет никогда не должен быть замечен контролем источника.

Answer 9

Мой предпочтительный ответ на этот вопрос уже упоминался здесь: проверьте фиктивный файл, сгенерируйте «реальный» файл, скопировав фиктивный файл во время выполнения и проигнорируйте «настоящий» файл в вашем VCS.

я уже отвечал на подобный вопрос, с полным пример того, как сделать это в Visual Studio:
how to ignore files in kiln/mercurial using tortoise hg "that are part of the repository"