Пока выписал свои рассуждения. Предлагаю здесь сохранить инфу о конфигурировании. Это может быть важной отправной точкой в построении Ansible скриптов для разворачивания системы.
Вот какой код нуждается во внешней «настройке»:
скрипты, используемые для автоматизации — импорт данных #3, отключатор #4, возможно какие-то другие скрипты;
тесты — им нужны параметры соединения;
модуль редиректов на Rust — ему нужен Rocket.toml хранящий конфиг с путём к Databus'у.
У нас нет единого соглашения о том что передавать в параметрах, а что хранить в отдельном конфиге.
В тоже время, нам необходима гибкость, а именно:
чтобы при деплое в продакшен, в локальное девелоперское окружение, на CI можно было легко настраивать конфигурацию всех модулей
хочется чтобы одна среда имела единую конфигурацию. Грубо говоря у нас есть файлики dev, prod, travis где хранятся все-все параметры необходимые при запуске всех модулей системы в целевом окружении
у нас имеется несколько окружений, даже когда система находится в продакшене: окружение сервера редиректов + окружение рабочего места арбитражника (GUI, Clickhouse, скрипты настройки кампаний и офферов для модуля редиректов)
если к серверу редиректов мы можем предъявить жёсткие требования, то для рабочего места они должны быть более «мягкими» — скрипты автоматизации могут выполняться на сервере или на рабочем месте арбитражника в ходе тестовых «прогонов» настроек и кампаний; импорт данных может выполняться в любой инстанс Clickhouse (как на сервере, так и на рабочем месте)
тестам нужна настройка тестовых соединений (Redis URL, Clickhouse URL) и передавать их проще всего через переменные окружения.
Пока выписал свои рассуждения. Предлагаю здесь сохранить инфу о конфигурировании. Это может быть важной отправной точкой в построении Ansible скриптов для разворачивания системы.
Вот какой код нуждается во внешней «настройке»:
У нас нет единого соглашения о том что передавать в параметрах, а что хранить в отдельном конфиге.
В тоже время, нам необходима гибкость, а именно: