Я не говорил ничего про обоснованность выбора архитектуры и количества компонентов разработчиками Sentry.
Адекватно или нет - у них есть определенный набор сервисов и зависимостей, необходимый для работы под их же нужды, в их сценарии, как они считают нужным. Добавлять сюда вариативность ради упрощения деплоя и поддержки бесплатной версии - это трата ресурсов команды, а бизнес ценность этого процесса сомнительна, на мой взгляд.
Ну а на тему чрезмерной декомпозиции и нерациональности и прочего - наверное не очень корректно рассуждать в таком ключе, не видя их инфраструктуру, метрики и требования.
Я думаю, что причина монструозности деплоя Sentry - не в хитром способе заставить вас купить SaaS, но в банальной экономии.
Экономии времени и трудозатрат на адаптацию их SaaS специфики (в виде огромных RPS, количества пользователей, SLO) под небольшие on-prem инсталляции. Можно сделать проще, конечно, но это будет фактически поддержка двух продуктов, один из которых - бесплатный и не накладывает ограничений (насколько я помню).
Я не предлагал протестное увольнение делать. У руководителя, конечно, есть своя жизнь, обязательства и прочее. Далеко не каждый может себе позволить демонстративно уйти в никуда.
Но это все еще не повод просто принимать участие в нарушении прав работника, как и не прилагать усилий для помощи, сваливая все на него одного.
Собрали бы cloud-init образ сами, это ведь намного интереснее, чем загрузить готовый. Возможностей автоматизации после старта там огромное количество и все это гибко настраивается под нужды среды или задачи образа.
Кстати, всю конфигурацию VM в PVE можно (и удобнее :) делать через этот же qm.
Слушайте, ну это же прошлый век уже, нужно использовать скиллы. /s
Я не говорил ничего про обоснованность выбора архитектуры и количества компонентов разработчиками Sentry.
Адекватно или нет - у них есть определенный набор сервисов и зависимостей, необходимый для работы под их же нужды, в их сценарии, как они считают нужным. Добавлять сюда вариативность ради упрощения деплоя и поддержки бесплатной версии - это трата ресурсов команды, а бизнес ценность этого процесса сомнительна, на мой взгляд.
Ну а на тему чрезмерной декомпозиции и нерациональности и прочего - наверное не очень корректно рассуждать в таком ключе, не видя их инфраструктуру, метрики и требования.
Я думаю, что причина монструозности деплоя Sentry - не в хитром способе заставить вас купить SaaS, но в банальной экономии.
Экономии времени и трудозатрат на адаптацию их SaaS специфики (в виде огромных RPS, количества пользователей, SLO) под небольшие on-prem инсталляции. Можно сделать проще, конечно, но это будет фактически поддержка двух продуктов, один из которых - бесплатный и не накладывает ограничений (насколько я помню).
Можно не знать о нем. Просто адреса нужно разбирать по версии протокола в коде (библиотека это умеет), а не считать все как v4.
Новые приложения вообще лучше писать так, чтобы они понимали v6, а v4 хранить как mapped.
Работу над ошибками никто не отменял.
Тем более, у автора внешний бэкап был, хоть и случайно, вместе с локальным бэкапом и репликой.
Весьма поучительная история. Хорошо, что все обошлось.
Если проект для вас важен - сейчас самое время провести аудит, вероятно, техдолг у вас накопился приличный.
Для секретов в репозитории есть sops, например, и vault как KMS/PKI.
Для ssh есть системы типа Teleport, но вам, наверное, проще просто перейти на ключи и настроить fw (либо вообще разрешать ssh только через VPN).
Это обычная практика, но нужно ли это вам? И не забудьте, что мониторинг тоже может сломаться или быть на той же инфре, что и все остальное.
BTW, для простых внешних проверок и алертинга есть uptime-kuma.
Выглядит интересно, спасибо.
Собирал аналогичный инструмент, только не для kubernetes, а вообще для мониторинга intra/inter DC трафика.
Как идея вам - добавьте возможность подключать внешние агенты (без kubernetes).
И вопросы напрашиваются:
Вы всегда полный mesh собираете, или все же как-то оптимизируете набор пиров для проверки?
На каком количестве нод это сейчас работает?
Как поведет себя на 100/1000/5000?
IPv6 по-умолчанию сейчас включен во всех современных ОС.
По этой причине, отсутствие конфигураций того же ND snooping и RA snooping на сети (где вроде бы не используется IPv6) - хороший вектор для атак.
Понимаю.
Простых решений без негатива тут все равно не будет, это факт.
Я не предлагал протестное увольнение делать. У руководителя, конечно, есть своя жизнь, обязательства и прочее. Далеко не каждый может себе позволить демонстративно уйти в никуда.
Но это все еще не повод просто принимать участие в нарушении прав работника, как и не прилагать усилий для помощи, сваливая все на него одного.
Понимаю, видимо я слишком буквально воспринял эту часть :)
Я согласен с многими пунктами вашего материала, но вот это просто режет глаз:
Важно понимать, что в таком случае менеджмент поступает с руководителем таким же образом, как и с увольняемым.
И я считаю (и сам так делаю), что задача руководителя, помимо прочих - защищать интересы сотрудника, даже если его вскоре уволят.
Намного интереснее смотреть, как от атак на ARP защищаются пятью разными способами, пока где-нибудь рядом летят IPv6 RA от злоумышленника.
Ну, классика, в целом, в самом начале статьи:
Проблемы от недооценки рисков, отсутствия DR стратегии и, видимо, экономии на специалистах.
Хорошо ещё, если после таких инцидентов выводы действительно делаются.
Интересно будет, когда модель отправит что-нибудь типа:
Не говоря о том, что пайп - это валидная конструкция для bash.
Чтобы их не забывать, ими нужно пользоваться. А чтобы вспомнить, есть man.
Эта задача решается одним скриптом на bash, а не обращением к LLM.
В таком случае, да, выглядит разумным решением.
Это скорее повод задуматься об изоляции нагрузок. Например, через виртуализацию, контейнеры или те же cgroups.
Этим же админам лучше оставить и развертывание серверов, мониторинг и оценку состояния систем :)
А еще не помешало бы предварительно сделать нагрузочные тесты и увидеть работу page cache там.
И available при этом ещё 30 gb?
Если вы постоянно пишете с sync, далеко масштабировать свое решение у вас не получится - IO дисков кончится раньше.
Для управления page cache есть vm.dirty, как минимум.
Собрали бы cloud-init образ сами, это ведь намного интереснее, чем загрузить готовый. Возможностей автоматизации после старта там огромное количество и все это гибко настраивается под нужды среды или задачи образа.
Кстати, всю конфигурацию VM в PVE можно (и удобнее :) делать через этот же qm.