Forwarded from Технологический Болт Генона
Как-то я пропустил, но тут в сентябре наконец-то выпустили Falco Talon условно стабильной версии.
Falco, если кратко, мониторит системные вызовы, анализирует что происходит и выдаёт предупреждение, если что-то нарушает его правила (делает это не только для Kubernetes, но и хоста).
Раньше, после того как Falco стриггерился на что-то, надо было придумать как на алерт реагировать. Так же Falco не позволял выстроить цепочку событий, которая бы объясняла, как к событию в алерте пришли.
Например, об этом рассказывал @gecube тут
https://youtu.be/uKX8TaLJK6E?t=293
Ответом на запрос в контексте реагирования появился Falco Talon
Introducing Falco Talon v0.1.0
https://falco.org/blog/falco-talon-v0-1-0/
Если кратко, то как это работает (схематично на первой картинке)
https://docs.falco-talon.org/docs/actionners/list/
Как это можно применять можно почитать в посте от Sysdig
Optimizing Wireshark in Kubernetes
https://sysdig.com/blog/optimizing-wireshark-in-kubernetes/
Там они рассказали, как дампили трафик с помощью Wireshark, отправляли в Falco, а потом с помощью Falco Talon реагировали на то что происходит.
В посте, где рассказывают про релиз, показан пример со складированием трафика в Amazon S3 (на второй картинке)
GitHub
https://github.com/falcosecurity/falco-talon
Документация
https://docs.falco-talon.org/
Falco, если кратко, мониторит системные вызовы, анализирует что происходит и выдаёт предупреждение, если что-то нарушает его правила (делает это не только для Kubernetes, но и хоста).
Раньше, после того как Falco стриггерился на что-то, надо было придумать как на алерт реагировать. Так же Falco не позволял выстроить цепочку событий, которая бы объясняла, как к событию в алерте пришли.
Например, об этом рассказывал @gecube тут
https://youtu.be/uKX8TaLJK6E?t=293
Ответом на запрос в контексте реагирования появился Falco Talon
Falco Talon is a Response Engine for managing threats in Kubernetes clusters. It enhances the solutions proposed by the Falco community with a no-code tailor-made solution. With easy rules, you can react to events from Falco in milliseconds.
Introducing Falco Talon v0.1.0
https://falco.org/blog/falco-talon-v0-1-0/
Если кратко, то как это работает (схематично на первой картинке)
Falco ловит событие, которое прокидывается на falco-talon (можно через sidekick). После этого, согласно настроенным actionner выполняется действие. На данный момент список поддерживаемый- kubernetes:terminate
- kubernetes:label
- kubernetes:networkpolicy
- kubernetes:exec
- kubernetes:script
- kubernetes:log
- kubernetes:delete
- kubernetes:drain
- kubernetes:download
- kubernetes:tcpdump
- aws:lambda
- calico:networkpolicy
- cilium:networkpolicy
https://docs.falco-talon.org/docs/actionners/list/
Как это можно применять можно почитать в посте от Sysdig
Optimizing Wireshark in Kubernetes
https://sysdig.com/blog/optimizing-wireshark-in-kubernetes/
Там они рассказали, как дампили трафик с помощью Wireshark, отправляли в Falco, а потом с помощью Falco Talon реагировали на то что происходит.
В посте, где рассказывают про релиз, показан пример со складированием трафика в Amazon S3 (на второй картинке)
GitHub
https://github.com/falcosecurity/falco-talon
Документация
https://docs.falco-talon.org/
🔥3❤1👍1
Forwarded from запуск завтра
Аналогичная штука для командной строки — Warp. Терминал с нормальной поддержкой AI.
Одну из ключевых идей Юникс можно понять за минуту: каждая программа должна уметь делать только одну вещь и делать её хорошо. Программы можно комбинировать, передавая результат работы первой как входные данные для второй, создавая сколь угодно длинные цепочки.
По сути, ты получаешь в руки набор кубиков Lego и каждый раз собираешь именно ту программу, которую нужна тебе прямо сейчас. Безграничные возможности.
К сожалению, в отличие от деталек Лего, которые различаются только шириной, высотой и длиной, и которые можно окинуть взглядом разложив на столе, Юникс программ огромное множество и особенности их поведения контролируется ключами, которых у каждой могут быть десятки.
Конечно, если проводишь в командной строке весь день — то большинство знаний отпечатываются на подкорке, входят в мышечную память.
Если никогда не чувствовал мощь шелла под своими пальцами, то это, наверное, как рассказывать вкус халвы тому, кто ни разу её не пробовал. И не так грустно, что у тебя ее нет. Но без практики все знания теряются.
Последние годы я часто обнаруживаю себя в ситуации, когда знаю, что задачу можно решить с помощью Шела за пару минут, но трачу полчаса на поиск нужных команд и ключей.
Warp возвращает мне эти знания, а порой подсказывает вещи, которых и я не знал никогда.
—
На практике, вместо написания команд можно нажать шорткат и сказать, что хочешь получить — на английском — и Warp предлагает тебе команду.
При этом у него есть контекст происходящего — что ты делал раньше и каким был результат. Можно прямо сказать «там че-то homebrew ругается, почини». И он чинит!
А ещё у него обычный ввод текста, не readline, так что можно наконец редактировать длинные многострочные команды прямо в нем.
Я сижу на бесплатном тарифе — 100 AI-запросов в месяц, дальше от 15$ в месяц. Пока только для Mac и Linux, Windows версию обещают скоро.
Одну из ключевых идей Юникс можно понять за минуту: каждая программа должна уметь делать только одну вещь и делать её хорошо. Программы можно комбинировать, передавая результат работы первой как входные данные для второй, создавая сколь угодно длинные цепочки.
По сути, ты получаешь в руки набор кубиков Lego и каждый раз собираешь именно ту программу, которую нужна тебе прямо сейчас. Безграничные возможности.
К сожалению, в отличие от деталек Лего, которые различаются только шириной, высотой и длиной, и которые можно окинуть взглядом разложив на столе, Юникс программ огромное множество и особенности их поведения контролируется ключами, которых у каждой могут быть десятки.
Конечно, если проводишь в командной строке весь день — то большинство знаний отпечатываются на подкорке, входят в мышечную память.
Если никогда не чувствовал мощь шелла под своими пальцами, то это, наверное, как рассказывать вкус халвы тому, кто ни разу её не пробовал. И не так грустно, что у тебя ее нет. Но без практики все знания теряются.
Последние годы я часто обнаруживаю себя в ситуации, когда знаю, что задачу можно решить с помощью Шела за пару минут, но трачу полчаса на поиск нужных команд и ключей.
Warp возвращает мне эти знания, а порой подсказывает вещи, которых и я не знал никогда.
—
На практике, вместо написания команд можно нажать шорткат и сказать, что хочешь получить — на английском — и Warp предлагает тебе команду.
При этом у него есть контекст происходящего — что ты делал раньше и каким был результат. Можно прямо сказать «там че-то homebrew ругается, почини». И он чинит!
А ещё у него обычный ввод текста, не readline, так что можно наконец редактировать длинные многострочные команды прямо в нем.
Я сижу на бесплатном тарифе — 100 AI-запросов в месяц, дальше от 15$ в месяц. Пока только для Mac и Linux, Windows версию обещают скоро.
👎15👍6
Forwarded from DevOps Deflope News
Долгожданный релиз containerd 2.0 предлагает множество новых функций, включая поддержку плагинов для проверки образов и интеграцию с OpenTelemetry. Это первое мажорное обновление с 2017 года.
samuel.karp.dev
containerd 2.0 (and KubeCon NA 2024)
The containerd maintainers (including me) are happy to announce the release of containerd 2.0! This is the first major release of containerd since 1.0 was released in 2017, and represents a committment both to the evolution of the containerd project and continued…
🔥15
Forwarded from HABR FEED + OPENNET
Проверка готовности приложения к работе в реальном ненадежном мире. Часть 2 #habr
https://habr.com/ru/companies/slurm/articles/857144/
Tags: go, golang, приложение, tutorial
Author: Hedgehog_art (Слёрм)
https://habr.com/ru/companies/slurm/articles/857144/
Tags: go, golang, приложение, tutorial
Author: Hedgehog_art (Слёрм)
Хабр
Проверка готовности приложения к работе в реальном ненадежном мире. Часть 2
Вторая часть статьи, в которой Виталий Лихачёв, SRE в booking.com и спикер курса Слёрма «Golang-разработчик» рассказывает, о чём стоит подумать перед выкаткой сервиса в жестокий...
👍1
Forwarded from Go Library
👎1
Forwarded from DevOps FM
В своем блоге Адольфо поделился опытом работы с dockerfileless-образами контейнеров. Два главных урока, которые вы можете вынести из статьи:
1. It is a true pain to deal with OCI images manually.
2. Рeeking under the hood of container images will not void your warranty, and is a great way to get a better idea of what an OCI image actually is.
#devops #docker #контейнеры
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4🔥4
Forwarded from DevOpsConf Channel
Ops или Engineering?
Новый, с пылу, с жару выпуск подкаста с Игорем Курочкиным — членом Программного комитета DevOpsConf 2025. Обсуждали DevOps и развитие инжиниринговых практик.
Говорили бодро, также обсуждали NextOps, который не то, чем кажется! Вспомнили массу приятных книг и не только.
Слушайте 321 подкаст The Art of Programming🔄
iTunes
ВКонтакте
Яндекс Музыка
🖐️ CFP на DevOpsConf 2025 открыт
П.С. Cut-Cut 321. Ops или Engineering? тут.
Новый, с пылу, с жару выпуск подкаста с Игорем Курочкиным — членом Программного комитета DevOpsConf 2025. Обсуждали DevOps и развитие инжиниринговых практик.
Говорили бодро, также обсуждали NextOps, который не то, чем кажется! Вспомнили массу приятных книг и не только.
Слушайте 321 подкаст The Art of Programming
iTunes
ВКонтакте
Яндекс Музыка
🖐️ CFP на DevOpsConf 2025 открыт
П.С. Cut-Cut 321. Ops или Engineering? тут.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2👍1👎1
Forwarded from DevOps Deflope News
Вышел Jaeger v2. Новая версия интегрирует OpenTelemetry и предлагает пользователям улучшенные возможности обработки данных и упрощённое развёртывание: https://goo.su/GuMQln
👍2
Forwarded from Евгений Козлов пишет про IT (Eugene Kozlov)
CPU, Memory Models, Concurrency, Multiprocess, Multithreading и Async. Часть 11. Сравнение видов многозадачности
В прошлом посте было дано определение 2м основным видам многозадачности используемых в Computer Science. В этом посте хочется дать чуть больше пояснений и порассуждать где и почему они применяются.
Вытесняющая многозадачность реализована на уровне ОС, практически все системы которые я знаю реализуют подход с вытесняющей многозадачностью. Этот подход позволяет пользователю ощущать что все запущенные программы на компьютере работают параллельно (при наличии ядер процесссора, помним про SMP). А если не параллельно то как минимум конкуррентно, то есть каждой задаче выделяется ресурс "поработать" а дальше ОС останавлвает программу чтобы выделить ресурсы соседнему процессу.
Какие основные плюсы и минусы есть у данного подхода к мультизадачности:
- Плюс: невозможна ситуация когда ресуры системы голодают (starvation) в ожидании работы. Планировщик всегда найдет для процесса поток и ядро процессора для исполнения команд.
- Минус: наличие планировщика так или иначе дает оверхед.
Если переходить к кооперативности то тут основной плюс в том что переключениями может управлять разработчик (Ну или рантайм языка программирования, т.е нечто на уровне самой программы а не ядра ОС). И планировщика может и не быть вовсе. Но имея такую силу в своих руках можно получить ситуацию когда мы пишем кооперативный код который с легкостью заблокирует всю программу и не передаст возможность делать полезную работу дргим файберам в рамках процесса. По сути программа зависнет и придется ее перезапускать. Чуть менее критичная ситуация - starvation, когда файбер не передает ресурсы другим файберам хотя ему они сейчас не нужны (например он заблокировался на IO).
Так зачем вообще нужно использовать кооперативную многозадачность? Давайте использовать нативные треды операционной системы и не будем париться? За нас все сделает ОС. Такой подход вполне имеет право на жизнь, но он является достаточно дорогим с точки зрения ресурсов. Треды дороже с точки зрения памяти + ими управляет ОС и переключения между ними очень дорогие. При этом помним что при разработке серверных программ большое количество времени программа проводит в состоянии ожидания ввода-вывода и для эффективной утилизации ресурсов и комфортного пользовательского опыта важно чтобы во время простоя могли выполняться другие задачи на железе.
Для того чтобы программисты могли писать IO bound программы эффективнее разработчики языков и начали привносить в рантаймы различные легковесные примитивы. Но что произойдет в программе если мы сделаем блокирующий вызов (например запрос к БД)? Зависит от того как реализован рантайм конкретного языка программирования. Где то мы в ответ получаем Promise и продолжаем выполнение программы и заблочиться на нем в ожиданиии результата спустя время. В других языках реализованы специальные планировщики которые умеют детектировать файберы которые заблочились на IO и их можно безопасно снять с реального потока ОС и выделить время другим файберам. То есть по сути получаем некоторый микс из двух подходов, взяли лучшее из каждого.
А как быть с CPU Bound задачами? Никак, CPU задачи не масштабируются с помощью файберов. Чтобы разобраться почему приглашаю читать предыдущие посты с обсуждением процессора😊
На этом на сегодня всё, спасибо что читали, до встречи в следующих постах.😇
В прошлом посте было дано определение 2м основным видам многозадачности используемых в Computer Science. В этом посте хочется дать чуть больше пояснений и порассуждать где и почему они применяются.
Вытесняющая многозадачность реализована на уровне ОС, практически все системы которые я знаю реализуют подход с вытесняющей многозадачностью. Этот подход позволяет пользователю ощущать что все запущенные программы на компьютере работают параллельно (при наличии ядер процесссора, помним про SMP). А если не параллельно то как минимум конкуррентно, то есть каждой задаче выделяется ресурс "поработать" а дальше ОС останавлвает программу чтобы выделить ресурсы соседнему процессу.
Какие основные плюсы и минусы есть у данного подхода к мультизадачности:
- Плюс: невозможна ситуация когда ресуры системы голодают (starvation) в ожидании работы. Планировщик всегда найдет для процесса поток и ядро процессора для исполнения команд.
- Минус: наличие планировщика так или иначе дает оверхед.
Если переходить к кооперативности то тут основной плюс в том что переключениями может управлять разработчик (Ну или рантайм языка программирования, т.е нечто на уровне самой программы а не ядра ОС). И планировщика может и не быть вовсе. Но имея такую силу в своих руках можно получить ситуацию когда мы пишем кооперативный код который с легкостью заблокирует всю программу и не передаст возможность делать полезную работу дргим файберам в рамках процесса. По сути программа зависнет и придется ее перезапускать. Чуть менее критичная ситуация - starvation, когда файбер не передает ресурсы другим файберам хотя ему они сейчас не нужны (например он заблокировался на IO).
Так зачем вообще нужно использовать кооперативную многозадачность? Давайте использовать нативные треды операционной системы и не будем париться? За нас все сделает ОС. Такой подход вполне имеет право на жизнь, но он является достаточно дорогим с точки зрения ресурсов. Треды дороже с точки зрения памяти + ими управляет ОС и переключения между ними очень дорогие. При этом помним что при разработке серверных программ большое количество времени программа проводит в состоянии ожидания ввода-вывода и для эффективной утилизации ресурсов и комфортного пользовательского опыта важно чтобы во время простоя могли выполняться другие задачи на железе.
Для того чтобы программисты могли писать IO bound программы эффективнее разработчики языков и начали привносить в рантаймы различные легковесные примитивы. Но что произойдет в программе если мы сделаем блокирующий вызов (например запрос к БД)? Зависит от того как реализован рантайм конкретного языка программирования. Где то мы в ответ получаем Promise и продолжаем выполнение программы и заблочиться на нем в ожиданиии результата спустя время. В других языках реализованы специальные планировщики которые умеют детектировать файберы которые заблочились на IO и их можно безопасно снять с реального потока ОС и выделить время другим файберам. То есть по сути получаем некоторый микс из двух подходов, взяли лучшее из каждого.
А как быть с CPU Bound задачами? Никак, CPU задачи не масштабируются с помощью файберов. Чтобы разобраться почему приглашаю читать предыдущие посты с обсуждением процессора😊
На этом на сегодня всё, спасибо что читали, до встречи в следующих постах.😇
Forwarded from Go Library
Fuzz Testing Go HTTP Services
https://packagemain.tech/p/fuzzing-http-services-golang
As a developer, you can't envision all of the possible inputs your programs or functions could receive. Even though you can define the major edge cases, you still can't predict how your program will behave in the case of some weird unexpected input. In other words, you can only find bugs you expect to find.
That's where fuzz testing or fuzzing comes to the rescue.
https://packagemain.tech/p/fuzzing-http-services-golang
Forwarded from Технологический Болт Генона
Я даже не знаю как описать масштаб бедствия, потому что когда это всё смотреть решительно непонятно 🌝
Выложены доклады с USENIX Security '24 в количестве 415 штук
Плейлист
https://www.youtube.com/playlist?list=PLbRoZ5Rrl5ldQ2K_dpmPKHEyRgyf5JSxd
Программа
https://www.usenix.org/conference/usenixsecurity24/technical-sessions
Выложены доклады с USENIX Security '24 в количестве 415 штук
Плейлист
https://www.youtube.com/playlist?list=PLbRoZ5Rrl5ldQ2K_dpmPKHEyRgyf5JSxd
Программа
https://www.usenix.org/conference/usenixsecurity24/technical-sessions
👍4
Forwarded from Кубернетичек
65k nodes in k8s
https://cloud.google.com/blog/products/containers-kubernetes/gke-65k-nodes-and-counting
Из прикольного, чтобы достичь этого, конечно же выкинули etcd из куба для этого. И взяли Spanner. На этом можно и закончить, в целом, это кажется главная причина с чем нужно постоянно приседать, не только на больших кластерах, но и там где интенсивность создаваемых ресурсов высокая.
Остальные вещи, вроде тюнинга secondary boot disk, или использование kueue/jobset контроллеров, в контексте скейлинга до 65к хостов роли не играют особо. Это скорее про скорость шедулинга ворклоада.
Знаю, что яндекс облако пыталось заменить etcd на ydb (те сделать api etcd совместимое), но что-то, как всегда, пошло не так.
https://cloud.google.com/blog/products/containers-kubernetes/gke-65k-nodes-and-counting
Из прикольного, чтобы достичь этого, конечно же выкинули etcd из куба для этого. И взяли Spanner. На этом можно и закончить, в целом, это кажется главная причина с чем нужно постоянно приседать, не только на больших кластерах, но и там где интенсивность создаваемых ресурсов высокая.
Остальные вещи, вроде тюнинга secondary boot disk, или использование kueue/jobset контроллеров, в контексте скейлинга до 65к хостов роли не играют особо. Это скорее про скорость шедулинга ворклоада.
Знаю, что яндекс облако пыталось заменить etcd на ydb (те сделать api etcd совместимое), но что-то, как всегда, пошло не так.
Google Cloud Blog
Google Kubernetes Engine supports 65,000-node clusters | Google Cloud Blog
With support for 65,000-node clusters, Google Kubernetes Engine offers more than 10X larger scale than the other two largest public cloud providers.
👍3❤2
Какие планы на 19 ноября? Приходи на OPS Talk в офис Сбера!
Открылась регистрация на митап для инженеров сопровождения и DevOps-специалистов «OPS Talk by Sber: от разработки до инцидента».
Вместе со спикерами из Сбера, СберТеха и HFLabs поговорим о сопровождении IT-систем, DevOps- и SRE-практиках в уютном офисе на Кутузовском проспекте, а также онлайн в прямом эфире.
В программе 3 доклада, интерактивы и подарки, пицца-брейк, много новых знакомств и общения!
👉🏻Подробная программа и регистрация – здесь.
И поторопись – количество очных мест ограничено!
Открылась регистрация на митап для инженеров сопровождения и DevOps-специалистов «OPS Talk by Sber: от разработки до инцидента».
Вместе со спикерами из Сбера, СберТеха и HFLabs поговорим о сопровождении IT-систем, DevOps- и SRE-практиках в уютном офисе на Кутузовском проспекте, а также онлайн в прямом эфире.
В программе 3 доклада, интерактивы и подарки, пицца-брейк, много новых знакомств и общения!
👉🏻Подробная программа и регистрация – здесь.
И поторопись – количество очных мест ограничено!
👎2
Forwarded from DevOps Deflope News
Red Hat объявила о передаче набора инструментов для работы с контейнерами, включая Podman, Buildah и Skopeo, под управление Cloud Native Computing Foundation: https://goo.su/nK98BDU
Это обеспечит повышение прозрачности разработки, поддержку открытых стандартов и активное участие сообщества в развитии инструментов.
Это обеспечит повышение прозрачности разработки, поддержку открытых стандартов и активное участие сообщества в развитии инструментов.
🔥10
Forwarded from Библиотека Go-разработчика | Golang
⚒️ Создание кастомного балансировщика нагрузки на Go для gRPC с приоритизацией адресов
Разработчик из VK делится опытом создания кастомного балансировщика нагрузки на Go для gRPC, который использует приоритеты адресов для выбора наилучшего соединения.
Это решение позволяет гибко управлять распределением клиентских запросов между серверами с разными уровнями доступности и обеспечивает подключение к оптимальному ЦОД с минимальными задержками.
👉 Читать
Разработчик из VK делится опытом создания кастомного балансировщика нагрузки на Go для gRPC, который использует приоритеты адресов для выбора наилучшего соединения.
Это решение позволяет гибко управлять распределением клиентских запросов между серверами с разными уровнями доступности и обеспечивает подключение к оптимальному ЦОД с минимальными задержками.
👉 Читать
Forwarded from Евгений Козлов пишет про IT (Eugene Kozlov)
Учел ваши пожелания и собрал все посты по теме многозадачности и производительности в один пост. Приятного чтения, дальше больше, это еще далеко не конец😊
🔹Многозадачность на уровне железа и OS / Kernel Space
1. Многозадачность в OS. Введение.
2. Процессор и его роль в многозадачности
2.1. Про Hyper Threading
3. Процессы. Начало
4. Процессы в Linux
5. Потоки. Начало
6. Потоки в Linux
7. Модели ввода-вывода. Универсальная(блокирующая) модель ввода-вывода
8. Multiplexed IO
9. Asynchronous IO
🔹Легковесные потоки в User Space / Многозадачность в языках программирования
10. Fibers. Виды многозадачности с примерами в языках программирования.
11. Сравнительный обзор двух видов многозадачности
🔹Многозадачность на уровне железа и OS / Kernel Space
1. Многозадачность в OS. Введение.
2. Процессор и его роль в многозадачности
2.1. Про Hyper Threading
3. Процессы. Начало
4. Процессы в Linux
5. Потоки. Начало
6. Потоки в Linux
7. Модели ввода-вывода. Универсальная(блокирующая) модель ввода-вывода
8. Multiplexed IO
9. Asynchronous IO
🔹Легковесные потоки в User Space / Многозадачность в языках программирования
10. Fibers. Виды многозадачности с примерами в языках программирования.
11. Сравнительный обзор двух видов многозадачности
👍2❤1
Тем временем, я как-то упустил важное обновление https://prometheus.io/blog/2024/11/14/prometheus-3-0/
prometheus.io
Announcing Prometheus 3.0 | Prometheus
An open-source monitoring system with a dimensional data model, flexible query language, efficient time series database and modern alerting approach.
🔥5
Forwarded from DevOps Deflope News
KubeCon + CloudNativeCon North America 2024 закончился несколько дней назад.
Делимся плейлистом.
Делимся плейлистом.
🔥3❤1👍1
Forwarded from Yandex for Backend
Недавно прошёл SRE Week — открытый интенсив Школы анализа данных по работе с большими нагруженными системами. Руководитель службы разработки динамических таблиц в Yandex Infrastructure и преподаватель ШАД Руслан Савченко сделал обзорную статью по мотивам курса.
Это большой обзор распределённых систем — он будет интересен студентам и разработчикам, которые хотят вкатиться в Site Reliability Engineering.
Из статьи вы узнаете:
Подписывайтесь:
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
Пиарим проекты подписчиков! Кстати, если вы пишите что-то полезное и нужны звезды на гитхабе или просто хочется поделиться с миром - приносите!
❤1👍1