Информирую. Не было никаких проблем с выписыванием ру сертификатов от LE. Ни в 23, ни в 24, ни в 25. Могут ли появиться? Ну, теоретически - да, тут правы. Но это будет означать масштабную войну в интернете и уже нарушение сетевого нейтралитета. Не только ведь российские фирмы имеют ру домены.
Касательно ошибки. Если процесс правильно настроен - ты узнаешь о невыпуске сертификата не в последний момент, а за неделю. Что дает шанс на реакцию. По платным - они не страхуют от «забыли», «не оплатили» итп.
Я сказал - в нашем случае выигрыш был 10х. Что на диапазоне в несколько часов дает десятки минут. Не то, чтобы супер, но хорошо. И явно лучше, чем поддерживать баш портянки. А за счет внедрения sentry (можно otel) - увеличилось качество обработки данных, так как ошибки стало возможно ловить и потом обрабатывать.
Касательно башни - там еще проблема, что когда у вас много скриптов, которые выполняются малое время (минуты) - потери на запуск достаточно ощутимые. Решение? Ну, я уже высказался.
Нет, чтобы переписать обработку на нормальный язык. Условно был - баш скрипт. Стала моно программа с аргументами на голанге. За счёт компиляции, быстрой загрузки и параллельности обработки - мы получили выигрыш до 10х на тех же задачах. Там уже скорее веселуха в том, что если база медленная - она прикладывается ) но это совсем другая проблемка, правда ? И это в далеком 2017….
Я бы оценил вероятность применения ИИ при подготовке этой статьи примерно в 60–70%.
Короткое обоснование: Текст структурирован по шаблону («введение → преимущества → проблемы → будущее»), использует ровный, “обезличенный” стиль без личного опыта и конкретных кейсов, что типично для генерации или сильной правки черновика от ИИ. В то же время терминология корректна, ошибок почти нет, а это указывает на возможную доработку человеком.
Cloud4Y дизлайк, отписка, шейм. Приближаете цифровую сингулярность. Я даже представить себе не могу, что будет, когда нейронка будет учиться на продуктах жизнедеятельности следующего поколения нейронок, а они - на результатах нейронок современности.
А это означает, что еще до написания кода все участники доставки ценности понимают, где сервис будет запущен, каким принципам должен соответствовать, каковы принципы межсервисного взаимодействия. Таким образом, общий контекст разработчиков/тестировщиков/админов — важная составляющая, которая существенно сокращает time-to-market.
поддержу! Я где-то в статьях на хабре видел тезис, что кубернетес стал lingua franca - общим языком между разработкой и эксплуатацией.
Данные процедуры, если автоматизировать, то займут вместе с тестами, тонну процессорного времени(и денег за ресурсы), что явно говорит о том что нужно выносить тестовую инфру на локальный сервер для тестирования и получения бОльшего контроля.
очень странный тезис. Учитывая, что в случае облака - можно дешево брать спотовые и прерываемые инстансы, которые идеально подходят для такого рода применений. А еще учитывая тот факт, что сборки обычно идут в рабочее время (но это зависит от типа организации), а сервера жгут электричество 24/7, что вызывает соблазн, либо унифицировать ресурсы (и гонять по ночам, например, аналитику), или как раз сделать скейлинг вверх и вниз.
реальная жизнь - из известных мне крупных контор - фряха есть только у CloudFlare вот. Почему? Потому что "индустрия порешал. ". Если что-то есть сказать по делу - можете подать свою заявку на https://cfp.devopsconf.io/ 2026 года, коллеги будут рады посмотреть на альтернативный мир...
При том, что даже такая якобы базовая технология как линукс требует знаний. Жаль, что не ввели сертификация до допуска до клавиатуры.
на тестах тот же selinux вырублен ибо тест даже не знает, что такое интернет
очень жаль. Вы попались. Это примерно как говорить. Я не буду мыть руки после личного туалета. А после общественного буду. Ну, а чо такова ? В случае с тестом: во-первых, часто тест резко становится продом, или он рядышком, что позволяет так называемое lateral movement. Во-вторых, отсутствие интернета не индульгенция. В третьих, если на тесте другая конфигурация, чем на проде - мы знаем к чему это приводит.
Насчет фрибсд и ее перформанса - полностью согласен, но где вы ее реально видите вокруг ? Все собирают сервера на линуксе + nginx / envoy / haproxy и хорошо, если действительно исповедуют принцип один сервер одна роль, а не делают таких вот универсальных бойцов
Дальше даже комментировать не хочется, потому что это подобно бисеру и свиньям.
которые друг от друга зависят и вот тут куберовский "автовозврат" может сломать вообще всю базу к чертовой матери потому что он то не знает что вот этот под можно откатить, а вот тот нельзя, а завтра наоборот
какой-то набор шаблонов, которые вы удачно тиражируете. Короче, проблема не в том, что "Кубер в первую очередь прям отличный для тех же хостингов и подобного". Вообще никак. А в том, что это новая абстракция, с которой тупо надо научиться работать. Типичные проблемы при кубернетизации приложения: засунули стейтфул, забыли вольюмы (ну, это при докеризации происходит). Забыли реквесты-лимиты (но это в целом проблема на любом шареном хосте, когда напихали nginx+mysql+backend и процессы начали друг на друга лезть на нагрузке). Стратегия Rolling Update, когда приложение не умеет во много реплик. И так далее. В целом - когда мигрируешь на линукс, то у тебя все то же самое, только с другой стороны. SELinux - надо готовить, иначе проблемы. Народ же просто по туториалам отключает, а потом удивляется - а чо нас взломали. Система прав на ФС. Давайте бахнем 777 на crontab. А потом черви. Или давайте положим .git в web-сервер (вообще нерелевантно ни к куберу, но к докеру, но типичная ошибка). И так далее. И на самом деле - кубер при базовом использовании не так уж и сложен, как хочется показать тем, кто все еще сидит на ансибле и не считает, что "на 2 сервера нужен кубернетес". Может и нужен. А может и не нужен. Но ответ в совершенно другой плоскости. Вы же всерьез не выбираете уже в 2025 году - брать линукс или фрибсд для обычных задач, правда? Здесь так же. Кто не изучит кубер, завтра будет за пределами рынка труда. И точка.
Ога, а когда в проде всего 2 реальных железяки и они справляются, тоже купер натягивать?
можно. k3s + пачка ямлов и поехали. Всяко лучше, чем ансибл.
Все технологии хороши, но пока настроишь все эти хелмы и прочее посидеешь
гы. Ну, типа если у тебя кубер везде - нет проблемы его настроить и на "2 реальных железках". Если ты его только на картинках в букваре видел... ну, так у тебя и с линуксом тогда проблемы будут... если линукс умеешь и кубер не умеешь - да, но вроде уже все изучили
Звучит круто, но есть нюанс: освоить и поддерживать Kubernetes в продакшене сложно.
Замени кубернетес на любую технологию, например, линукс - ничего не изменится. Тогда почему именно кубернетес сложный ? Непонятно. Решительно непонятно.
Кажется, что компания "Пульт" просто хочет завендорлочить своих клиентов, вот и весь сказ.
так это желание любой компании. Компании графана тоже. Посмотрите на их опенсорс - он специально сделан так, чтобы вы максимально быстро захотели поехать в облако. Тот же Темпо и Локи…
В первом случае ты готов, к тому, что что-то пойдет не так. И бизнес тоже в курсе.
Во втором случае ты якобы спокоен, но весь operations - это решение всяких неожиданных проблем, 24/7. Так что от пейджера уже скоро вздрагивать начинаешь.
Не хватает аналогии с живыми организмами. Именно поэтому мы рождаемся и умираем, чтобы экспериментировать и не накапливать ошибки. Каждый акт рождения - это процесс сброса, обнуления.
Тоже не понимаю этого высокомерия, типа баш должен умереть
Должен, потому что что-либо длиннее 10 строчек на нем становится write only, как перл. Не говоря уже о разнице тулингов между Макось и Линуксом. Ни на что нельзя рассчитывать заранее. Все таки библиотеки вроде пайтоновских сглаживают эти различия и там тесты удобнее писать на разные случаи, то есть получается более качественный код.
Информирую. Не было никаких проблем с выписыванием ру сертификатов от LE. Ни в 23, ни в 24, ни в 25. Могут ли появиться? Ну, теоретически - да, тут правы. Но это будет означать масштабную войну в интернете и уже нарушение сетевого нейтралитета. Не только ведь российские фирмы имеют ру домены.
Касательно ошибки. Если процесс правильно настроен - ты узнаешь о невыпуске сертификата не в последний момент, а за неделю. Что дает шанс на реакцию. По платным - они не страхуют от «забыли», «не оплатили» итп.
Тогда это будет летс енд крип и придется умолять минцифры сделать acme подобное. Кстати, это уже случилось? Или вы только будущее предсказываете ? )
Я сказал - в нашем случае выигрыш был 10х. Что на диапазоне в несколько часов дает десятки минут. Не то, чтобы супер, но хорошо. И явно лучше, чем поддерживать баш портянки. А за счет внедрения sentry (можно otel) - увеличилось качество обработки данных, так как ошибки стало возможно ловить и потом обрабатывать.
Касательно башни - там еще проблема, что когда у вас много скриптов, которые выполняются малое время (минуты) - потери на запуск достаточно ощутимые. Решение? Ну, я уже высказался.
Нет, чтобы переписать обработку на нормальный язык. Условно был - баш скрипт. Стала моно программа с аргументами на голанге. За счёт компиляции, быстрой загрузки и параллельности обработки - мы получили выигрыш до 10х на тех же задачах. Там уже скорее веселуха в том, что если база медленная - она прикладывается ) но это совсем другая проблемка, правда ? И это в далеком 2017….
Ты точно не выдрал фразу из моих уст ? Но вообще ответ в статье есть - они это делали еще, когда эйрфлоу был маленький.
зато собрали ройал флеш из всех баззвордов.
Cloud4Y дизлайк, отписка, шейм. Приближаете цифровую сингулярность. Я даже представить себе не могу, что будет, когда нейронка будет учиться на продуктах жизнедеятельности следующего поколения нейронок, а они - на результатах нейронок современности.
поддержу! Я где-то в статьях на хабре видел тезис, что кубернетес стал lingua franca - общим языком между разработкой и эксплуатацией.
очень странный тезис. Учитывая, что в случае облака - можно дешево брать спотовые и прерываемые инстансы, которые идеально подходят для такого рода применений. А еще учитывая тот факт, что сборки обычно идут в рабочее время (но это зависит от типа организации), а сервера жгут электричество 24/7, что вызывает соблазн, либо унифицировать ресурсы (и гонять по ночам, например, аналитику), или как раз сделать скейлинг вверх и вниз.
Очень круто !
Пара вопросов для разогрева:
Node Maintenance Operator - Вы в опенсурс вернули то, что там исправили и дописали ?
Были ли случаи, когда автоматика делала не то, что хотели, или приводила к более серьезному отказу, чем она должна была предотвратить?
реальная жизнь - из известных мне крупных контор - фряха есть только у CloudFlare вот. Почему? Потому что "индустрия порешал. ". Если что-то есть сказать по делу - можете подать свою заявку на https://cfp.devopsconf.io/ 2026 года, коллеги будут рады посмотреть на альтернативный мир...
При том, что даже такая якобы базовая технология как линукс требует знаний. Жаль, что не ввели сертификация до допуска до клавиатуры.
очень жаль. Вы попались. Это примерно как говорить. Я не буду мыть руки после личного туалета. А после общественного буду. Ну, а чо такова ? В случае с тестом: во-первых, часто тест резко становится продом, или он рядышком, что позволяет так называемое lateral movement. Во-вторых, отсутствие интернета не индульгенция. В третьих, если на тесте другая конфигурация, чем на проде - мы знаем к чему это приводит.
Насчет фрибсд и ее перформанса - полностью согласен, но где вы ее реально видите вокруг ? Все собирают сервера на линуксе + nginx / envoy / haproxy и хорошо, если действительно исповедуют принцип один сервер одна роль, а не делают таких вот универсальных бойцов
Дальше даже комментировать не хочется, потому что это подобно бисеру и свиньям.
какой-то набор шаблонов, которые вы удачно тиражируете. Короче, проблема не в том, что "Кубер в первую очередь прям отличный для тех же хостингов и подобного". Вообще никак. А в том, что это новая абстракция, с которой тупо надо научиться работать. Типичные проблемы при кубернетизации приложения: засунули стейтфул, забыли вольюмы (ну, это при докеризации происходит). Забыли реквесты-лимиты (но это в целом проблема на любом шареном хосте, когда напихали nginx+mysql+backend и процессы начали друг на друга лезть на нагрузке). Стратегия Rolling Update, когда приложение не умеет во много реплик. И так далее. В целом - когда мигрируешь на линукс, то у тебя все то же самое, только с другой стороны. SELinux - надо готовить, иначе проблемы. Народ же просто по туториалам отключает, а потом удивляется - а чо нас взломали. Система прав на ФС. Давайте бахнем 777 на crontab. А потом черви. Или давайте положим .git в web-сервер (вообще нерелевантно ни к куберу, но к докеру, но типичная ошибка). И так далее. И на самом деле - кубер при базовом использовании не так уж и сложен, как хочется показать тем, кто все еще сидит на ансибле и не считает, что "на 2 сервера нужен кубернетес". Может и нужен. А может и не нужен. Но ответ в совершенно другой плоскости. Вы же всерьез не выбираете уже в 2025 году - брать линукс или фрибсд для обычных задач, правда? Здесь так же. Кто не изучит кубер, завтра будет за пределами рынка труда. И точка.
можно. k3s + пачка ямлов и поехали. Всяко лучше, чем ансибл.
гы. Ну, типа если у тебя кубер везде - нет проблемы его настроить и на "2 реальных железках". Если ты его только на картинках в букваре видел... ну, так у тебя и с линуксом тогда проблемы будут... если линукс умеешь и кубер не умеешь - да, но вроде уже все изучили
Замени кубернетес на любую технологию, например, линукс - ничего не изменится. Тогда почему именно кубернетес сложный ? Непонятно. Решительно непонятно.
так это желание любой компании. Компании графана тоже. Посмотрите на их опенсорс - он специально сделан так, чтобы вы максимально быстро захотели поехать в облако. Тот же Темпо и Локи…
В первом случае ты готов, к тому, что что-то пойдет не так. И бизнес тоже в курсе.
Во втором случае ты якобы спокоен, но весь operations - это решение всяких неожиданных проблем, 24/7. Так что от пейджера уже скоро вздрагивать начинаешь.
Не хватает аналогии с живыми организмами. Именно поэтому мы рождаемся и умираем, чтобы экспериментировать и не накапливать ошибки. Каждый акт рождения - это процесс сброса, обнуления.
Должен, потому что что-либо длиннее 10 строчек на нем становится write only, как перл. Не говоря уже о разнице тулингов между Макось и Линуксом. Ни на что нельзя рассчитывать заранее. Все таки библиотеки вроде пайтоновских сглаживают эти различия и там тесты удобнее писать на разные случаи, то есть получается более качественный код.
Есть опыт полнотекстового поиска не хуже, чем в Эластике.