Пятничный деплой

Kuber Community Day возвращается: 30 июля, Москва 😀 30 июля во второй раз состоится конференция Kuber Community Day. В этом году участников ждут новые доклады, форматы и площадка. Будут два пространства с техническим контентом от практиков из X5 Tech, MWS, «Райффайзенбанка», «СберЗдоровья», «Лаборатории Числитель», «Инфосистемы Джет», Hilbert Team, OpsMaster и других компаний. Среди заявленных тем: - Не Argo CD единым живы: комплексная автоматизация на стеке Argo Project - Неидемпотентный мир победил, AI оказался сильней - NixOS вместо Talos: когда хочется Kubernetes, но не хочется терять Linux - Kubernetes — это всего пять сертификатов - Мониторинг здоровья Kubernetes ◽️ Форматы: офлайн и онлайн (трансляция предусмотрена для обоих залов). Участие бесплатное, но места на офлайн ограничены площадкой. Регистрация уже идет по ссылке.

Наткнулся на очередную статью: «Zero-Downtime Deployments with Docker Compose — No Kubernetes Required». Автор прямо пишет - в индустрии, мол, массовое заблуждение, что для серьёзного прода нужен k8s. Не нужен. Тысячи проверок в минуту, мульти-регион, деплой по нескольку раз в день - и всё на компоузе. И тут он прав. Для одного хоста и пары сервисов Kubernetes - это из пушки по воробьям. Бесшовно перекатить контейнер умеет и nginx, никакой оркестратор для этого не нужен. Только это подмена тезиса. В k8s идут не за zero-downtime деплоем - за ним и так все умеют. Идут за другим. Первое - пул машин. Compose заперт в пределах одного хоста. В комментах это сразу и поймали: «тысячи проверок в минуту - это вообще немного, спокойно живёт на одной железке. Kubernetes берут, когда надо выйти за её пределы». Вот и весь спор. Второе - стандарт. k3s ставится за пять минут, и ты получаешь готовую вселенную типового тулинга. Новый человек приходит с любого облака и сразу в теме. А не разбирает полгода твой самодельный оркестратор из bash'а и скотча. Лучший коммент в треде - вообще не про технику. Человек честно признался: «взяли инструмент попроще, проект взлетел - и все эти "сложные" фичи k8s внезапно стали нужны. Зря не взяли сразу». Знакомо до боли. 🤡🤡 Короче. «Не нужен Kubernetes» - честный заголовок. Просто допишите в конце: «пока у тебя один хост». А на втором десятке нод поговорим заново. #kubernetes #docker #devops

Когда метрики сходят с ума: автоматическая детекция аномалий во временных рядах в Yandex Monium А вот Яндекс пишет как они решали задачу поиска аномалий на своем внутреннем контуре Monium. Когда-нибудь обещают это это же самое реализовать и для внешних пользователей. 📱 Telegram | 📲 MAX

Если в вашей работе регулярно всплывают GitLab Runner, Kubernetes, ArgoCD или CDN, возможно, этот митап стоит добавить в календарь. 10 июля команда Спортса" проводит Infrastructure & Reliability Meetup 📍 Москва + онлайн В программе четыре доклада: • как защитить GitLab Runner; • как устроена CDN и что важно при миграции инфраструктуры; • опыт внедрения ArgoCD и GitOps; • запуск GPU-задач в Kubernetes на нестандартном железе. Выступать будут инженеры из Спортса", Wildberries & Russ и 2ГИС. После докладов обещают просмотр матча 1/4 финала ЧМ-2026 ⚽️ Подробная программа и регистрация по ссылке: https://sprts.cc/deploy

📎 Пусть main делает реальную работу «Просто свяжи всё в main, логику вынеси в пакеты, держи main.go в двадцать строк». Так советуют. Совет не то чтобы неверный, но ведёт к конкретной поломке. Вы получаете папку cmd/ из пакетов, которые вызываются ровно из одного места, и main.go на двадцать строк вида «вызвать функцию бутстрапа в internal/app». Вы добавили лишний слой, но не добавили абстракции. ➡️ Что делать вместо Пусть main делает настоящую работу. Читает конфиг, инициализирует пул базы, связывает зависимости, поднимает gRPC сервер и регистрирует обработчик остановки. Если ваш main.go на двести строк, но каждая строка это честная проводка без бизнес логики и без условий по фичефлагам, это нормально:

func main() {
    ctx, stop := signal.NotifyContext(context.Background(), syscall.SIGINT, syscall.SIGTERM)
    defer stop()

    cfg := config.MustLoad() // паникует на плохом конфиге, намеренно на старте

    pool, err := pgxpool.New(ctx, cfg.DatabaseURL)
    if err != nil {
        log.Fatal("failed to initialize database pool", zap.Error(err))
    }
    defer pool.Close()

    queries := db.New(pool)
    memberSvc := members.NewService(queries)

    srv := grpc.NewServer(grpc.ChainUnaryInterceptor(
        logging.UnaryServerInterceptor(logger),
        recovery.UnaryServerInterceptor(),
    ))
    memberspb.RegisterMembersServiceServer(srv, memberSvc)

    go func() {
        if err := srv.Serve(lis); err != nil {
            log.Fatal("server exited", zap.Error(err))
        }
    }()

    <-ctx.Done()
    srv.GracefulStop()
}

Это читаемо, и это реальная топология приложения, видная в одном файле. Тонкий main оправдан, только когда стартовая логика действительно сложная и заслуживает отдельного пакета. В остальных случаях честная проводка прямо в main понятнее. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека Go-разработчика #GoToProduction

herdr

agent multiplexer that lives in your terminal.

https://github.com/ogulcancelik/herdr

4 MCP-сервера, о которых стоит знать каждому DevOps-инженеру 1. Kubernetes MCP - расследовать pod’ы в CrashLoopBackOff; - дебажить неудачные деплои; - анализировать состояние кластера. Repo: https://github.com/Flux159/mcp-server-kubernetes 2. AWS MCP - разбирать резкие скачки расходов в AWS; - находить неиспользуемые ресурсы; - troubleshooting облачной инфраструктуры. Repo: https://github.com/awslabs/mcp 3. Terraform MCP - проверять Terraform-планы; - находить drift в инфраструктуре; - объяснять изменения в инфраструктуре. Repo: https://github.com/hashicorp/terraform-mcp-server 4. Grafana + Prometheus MCP - расследовать скачки latency; - анализировать production-инциденты; - объяснять alert storms. Repos: https://github.com/grafana/mcp-grafana https://github.com/pab1it0/prometheus-mcp-server ИИ может получать доступ к вашей инфраструктуре, понимать, что реально происходит, и помогать разбирать проблемы на основе настоящих данных, а не догадок.

📖 Как использовать Temporal Меня зовут Миша Иглицкий, я бэкенд‑разработчик в платформе Яндекс Еды. Наш процессинг заказов уже почти год работает целиком на Temporal. Я уже рассказывал, как эта функция безболезненно решает привычную проблему распределённой бизнес-логики. А сегодня хочу поделиться советами миграции на Temporal, которые мы вывели из нашего опыта. ❇️ Не поддавайтесь иллюзии чистой архитектуры Бизнес-логика в Temporal Workflow выглядит очень соблазнительно. Но её изоляция от ввода-вывода (I/O) сама по себе не гарантирует хорошую архитектуру. В идеале ваша доменная область вообще ничего не должна знать о Temporal — только предоставлять нужные вам интерфейсы. Наши грабли: первая версия Workflow была просто «простынёй» вызовов Activity в правильном порядке. Одну часть бойлерплейта для юнит-тестов мы копипастили, а вторую — адаптировали. В итоге сложность нашей системы разрослась до неподдерживаемой и пришлось менять подход. ❇️ Как надо делать: 🟢 Тестируйте бизнес-логику небольшими блоками, изолированно от Temporal SDK 🟢 Используйте интерцепторы для метрик, retry policy и кастомного логирования 🟢 На Go обязательно пользуйтесь кодогенератором для вызовов Activity 💹 Сохраняйте всё, что способно повлиять на работу бизнес-логики Она должна всегда приводить к одному и тому же результату на одинаковой истории событий — это суть детерминистического подхода в Temporal, который обеспечивает такую надёжность. Какие инструменты могут помочь: 🟢 SideEffect. Фиксирует в истории результат недетерминированного вычисления и не оформляет его как отдельную Activity. При повторных проигрываниях Temporal просто достаёт сохранённое значение 🟢 Версионирование. Позволяет старым Workflow работать по-старому, новым — по-новому. Полезно именно там, где бизнес-логика обновляется без возможности отката 🟢 Feature Flags. Хотя технически они реализуются через LocalActivity или SideEffect, эта парадигма гораздо гибче простого версионирования и позволяет переключить поведение только у части Workflow. Это особенно полезно для постепенного внедрения изменений с возможностью откатиться ➖ Неочевидный совет: лучший способ не выстрелить себе в ногу с версионированием — это копипаст. Весь старый код оборачивается в if version == oldVersion, а новый просто пишется рядом уже с улучшениями. Когда старых Workflow не остаётся, ветвление удаляется. Да, это временное нарушение DRY, но код всё равно скоро исчезнет. Главное — действительно потом его удалить 🤫 🔶 Читайте все подробности в статье на Хабре. Там я рассказал, что именно нам помогло обеспечить плавность перехода на Temporal и какие тесты мы используем для защиты от случайного недетерминизма. А также объяснил, что делать, если в Workflow слишком много действий, и поделился другими разными полезностями для работы с Temporal. Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

cardamon

О бенчмаркинге, часть 2 (первая часть тут) Производительности в вакууме не бывает Состояние одной и той же системы от запуска к запуску бенчмарков всегда разное. Даже если зафиксированы все статические параметры (настройки OS и рантайма, CPU affinity, etc), то температура процессоров, состояние кешей, layout кода в памяти всё равно плавают. Что уж говорить про внешне схожие окружения - там различий может быть еще больше.   Следовательно результаты на выходе всегда различаются. Так какой из них нам взять за основу? ——— Помогает формулировка от Ben Sigelman: «Performance is a shape, not a number». Производительность это всегда распределение, а не одно конкретное число. Не существует одного единственного, правильного значения.  И каждый отдельный прогон бенчмарка это просто один сэмпл из всего распределения, полученный при конкретных условиях.  Если углубить, то и внутри одного запуска мы всегда получаем распределение:

$ funclatency-bpfcc __sys_sendto -d 10 -u

usecs           : count    distribution
    0 -> 1      : 12433    |************        |
    2 -> 3      : 20394    |******************* |
    4 -> 7      : 20540    |********************|
    8 -> 15     : 1962     |**                  |
   16 -> 31     : 237      |                    |
   32 -> 63     : 19       |                    |
   64 -> 127    : 8500     |********            |
  128 -> 255    : 12       |                    |
  256 -> 511    : 0        |                    |
  512 -> 1023   : 4        |                    |
 1024 -> 2047   : 5        |                    |
 2048 -> 4095   : 1        |                    |
 4096 -> 8191   : 2        |                    |

——— Задача перформанс-инженера сводится к двум вещам: 1. сужать это распределение 2. объяснять, почему оно именно такое На ширину распределения влияет шум: переключение контекста, прерывания, соседи, и т.д. И чем шум больше, тем шире хвосты распределения. Важный момент: шум может быть случайным, а может быть систематическим. Бороться с ними нужно по-разному. ——— Случайный шум (random noise) это то, что возникает непредсказуемо, без видимой системы. Например, фоновый процесс случайно попал на наше ядро в одних прогонах и не попал в других. Или соседнее ядро внезапно дало всплеск нагрузки на общий L3. Лечится количеством прогонов: чем их больше, тем сильнее усредняем случайные отклонения, и тем точнее итоговая оценка. Систематический шум (systematic bias), уже другое явление. Какой-то фактор стабильно сдвигает измерения в одну и туже сторону. Например IRQ, прибитый к нашему ядру, просыпается через равные промежутки. Такой тип шумов (или отклонений) не лечится количеством прогонов, из раза в раз будем получать искаженный результат.  В "Producing Wrong Data Without Doing Anything Obviously Wrong",  авторы показали, что даже размер переменных окружения может вносить существенные искажения в итоговый результат.  С систематическим шумом борются наблюдением и рандомизацией факторов, см. Stabilizer. ——— Это объясняет, почему Passive Benchmarking плох, даже при тысяче прогонов: он не отличает один тип шума от другого. Active Benchmarking, помимо прочего, как раз про то, чтобы такие смещения находить. Ранее мы говорили о цикле в Active Benchmarking: запустил → пронаблюдал → сформулировал гипотезу → проверил → повторил. Это как раз про то, что борьба с шумом процесс бесконечный: зафиксировали частоту, получили распределение уже, в следующем прогоне в топ выходят прерывания, вынесли их с ядра, получили еще более стабильный результат. Далее поднимают голову соседи по L3 кешу...  По своей природе это похоже на дрейфующее бутылочное горлышко в производительности: всегда что-то будет в топ-1. Следующим возникает естественный вопрос: "где и когда остановиться?" To be continued. ——— Выводы - Производительность это распределение, а не число - Шум есть всегда, и работать с ним нужно исходя из его типа - Борьба с шумом бесконечный процесс - главное знать, где остановиться. ——— Поставить лайк на Linkedin

Контроль доступа в Kubernetes 🔐Всем DevOps! Собрали для вас подборку статей с LearnKube, которая поможет разобраться, кто может подключаться к серверу API, что именно ему разрешено и как это контролировать в Kubernetes. ⏺В первой статье Гулькан Топку и Артур Чиао сосредоточились на аутентификации. На примерах поймете, как действуют ограничения к серверу HTTP API и ни слова про kubectl. ⏺Следующий этап – авторизация и RBAC. Всё о том, как ограничить доступ, чтобы у каждого пользователя и сервиса были только нужные права. ⏺И наконец, практическая модель адаптации аутентификации под свою инфраструктуру, например через LDAP. Желаем приятного чтения и продуктивной недели! #девопс #kubernetes #безопасность

Антиконференция Summer Merge — летняя перезагрузка для ИТ, которую нельзя пропускать 🔥 Устали от одинаковых событий и рабочей рутины? Присоединяйтесь к Summer Merge! Это по-настоящему летний формат ИТ-ивента. Программа события готова и уже на сайте. — 3 дня на природе, без офисов и дедлайнов; — Живые дискуссии под открытым небом вместо лекций в аудиториях; — Soft skills, карьера и реальные боли индустрии; — Нетворкинг, который действительно работает; — Спорт, вечерние посиделки у костра и десятки видов активностей. 🤝 За 4 года антиконференция объединила тысячи IT-специалистов: разработчиков, менеджеров, аналитиков, владельцев бизнеса и маркетологов. Summer Merge – сообщество, в котором легко находить единомышленников, деловых партнеров, новые карьерные возможности и даже вторую половинку. ⛺ Формат палаточного лагеря и дружеская открытая атмосфера помогают перезагрузиться, посмотреть на работу по-новому и уехать с новыми идеями и вдохновением на весь год. Спешите приобрести билет до повышения цен со скидкой 15% по промокоду «ПЯТНИЧНЫЙДЕПЛОЙ»! Купить билеты на сайте.

📖100 Go Mistakes and How to Avoid Them 🖋Harsanyi Teiva | 2022 Книга «100 ошибок в Go и как их избежать» показывает, как заменить распространенные проблемы в программировании на Go идиоматичным и выразительным кодом. Вы изучите десятки интересных примеров и кейсов и научитесь выявлять ошибки, которые могут возникнуть в ваших собственных приложениях. Автор книги Тейва Харсаньи систематизирует методы предотвращения ошибок по удобным категориям — от типов данных и строк до параллелизма и тестирования. 💾 Скачать книгу Clean Code | #книги #Go & Мах

OpenTelemetry Semantic Conventions: изменения в HTTP, RPC, gRPC, JSON-RPC (v1.37 → v1.43) Собрал это, потому что был удивлен, когда ребята в сервисе обновили либу otel для golang, а там часть метрик для gRPC исчезла, они перестали видеть сервис на нашей стандартизированной доске gRPC RED-метрики в Grafana. Версия 1.37.0 (Базовая) - HTTP: - Метрики: http.server.request.duration, http.client.request.duration - Единица измерения: Секунды (s) - Атрибуты: http.request.method, url.scheme, http.response.status_code и др. - RPC (включая gRPC и JSON-RPC): - Метрики: rpc.server.duration, rpc.client.duration - Единица измерения: Миллисекунды (ms) - Атрибуты: rpc.system, rpc.service, rpc.method Версия 1.38.0 - HTTP: - Единица измерения: Окончательно закреплена в секундах (s). В более ранних черновиках и некоторых реализациях использовались миллисекунды, но в 1.38.0 стандарт окончательно перешел на секунды для всех duration метрик. - RPC: - Начало перехода от rpc.server.duration к rpc.server.call.duration. Версия 1.39.0 - RPC: - Переименование метрик: Метрики rpc.server.duration и rpc.client.duration начинают заменяться на rpc.server.call.duration и rpc.client.call.duration. - Единица измерения: Переход с миллисекунд (ms) на секунды (s) для новых метрик call.duration. - gRPC/JSON-RPC: - Продолжают следовать общим правилам для RPC, но теперь используют новые имена и секунды. Версия 1.40.0 - RPC: - Стабилизация: rpc.server.call.duration и rpc.client.call.duration становятся основными и рекомендуемыми метриками. - Атрибуты: Уточнены требования к атрибутам rpc.system (например, grpc, jsonrpc), rpc.service и rpc.method. - HTTP: - Незначительные уточнения в описании атрибутов, связанных с повторными попытками (retries). Версия 1.41.0 - RPC: - Финализация: Старые метрики rpc.server.duration и rpc.client.duration официально помечены как устаревшие (deprecated) или удалены из основных рекомендаций в пользу rpc.server.call.duration и rpc.client.call.duration. - Единица измерения: Строго секунды (s) для всех call.duration метрик. - gRPC/JSON-RPC: - Значения атрибута rpc.system стандартизированы: grpc для gRPC, jsonrpc для JSON-RPC. Версия 1.42.0 - HTTP: - Уточнения в атрибутах http.request.method (например, добавление поддержки нестандартных методов или уточнение регистра). - RPC: - Уточнения в описании того, как должны обрабатываться ошибки и какие атрибуты должны добавляться при сбоях (например, error.type). Версия 1.43.0 - RPC: - Продолжение работы над согласованностью атрибутов между различными RPC-системами. - Уточнения в документации по использованию rpc.service и rpc.method для gRPC и JSON-RPC. - HTTP: - Незначительные корректировки в семантике атрибутов server.address и server.port. Резюме ключевых изменений: - Единицы измерения: Повсеместный переход с миллисекунд (ms) на секунды (s) для всех метрик duration. - Имена метрик RPC: Переход от rpc.*.duration к rpc.*.call.duration. - Атрибуты: Стандартизация значений для rpc.system (grpc, jsonrpc) и уточнение набора обязательных атрибутов. А как вы решаете вопрос с именами метрик и изменениями в OTEL? #opentelemetry #observability #changelog #otel

nfraDev Community приглашает на InfraDev Meetup #4: про AI и не только Прямо сейчас мы наблюдаем как AI в SDLC меняет процесс разработки — об удачных примерах и кейсах поговорим в этот раз. Обсудим, как разрабатывать инфраструктурные сервисы с помощью AI и как построить MLOps-платформу для обучения моделей. И не только: пока AI не перестроил DevOps-цикл, классические вызовы сборки образов для виртуальных машин остаются актуальными. Спикеры ▫️Кирилл Фролов, эксперт-разработчик в отделе разработки базовых сервисов, VK Cloud, VK Tech ▫️Павел Шипилов, Старший разработчик ML Платформы в Avito ▫️Александр Александров, системный архитектор в направлении разработки и управления инфраструктурой, VK Cloud, VK Tech Подробнее о докладах читайте на странице мероприятия. Когда: 10 июня, с 18:00 до 23:59 Где: Москва, Ленинградский пр., 70, офис VK Tech, БЦ «Алкон» (количество мест ограничено). Приходите на встречу или участвуйте онлайн. Зарегистрироваться.

OpenTelemetry Semantic Conventions: изменения в HTTP, RPC, gRPC, JSON-RPC (v1.37 → v1.43) Собрал это, потому что был удивлен, когда ребята в сервисе обновили либу otel для golang, а там часть метрик для gRPC исчезла, они перестали видеть сервис на нашей стандартизированной доске gRPC RED-метрики в Grafana. Версия 1.37.0 (Базовая) - HTTP: - Метрики: http.server.request.duration, http.client.request.duration - Единица измерения: Секунды (s) - Атрибуты: http.request.method, url.scheme, http.response.status_code и др. - RPC (включая gRPC и JSON-RPC): - Метрики: rpc.server.duration, rpc.client.duration - Единица измерения: Миллисекунды (ms) - Атрибуты: rpc.system, rpc.service, rpc.method Версия 1.38.0 - HTTP: - Единица измерения: Окончательно закреплена в секундах (s). В более ранних черновиках и некоторых реализациях использовались миллисекунды, но в 1.38.0 стандарт окончательно перешел на секунды для всех duration метрик. - RPC: - Начало перехода от rpc.server.duration к rpc.server.call.duration. Версия 1.39.0 - RPC: - Переименование метрик: Метрики rpc.server.duration и rpc.client.duration начинают заменяться на rpc.server.call.duration и rpc.client.call.duration. - Единица измерения: Переход с миллисекунд (ms) на секунды (s) для новых метрик call.duration. - gRPC/JSON-RPC: - Продолжают следовать общим правилам для RPC, но теперь используют новые имена и секунды. Версия 1.40.0 - RPC: - Стабилизация: rpc.server.call.duration и rpc.client.call.duration становятся основными и рекомендуемыми метриками. - Атрибуты: Уточнены требования к атрибутам rpc.system (например, grpc, jsonrpc), rpc.service и rpc.method. - HTTP: - Незначительные уточнения в описании атрибутов, связанных с повторными попытками (retries). Версия 1.41.0 - RPC: - Финализация: Старые метрики rpc.server.duration и rpc.client.duration официально помечены как устаревшие (deprecated) или удалены из основных рекомендаций в пользу rpc.server.call.duration и rpc.client.call.duration. - Единица измерения: Строго секунды (s) для всех call.duration метрик. - gRPC/JSON-RPC: - Значения атрибута rpc.system стандартизированы: grpc для gRPC, jsonrpc для JSON-RPC. Версия 1.42.0 - HTTP: - Уточнения в атрибутах http.request.method (например, добавление поддержки нестандартных методов или уточнение регистра). - RPC: - Уточнения в описании того, как должны обрабатываться ошибки и какие атрибуты должны добавляться при сбоях (например, error.type). Версия 1.43.0 - RPC: - Продолжение работы над согласованностью атрибутов между различными RPC-системами. - Уточнения в документации по использованию rpc.service и rpc.method для gRPC и JSON-RPC. - HTTP: - Незначительные корректировки в семантике атрибутов server.address и server.port. Резюме ключевых изменений: - Единицы измерения: Повсеместный переход с миллисекунд (ms) на секунды (s) для всех метрик duration. - Имена метрик RPC: Переход от rpc.*.duration к rpc.*.call.duration. - Атрибуты: Стандартизация значений для rpc.system (grpc, jsonrpc) и уточнение набора обязательных атрибутов. А как вы решаете вопрос с именами метрик и изменениями в OTEL? #opentelemetry #observability #changelog #otel

Загадка ядра Linux: почему на 36 vCPU Cilium падает, а на 32 — нет

Автор оригинальной статьи, Пьер Мане, рассказывает, как его команда столкнулась с на первый взгляд необъяснимым поведением Cilium и как поиск решения привёл его к конфигурации ядра Linux. Отладка сродни археологии: ты пробираешься сквозь слои абстракций, пока не доберёшься до коренной породы — ядра. Это история о том, как скрытая в коде Linux логика работы со степенями двойки приводила к случайным и загадочным падениям Cilium, из-за чего мы не могли выкатиться в production.

Подробности в статье на Хабре. @usr_bin_linux

Материалы и слайды своего мастер-класса на CodeFest выложил на GitHub (продублирую в комменты) Open source на страже Kubernetes Runtime Security https://github.com/rusdacent/codefest-2026

В эфире DevOps FM с первой летней подборкой новостей! ⏺ Стало известно о масштабном инциденте провайдера MIRhosting. Платформа nLighten без предупреждения отключила оборудование, и часть инфраструктуры компаний в европейских ДЦ стала недоступна. На момент публикации остановлена работа серверов в Германии и Нидерландах. Также недоступны THE.Hosting, UFO.Hosting, Alexhost.com, Vdsina.com и другие. Накануне инцидента MIRhosting подвергся проверкам регуляторов, были предъявлены обвинения в обходе санкций. ⏺ Codex обнаружил новую уязвимость. HTTP/2 Bomb позволяет провести удалённую DoS-атаку на серверы с включённым HTTP/2. Проблема затрагивает NGINX, Apache HTTPD, Microsoft IIS, Envoy и Cloudflare Pingora в конфигурации по умолчанию. Атака сочетает две известные техники: • Первая использует особенности HPACK, сжатия HTTP-заголовков в HTTP/2, из-за которого расходуется больше памяти сервера. • Вторая техника работает на задержке через flow control, из-за которого ресурсы не освобождаются. Весь PoC – здесь, а список затронутых серверов и рекомендации – тут. ⏺ Шон Вэбб отчитался о прогрессе HardenedBSD за апрель и май 2026. Основная часть усилий ушла на миграцию с GitLab на Radicle. Ключевые репозитории уже перенесены, хотя Вэбб сообщил, что часть интеграций ещё дорабатывается вручную. За два месяца вышло несколько рекомендаций по безопасности для FreeBSD и новые сборки FreeBSD 16, FreeBSD 15. ⏺Вслед за обзором инцидентов атак ИИ-агентов блоге Docker вышло 2 практических гайда по безопасности в песочнице. В первой Шрини Секаран разбирает набор из 5-ти практик обеспечения безопасности: ограничение процессов, контроль сети, лимиты ресурсов и постоянный мониторинг поведения во время выполнения. Во второй части даёт схему внедрения принципов в жизненный цикл работы ИИ-агента и оставляет подробный чек-лист для проверки. ⏺ В блоге CNCF вышел подробный разбор архитектуры платформы разработки на базе Kubernetes. Автор показывает, как объединить принципы нативных облачных технологи, IaC, GitOps и практики безопасности цепочки поставок. Логика построена на работе трёх уровней – архитектуры, платформы и приложения. ⏺ На Medium рассказали о сетях Kubernetes, от базовых принципов до практических сценариев. В статье описали логику работы pod IP, роль CNI-плагинов и особенности ClusterIP, NodePort и LoadBalancer. Отдельно вынесли частые вопросы и сценарии отладки проверок селекторов Service, бесконечным <pending> и проблемами в работе CNI. #новостная_подборка #девопс #Docker #Kubernetes #HardenedBSD

5 слоев кэширования в веб-приложениях: Полное руководство для Python-разработчиков #habr https://habr.com/ru/articles/1031748/ Tags: кэширование, http-заголовки, cdn, local storage Author: artemshumeiko