Re[4]: лучшие практики для настроек-конфигов приложения..
От: Ночной Смотрящий Россия  
Дата: 29.03.21 09:11
Оценка: +1 -1
Здравствуйте, IT, Вы писали:

IT>Здрасти. Велосипеды — это наше всё! Лучше своя хорошо контролируемая самоделка, которую в любой момент можно переделать в любую сторону, чем рукожопный кусок непонятно чего с гитхаба. На то, что у меня уходит до недели работы, я предпачитаю велосипедить сам. Потом меньше проблем.


У меня опыт прямо обратный. Почти всегда велосипеды — не едут.

IT>Что касается РСУБД, то это вопрос философский. Когда это только делалось я сам вопрошал коллег а нужна ли здесь СУБД? Как часто мы меняем настройки между релизами? Решили, что пусть будет. А вдруг. Хотя за всё время эксплуатации системы не припомню, чтобы это делалось. Хотя я не уверен.


Тем не менее есть готовые решения, например Consul, в которых много pain points заранее предусмотрено.

IT>Про json не понял. Ты предлагаешь не генерировать класс, а каждый раз парсить json или наоборот?


Предлагаю в данном случае code first.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[5]: лучшие практики для настроек-конфигов приложения..
От: IT Россия linq2db.com
Дата: 29.03.21 13:52
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>У меня опыт прямо обратный. Почти всегда велосипеды — не едут.


Тут как бы всё очевидно. Чем больше зависимостей у тебя в проекте, тем больше ты от них зависишь. Ты зависишь от их багов, кривых конфигураций, кособоких API, причуд разработчиков и т.п.

НС>Тем не менее есть готовые решения, например Consul, в которых много pain points заранее предусмотрено.


Консул это тут? Если да, то оно вообще для чего? Там про какой-то порт Go для HTTP API. Ты предлагаешь мне ради пары побочных функций тащить это всё в свой проект?

IT>>Про json не понял. Ты предлагаешь не генерировать класс, а каждый раз парсить json или наоборот?

НС>Предлагаю в данном случае code first.

Тут вопрос деплоймента. БД у нас деплоится отдельно. json в данном случае выступаетв в качестве golden source для генерации как SQL, так и кода. А так согласен, если бы БД была не нужны, то можно было бы сделать простенький репозиторий настроечных параметров.
Если нам не помогут, то мы тоже никого не пощадим.
Re[6]: лучшие практики для настроек-конфигов приложения..
От: Ночной Смотрящий Россия  
Дата: 29.03.21 15:47
Оценка:
Здравствуйте, IT, Вы писали:

НС>>У меня опыт прямо обратный. Почти всегда велосипеды — не едут.

IT>Тут как бы всё очевидно. Чем больше зависимостей у тебя в проекте, тем больше ты от них зависишь. Ты зависишь от их багов, кривых конфигураций, кособоких API, причуд разработчиков и т.п.

Если следовать этой логике — надо начинать со своей ОС или сразу процессор свой проектировать?

НС>>Тем не менее есть готовые решения, например Consul, в которых много pain points заранее предусмотрено.


IT>Консул это тут?


Нет. Это https://www.consul.io/

IT>>>Про json не понял. Ты предлагаешь не генерировать класс, а каждый раз парсить json или наоборот?

НС>>Предлагаю в данном случае code first.
IT>Тут вопрос деплоймента. БД у нас деплоится отдельно. json в данном случае выступаетв в качестве golden source для генерации как SQL, так и кода.

Почему он, а не дотнетный класс? Ну а генерация скриптов это следствие выбора РСУБД для хранения конфигов, а не исходное требование.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[7]: лучшие практики для настроек-конфигов приложения..
От: IT Россия linq2db.com
Дата: 29.03.21 16:06
Оценка: 1 (1)
Здравствуйте, Ночной Смотрящий, Вы писали:

IT>>Тут как бы всё очевидно. Чем больше зависимостей у тебя в проекте, тем больше ты от них зависишь. Ты зависишь от их багов, кривых конфигураций, кособоких API, причуд разработчиков и т.п.

НС>Если следовать этой логике — надо начинать со своей ОС или сразу процессор свой проектировать?

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

НС>>>Тем не менее есть готовые решения, например Consul, в которых много pain points заранее предусмотрено.


IT>>Консул это тут?

НС>Нет. Это https://www.consul.io/

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

IT>>Тут вопрос деплоймента. БД у нас деплоится отдельно. json в данном случае выступаетв в качестве golden source для генерации как SQL, так и кода.

НС>Почему он, а не дотнетный класс?

Потому что json парсить проще, чем дотнетный класс.

НС>Ну а генерация скриптов это следствие выбора РСУБД для хранения конфигов, а не исходное требование.


Об этом я уже сказал.
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: лучшие практики для настроек-конфигов приложения..
От: Ночной Смотрящий Россия  
Дата: 29.03.21 18:51
Оценка:
Здравствуйте, IT, Вы писали:


IT>>>Консул это тут?

НС>>Нет. Это https://www.consul.io/
IT>Таже фигня, если не хуже. Ради мелкой задачки тянут в проект неизвестную науке пое...хрень.

Ну это еще большой вопрос насколько она мелкая. Потому что когда в проект приходит пачка деплойментов, всякие SOC-сертификации и прочая — все становится намного веселее и велосипеды начинают припадать на оба колеса.

IT>>>Тут вопрос деплоймента. БД у нас деплоится отдельно. json в данном случае выступаетв в качестве golden source для генерации как SQL, так и кода.

НС>>Почему он, а не дотнетный класс?
IT>Потому что json парсить проще, чем дотнетный класс.

А зачем парсить дотнетный класс, если можно воспользоваться уже отпарсеным компилятором в сборке?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[9]: лучшие практики для настроек-конфигов приложения..
От: IT Россия linq2db.com
Дата: 29.03.21 18:59
Оценка: 1 (1)
Здравствуйте, Ночной Смотрящий, Вы писали:

IT>>Таже фигня, если не хуже. Ради мелкой задачки тянут в проект неизвестную науке пое...хрень.

НС>Ну это еще большой вопрос насколько она мелкая. Потому что когда в проект приходит пачка деплойментов, всякие SOC-сертификации и прочая — все становится намного веселее и велосипеды начинают припадать на оба колеса.

А если не приходит? Или если не приходит, то надо сделать так, чтобы пришли, иначе это уже неправильная система?

IT>>Потому что json парсить проще, чем дотнетный класс.

НС>А зачем парсить дотнетный класс, если можно воспользоваться уже отпарсеным компилятором в сборке?

Я могу и уже согласился с тем, что в случае отсутствия БД можно всё сделать в виде класса. Но не могу согласиться с тем, что ты лучше меня знаешь нужна мне в моей системе БД или нет. Или знаешь? Хотя это уже гордынькой попахивает
Если нам не помогут, то мы тоже никого не пощадим.
Re[10]: лучшие практики для настроек-конфигов приложения..
От: Ночной Смотрящий Россия  
Дата: 29.03.21 21:07
Оценка: -1
Здравствуйте, IT, Вы писали:

IT>А если не приходит?


Значит повезло.

IT>>>Потому что json парсить проще, чем дотнетный класс.

НС>>А зачем парсить дотнетный класс, если можно воспользоваться уже отпарсеным компилятором в сборке?
IT>Я могу и уже согласился с тем, что в случае отсутствия БД можно всё сделать в виде класса. Но не могу согласиться с тем, что ты лучше меня знаешь нужна мне в моей системе БД или нет.

Здесь вроде топик не про твою персональную систему, не?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[11]: лучшие практики для настроек-конфигов приложения..
От: IT Россия linq2db.com
Дата: 29.03.21 21:22
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

IT>>Я могу и уже согласился с тем, что в случае отсутствия БД можно всё сделать в виде класса. Но не могу согласиться с тем, что ты лучше меня знаешь нужна мне в моей системе БД или нет.

НС>Здесь вроде топик не про твою персональную систему, не?

С тех пор как я привёл код — про мою.
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: лучшие практики для настроек-конфигов приложения..
От: Kolesiki  
Дата: 30.03.21 13:47
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, Kolesiki, Вы писали:


K>>Потому что конфиг — это вообще не про код. Код должен быть в программе, а в конфиге — лишь "настроечные величины". Если ты налепил конфиг в виде кода, ты явно решил задачу левым путём. Времена ЛИСПа прошли и не потому, что ЛИСП устарел — он просто непригоден для надёжного ПО — как раз в силу идеи "данные как код".


Pzz>...[оффтопишная бредятина поскипана]

Pzz>4. Если конфигурация должна описывать некие действия (например, куда почтовый сервер должен отправить письмо, в зависимости от его параметров), то описание ее в виде инперативной "программы" может быть значительно удобнее, чем в виде декларативного набора правил.

Ещё один любитель получать граблями! Поясняю как в школе:

Если логика выбора сервера сложная, делается плагин (о чём я уже упомянул).
Если логика покрывается простыми регэкспами над хэдер-полями (что на 99% верно), то и в конфиге просто прописываем нужные RE!
Re[9]: лучшие практики для настроек-конфигов приложения..
От: Pzz Россия https://github.com/alexpevzner
Дата: 30.03.21 13:56
Оценка: +1
Здравствуйте, Kolesiki, Вы писали:

K>Если логика выбора сервера сложная, делается плагин (о чём я уже упомянул).

K>Если логика покрывается простыми регэкспами над хэдер-полями (что на 99% верно), то и в конфиге просто прописываем нужные RE!

Угу. В sendmail'е так и сделано
Впрочем, ты не знаешь, что такое sendmail...
Re[9]: лучшие практики для настроек-конфигов приложения..
От: Sinclair Россия https://github.com/evilguest/
Дата: 30.03.21 16:07
Оценка: 12 (1) +1
Здравствуйте, Kolesiki, Вы писали:
K>Ну так ты вообще про другое — ПРО ПЛАГИНЫ! К каждому из которых, прикинь, можно тоже поставлять конфиг простейших величин.
Я, наверное, плохо объяснил. Плагины — плагинами. Но "простейшие величины" быстро превращаются в сложную кашу типа "получи данные от плагина №4512, результат запиши в плагин №2145".
На первый взгляд мы всё ещё работаем с "простым плоским конфигом", но вот только резко растут шансы сделать ошибку — типа сослаться на несуществующй номер плагина, или получить кольцевую зависимость.

Я N+1 раз встречал на практике системы, в которых "конфиг" — это половина логики решения.
В итоге получается так, что программисты реализуют и выкатывают фичу за месяц, а эксплуатация её конфигурит на проде два месяца.
Потому, что у программистов есть средства проверки корректности их кода — от подсветки в редакторе, выхлопа компилятора, и до верификаторов и юнит-тестов, которые прогоняются автоматом.
А у эксплуатации всё, что есть — это какая-то каша из "простейших величин", с бесконечным количеством способов сделать в них незначительную ошибку, которую обнаружить можно будет только по тикетам в саппорт.

S>>Начиная от "запросы по адресам '/users/*'...


K>Местечковая галиматья. НЕТ у конфигов задачи "запросы по адресам". Это твоя бизнес-задача, решённая через одно неприличное место.

Правда что ли? Авторы nginx, iss, и apache с вами не согласны.
K>Ещё раз вернись в место, где про "простейшие величины" — вот конфиг — это оно. При всех порочных практиках, самое ужасное, что ты можешь сделать — позволить чему-то внешнему исполняться на хосте.

То есть, вы полагаете, что конфиги с "простейщими величинами" можно давать править кому угодно, а вот код — уже нет?
Я вот не вижу принципиальной разницы. Ну, то есть понятно, что будучи суперосторожным, можно так ограничить конфиг, чтобы злоумышленник не смог при помощи него сделать ничего опасного.
Но таких случаев — исчезающе мало. Даже выбор "на каком порту слушать" уже позволяет нам в определённых обстоятельствах организовать атаку.
Поэтому самое ужасное, что вы можете сделать при всех порочных практиках — это давать доступ до конфигурации тем, кому нельзя доверять.
А если у вас (как и у всех минимально вменяемых людей) доступ к конфигурации ограничен, то нет никакой разницы, класть туда "данные" или "код".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[10]: лучшие практики для настроек-конфигов приложения..
От: karbofos42 Россия  
Дата: 31.03.21 04:12
Оценка: 1 (1) -1
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Kolesiki, Вы писали:

K>>Ну так ты вообще про другое — ПРО ПЛАГИНЫ! К каждому из которых, прикинь, можно тоже поставлять конфиг простейших величин.
S>Я, наверное, плохо объяснил. Плагины — плагинами. Но "простейшие величины" быстро превращаются в сложную кашу типа "получи данные от плагина №4512, результат запиши в плагин №2145".
S>На первый взгляд мы всё ещё работаем с "простым плоским конфигом", но вот только резко растут шансы сделать ошибку — типа сослаться на несуществующй номер плагина, или получить кольцевую зависимость.

Это уже не конфиг, а обмен данными какой-то.

S>Я N+1 раз встречал на практике системы, в которых "конфиг" — это половина логики решения.

S>В итоге получается так, что программисты реализуют и выкатывают фичу за месяц, а эксплуатация её конфигурит на проде два месяца.
S>Потому, что у программистов есть средства проверки корректности их кода — от подсветки в редакторе, выхлопа компилятора, и до верификаторов и юнит-тестов, которые прогоняются автоматом.
S>А у эксплуатации всё, что есть — это какая-то каша из "простейших величин", с бесконечным количеством способов сделать в них незначительную ошибку, которую обнаружить можно будет только по тикетам в саппорт.

Разве это не показатель, что конфиг должен быть только конфигом, а не нести в себе какую-то логику?

S>>>Начиная от "запросы по адресам '/users/*'...


K>>Местечковая галиматья. НЕТ у конфигов задачи "запросы по адресам". Это твоя бизнес-задача, решённая через одно неприличное место.

S>Правда что ли? Авторы nginx, iss, и apache с вами не согласны.
K>>Ещё раз вернись в место, где про "простейшие величины" — вот конфиг — это оно. При всех порочных практиках, самое ужасное, что ты можешь сделать — позволить чему-то внешнему исполняться на хосте.

S> То есть, вы полагаете, что конфиги с "простейщими величинами" можно давать править кому угодно, а вот код — уже нет?


Так простейшие величины — по сути просто значения переменных, которые потом пойдут на вход каких-то методов, а в методах вероятно будет валидация входных параметров.
Ну, неправильное значение размера буфера человек указал или адрес сервера не тот, значит ПО упадёт при запуске и работать не будет, либо вместо некорректных значений будет использовать дефолтные.
Неправильный код сложнее изолировать и потом окажется, что ошибка в конфиге разносит БД или ещё что-то важное ломает/удаляет.

S>Я вот не вижу принципиальной разницы. Ну, то есть понятно, что будучи суперосторожным, можно так ограничить конфиг, чтобы злоумышленник не смог при помощи него сделать ничего опасного.

S>Но таких случаев — исчезающе мало. Даже выбор "на каком порту слушать" уже позволяет нам в определённых обстоятельствах организовать атаку.
S>Поэтому самое ужасное, что вы можете сделать при всех порочных практиках — это давать доступ до конфигурации тем, кому нельзя доверять.
S>А если у вас (как и у всех минимально вменяемых людей) доступ к конфигурации ограничен, то нет никакой разницы, класть туда "данные" или "код".

Так вы о каких-то разных конфигах говорите.
Одно дело — серверная часть, для которой и настройка может быть сложнее и доступ ограничен.
Другое дело — какой-нибудь Notepad++, который ставит кто хочет и его конфиги правит кто хочет.
Делаем конфиг такого приложения просто куском кода, который потом исполняется и завтра у нас будет толпа вирусов, которые просто дописывают нужный код в текстовый файлик, никто на это не обращает внимания, а пользователь потом ещё и сам админские права даст на выполнение, т.к. он же программе доверяет и никто её не менял.
Не уверен, что некий скрипт развёртывания сервера правильно называть конфигом.
Может просто дело в том, что вырос на винде и привык к конфигам в виде ini-файла или xml какого, в которые никакую логику не засунуть.
Re[11]: лучшие практики для настроек-конфигов приложения..
От: Sinclair Россия https://github.com/evilguest/
Дата: 31.03.21 05:27
Оценка:
Здравствуйте, karbofos42, Вы писали:
K>Это уже не конфиг, а обмен данными какой-то.
Обмен данными — это то, что происходит в рантайме. А конфиг задаёт то, кто с кем общается.
Вы можете это наблюдать в любом app.config в виде секций, к примеру, управления логгированием.

K>Разве это не показатель, что конфиг должен быть только конфигом, а не нести в себе какую-то логику?

Что вы имеете в виду?

S>>>>Начиная от "запросы по адресам '/users/*'...

K>Так простейшие величины — по сути просто значения переменных, которые потом пойдут на вход каких-то методов, а в методах вероятно будет валидация входных параметров.
K>Ну, неправильное значение размера буфера человек указал или адрес сервера не тот, значит ПО упадёт при запуске и работать не будет, либо вместо некорректных значений будет использовать дефолтные.
K>Неправильный код сложнее изолировать и потом окажется, что ошибка в конфиге разносит БД или ещё что-то важное ломает/удаляет.
Ну, мы же говорим не про C/C++, где код может резвиться как ему угодно. Мы говорим об управляемой среде, в которой код не может получить доступ к тому, к чему ему доступа не дали.
Если он сделает что-то совсем неправильное, то ПО упадёт при запуске и работать не будет.
Самый патологический случай — это бесконечный цикл в коде "вычисления параметра конфига". Такие вещи статическим компилятором не отловишь.
Если такие проблемы представляют реальную угрозу, то инициализация конфига выносится в отдельный поток с таймаутом, при превышении которого приложение вырубается с соответствующей записью в логе.

K>Так вы о каких-то разных конфигах говорите.

K>Одно дело — серверная часть, для которой и настройка может быть сложнее и доступ ограничен.
K>Другое дело — какой-нибудь Notepad++, который ставит кто хочет и его конфиги правит кто хочет.
Как это "кто хочет"? Ставить приложение — привилегия админа. Если у пользователя есть привилегия ставить приложение, то его никакое разделение кода и данных не спасёт.
K>Делаем конфиг такого приложения просто куском кода, который потом исполняется и завтра у нас будет толпа вирусов, которые просто дописывают нужный код в текстовый файлик, никто на это не обращает внимания, а пользователь потом ещё и сам админские права даст на выполнение, т.к. он же программе доверяет и никто её не менял.
K>Не уверен, что некий скрипт развёртывания сервера правильно называть конфигом.
Скрипт развёртывания — это скрипт развёртывания. Он выполняется один раз при развёртывании.
А конфиг — это конфиг; он читается при старте приложения и, по хорошему, каждый раз при его изменении.
Более-менее любое Line of business приложение состоит из "конфигов" чуть менее, чем полностью. Какой-нибудь Power BI, или 1С — там же всё как раз в "конфигурации".
Вот, расскажите мне, как свести конфигурацию 1C к небольшому набору параметров.

K>Может просто дело в том, что вырос на винде и привык к конфигам в виде ini-файла или xml какого, в которые никакую логику не засунуть.

Как раз на винде масса всяческих конфигов в виде ini-файлов или xml (или того же реестра), которые очень сильно влияют на логику приложения.
И в общем случае нет никакого способа проверить корректность этих конфигов. Отсюда стандартный способ починки того, что отвалилось — просто переставляем приложение; если не помогло — переставляем винду.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re: лучшие практики для настроек-конфигов приложения..
От: Carc Россия http://www.amlpages.com/home.php
Дата: 31.03.21 10:49
Оценка: 4 (1)
Здравствуйте, MadHuman, Вы писали:

MH>Доброго всем!

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

MH>В частности интересны следующие моменты (и для затравки, привожу свой опыт)

MH>в каком формате хранить?
MH>В ini файлах — легко читать/править. большинство практических потребностей покрывает.
MH>xml/json — сложнее править, больше шансов ошибиться при ручной правке. основное преимущество — возможность большей вложенности (иерархичность) настроек,
MH>но на практике не особо ощущается т.к. в том же ini-файле вложенность вполне ок можно эмулировать за счет имен секций [system.limits]

MH>более интересный вопрос — как в приложении организована работа (чтение/хот релоад)?


  • Единый класс COptions, с открытыми member-переменными настроек (всякие bool, long\num, strings)

  • умеет писать себя и в реестр, и в ini-файл. Это спрятано внутри класс COptions. Сделано через выбор интерфейсов IWriteSettings, IReadSettings на лету. Выбор куда писать: реестр или ини-файл определяется пользователем.

    Из плюсов:
    1) Если реестр — то настройки единые для всех копий софтины на диске. Если ини — тогда у каждой копии софтины (разные версии например) у каждой свои копии настроек.
    2) Второй плюс: экспорт настроек действием пользователя суть та же запись в ini-файл через тот же самый интерфейс IWriteSettings. Разве что имя ини-файла выбирается пользователем стандартным диалогом выбора файла.
    3) Легкость создания портабельных настроек. Для портабельной версии используется запись\чтение настроек именно в\из ини-файла.

  • Для каких-то малоиспользуемых настроек (к примеру, какая-то третьеразрядная галка, в каком-то вспомогательном диалоге, в самом дальнем уголке проекта) этот класс COptions предоставляет парочку статических функций Write_Value(bool|string|num) и соответственно Read_Value(…). Но за уникальный ключ (для реестра\ини-файла) отвечает внешний код. Какое-то маловменяемое имя (ключ) для таких настроек придумать несложно. Благо это всё равно используется для малозначимых, каких-то там третьеразрядных настроек.

  • Чтение в стиле hot. При первом же обращении к такому классу COptions, он сам выполняет чтение (из того же реестра\ини-файла).

  • Все переменные в COptions — открытые, дабы без конца не мутить геттеры\сеттеры.

  • Как только появляется более "хитропопая" логика использования какой-либо переменной, она переносится в private. И приписывается геттер\сеттер. Проект, конечно, приходится крепко пересобрать. Но компилятор сам всё отловит. Останется только пробежаться по таким ошибочным строчкам, и тупо через копи-паст заменить прямое обращение к переменной на вызовы геттеров\сеттеров.

    Пример: выручает когда чешутся ручки удалить какую-то настройку, потому как, никто ей как настройкой и не пользуется. Но "терзают смутные сомнения" ©, а пользователям оно как будет? Может кто-то всё-таки использует эту "мнительную" настройку.

    В таком случае переменная этой настройки в COptions закрывается в private, дописываются геттеры-сеттеры, и всё пересобирается. Но! Есть нюанс. Сами геттеры\сеттеры просто ни хрена не делают. Геттер всегда возвращает одну и ту же константу, сеттер — это просто пустышка.
    Что это дает: для внешнего кода всё как было, так и осталось читает\меняет настройку через геттеры\сеттеры. Логика как была, так и осталось. Но де факто то, на самом деле никакой настройки больше нет.

    Со временем, если всё тихо, и пользователям "такой поворот с рекой" прошел нормально, эти пустышки геттеры\сеттеры удаляются.

    А вот если начинается кипешь пользователей на тему "верни настройку, я все прощу", тогда просто правим пару строк в геттерах\сеттерах — возвращая логику настройки по сути. И опять просто пересобираем код, и всё готово.

    Ну, как-то так что ли…
  • Aml Pages Home
    Отредактировано 31.03.2021 10:52 Carc . Предыдущая версия . Еще …
    Отредактировано 31.03.2021 10:50 Carc . Предыдущая версия .
    Re[12]: лучшие практики для настроек-конфигов приложения..
    От: karbofos42 Россия  
    Дата: 31.03.21 18:25
    Оценка: -1
    Здравствуйте, Sinclair, Вы писали:

    S>Здравствуйте, karbofos42, Вы писали:

    K>>Это уже не конфиг, а обмен данными какой-то.
    S>Обмен данными — это то, что происходит в рантайме. А конфиг задаёт то, кто с кем общается.
    S>Вы можете это наблюдать в любом app.config в виде секций, к примеру, управления логгированием.

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

    K>>Разве это не показатель, что конфиг должен быть только конфигом, а не нести в себе какую-то логику?

    S>Что вы имеете в виду?

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

    S>>>>>Начиная от "запросы по адресам '/users/*'...

    K>>Так простейшие величины — по сути просто значения переменных, которые потом пойдут на вход каких-то методов, а в методах вероятно будет валидация входных параметров.
    K>>Ну, неправильное значение размера буфера человек указал или адрес сервера не тот, значит ПО упадёт при запуске и работать не будет, либо вместо некорректных значений будет использовать дефолтные.
    K>>Неправильный код сложнее изолировать и потом окажется, что ошибка в конфиге разносит БД или ещё что-то важное ломает/удаляет.
    S>Ну, мы же говорим не про C/C++, где код может резвиться как ему угодно. Мы говорим об управляемой среде, в которой код не может получить доступ к тому, к чему ему доступа не дали.
    S>Если он сделает что-то совсем неправильное, то ПО упадёт при запуске и работать не будет.
    S>Самый патологический случай — это бесконечный цикл в коде "вычисления параметра конфига". Такие вещи статическим компилятором не отловишь.
    S>Если такие проблемы представляют реальную угрозу, то инициализация конфига выносится в отдельный поток с таймаутом, при превышении которого приложение вырубается с соответствующей записью в логе.

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

    K>>Так вы о каких-то разных конфигах говорите.

    K>>Одно дело — серверная часть, для которой и настройка может быть сложнее и доступ ограничен.
    K>>Другое дело — какой-нибудь Notepad++, который ставит кто хочет и его конфиги правит кто хочет.
    S>Как это "кто хочет"? Ставить приложение — привилегия админа. Если у пользователя есть привилегия ставить приложение, то его никакое разделение кода и данных не спасёт.
    K>>Делаем конфиг такого приложения просто куском кода, который потом исполняется и завтра у нас будет толпа вирусов, которые просто дописывают нужный код в текстовый файлик, никто на это не обращает внимания, а пользователь потом ещё и сам админские права даст на выполнение, т.к. он же программе доверяет и никто её не менял.

    Ну, конечно дома или в фирме на 30 сотрудников, есть админ, который ещё и осилит права правильно раздать.

    K>>Не уверен, что некий скрипт развёртывания сервера правильно называть конфигом.

    S>Скрипт развёртывания — это скрипт развёртывания. Он выполняется один раз при развёртывании.
    S>А конфиг — это конфиг; он читается при старте приложения и, по хорошему, каждый раз при его изменении.
    S>Более-менее любое Line of business приложение состоит из "конфигов" чуть менее, чем полностью. Какой-нибудь Power BI, или 1С — там же всё как раз в "конфигурации".
    S>Вот, расскажите мне, как свести конфигурацию 1C к небольшому набору параметров.

    Конфигурация в 1С — это отдельная песня.
    Только вот настраивается 1С Предприятие автоматически, а минимальные настройки для ключей и т.п. — обычные ini-файлы из десятка строк, где что-то сломать проблематично.
    А если конфигурацию из 1С считать конфигом, то в принципе любую программу можно считать им, особенно если там интерпретатор, а не компилятор.

    K>>Может просто дело в том, что вырос на винде и привык к конфигам в виде ini-файла или xml какого, в которые никакую логику не засунуть.

    S>Как раз на винде масса всяческих конфигов в виде ini-файлов или xml (или того же реестра), которые очень сильно влияют на логику приложения.
    S>И в общем случае нет никакого способа проверить корректность этих конфигов. Отсюда стандартный способ починки того, что отвалилось — просто переставляем приложение; если не помогло — переставляем винду.

    эти конфиги достаточно просты и их легко сейчас заменяет сериализация DTO в json
    Re[13]: лучшие практики для настроек-конфигов приложения..
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 01.04.21 03:41
    Оценка:
    Здравствуйте, karbofos42, Вы писали:

    K>Здравствуйте, Sinclair, Вы писали:


    S>>Здравствуйте, karbofos42, Вы писали:

    K>>>Это уже не конфиг, а обмен данными какой-то.
    S>>Обмен данными — это то, что происходит в рантайме. А конфиг задаёт то, кто с кем общается.
    S>>Вы можете это наблюдать в любом app.config в виде секций, к примеру, управления логгированием.

    K>Ни разу не попадалось в конфигах что-то сильно замороченное.

    K>Имя файлов лога, продолжительность хранения, уровень логгирования,..
    K>Чтобы там поменять две строчки местами и всё сломалось — не попадалось.
    Правда что ли?
    <?xml version="1.0" encoding="utf-8" ?>
    <configuration>
        <configSections>
            <section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" /> <-- опечатка в имени типа, или неподключенная сборка - ловим в рантайме.
        </configSections>
        <log4net>
            <appender name="ConsoleAppender" type="log4net.Appender.ConsoleAppender" > <-- опечатка в имени типа, или неподключенная сборка - ловим в рантайме.
                <layout type="log4net.Layout.PatternLayout"> <-- опечатка в имени типа, или неподключенная сборка - ловим в рантайме.
                    <conversionPattern value="%date [%thread] %-5level %logger [%ndc] - %message%newline" />
                </layout>
            </appender>
            <root>
                <level value="INFO" />
                <appender-ref ref="ConsoleAppender" /> <-- ссылка на аппендер, определённый в другой части конфигурации. Ошибка в ссылке - ловим в рантайме.
            </root>
        </log4net>
    </configuration>

    Когда мы это размажем по иерархии веб-конфигов, всё станет ещё веселее.
    K>Что лучше бы программисты десяток типовых сборок сделало или реализовать удобный инструмент для настройки ПО, чем заставлять людей месяцами ковыряться в километровых конфигах неизвестно на каком языке.
    У нас с вами разные понятия об удобстве инструментов для настройки ПО. Вот в примере выше в качестве языка управления конфигурацией мы породили некоторый DSL, для которого нет инструментов ни автодополнения, ни рефакторинга. Это нам ещё повезло — язык остался текстовым (а не представлен, скажем, в виде каких-то данных в РСУБД), поэтому мы хотя бы можем делать diff и blame.
    Даже в таком простом примере видно, что "простые значения" в конфиге должны быть согласованы между собой; но никаких средств проверки этого (кроме запуска приложения и тестирования сценариев) у нас нет.

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

    Ещё проще — человек запустил доверенное приложение под админом, а в нём — левый код.
    Вы хотите избежать ситуации, когда админом запускается код, принесённый не-админом? Этот аспект отличается для серверных и настольных приложений.
    В том смысле, что для настольных он более важен.
    В целом, я думаю, что вы правы в том, что выполнять произвольный императивный код в конфиге — не лучшая идея.
    Но я всё ещё считаю, что это должен быть код на каком-то языке с нормальным тулчейном, а не просто плоский ini, или простынки json/XML.

    K>Ну, конечно дома или в фирме на 30 сотрудников, есть админ, который ещё и осилит права правильно раздать.

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

    K>Только вот настраивается 1С Предприятие автоматически, а минимальные настройки для ключей и т.п. — обычные ini-файлы из десятка строк, где что-то сломать проблематично.

    K>А если конфигурацию из 1С считать конфигом, то в принципе любую программу можно считать им, особенно если там интерпретатор, а не компилятор.
    Да, я предлагаю конфигурацию 1С считать конфигурацией. Ну, потому что это конфигурация.

    K>эти конфиги достаточно просты и их легко сейчас заменяет сериализация DTO в json

    А почему не хранить сам этот DTO в формате object initializer?
    В отличие от json, этот код можно рефакторить, а написание оборудовано автодополнением.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[14]: лучшие практики для настроек-конфигов приложения..
    От: Ночной Смотрящий Россия  
    Дата: 01.04.21 09:37
    Оценка: 9 (1)
    Здравствуйте, Sinclair, Вы писали:

    S> <section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" /> <-- опечатка в имени типа, или неподключенная сборка — ловим в рантайме.


    А как надо? Захерачить в код, а как потом в кубере эту настройку поменять пусть у девопсов голова болит?
    ... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
    Re[15]: лучшие практики для настроек-конфигов приложения..
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 01.04.21 09:45
    Оценка:
    Здравствуйте, Ночной Смотрящий, Вы писали:
    НС>А как надо? Захерачить в код, а как потом в кубере эту настройку поменять пусть у девопсов голова болит?
    Хороший вопрос. Разберусь — отвечу.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[16]: лучшие практики для настроек-конфигов приложения..
    От: Ночной Смотрящий Россия  
    Дата: 01.04.21 11:38
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    НС>>А как надо? Захерачить в код, а как потом в кубере эту настройку поменять пусть у девопсов голова болит?

    S>Хороший вопрос. Разберусь — отвечу.



    Вот о чем я и говорю. Основная проблема велосипедов — шаг в сторону и мы вынуждены продолжать велосипедить. В то время как если бы мы взяли хотя бы штатный конфиг кора, то автоматом получили бы возможность поменять имя провайдера просто выставив переменную среды log4net_appender_type. А если бы мы еще и консул взяли, то получили бы еще и готовые инструкции всякие для админов/девопсов/безопасников, которые для велосипеда в случае какой нибудь SOC сертификации пришлось бы писать самому.
    ... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
    Re[14]: лучшие практики для настроек-конфигов приложения..
    От: karbofos42 Россия  
    Дата: 04.04.21 12:54
    Оценка: +1
    Здравствуйте, Sinclair, Вы писали:

    S>Когда мы это размажем по иерархии веб-конфигов, всё станет ещё веселее.


    В итоге этого можно относительно избежать, если конфиг делать в виде библиотеки, чтобы пользователь открывал IDE Собирал проект с зависимостями от неких публичных API приложения и тогда у него будет всё относительно доступно. Только конфиги почему-то обычно в блокнотике правят совсем не программисты.

    K>>Что лучше бы программисты десяток типовых сборок сделало или реализовать удобный инструмент для настройки ПО, чем заставлять людей месяцами ковыряться в километровых конфигах неизвестно на каком языке.

    S>У нас с вами разные понятия об удобстве инструментов для настройки ПО. Вот в примере выше в качестве языка управления конфигурацией мы породили некоторый DSL, для которого нет инструментов ни автодополнения, ни рефакторинга. Это нам ещё повезло — язык остался текстовым (а не представлен, скажем, в виде каких-то данных в РСУБД), поэтому мы хотя бы можем делать diff и blame.

    xml, json, ini — большинству айтишников знакомы и понятны. Добавить раздел в xml или json сможет любой в блокнотике.
    Чем ему поможет, если конфиг будет в виде какого-нибудь cs-файла с кодом на шарпе?

    S>Даже в таком простом примере видно, что "простые значения" в конфиге должны быть согласованы между собой; но никаких средств проверки этого (кроме запуска приложения и тестирования сценариев) у нас нет.


    Их не будет в любом случае

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

    S>Ещё проще — человек запустил доверенное приложение под админом, а в нём — левый код.

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

    S>Вы хотите избежать ситуации, когда админом запускается код, принесённый не-админом? Этот аспект отличается для серверных и настольных приложений.


    Я хочу избежать ситуации, когда админ вынужден давать лишние права "не админам".

    S>Но я всё ещё считаю, что это должен быть код на каком-то языке с нормальным тулчейном, а не просто плоский ini, или простынки json/XML.


    Так я и говорю, что либо простой плоский ini/xml/json, либо отдельный человеческий инструмент, который даст пользователям нормально настроить программу

    K>>Ну, конечно дома или в фирме на 30 сотрудников, есть админ, который ещё и осилит права правильно раздать.

    S>Ещё раз: в такой фирме или дома, компьютер уже представляет из себя большую дыру. Люди гоняют скачанные из интернета екзешники под локальным админом и в ус не дуют.

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

    K>>Только вот настраивается 1С Предприятие автоматически, а минимальные настройки для ключей и т.п. — обычные ini-файлы из десятка строк, где что-то сломать проблематично.

    K>>А если конфигурацию из 1С считать конфигом, то в принципе любую программу можно считать им, особенно если там интерпретатор, а не компилятор.
    S>Да, я предлагаю конфигурацию 1С считать конфигурацией. Ну, потому что это конфигурация.

    Ну, значит программа на шарпе с использованием WPF и Entity Framework — это тоже некий конфиг
    Конфигурация 1С — это не просто описание подключения неких модулей, а вполне себе и описание схемы БД и код всех методов.

    S>А почему не хранить сам этот DTO в формате object initializer?

    S>В отличие от json, этот код можно рефакторить, а написание оборудовано автодополнением.

    Что-то там дописывать будут только разработчики, а пользователи и админы всякие туда залезают обычно — поменять пути к файлам, изменить какие-то константы, добавить пару строчек копипастой из документации от разработчиков.
    Если уж конфиг нужно часто менять и сильно дописывать, то никто разработчикам не мешает сделать GUI-тулзу для заполнения этого json c валидацией.
    Подождите ...
    Wait...
    Пока на собственное сообщение не было ответов, его можно удалить.