DevOps *

Между сборкой контейнера в CI и его запуском на узле есть длинная цепочка, в которой злоумышленники могут что-то подменить. Образ в registry, слои на диске, конфигурация в etcd, бинарники рантайма — каждый участок требует своей защиты. 

Рассказываем, как мы реализовали сквозной контроль целостности в Deckhouse Kubernetes Platform: что доработали в containerd и kube-apiserver, как подписываем ELF-файлы и почему выпадение любого звена ломает всю систему. Если вы строите свой контур доверия, в статье есть Open Source-альтернативы для старта.

DNS — это та штука, которую замечаешь только когда она падает. Весь твой трафик, почта, сертификаты, доступ к админкам — всё висит на том, что кто-то корректно ответит на запрос «а где example.com?». У меня этим «кем-то» был Cloudflare. Для большинства это правильный выбор — удобно, быстро, бесплатно. Но в какой-то момент я поймал себя на мысли, что фундамент всей моей инфраструктуры я не контролирую: он живёт в чужом дашборде, по чужим правилам и лимитам.

Я перенёс все свои зоны — несколько десятков доменов — на собственную DNS-инфра- структуру. Ниже — зачем, какая получилась архитектура, и обо что я споткнулся по дороге.

Карьерный рост в IT редко упирается только в «выучить еще один инструмент». Чаще проблема в другом: понять, какие технологии уже стали рабочей практикой, где стоит углубиться в архитектуру, а где пора закрыть пробелы в инфраструктуре, безопасности, аналитике или управлении.

В этом дайджесте собрали 62 бесплатных открытых урока OTUS на июнь — от Java, Docker, Kubernetes, Kafka и SRE до LLM, DWH, Data Mesh, тестирования и ИБ. Занятия проводят преподаватели-практики, поэтому это не обзор ради обзора, а возможность разобрать актуальные темы с экспертами и задать вопросы.

3.3. Что я сделал бы иначе

Закладывал бы MLOps с первого дня, а не «сначала модель, потом инфраструктура». Параллельно — дешевле.

Автоматизировал бы тестирование данных раньше. Самые неприятные баги — не в коде, а в «тихом» изменении распределения.

Завёл бы playbook для инцидентов. Когда что-то падает в три часа ночи, нужен чеклист, а не паника.

Глава 4. Чеклист: готов ли проект к масштабированию

Это самая практичная часть — её можно унести с собой.

Представьте: сотни микросервисов, неделя на поиски API, устаревшая документация. Backstage от Spotify превращает хаос в порядок — и возвращает контроль над масштабом.

Статья получилась большой: практик много, и каждая из них важна по-своему. Я собрал её как набор best practices: не все пункты нужны каждому проекту, но почти каждый пункт однажды всплывает на ревью, в CI или после неприятного инцидента.

Я старался писать для разных грейдов: от базовых ошибок вроде COPY . ., latest и root-пользователя до продовых тем вроде BuildKit, секретов, SBOM, подписи образов и защиты цепочки поставки ПО.
Поэтому язык подачи здесь намеренно сухой, прямой и инженерный: без долгих заходов, без воды и без пересказа документации ради пересказа. Я хотел сделать не обзорную статью, а рабочую памятку, к которой можно вернуться при написании, ревью или доработке Dockerfile.

Чтобы в статье было легче ориентироваться, я разбил её на смысловые блоки. Ниже оглавление: нажали на нужный пункт — сразу перешли к соответствующему разделу.

Оглавление:

1. Базовый образ, версии и управляемое обновление

2. Контекст сборки, .dockerignore, копирование файлов и безопасное получение внешних данных ...

Я создал собственный бенчмарк для оценки языковых моделей, потому что стандартные публичные тесты не отвечают на мой главный вопрос: какая модель лучше справляется с триажем security-находок. Эта задача отличается от оценки общей сообразительности модели.

Все мы любим envsubst за простоту, но он примитивен. Переходить на Python с Jinja2 ради шаблонизации конфигов в CI/CD — всё равно что стрелять из пушки по воробьям, да и тащить рантайм ради пары переменных не хочется. В мире Go есть неплохие аналоги, но их вес в 100 МБ вгоняет в тоску, когда стремишься к минимализму в Docker-образах.

Теперь всё изменилось так как появился muenvsubst — замена стандартной утилите, написанная на C++17, заточенная под хардкорную шаблонизацию в инфраструктуре. В этой статье я расскажу, как уместить мощь, близкую к Jinja2 (включая циклы, условия, макросы и вызов shell), в статический бинарник весом менее 400 КБ.

Самый полный обзор видеокарты V100 в интернете! Или как собрать самый бюджетный ИИ-сервер в 2026 году. Внутри вас ждёт:

1. Что за V100 и почему она такая дешевая?
2. Какие у неё ограничения и где она реально спотыкается?
3. Бенчмарки 128 моделей — от текста до генерации видео и картинок, с реальными конфигурациями запуска!

Представьте: ваш сервис Y генерирует 10 000 событий в секунду, а сервис X может проглотить только 500. И при этом нельзя потерять ни одного события, а порядок обработки обязан быть строгим. Очередь? Конечно. Но какую? И что делать, когда она переполнится?

В статье — разбираем реальную архитектурную задачу с разбором типовых ошибок, двух подходов к порядку (strict FIFO и per‑key ordering), нюансами DLQ, backpressure, идемпотентностью и скрытыми проблемами типа head‑of‑line blocking.

Пятница, вечер. Один эндпоинт начал отвечать восемь секунд вместо двухсот миллисекунд, а в Grafana всё зелёное. PostgreSQL редко падает громко — он неделями копит мёртвые строки, лишние индексы и зависшие транзакции, пока не станет совсем плохо.

В статье — пять SQL-запросов из моего queries.sql, которыми я реально пользуюсь: bloat и dead tuples, топ тяжёлых запросов по pg_stat_statements, неиспользуемые индексы, висящие транзакции и блокировки. Работают на голом PostgreSQL 13+

Поднял Kubernetes кластер на 5 VM с нуля на VMware: Calico IPIP, MetalLB, GitOps через ArgoCD, PostgreSQL HA. Три неочевидные проблемы которые съели много времени — MTU и TLS, нестабильный BGP на VMware, конфликты git push в GitOps.

Классическая проблема аналитических систем: кластер СУБД сайзится под пик, а 28 дней в месяц он задействован чуть больше чем наполовину. StarRocks (shared-data) и автоскейл Kubernetes убирают этот избыток. Compute добавляется под нагрузку и сворачивается на спаде. Внутри легкая пятничная статья: как это работает и где у эластичности потолок.

Привет, я Даниил, DevOps-инженер в KTS.

Я работаю над инфраструктурой одной крупной сети. В ее штате несколько команд разработки, которые делят между собой больше 40 микросервисов, составляющих одну систему. Ожидаемо, со временем их dev-стенд сильно отстал от продакшена, и разные команды с трудом протаскивали новые фичи до релиза.

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

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

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

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

Cilium работает в сетевом пути уровня ядра в миллионах Kubernetes-pod'ов: от облачных провайдеров до собственных кластеров банков и телекомов. Если бы кто-то скомпрометировал сборочный пайплайн Cilium, зона поражения была бы сопоставима с инцидентом SolarWinds, но в облачно-нативной экосистеме. Поэтому подход проекта к безопасности CI/CD интересен не только мейнтейнерам других опенсорс-проектов: те же паттерны полезны любой команде, которая собирает прод-артефакты в GitHub Actions. Команда VK Cloud перевела статью с конкретными YAML-конфигами, дизайн-решениями и честным списком того, что у Cilium пока не сделано.

Привет, Хабр! Примерно полтора года назад я решил обновить наш рабочий Nexus Repository OSS — и был «приятно» удивлён: Sonatype отказались от OSS-версии и перешли на Community Edition с лимитами на количество репозиториев и компонентов. Платить за Pro я не хотел, переходить на Artifactory тоже — JFrog ушёл из России ещё в 2022-м. Так что пообещал себе разобраться с этим «на следующих выходных» и написать что-то своё. Выходные закончились, а я всё ещё пишу код 🙂 Но зато получился нормальный инструмент, которым пользуемся сами — и теперь хочу рассказать про него.

Это статья про Nexspence — open-source менеджер артефактов на Go, который поддерживает 14 форматов пакетов и совместим с Nexus REST API.

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

В статье разбираем 5 типичных провалов при внедрении SRE: от формального переименования эксплуатации до поспешной покупки AIOps без нормального observability. Это разбор о том, почему надежность ломается не только в инфраструктуре, но и в процессах, метриках, найме и управленческих стимулах.

Для соло-разработки на ИИ-агентах уже есть много готовых инструментов — не только голый tmux.

Agent Deck, AoE, Vibe Kanban и похожие решения помогают запускать много параллельных агентских сессий локально и удаленно. Сами вендоры тоже идут в эту сторону: например, в Claude Code недавно появился /agent-view.

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

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

Сегодня я расскажу как сделать базовый агентный runtime для команд от 2х человек:

Привет, Хабр!

Меня зовут Артём Бердашкевич, в Positive Technologies руковожу направления DevSecOps. Сегодня хочу поговорить о теме, которая с годами становится только острее — о контроле зависимостей и о том, почему привычных подходов к нему уже катастрофически не хватает. Современная разработка давно превратилась в сборку из готовых компонентов, где мы почти не пишем код с нуля, а комбинируем фреймворки, библиотеки и модули с открытым исходным кодом. Такой подход радикально ускоряет вывод продуктов на рынок, но за скорость приходится платить прозрачностью. Команда часто не знает точный состав своего приложения до финальной сборки. Почему это стало большой проблемой и что с ней делать — читайте под катом.