Современный подход к организации конфигурационных файлов

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

Но современный подход как раз таки и подразумевает дублирование опций, возможно даже многократное.

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

Некоторые системы прямо подразумевают такой подход, например, systemd, которая категорически не рекомендует править вручную стандартные юниты, а предлагает воспользоваться технологией drop-in.

Аналогичную схему предлагает и Fail2ban, а так или иначе подобный подход поддерживают очень и очень многие приложения.

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

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

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

После чего у вас есть нелегкий выбор: или оставить все как есть, или принять новый конфиг и потерять все свои настройки. Ну еще можно заморочиться и попробовать смержить конфиги вручную.

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

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

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

Отдельный толчок в этом направлении дала контейнеризация и докеризация, контейнер Docker неизменяем, мы можем его убить, перезапустить, обновить на новый, и т.д. и т.п. не затрагивая пользовательские данные. За это его и любят.

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

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

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

Также мы можем смело обновляться и получать новые функции, исправления и т.д. и т.п. не боясь потерять свои настройки, все ваши настройки в отдельном файле.

P.S. Алиса - художник, она так видит. Но в целом картинка в тему.