Не лучше ли использовать какое либо специализированное ПО - например argo rollout или flagger? Тогда можно будет и более сложные сценарии деплоя делать (например с промежуточными проверками), да и другие паттерны выкатки заюзать - например канареечное обновление + обычно там же есть интеграция с разными Nginx/Istio/etc из коробки, не нужно будет это руками описывать, особенно если таких сервисов десятки
есть конечно минусы: +1 компонент в системе и время на освоение, но последнее это разовая затрата
Мне кажется в эпоху loki/kibane/etc и все большего развития трейсинга, достаточно:
в месте ошибки создать трейс (как и выше по коду)
опционально: написать в лог ошибку с данными достаточными для воспроизведения проблемы (+файл:строка+trace_id)
прокинуть нормальную кастомную ошибку выше, такую как LoadDBError{ error: err, sql: sql, etc... }
loki покажет полный набор логов по конкретному trace_id и для этого не нужно делать враппинг самому + трейсы покажут откуда пришел запрос и прочие данные
Сейчас использую Notion для хранения общей информации и пет-проджект для хранения типовых решений (например Dockerfile + docker-compose для go, python, php - но с комментами и пояснениями почему так для каждой строчки которая не в руках), при обновлении докера соотвественно обновляю примеры (например когда новый тип кеширования завезли)
Два года платил за Miro, но в итоге оказалось не так удобно использовать. Evernote/OneNote крутые, но как то не прижелось по итогу.
Я сразу же отключил, так как сломался вывод моего zsh, с выводом гит ветки и прочего, автокомплит - меня устраивает тот что даёт zsh+плагины которые я сам выбрал и настроил. В плане визуализации, чтало меньше влезать контента, тоде минус
Один из моментов в том что это все меньше нужно рядовой компании, к примеру взять Talos - ни ssh, read-onle fs - обновление os/кубера одной командой
А если нужно обновить sysctl, то вот вам yaml-файл в котором можно задать нужные значения, хотя конечно, в этом случае понимание что под капотом будет не лишним, благо есть всякие hard way-туториалы в которых есть в том числе и про то что под капотом
Можно локально поставить npm-registry - например https://verdaccio.org/ (но на гитхабе есть и другие варианты) и проксировать зависимости через него - заодно и от падений npm/github защитит
О, да! Имел опыт разнорабочего в 14 и 17лет, мне даже нравилась размеренность жизни, режим дня - но быстро понимал что для меня это скучно, что условно еще пол года и все что нужно освоить я освою, а дальше 20лет монотонно одно и тоже
Поддерживаю, более того в варианте с APIFirst типовые запросы/ответы можно вынести в схемы и переиспользовать в более высокоуровневых элементах (все что касается авторизации, базовых ошибок, Item->Items, и т.д.) в итоге получаются вполне компактные спеки даже в средних по размеру проектах. Еще + в том что для изменения в формате логирования/трейсов/etc достаточно поменять темплейт и перегенерировать код
Как развитие идеи модулей - хорошо заходит DI - google/wire например, можно сделать набор провайдеров и потом через запятую указать нужные, в целом к этому при желании можно и promt-прикрутить что бы в диалоге прописать какие модули нужны для сервиса
p.s. генерация графана-дашбордов выглядит интересно, полезная вещь, было бы интересно посмотреть как генерите и какие метрики туда вносили (и почему добавили те или иные - тоже было бы интересно послушать)
Собственно в плане Crossplane не очень понятно чем он дополняет Argo CD. Разве что создавать с нуля кластер, а дальше - управление БД - операторы для rabbitmq, kafka и так дают описать все что нужно в Helm-чарте и не понятно зачем использовать кастомный для конкретного кластера mysqlcluster если можно взять оператор, который не будет завесить от вендора
CoreOS была крутой OS, использовали долгое время, крутой механизм обновлений с откатом если что-то пошло не так на последнюю рабочую версию, синхронизация времени между машинами (etcd-кластер), протестированные докер/кубер из коробки и что самое главное - долгое время это была наиболее полная дока по работе с k8s на baremetal
А разве для этих кейсов не подойдет kyverno или OPA? Также можно задать правила и автоматически проверять, что у разработчиков все правильно (в плане описания информации о сервисах команды, что установлены лимиты по ресурсам, есть пробы).
можно еще kind поднимать прямо в CI и прогонять тесты еще до деплоя в k8s - в этом случае, конечно, свои тесты имеют смысл.
Двояко, например в wire нельзя делать провайдеры которые возвращают одинаковую структуру (например когда у нас есть отдельно redis для кеша, отдельно для сессий и тп) - нужно писать свои врапперы, зато при падении (или получении nil как описано ниже в комментах) будет сразу понятно что ошибка возникла в wire_gen.go:37:5 RedisSessionStore - условно, и граф зависимостей виден в файле в виде линейной последовательности вызовов - ну и тестов особо не нужно, IDE подстветит код если сгенерировалось что-то не валидное, да и golang не даст скомпилировать неправильный код, хотя риск ошибок в рантайм конечно остается
wire особенно удобен в монорепах, можно сделать DefaultSet (с логером, трейсами, grpc-clients/server) и сильно сократить объем дублирования кода
p.s. хотя еще один момент что иногда стреляет в wire это то что он игнорит зависимости если их никто не требует явно, и бывает странно, вроде добавил в зависимости Tracer а в wire_gen.go он не попал, но это скорее повод подумать об рефакторинге кода и убраь не явные ожидания от окружения
p.s. еще DI неплохо использовать не только на уровне main.go но и на уровне модулей, что бы точно также объединить одной строчкой нужные репозитории, сервисы, домены - хотя это и спорное решение
Не лучше ли использовать какое либо специализированное ПО - например argo rollout или flagger? Тогда можно будет и более сложные сценарии деплоя делать (например с промежуточными проверками), да и другие паттерны выкатки заюзать - например канареечное обновление + обычно там же есть интеграция с разными Nginx/Istio/etc из коробки, не нужно будет это руками описывать, особенно если таких сервисов десятки
есть конечно минусы: +1 компонент в системе и время на освоение, но последнее это разовая затрата
Мне кажется в эпоху loki/kibane/etc и все большего развития трейсинга, достаточно:
в месте ошибки создать трейс (как и выше по коду)
опционально: написать в лог ошибку с данными достаточными для воспроизведения проблемы (+файл:строка+trace_id)
прокинуть нормальную кастомную ошибку выше, такую как LoadDBError{ error: err, sql: sql, etc... }
loki покажет полный набор логов по конкретному trace_id и для этого не нужно делать враппинг самому + трейсы покажут откуда пришел запрос и прочие данные
Сейчас использую Notion для хранения общей информации и пет-проджект для хранения типовых решений (например Dockerfile + docker-compose для go, python, php - но с комментами и пояснениями почему так для каждой строчки которая не в руках), при обновлении докера соотвественно обновляю примеры (например когда новый тип кеширования завезли)
Два года платил за Miro, но в итоге оказалось не так удобно использовать. Evernote/OneNote крутые, но как то не прижелось по итогу.
Я сразу же отключил, так как сломался вывод моего zsh, с выводом гит ветки и прочего, автокомплит - меня устраивает тот что даёт zsh+плагины которые я сам выбрал и настроил. В плане визуализации, чтало меньше влезать контента, тоде минус
Один из моментов в том что это все меньше нужно рядовой компании, к примеру взять Talos - ни ssh, read-onle fs - обновление os/кубера одной командой
А если нужно обновить sysctl, то вот вам yaml-файл в котором можно задать нужные значения, хотя конечно, в этом случае
понимание что под капотомбудет не лишним, благо есть всякиеhard way-туториалы в которых есть в том числе и про то что под капотомМожно локально поставить npm-registry - например https://verdaccio.org/ (но на гитхабе есть и другие варианты) и проксировать зависимости через него - заодно и от падений npm/github защитит
О, да! Имел опыт разнорабочего в 14 и 17лет, мне даже нравилась размеренность жизни, режим дня - но быстро понимал что для меня это скучно, что условно еще пол года и все что нужно освоить я освою, а дальше 20лет монотонно одно и тоже
Поддерживаю, более того в варианте с APIFirst типовые запросы/ответы можно вынести в схемы и переиспользовать в более высокоуровневых элементах (все что касается авторизации, базовых ошибок, Item->Items, и т.д.) в итоге получаются вполне компактные спеки даже в средних по размеру проектах. Еще + в том что для изменения в формате логирования/трейсов/etc достаточно поменять темплейт и перегенерировать код
Как развитие идеи модулей - хорошо заходит DI - google/wire например, можно сделать набор провайдеров и потом через запятую указать нужные, в целом к этому при желании можно и promt-прикрутить что бы в диалоге прописать какие модули нужны для сервиса
p.s. генерация графана-дашбордов выглядит интересно, полезная вещь, было бы интересно посмотреть как генерите и какие метрики туда вносили (и почему добавили те или иные - тоже было бы интересно послушать)
Не увидел ссылки на продолжение этой истории - github.com/cmuratori/misc
Там автор статьи ведет обсуждение с дядюшкой Бобом. Каждый остался при своем, но дискуссия занятная
Собственно в плане Crossplane не очень понятно чем он дополняет Argo CD. Разве что создавать с нуля кластер, а дальше - управление БД - операторы для rabbitmq, kafka и так дают описать все что нужно в Helm-чарте и не понятно зачем использовать кастомный для конкретного кластера mysqlcluster если можно взять оператор, который не будет завесить от вендора
CoreOS была крутой OS, использовали долгое время, крутой механизм обновлений с откатом если что-то пошло не так на последнюю рабочую версию, синхронизация времени между машинами (etcd-кластер), протестированные докер/кубер из коробки и что самое главное - долгое время это была наиболее полная дока по работе с k8s на baremetal
А разве для этих кейсов не подойдет kyverno или OPA? Также можно задать правила и автоматически проверять, что у разработчиков все правильно (в плане описания информации о сервисах команды, что установлены лимиты по ресурсам, есть пробы).
можно еще kind поднимать прямо в CI и прогонять тесты еще до деплоя в k8s - в этом случае, конечно, свои тесты имеют смысл.
Двояко, например в wire нельзя делать провайдеры которые возвращают одинаковую структуру (например когда у нас есть отдельно redis для кеша, отдельно для сессий и тп) - нужно писать свои врапперы, зато при падении (или получении nil как описано ниже в комментах) будет сразу понятно что ошибка возникла в
wire_gen.go:37:5 RedisSessionStore- условно, и граф зависимостей виден в файле в виде линейной последовательности вызовов - ну и тестов особо не нужно, IDE подстветит код если сгенерировалось что-то не валидное, да и golang не даст скомпилировать неправильный код, хотя риск ошибок в рантайм конечно остаетсяwire особенно удобен в монорепах, можно сделать DefaultSet (с логером, трейсами, grpc-clients/server) и сильно сократить объем дублирования кода
p.s. хотя еще один момент что иногда стреляет в wire это то что он игнорит зависимости если их никто не требует явно, и бывает странно, вроде добавил в зависимости
Tracerа вwire_gen.goон не попал, но это скорее повод подумать об рефакторинге кода и убраь не явные ожидания от окруженияp.s. еще DI неплохо использовать не только на уровне
main.goно и на уровне модулей, что бы точно также объединить одной строчкой нужные репозитории, сервисы, домены - хотя это и спорное решениеВопрос. Рассматривали ли вариант со статической генерацией графа зависимостей, например wire и если да, то почему выбор пал на uber.fx