Comments 4
Добрый день. Спасибо за статью.
Такой вопрос - что Вы имели ввиду написав ?
Отмечу, что мы имеем две точки пользовательского конфигурирования — inventory и пользовательский конфигурационный файл.
Добрый день. В файле inventory пользователи могут задавать имена хостов, креды для подключения к ним, их количество. А вот непосредственно управлять включением и настройкой той или иной функциональности возможно через пользовательский конфигурационный файл в yml формате. Ключи, отвечающие за ту или иную функциональность, в случае если пользователя не устраивают их значения по умолчанию, можно переопределить в этом файле, после чего передать путь до него при запуске одного из наших плэйбуков. Более подробно вся информация описана в том числе в нашей документации.
Второй вопрос - как вы реализовали
При разработке метода обновления мы придерживались подхода, где обновление только обновляет (но не исправляет и не переконфигурирует СУБД и компоненты).
при обновлении пакетов ОС (кастомные конфиги сформированные ansible при таких манипуляциях перетираются значениями по умолчанию из пакета)?
Мы не настраиваем конфигурационные файлы пакетов самой ОС, так как в этом нет необходимости. В том числе при обновлении наших компонентов (pangolin-dbms, pangolin-manager и тд), соответствующие им конфигурационные файлы сохраняют все пользовательские значения, которые были до обновления.
Как мы автоматизировали обновление, развёртывание и настройку Postgres-like СУБД для пользователей