Как правильно хранить конфиги на продакшене?

Question

[NOONE]

Привет кто сталкивался с такой проблемой, нужно реализовать контроль версий конфиг файлов, больше это нужно для реализации бекапов, например есть много конфигов для nginx, нужно иметь всегда зеркало этих конфигов т.к местами конфиги очень трудные и при исправлении/добавлении какого-то функционала легко можно что ни будь сломать, нужно возможность оперативно выкачать пред версию конфига, ну и есть конфиги разных приложений которые тоже желательно иметь в зеркале с контролем версий, как это можно релизовать? Кто сталкивался с такой задачей поделитесь мыслями, спасибо.
UPD имею представление о git и github с другими системами контроля версий не имел дела

Answer 1

[Saboteur]

Конфиги nginx позволяют делать include, поэтому можете все sensitivity данные выложить в отдельный файлик, и добавить его в .gitignore, а остальное можно и в гите хранить (но лучше не гитхаб, а свой).

Стандартный велосипедный способ для конфигов - перед тем как поменять config.cfg делаешь
cp config.cfg config.cfg-yymmdd
можно и им обойтись.

Comments

[NOONE]

Я вот как раз и делаю последним способом, но бывает в спешке хоп забыл и что-то сломалось)

[Saboteur]

NOONE: Напишите скрипт, который копирует все конфигурационные файлы по ночам, храните последние 30 дней, или хоть все - конфиги мало места занимают, и забудьте про забываемость.
Можно даже делать так, что на месте у вас лежит два файла
config.cfg
config.cfg.nightly

или
etc/nginx/
etc/nginx.nightly/

А в отдельной папке уже архивы по датам. При этом пришли, поправили, и всегда под рукой оригинал для diff без лишних телодвижений.

[NOONE]

Saboteur: Спасибо, я так и планировал делать, думал может есть какое-то более лучшее решение, спасибо за ответ

[Алексей Шумкин]

NOONE:
>Я вот как раз и делаю последним способом, но бывает в спешке хоп забыл и что-то сломалось)
зачем ТАК, если есть Git, который делает ровно то же, только удобнее?
и чем хранение sensitive data в SCM-репозитории отличается от хранения кучи файлов с датами в имени?

[Saboteur]

Потому что git не позволяет удалить какую-либо ревизию, а данные - sensitive.
Хранить гит только локально - ну можно, но пихать его везде где ни попадя - не есть гуд. Не везде можно поставить git.

Answer 2

[aol-nnov]

правильный ответ - не хранить конфиги с секретами в системе контроля версий.

ты можешь сделать так, чтобы конфиг из гита предоставлял т.н. "sensible defaults", а все секреты будут переопределены вторым конфигом, который подложит система деплоя.
Это про твои приложения.

про управление конфигурациями узлов (контуперов, то бишь), кошерно использовать системы управления конфигурацией - ansible, salt и пр.
Из наколеночного есть etckeeper, например

Answer 3

[huwesu]

Любая современная развитая система контроля версий
git, mercurrial...

Как верно заметили - ключи и пароли хранить отдельно от конфигов.

Answer 4

[voronkovich]

Помимо уже указанного выше, почитайте про 12-факторные приложения, там ключи и пароли рекомендуется конфигурировать через переменные окружения. 12factor.net/config
Соответственно, сами конфигурации, можно хранить в системе контроля версий.

Answer 5

[CityCat4]

VCS - наше все :) Тип выбираете по вкусу - централизованные, распределенные... Единственное что, как верно заметили - не хранить ключи, пароли, никакой такой информации.

Answer 6

[Philipp]

Конфигурацию нужно хранить в VCS, например на том же github или gitlab. Лично я бы рекомендовал GitHub, если ваш проект не подпадает под гос.тайну или не является системой управления ядерным реактором. В остальных случаях код можно хранить на GitHub. Даже Microsoft хранит свой код на нем.

Для хранения ключей и т.д. нужно использовать решения вроде Vault.