Конфигурация, которая не разъезжается
maxicfg — утилита командной строки из одного бинарника. Проверяет конфигурационные файлы по схеме, рендерит шаблоны и показывает расхождения между окружениями до того, как они доедут до продакшена.
Быстрый старт
Проверить все конфигурационные файлы в каталоге по схеме:
$ maxicfg lint ./config --schema ./config/schema.yaml
config/production.yaml ok
config/staging.yaml ok
config/local.yaml 2 problems
local.yaml:14:3 unknown key "databse.pool_size" (did you mean "database"?)
local.yaml:31:1 required key "logging.level" is missing
1 of 3 files failed
Сравнить два окружения и увидеть только реальные различия:
$ maxicfg diff config/staging.yaml config/production.yaml --ignore-secrets
~ database.pool_size 10 -> 40
~ cache.ttl 5m -> 1h
+ features.new_billing true (only in production)
- debug.profiler true (only in staging)
4 differences, 27 keys identical
Проверка по схеме
Опечатки, пропущенные ключи и неверные типы ловятся до деплоя, а не после.
Поиск расхождений
Сравнение окружений показывает конфигурацию, которая незаметно разъехалась.
Шаблонизация
Рендер конфигов из шаблонов с переменными окружения и значениями по умолчанию.
Поиск секретов
Находит учётные данные, случайно попавшие в конфигурационные файлы.
Зачем ещё одна утилита для конфигов
В большинстве проектов со временем накапливается несколько почти одинаковых конфигурационных файлов — по одному на окружение, — которые постепенно расходятся. Ключ добавили в staging и забыли перенести в production. Значение подкрутили во время инцидента и нигде не записали. Через полгода никто не может сказать, какой файл правильный.
maxicfg не пытается заменить систему управления конфигурацией. Он читает те файлы, которые у вас уже есть, показывает, где они расходятся, и роняет сборку, когда что-то выглядит неправильно. На этом область задач заканчивается.
Статус: версия ниже 1.0. На практике интерфейс командной строки стабилен, но флаги ещё могут меняться между минорными версиями. В CI фиксируйте версию — см. установку.