Я как-то даже не сразу понял, что именно меня так триггернуло.
Во-первых, в статье смешаны реальные проблемы (типа мертвого РНР) и хрень в виде "не можем сделать ультраприложение". То есть дана не вся правда, а ровно столько её, чтобы бОльшая часть читателей решила, что остальные высказывания тоже правда. А это ну вот совсем не так.
Да и по поводу пыхи тут ситуация двоякая. Конечно, для прицельной атаки это прямо подарок... Но в далёком 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 разными методами достигается.
Очень интересно (нет). Пожалуйста, больше никогда не делайте на хабре подобный кликбейт.
Ожидал тут увидеть хотя бы упоминание про Эадор, но его внезапно нет. Странно.