Четыре паттерна Docker Compose, каждый ценой вечера отладки

Полдюжины сервисов на одном VPS: база, шлюз API, пара воркеров, Redis. Compose тут очевидный выбор, вот только первые конфиги обычно собираются методом тыка.

Показателен первый паттерн, про хелсчеки. Слишком агрессивный вариант с interval: 5s и start_period: 5s перезапускает контейнер раньше, чем тот успевает подняться, и вместо диагностики вы получаете бесконечный цикл рестартов.

Остальные три из той же категории: не про красоту конфига, а про то, что реально ломается на длинной дистанции. Разбор с готовыми кусками compose-файла.

Образ с Go-сервисом влезает в 15 МБ, если не собирать его на scratch

Go компилируется в один статически слинкованный бинарник без рантайма и системных зависимостей, поэтому образ это ваш бинарник плюс пара килобайт метаданных. Там, где Node с трудом влезает в 150 МБ, Go садится ниже 15 МБ без всяких усилий.

Ключевые флаги: CGO_ENABLED=0 даёт по-настоящему статический бинарник с чистой Go-реализацией сети и DNS, -ldflags="-s -w" убирает отладочные символы и режет примерно 30% размера, а копирование go.mod и go.sum до исходников оставляет слой зависимостей в кеше между сборками.

Вывод про базовый образ неочевидный. FROM scratch работает ровно до того момента, когда понадобятся HTTPS и часовые пояса: там нет ни CA-сертификатов, ни tzdata. Distroless static везёт и то и другое плюс пользователя nonroot примерно в 2 МБ. Разбор с Dockerfile.

Когда Helm-чарта уже мало: пишем свой Kubernetes Operator

В Kubernetes есть контроллеры для встроенных ресурсов: деплойментов, сервисов, нод. Оператор растягивает тот же паттерн на ресурсы, о которых кластер ничего не знает, и позволяет управлять кастомными и внешними системами так же декларативно, как всем остальным.

Первый вопрос, на который стоит ответить до кода: чем оператор отличается от контроллера и CRD и почему в вашем случае не хватит чарта, CronJob или скрипта. Руководство начинается ровно с него, а не с генерации проекта.

Дальше идут анатомия оператора, сборка с нуля и подготовка к продакшену. Руководство разбито на четыре части и годится как план на несколько вечеров.

Дежурный инженер не должен работать движком корреляции

В Atlassian сотни связанных микросервисов в нескольких регионах, и любой инцидент рождает столько телеметрии, что причину по-прежнему находят вручную.

Типичный путь выглядит так. Дежурного разбудил алерт, он открыл дашборд метрик, увидел аномалию в ошибках или задержках, ушёл в логи искать исключения в том же временном окне, потом в трейсы смотреть отдельные запросы. Дальше он глазами сводит три разных представления, строит гипотезу и идёт назад по графу зависимостей проверять её.

Процесс последовательный и дорогой по вниманию: он держится на том, что человек заранее знает, какие дашборды открывать и какие сервисы стоят выше по потоку. Сеньор делает это за минуты, остальные заметно дольше, а на пользовательском инциденте важна каждая. Чем это заменили в Atlassian, показано в их разборе.

Хроника вторжения: как ИИ-агент четверо суток ходил по инфраструктуре

Hugging Face выложила технический разбор июльского инцидента 2026 года: два вектора первичного доступа, как агент закрепился и двигался вбок, и примеры команд, которые реально выполнялись. Живые учётные данные и внутренние имена хостов вымараны, техники описаны как наблюдались.

Отдельная деталь: расследование вели с помощью GLM 5.2, модели с открытыми весами. В посте есть интерактивный проигрыш кампании длиной 4,5 суток по шагам: цепочка через границы доверия, активность по фазам и записанные команды.

Публикуют это ровно потому, что техника важнее самого инцидента. Хронология редка тем, что показывает не выводы, а рабочий процесс атакующего агента целиком.

Поставил CDN-кеш перед статикой, и сайт стал медленнее

Не тонко медленнее: независимый краулер до изменения отмечал 38 медленных страниц, после — 75. Автор откатил всё в тот же день.

Ценность материала в самом расчёте, который стоило провести до деплоя. Автор приводит одну формулу, которая заранее отвечает на вопрос, окупится кеш на вашем трафике или нет, и разбирает, почему в его случае ответ был отрицательным.

Прогоните эту формулу, прежде чем ставить CDN перед малопосещаемым разделом. Разбор с цифрами до и после.

Проверка подписи образа на уровне рантайма, а не admission-вебхука

Kyverno, OPA Gatekeeper и Sigstore Policy Controller работают на слое API Kubernetes: перехватывают создание пода, проверяют подписи и аттестации, пропускают или отклоняют.

Проблема в том, на чём это держится. Вебхуки зависят от явной конфигурации и от сети: криво заданный селектор неймспейсов молча пропускает проверку, отказ вебхука ставит перед выбором между блокировкой кластера и тихим байпасом, а статические поды и прямой доступ к API kubelet обходят admission целиком.

Supply Chain NRI Plugin спускает проверку на слой ниже, в сам рантайм контейнеров, через который проходит любой контейнер независимо от способа запуска. Работает и с CRI-O, и с containerd, выпускается отдельным циклом. Порядок подключения описан в статье CNCF.

DRA дошёл до GA, но HAMi он не отменяет

Раньше словарь для GPU в Kubernetes состоял из одной строчки nvidia.com/gpu: 1: целая карта, берите или отказывайтесь. HAMi, которого TOC принял в инкубацию CNCF 15 июля 2026 года, целиком построен вокруг обхода этого ограничения: мутирующий вебхук, расширитель планировщика, аннотации и принуждение лимитов внутри контейнера.

Теперь словарь изменился. Dynamic Resource Allocation дошёл до GA в Kubernetes 1.34 и включён по умолчанию с 1.35, а вместе с consumable capacity под может нативно попросить у планировщика долю памяти устройства, без всяких аннотаций.

Отсюда и вопрос, который задают в чатах HAMi. Короткий ответ: нет, не отменяет. Кодирование дробных запросов DRA действительно забирает себе, а вот принуждать лимиты внутри контейнера на уровне вызовов CUDA он не проектировался. Что оставить HAMi, а что отдать DRA, разобрано в материале.

Kubernetes 1.37 выкидывает kube-dns, IPVS и cgroup v1: проверьте три вещи до апгрейда

Релиз назвали Garhwal, в нём 67 изменений: 16 фич доведены до стабильных, 23 в бете, 27 новых альфа и одно удаление. Команда явно расставляет приоритеты в сторону готовности к продакшену, а не новизны.

Проверить до обновления надо три вещи: не остался ли kube-dns вместо CoreDNS, не работает ли kube-proxy в режиме IPVS и не сидят ли ноды на cgroup v1. Всё три уезжают, и молча это не пройдёт.

Для контекста: по январскому опросу CNCF Kubernetes крутят в проде около 82% тех, кто вообще пользуется контейнерами, против 66% в 2023 году, а 66% организаций, которые хостят генеративные модели, гоняют через него инференс. Разбор релиза.

Buildpacks собирает OCI-образ прямо из исходников и стал Graduated в CNCF

Проект получил статус Graduated. Buildpacks сам определяет язык, ставит зависимости и раскладывает слои, поэтому Dockerfile на каждый сервис не нужен: поддержаны Java, Python, Go, Node.js и Ruby, на выходе образы, готовые к Kubernetes и совместимые с Helm и Harbor.

Аргумент, ради которого стоит смотреть, из практики: в крупных финансовых внедрениях на 500 с лишним приложений время закрытия уязвимости упало с недель до часов за счёт централизованного патча самого buildpack. Правите в одном месте, разъезжается по всем сервисам.

В контрибьюторах Bloomberg и Heroku от Salesforce, в дорожной карте OCI Artifacts, работа с SBOM и совместимость с WebAssembly.

Ваш пайплайн знает версию образа, но не знает, какая модель выдала странный ответ

Обычный CI/CD построен на понятной цепочке: изменился код, тесты проверили, собрался артефакт, приложение поехало по средам. С ИИ-приложениями модель ломается: поведение в проде меняется, даже когда код не менялся ни строчкой.

Сдвинуть вывод системы может новая версия модели, изменение преобразования признаков, конфигурация промпта, индекс для поиска или зависимость по данным. Для обычного сервиса хватало идентификатора коммита и образа; здесь к ним добавляются версия модели, определения признаков, конфигурация инференса, правила политик и схема данных.

Правило простое: если что-то способно изменить поведение в проде, оно должно быть версионировано и прослеживаемо. Иначе разбор инцидента превращается в гадание. Разбор перечисляет, что именно версионировать.

CoHDI даёт Kubernetes подключать и отключать PCIe-устройства на живой ноде

Проект приняли в песочницу CNCF. Запустили его в марте 2025 года совместно Red Hat, FSAS, Fujitsu, IBM Research и NTT, занимается он компонуемым железом в дезагрегированной инфраструктуре.

Практически это динамическое подключение и отключение устройств PCIe на уровне хоста через Dynamic Resource Allocation прямо на нодах Kubernetes. Железо перестаёт быть намертво привязанным к машине.

Где это даёт выигрыш: в инференсе больших моделей с разделением фаз, где prefill упирается в вычисления, а decode в память, и в агентных сценариях, где потребности меняются от шага к шагу. Заявка на заметную экономию энергии отсюда же.

SpaceWeb стукнуло 25, и вместе с Типичным программистом компания решила не только вспомнить прошлое, но и заглянуть вперёд.

В анкете школьные вопросы про спорт, друга и обои на рабочий стол соседствуют с историей аськи, скайпа и биткоина — всем, чем жил рунет с 2001 года. Здесь же история рунета за 25 лет и самой компании.

Запустить kubectl expose умеют все, объяснить, что при этом произошло, меньше десяти процентов

Автор отлаживал сетевые проблемы Kubernetes больше чем в десяти компаниях и говорит, что пробелы каждый раз одни и те же: как ClusterIP работает под капотом, почему поды из разных неймспейсов по умолчанию видят друг друга и что делает CNI-плагин на уровне ядра.

Гайд идёт снизу вверх: как назначаются IP подов и почему они работают между нодами, как kube-proxy реализует ClusterIP через правила iptables, как Ingress маршрутизирует внешний трафик через один балансировщик и как сетевые политики дают микросегментацию под требования SOC2 CC6.1.

Финал про Cilium и то, как eBPF заменяет всё перечисленное на более быстрый и наблюдаемый вариант. Открыть стоит перед тем, как в следующий раз спрашивать, почему под не достучался до сервиса.

tfpolicy переносит правила управления в HCL, тот же язык, что и сама инфраструктура

HashiCorp выпустила tfpolicy в публичную бету на HCP Terraform. Платформенные команды пишут правила на HCL вместо отдельного инструмента с отдельным синтаксисом.

Проверять умеет не только отдельный ресурс: доступны связи между ресурсами, внешние данные, использование провайдеров и модулей, а также живая инфраструктура уже после применения.

Смысл в том, чтобы убрать из стека второй язык политик и приблизить управление к рабочему процессу, который у команды уже есть. Если у вас сейчас OPA рядом с Terraform, это повод сравнить.

CISA добавила семь эксплуатируемых уязвимостей: SonicWall на 10,0 и Artifactory на 9,8

В каталог известных эксплуатируемых уязвимостей добавили семь записей: атакующие уже разворачивают через них обратные шеллы и майнеры.

CVE-2026-83548 в SonicWall SMA 1000 с оценкой 10,0 даёт неаутентифицированному атакующему доступ к чувствительным функциям через подделку запроса на стороне сервера. CVE-2026-9586 в Sangoma Switchvox, 9,3, позволяет одним запросом выполнить произвольный SQL против PostgreSQL и дойти до выполнения кода.

Первым делом стоит закрыть CVE-2026-82329 в JFrog Artifactory на 9,8: при конфигурации по умолчанию неаутентифицированный атакующий с сетевым доступом получает права администратора. Если Artifactory смотрит внутрь периметра, это ваш случай.

Апгрейд control plane за одиннадцать минут и без единого человека в цикле

Как это выглядело раньше: ночь, SSH на каждую ноду, апгрейд руками и постоянный присмотр за здоровьем etcd в надежде, что кворум переживёт очередную перезагрузку.

Оливье Кальци, Golden Kubestronaut, описывает пайплайн, который он построил, чтобы этой ночи больше не было, и, главное, как он проверил, что тот действительно работает.

Ценность материала в проверке, а не в схеме: одиннадцать минут от старта до готового обновлённого кластера, ноль людей. Прочитать стоит до того, как планировать следующий апгрейд вручную.

Лиз Фонг-Джонс: телеметрия это сырьё, наблюдаемость это свойство системы

Границу, которую большинство команд размывает, она проводит жёстко. Телеметрия это логи, метрики и трейсы, описывающие происходящее внутри системы. Наблюдаемость это способность соединить эти данные со знаниями людей и процессом и в итоге понять систему.

Отсюда её формулировка: наблюдаемость это живое качество софта, вроде тестируемости или доступности, и закончить работу над ней нельзя.

Сдвиг, который приносят агенты: они генерируют код инструментирования и просеивают горы телеметрии, но не убирают человека из цикла, а переносят его время с рутины на интерпретацию и решения. Под всей картиной, по её словам, лежит OpenTelemetry как общий стандарт.

Fallback на упавший сервис продаёт товар, которого нет на складе, но отличить такие места от безопасных помогает одно правило

Каталог, склад, заказы, расчёты с продавцом: любой из них может лечь, и вопрос не в том, как это предотвратить, а в том, какие запросы отдавать с деградацией, а какие обрывать. Разбор на dev.to предлагает критерий: обратима ли ошибка, если сервис угадал неверно.

Лёг каталог: отдавайте кэшированный снимок или пустую выдачу. Цена устарела на пару секунд, товар выглядит недоступным, и это чинится само, как только каталог вернётся.

Лёг склад или сервис выплат: fallback запрещён. Отгрузку и ушедший продавцу платёж не откатить UPDATE'ом, а сверка склада задним числом означает, что последнюю единицу продали пяти покупателям сразу. 503 с предложением повторить дешевле.

Что делать: пройти по своим fallback'ам и убрать те, что стоят перед необратимой операцией.

Инвалидация кеша по URL ломается на первом же обновлении товара, спасают теги

Короткий TTL кладёт базу наплывом запросов, длинный отдаёт устаревшие цены. Событийная очистка снимает выбор, но PURGE /api/products/linen-shirt заставляет помнить все адреса, которые задело одно обновление: карточку товара, листинг категории, страницу бренда. Забыли один — там висит старая цена.

Вместо адресов бэкенд проставляет в ответ теги: заголовок Surrogate-Key у Fastly, Cache-Tag у Cloudflare, значения вида product:1029, collection:summer. Прокси держит обратный индекс «тег → ответы в кеше» и по запросу на product:1029 выбрасывает их во всех точках присутствия.

Что сделать: дёргать очистку из вебхука после коммита в БД, а не до; добавить ретраи с идемпотентным ключом, иначе потерянная доставка держит устаревший ответ до конца TTL; сам TTL оставить длинным как страховку. Схема — в статье на dev.to.

Образ в вашем проде теперь можно проверить одной командой: из какого коммита и каким пайплайном он собран

В Packer v1.16.0 появился post-processor provenance. На каждую сборку он выпускает и подписывает attestation, то есть машиночитаемую справку о происхождении образа: коммит, репозиторий и ref, пайплайн, время сборки. Формат стандартный (in-toto с предикатом SLSA Provenance v1), поэтому такую подпись понимают и сторонние сканеры цепочки поставки.

У локальных артефактов подпись привязана к SHA-256 файла, у облачных — к builder ID и artifact ID, плюс URI реестра HCP Packer, если билдер его отдаёт.

Что делать: обновиться до 1.16.0, дописать post-processor в build-блок и поставить проверку packer verify-attestation в пайплайн деплоя перед раскаткой.