Валидация конфига #3

New Issue

skeris · 2024-11-04T22:49:11Z

skeris commented

2024-11-04 22:49:11 +00:00

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

Решение:
вопрос ci\cd я беру на себя. но вопрос разработки целиком на тебе. к тому же, мне посоветовали меньше давать готовых решений, давая больше свободы разработчику, поэтому здесь и далее задачи будут немного совещательными

Надо:

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

Проблема: когда кто-либо деплоит этот сервис, есть шанс совершить ошибку и предоставить неверный конфиг, из-за чего сервис будет работать неправильно или вовсе не будет работать. В рамках повышения стабильности релизов надо сделать так, чтобы валидность конфига проверялась ещё до того, как сервис отправится на деплой. т.е. после сборки образа, но до развертывания. Решение: вопрос ci\cd я беру на себя. но вопрос разработки целиком на тебе. к тому же, мне посоветовали меньше давать готовых решений, давая больше свободы разработчику, поэтому здесь и далее задачи будут немного совещательными Надо: - записать список полей конфига, которые критичны, т.е. их неправильное заполнение может ломать работоспособность сервиса - накидать идей, как мы можем проверить что поле конфига валидно - реализовать какое-то решение, которое можно будет запустить и отдельно, не запуская сервиса, и импортировать в сервис и запустить на этапе его инициализации. а то мало ли, вдруг сломается между проверкой и заливкой

skeris added the

Priority

Medium

Kind/Enhancement

labels 2024-11-04 22:49:11 +00:00

pasha1coil was assigned by skeris

2024-11-04 22:49:11 +00:00

skeris added this to the Стабильность релизов project 2024-11-04 22:49:11 +00:00

skeris added the due date 2024-11-08

2024-11-04 22:49:30 +00:00

skeris added a new dependency 2024-11-04 22:49:36 +00:00

#2 Заменить имя модуля

skeris added a new dependency 2024-11-05 13:29:31 +00:00

#5 Liveness и Readiness

pasha1coil commented

2024-11-06 12:10:08 +00:00

выделил основные поля конфига в трешлоге которые как мне кажется критичны для заполнения:


Addr        string `env:"APP_ADDR" default:":7113"`

ClickhouseCred string `env:"CH_CRED" default:"tcp://127.0.0.1:9000?debug=true"` 
DBPath         string `env:"DB_PATH" default:"./recover.bolt"`
BucketName     string `env:"BUCKET_NAME" default:"recover"`

TgToken  string `env:"TG_TOKEN" default:"1408111289:AAHfWZRiBQRncb2gl2LtU8OeASjfJi4e8YE"`
TgChatID uint64 `env:"TG_CHAT_ID" default:"1001256687920"`

самыми важными являются как мне кажется это ClickhouseCred , TgToken , TgChatID и уже косвенно это DBPath BucketName, почему косвенно, ну я думаю эти мутирующие переменные будут со временем их по желанию будто бы можно по разному называть

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

для параметров болта достаточно чтобы они не были пустыми как я понимаю

выделил основные поля конфига в трешлоге которые как мне кажется критичны для заполнения: ``` Addr string `env:"APP_ADDR" default:":7113"` ClickhouseCred string `env:"CH_CRED" default:"tcp://127.0.0.1:9000?debug=true"` DBPath string `env:"DB_PATH" default:"./recover.bolt"` BucketName string `env:"BUCKET_NAME" default:"recover"` TgToken string `env:"TG_TOKEN" default:"1408111289:AAHfWZRiBQRncb2gl2LtU8OeASjfJi4e8YE"` TgChatID uint64 `env:"TG_CHAT_ID" default:"1001256687920"` ``` самыми важными являются как мне кажется это ClickhouseCred , TgToken , TgChatID и уже косвенно это DBPath BucketName, почему косвенно, ну я думаю эти мутирующие переменные будут со временем их по желанию будто бы можно по разному называть а вот строка подключения к кликхаусу и тг параметры уже важны для нормального функционирования их я думаю стоит валидировать, как пинг в кликхаус и проверку подключения бота к тг для параметров болта достаточно чтобы они не были пустыми как я понимаю

pasha1coil commented

2024-11-06 12:30:16 +00:00

я наверное банально выражусь, но примерно такое в голову приходит как это делать

Проверка на пустое значение строковых параметров
Проверка формата адреса строки подключения и порта к примеру
Проверка числовых значений, не совсем уместно тут ну как проверка что подходит в допустимый диапазон, то почему бы и нет
Ну и самое важное это наверное распинговка по "адресам" возможно с помощью net/url

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

хм ну возможно без рефлексии тут не обойтись или обойтись, как то наверное стоит собрать то что у нас используется, стандартизировать для них название env формата и уже отталкиваясь от этого создавать правила проверок.
Потому что ну допустим, redis_host,redis_port,http_host,http_port и тд также с кафкой постгресом называются примерно одинаково

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

получая эти теги строить конвеер проверок.

пока сыро пояснил, потому что сам не очень представляю.

я наверное банально выражусь, но примерно такое в голову приходит как это делать - Проверка на пустое значение строковых параметров - Проверка формата адреса строки подключения и порта к примеру - Проверка числовых значений, не совсем уместно тут ну как проверка что подходит в допустимый диапазон, то почему бы и нет - Ну и самое важное это наверное распинговка по "адресам" возможно с помощью net/url на самом деле как я понимаю это лучше сделать сразу для всех конфигов которые у нас могут использоваться на проектах, я вот про то что один валидатор для всего хм ну возможно без рефлексии тут не обойтись или обойтись, как то наверное стоит собрать то что у нас используется, стандартизировать для них название env формата и уже отталкиваясь от этого создавать правила проверок. Потому что ну допустим, redis_host,redis_port,http_host,http_port и тд также с кафкой постгресом называются примерно одинаково как бы возможно сделал в валидаторе, во первых добавил бы эти env форматы за правило в мапку которая будет описывать что с ними делать и в каких проверках нуждаются, сделал бы рефлексию по тегам конфига, кстати вот интересно с json точно помню что умеет, с env не пробовал получая эти теги строить конвеер проверок. пока сыро пояснил, потому что сам не очень представляю.

skeris commented

2024-11-06 21:40:27 +00:00

не, норм пояснил
но ответить мне есть и много чего. и если бы мы не начали это обсуждать, я бы об этом и не подумал

DBPath проверить надо. может быть такая ситуация, что по какой-то запарке фс находится в режиме read only. т.е. создать файл не получится вообще. ну например при создании томов контейнеру, будет передан том с правом записи, который лежит в томе защищённом от записи. может быть ещё такая ситуация, что такой файл уже существует и открыт другим приложением. например, если при запуске контейнера ему был передан том от другого контейнера, где открыт файл с таким же названием.
BucketName можно наверное не валидировать. да и особого смысла передавать его я не вижу, на самом деле. лучше убрать из конфига и сделать константой
я не уверен, что стоит делать универсальный валидатор конфига, как модуль с рефлексией и прочим. лучше его накодогенерить. почему:

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

APP_ADDR почти нет смысла проверять. только на то, что он соответствует шаблону ":"

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

не, норм пояснил но ответить мне есть и много чего. и если бы мы не начали это обсуждать, я бы об этом и не подумал 1) DBPath проверить надо. может быть такая ситуация, что по какой-то запарке фс находится в режиме read only. т.е. создать файл не получится вообще. ну например при создании томов контейнеру, будет передан том с правом записи, который лежит в томе защищённом от записи. может быть ещё такая ситуация, что такой файл уже существует и открыт другим приложением. например, если при запуске контейнера ему был передан том от другого контейнера, где открыт файл с таким же названием. 2) BucketName можно наверное не валидировать. да и особого смысла передавать его я не вижу, на самом деле. лучше убрать из конфига и сделать константой 3) я не уверен, что стоит делать универсальный валидатор конфига, как модуль с рефлексией и прочим. лучше его накодогенерить. почему: - не всегда пустая строка это невалидно. иногда пустая строка значит только то, что мы эту сущность не используем. например, при запуске gitea можно передать набор кредов для постгресса или для мускула. и это довольно мощный подход - не нужен компонент - не передавай для него данные. это можно разрулить и рефлексией, но это надо заводить тег required, а это только увеличит шанс человеческой ошибки, потому что тогда надо будет разруливать вопрос правильной постановки тегов - распинговка может быть недостаточным критерием. в каждой ситуации это может быть по разному. например монга в случае с репликасетом - secondary или arbiter на пинг отзовутся адекватно, но записать что-то в себя не дадут - критериев оценки валидности может быть сииильно больше, чем приходит в голову при первоначальном обдумывании. например соль или параметр для шифрования токена авторизации. если соль не совпадает, вся авторизация отвалится. а несовпасть она может очень легко - случаянно не там поставил символ, залил и ушел на выходные 5) APP_ADDR почти нет смысла проверять. только на то, что он соответствует шаблону ":<number>" как по мне, сейчас лучше не писать обобщенный валидатор целиком. лучше в каждом проекте сделать свою валидацию, а потом вынести похожие функции в тулзы в коммоне. даже придумать как обобщенно скодогенерить пока сложно. как только набор тулзов появится, можно будет в конфиге блупринта прописать откуда брать готовые темплейты и для каких полей заготавливать заглушки с тудушками

skeris moved this to inProrgess in Стабильность релизов on 2024-11-06 22:30:14 +00:00

pasha1coil commented

2024-11-08 09:00:00 +00:00

сделал некую валидацию для конфига трешлога, вроде по максимуму выжал как мне кажется оттуда

skeris moved this to inProrgess in Стабильность релизов on 2024-11-08 22:36:02 +00:00

skeris moved this to inProrgess in Стабильность релизов on 2024-11-08 22:36:13 +00:00

pasha1coil added the

Reviewed/Requested

label 2024-11-17 18:16:56 +00:00

skeris moved this to deploy in Стабильность релизов on 2024-11-18 21:48:53 +00:00

skeris moved this to deploy in Стабильность релизов on 2024-11-18 21:48:56 +00:00

skeris moved this to deploy in Стабильность релизов on 2024-11-18 21:48:59 +00:00