Избегайте конфигурации сервера жесткого кода

Question

Я работаю над приложением Rails, и я собираюсь открыть его с открытым исходным кодом.

Я развертываю его на сервере VPS, настроенном на nginx и единороге, после this RailsCast.

Для того, чтобы получить Capistrano, Nginx и единорог работает должным образом, я должен был добавить некоторые файлы конфигурации сервера в моей config/ папке, такие как deploy.rb, nginx.conf, unicorn.rb и unicorn_init.sh.

Я работаю с хранилищем git, и все работает под веткой master. Другими словами, Капистрано вытащил его, чтобы развернуть на сервере, а также это филиал, который я собираюсь открыть с открытым исходным кодом.

Однако я не хочу, чтобы мои файлы конфигурации сервера были общедоступными.

Какое оптимальное решение?

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

Или было бы лучше установить параметры конфигурации в качестве переменных среды и оставить файлы конфигурации в репозитории?

Answer 1

Это решение - лучшее, что я нашел для этой проблемы (и тот, который я лично использую).

Вы должны поместить свои файлы конфигурации в

/path/to/deployed_app/shared 

Тогда в задаче Капистрано, создать ссылки на эти файлы:

namespace :deploy do 
    task :symlink_shared do 
    run "ln -s #{shared_path}/database.yml #{release_path}/config/" 
    end 
end 

before "deploy:restart", "deploy:symlink_shared" 

Answer 2

я сделал так, но так как это не так сексуально выглядеть для переменных env, я закончил:

• , имеющий сырой файл yml, чтобы дать ожидаемый формат в моем репо (named lik е config.yml_example)

• , имеющие действительные yml файлы на моем сервере в слинкован каталоге

Answer 3

Вы все еще можете просто открыть источник тока хранилище, если вы хотите, если вы не хотите, чтобы это было под другим именем, таких как организации, которая будет принимать (т.е. рельсы/рельсы). Помимо этого вы захотите удалить эти файлы из истории git, так как это похоже на то, что вы не хотите, чтобы они были общедоступными, для получения более подробной информации: https://help.github.com/articles/remove-sensitive-data.

Лучший способ достичь с помощью этих конфигураций, чтобы настроить общую папку на сервере, который затем слинкован см: Where do you put your app-config-files when deploying rails with capistrano and svn

Answer 4

Не ставьте свои конфигурационные файлы под контролем версий. Вместо этого создайте стандартные или примерные версии с суффиксом имени файла .dist и поместите исходные имена файлов в .gitignore, чтобы предотвратить случайную загрузку. Затем пользователь должен скопировать myconfig.conf.dist по номеру myconfig.conf перед запуском приложения.

Преимущества

• не случайно загрузка конфигурации
• нет конфигурации конфликтов на git pull, когда восходящие файлы конфигурации изменяются
• не случайно изменение конфигурации на git pull
• пользователь не может забыть адаптироваться конфигурация после git clone

Недостатки

• добавляет дополнительный шаг для пользователя перед началом или развернуть
• должны быть задокументированы в риом, так что пользователь знает об этом
• пользователей, которые не читать readme может все еще пропустить это и задаться вопросом, почему приложение не работает.

PS: Это не Rails, но мой подход подходит для всех элементов управления версиями приложений с конфигурационными файлами.