В целом полностью разделяю подход, сейчас ваяю себе приложение, и из таких же параноидальных соображений выбрал знакомый стек. Пока даже пришлось пару раз лезть в код. Чувства полёта и лёгкости вкупе с "не так чихнуло" подтверждаю)
Я как-то даже не сразу понял, что именно меня так триггернуло.
Во-первых, в статье смешаны реальные проблемы (типа мертвого РНР) и хрень в виде "не можем сделать ультраприложение". То есть дана не вся правда, а ровно столько её, чтобы бОльшая часть читателей решила, что остальные высказывания тоже правда. А это ну вот совсем не так.
Да и по поводу пыхи тут ситуация двоякая. Конечно, для прицельной атаки это прямо подарок... Но в далёком 2017 году был у меня клиент, который идейно сидел на 98 винде по соображениям "да под неё малварь-то уже и вымерла". И, как ни странно, ни одного червя там я не видел, хотя пытался найти регулярно. Так что это в какой-то извращённой мере может быть безопасно.
По поводу МС рядом - гладко было на бумаге. Начиная от квалификации того, кто модуль пишет, заканчивая квалификацией того, кто составляет требования, основываясь на артефактах седой древности, которых может и не быть. То есть это, опять же, замена стабильно работающего модуля ради неизвестно чего. Может, там вообще всё в докере крутится и безопасностью обмазано так, что внутри хоть гопак пляши - выхлоп нулевой будет (да, вряд ли, но оставим такой шанс). Смысл тогда это переводить на что-то другое? Одни операционные расходы.
Ну и это банки, как-никак. Если у них требование регулятора исполняется другими методами - то, опять же, с точки зрения пользователя черного ящика, мне по барабану, из латуни внутри шестерёнки или из модного титано-вольфрамового сплава.
С первых строк не покидало ощущение "Что я, блин, читаю?" То есть кол, который стабильно работает 15 и больше лет - это проблема, а решение - современные пикосервисы, которые рестартятся раз в час или приложения на электроне, которые жрут 2 гига рамы, чтобы показать пару цифр? Автор, если эит кликбейт - то он удался. Если статья на полном серьёзе - то тут, кажется, все очень плохо с логикой и инженерным подходом...
Задумка хорошая, но это костыль. Вместо ограничения по количеству хранимых джобов, которое есть в самой спеке, например, вы тащите сторонний инструмент или обмазываетесь скриптами.
С ручным созданием манифестов при наличии хелма вообще не ясно - это системная проблема, которую вы вообще не решаете, подпирая тем же костылем.
Короче, инструмент вроде интересный - для тех, у кого проблемы с освоением основного тулсета.
GitOps по умолчанию менее устойчив а распиздяйству, вот и всё. В чистое вон, "полный контекст в пулл реквесте", "тщательно анализируют"... Ну то классический случай столкновения хорошей идеи с реальным миром. В реальности будут пуши в ветку напрямую, десятки коммитов с комментариями "1" или "test", аппрув МР будет по принципу "вроде норм" - и не потому, что все такие плохие, а потому, что лучшие практики - это хорошо, но в беклоге ещё 100500 задач, которые нужны вчера, и надо быстро работу работать, а не (допишите сами).
Плюс один очевидный минус лично для меня - не прямая связь между " внесли изменения" и "всё упало". Если при запуске джобы в дженкинсе ты чётко видишь результат действий и джобы, то в деплое через гит, например, может стоять таймаут полчаса, за который ещё десяток коммитов будет (если команда большая или работа интенсивная). И сиди разбирайся потом, после чего именно развертывание легло. Ну и отдельные алерты на такие падения нужны, именно по этой причине.
Плюс не раскрыта тема гитопса в применении к созданию инфраструктуры, там вообще граблей миллион.
> Кубконфиг кладется в /root/.kube/config и контекст докер билда не захватывает эту папку. Или вы чтото другое имели в виду? Другое, да. Я про конфиг который web.config, его лучше монтировать как файл из configmap куба. Ну а в идеале перейти на конфигурацию из env-переменных, но это выходит за рамки этого проекта и обсуждения)
> В случае с * придется делать отдельный поддомен. А из за этого как минимум Cloudflare не будет генерировать сертификат. Но в целом тоже рабочий вариант конечно, как-то давно использовал такое
Ну тут такое, серты можно генерить другими способами. Но да, тут аргумент принимается. Просто впервые вижу использование edns для такого масштаба, удивился.
> В статье ведь был был не сложный проект как пример, схема в целом рабочая и для большего числа приложений
"В целом рабочая" - это достаточно большой класс схем с костылями и усложнениями разного масштаба. KISS - наше всё. А то посмотришь, как предыдущие девопсы в компании напилили после таких гайдов - и рыдать хочется. Мой фаворит - это докер, внутри которого puppet, который запускает ansible, который дёргает helm, который после себя вызывает kustomize, после чего ямлы идут в кластер и там изменяются с помощью мутатора в кластере. Тоже схема-то "в целом рабочая")
Вьетнамские флешбеки. Собирал когда-то такую штуку вдвоём с отцом, как раз на 8 диодов сторону. Исплевался. Проблема в том, что конструкция дюже хрупкая с неремонтопригодная: если вылетит диод внутри, надо разбирать и собирать обратно половину Куба, то есть делать под 400 паек. Так что заголовок не врет - и правда для сильных духом.
Что я только что прочитал? SMS - резервный способ оповещения! То есть если интернет есть - лучше слать через какой-то tg, а если его нет (о чем, в целом, и надо быью послать оповещение) - то и смс не уйдут. Так что коллега выше прав полностью.
Таки да. И чем меньше там контроля и понимания работы ГАП, тем более лезет трэшак и синдром "яскозал". Как сказал один мой знакомый девопёс (правда, не из МТС, но из другого крупняка), который разрабатывает "универсальную платформу для пайплайнов" - "Ты же знаешь, нашу систему приятней разрабатывать, чем использовать". Для меня это теперь исчерпывающее определение всего "крутого интеграторства", что сделано в больших ИТ и псевдо-ИТ корпорациях.
Что подробней? Про авторитарное управление? Про навязывание своих решений под соусом "всё, что вы бы не внедрили сами - хрень, наше лучше!"? Про синдром бога? Нет, нельзя, пардоньте.
Скажем так, стиль управления у них и инженерные практики такие, что в принципе ломают инженеров. Таких будет крайне тяжко учить думать самим, если нанять.
Так-то да, нативные языки лучше. Но надо учитывать такую вещь, как "отраслевой стандарт". Если вы готовы на несколько месяцев дольше искать человека в случае необходимости замены или расширения команды - то никаких проблем. Job security разными методами достигается.
Вайб-читатели отметились.
В целом полностью разделяю подход, сейчас ваяю себе приложение, и из таких же параноидальных соображений выбрал знакомый стек. Пока даже пришлось пару раз лезть в код. Чувства полёта и лёгкости вкупе с "не так чихнуло" подтверждаю)
Погалаю, то же, что обычно - подняли комиссии.
Очевидный совет: сначала собрать схему на коленке, чтобы понять, что вообще работает, а потом уже с корпусами заморачиваться.
А так - да, самостоятельная разработка устройства выглядит простой, пока в это не погрузишься. Удачи, коллега-инженер)
Несколько. Посмотрел в истории бота - Ануб'Арак, Король Лич, Смертокрыл и Марадёр из DOOM. Главное для меня было, чтобы голос был низкий.
Наверное, всё же "зуд"?)
Я как-то даже не сразу понял, что именно меня так триггернуло.
Во-первых, в статье смешаны реальные проблемы (типа мертвого РНР) и хрень в виде "не можем сделать ультраприложение". То есть дана не вся правда, а ровно столько её, чтобы бОльшая часть читателей решила, что остальные высказывания тоже правда. А это ну вот совсем не так.
Да и по поводу пыхи тут ситуация двоякая. Конечно, для прицельной атаки это прямо подарок... Но в далёком 2017 году был у меня клиент, который идейно сидел на 98 винде по соображениям "да под неё малварь-то уже и вымерла". И, как ни странно, ни одного червя там я не видел, хотя пытался найти регулярно. Так что это в какой-то извращённой мере может быть безопасно.
По поводу МС рядом - гладко было на бумаге. Начиная от квалификации того, кто модуль пишет, заканчивая квалификацией того, кто составляет требования, основываясь на артефактах седой древности, которых может и не быть. То есть это, опять же, замена стабильно работающего модуля ради неизвестно чего. Может, там вообще всё в докере крутится и безопасностью обмазано так, что внутри хоть гопак пляши - выхлоп нулевой будет (да, вряд ли, но оставим такой шанс). Смысл тогда это переводить на что-то другое? Одни операционные расходы.
Ну и это банки, как-никак. Если у них требование регулятора исполняется другими методами - то, опять же, с точки зрения пользователя черного ящика, мне по барабану, из латуни внутри шестерёнки или из модного титано-вольфрамового сплава.
>frameset на фронте
>отсутствие адаптивной верстки
>стек, который стабильно работает 20+ лет
>АААААА, КОТОСТРОФА!
С первых строк не покидало ощущение "Что я, блин, читаю?" То есть кол, который стабильно работает 15 и больше лет - это проблема, а решение - современные пикосервисы, которые рестартятся раз в час или приложения на электроне, которые жрут 2 гига рамы, чтобы показать пару цифр? Автор, если эит кликбейт - то он удался. Если статья на полном серьёзе - то тут, кажется, все очень плохо с логикой и инженерным подходом...
Спасибо за статью. Как раз сейчас бьюсь над своим компонентом и, кажется, наконец вижу свет в конце тоннеля.
Нифига себе, вы уже аж три этажа себе отжали?) Молодцы.
Задумка хорошая, но это костыль. Вместо ограничения по количеству хранимых джобов, которое есть в самой спеке, например, вы тащите сторонний инструмент или обмазываетесь скриптами.
С ручным созданием манифестов при наличии хелма вообще не ясно - это системная проблема, которую вы вообще не решаете, подпирая тем же костылем.
Короче, инструмент вроде интересный - для тех, у кого проблемы с освоением основного тулсета.
DevOps возник как ответ на уход в облако? Серьёзно?
Ух ёпт, helm консервативным назвали...
GitOps по умолчанию менее устойчив а распиздяйству, вот и всё. В чистое вон, "полный контекст в пулл реквесте", "тщательно анализируют"... Ну то классический случай столкновения хорошей идеи с реальным миром. В реальности будут пуши в ветку напрямую, десятки коммитов с комментариями "1" или "test", аппрув МР будет по принципу "вроде норм" - и не потому, что все такие плохие, а потому, что лучшие практики - это хорошо, но в беклоге ещё 100500 задач, которые нужны вчера, и надо быстро работу работать, а не (допишите сами).
Плюс один очевидный минус лично для меня - не прямая связь между " внесли изменения" и "всё упало". Если при запуске джобы в дженкинсе ты чётко видишь результат действий и джобы, то в деплое через гит, например, может стоять таймаут полчаса, за который ещё десяток коммитов будет (если команда большая или работа интенсивная). И сиди разбирайся потом, после чего именно развертывание легло. Ну и отдельные алерты на такие падения нужны, именно по этой причине.
Плюс не раскрыта тема гитопса в применении к созданию инфраструктуры, там вообще граблей миллион.
> Кубконфиг кладется в /root/.kube/config и контекст докер билда не захватывает эту папку. Или вы чтото другое имели в виду?
Другое, да. Я про конфиг который web.config, его лучше монтировать как файл из configmap куба. Ну а в идеале перейти на конфигурацию из env-переменных, но это выходит за рамки этого проекта и обсуждения)
> В случае с * придется делать отдельный поддомен. А из за этого как минимум Cloudflare не будет генерировать сертификат. Но в целом тоже рабочий вариант конечно, как-то давно использовал такое
Ну тут такое, серты можно генерить другими способами. Но да, тут аргумент принимается. Просто впервые вижу использование edns для такого масштаба, удивился.
> В статье ведь был был не сложный проект как пример, схема в целом рабочая и для большего числа приложений
"В целом рабочая" - это достаточно большой класс схем с костылями и усложнениями разного масштаба. KISS - наше всё. А то посмотришь, как предыдущие девопсы в компании напилили после таких гайдов - и рыдать хочется. Мой фаворит - это докер, внутри которого puppet, который запускает ansible, который дёргает helm, который после себя вызывает kustomize, после чего ямлы идут в кластер и там изменяются с помощью мутатора в кластере. Тоже схема-то "в целом рабочая")
А смысл здесь от ансиболи? Шаблонизировать можно хелмом, тем более что конфиг в кубе можно и нужно передавать извне, а не запекать в докере.
Более того, external dns не нужен, для такого масштаба проекта проще сделать запись со * с dns.
Пока выглядит как переусложненное решение тестового задания на девопса, которое можно было сделать гораздо проще и правильнее.
Вьетнамские флешбеки. Собирал когда-то такую штуку вдвоём с отцом, как раз на 8 диодов сторону. Исплевался. Проблема в том, что конструкция дюже хрупкая с неремонтопригодная: если вылетит диод внутри, надо разбирать и собирать обратно половину Куба, то есть делать под 400 паек. Так что заголовок не врет - и правда для сильных духом.
Что я только что прочитал? SMS - резервный способ оповещения! То есть если интернет есть - лучше слать через какой-то tg, а если его нет (о чем, в целом, и надо быью послать оповещение) - то и смс не уйдут. Так что коллега выше прав полностью.
Таки да. И чем меньше там контроля и понимания работы ГАП, тем более лезет трэшак и синдром "яскозал". Как сказал один мой знакомый девопёс (правда, не из МТС, но из другого крупняка), который разрабатывает "универсальную платформу для пайплайнов" - "Ты же знаешь, нашу систему приятней разрабатывать, чем использовать". Для меня это теперь исчерпывающее определение всего "крутого интеграторства", что сделано в больших ИТ и псевдо-ИТ корпорациях.
Что подробней? Про авторитарное управление? Про навязывание своих решений под соусом "всё, что вы бы не внедрили сами - хрень, наше лучше!"? Про синдром бога? Нет, нельзя, пардоньте.
Скажем так, стиль управления у них и инженерные практики такие, что в принципе ломают инженеров. Таких будет крайне тяжко учить думать самим, если нанять.
Так-то да, нативные языки лучше. Но надо учитывать такую вещь, как "отраслевой стандарт". Если вы готовы на несколько месяцев дольше искать человека в случае необходимости замены или расширения команды - то никаких проблем. Job security разными методами достигается.