Учимся на практике: как выбрать правильный Distroless Base Image 🤔

На этот раз тебе предстоит разобраться с контейнером, который ведёт себя некорректно. Приложение даже не может стартовать

Твоя задача – найти причину проблемы и устранить её. Возможно, для этого придётся пересобрать образ.
Лабораторная работа: https://labs.iximiuz.com/challenges/pick-the-right-distroless-base-image

👉 DevOps Portal

DevOps-инструмент недели: Dragonfly

Загрузка модели размером 130 ГБ на 200 GPU-нод создаёт около 26 ТБ сетевого трафика.

Но что если ноды будут скачивать данные друг у друга, а не напрямую из исходного источника?

Именно для этого нужен Dragonfly – опенорс система P2P-распространения файлов.

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

Что умеет Dragonfly 👇
- Поддерживает прямую загрузку моделей из Hugging Face и ModelScope.
- Разбивает файлы на части и начинает раздачу по P2P ещё до завершения первого скачивания.
- Снижает нагрузку на источник с 26 ТБ до примерно 130 ГБ при развёртывании на 200 нодах.
- Поддерживает работу с приватными репозиториями через аутентификацию по токенам.
- Разворачивается в Kubernetes как DaemonSet.

GitHub-репозиторий: https://github.com/dragonflyoss/dragonfly

👉 DevOps Portal

Как запускать Linux-демон при первом подключении к его API-сокету?

Одно из ключевых назначений systemd – запуск и управление долго работающими фоновыми процессами. Демоны регистрируются в systemd как service units и обычно стартуют во время загрузки системы.

Однако если сервис не нужен сразу после загрузки и предоставляет API через TCP-сокет или Unix-сокет, зачастую эффективнее запускать его только тогда, когда к нему подключается первый клиент. Такой механизм называется socket activation.

Изучите, как работает socket activation в systemd, выполнив следующие задания:

- Запустите сервис при первом подключении к его TCP-сокету:
https://labs.iximiuz.com/challenges/systemd-socket-activate-listen-stream-inet
- Запустите сервис при первом подключении к его Unix-сокету:
https://labs.iximiuz.com/challenges/systemd-socket-activate-listen-stream-unix

👉 DevOps Portal

VPN и mTLS — это базовые и обязательные для понимания технологии для DevOps-инженеров.

Это руководство поможет вам на практике разобраться со следующими темами:
- VPN типа Client-to-Site
- Генерация клиентских и серверных сертификатов с помощью EasyRSA
- Взаимная TLS-аутентификация (mTLS)

Почему это важно изучить?
Практически в любой организации VPN используется для безопасного подключения к облачным ресурсам и внутренней инфраструктуре.

Лучший способ по-настоящему понять, как работают VPN и mTLS, — развернуть и настроить их самостоятельно.

Подробное руководство: https://devopscube.com/aws-client-vpn/

В рамках руководства в теоретическом формате также рассматриваются следующие темы:
- Аутентификация на основе SAML и Active Directory
- TCP vs UDP — различия и сценарии использования

👉 DevOps Portal

DevOps-инструмент недели: AirLLM

Для локального запуска больших моделей вам не нужен мощный GPU.

AirLLM — это open-source инструмент, который позволяет запускать крупные модели на одной видеокарте, не загружая всю модель в VRAM целиком.

Он разбивает модель на слои и во время инференса подгружает их по одному.

Вот как это работает 👇

- При первом запуске AirLLM скачивает полную модель, разбивает её на отдельные шарды по слоям и сохраняет их на локальном диске.
- Когда вы отправляете запрос, модель начинает загружаться в VRAM послойно.
- Сначала из диска в VRAM видеокарты загружается первый слой, выполняется его обработка, затем память освобождается и загружается следующий слой.
- Этот процесс повторяется для каждого слоя. После обработки всех слоёв AirLLM возвращает ответ на ваш запрос.

Благодаря такому подходу даже GPU с 4 ГБ видеопамяти способен запускать модель размером 70B параметров.

Начать можно здесь: AirLLM GitHub Repository

👉 DevOps Portal

Корректное завершение работы контейнеризированных приложений может быть не таким простым, как кажется

Разберитесь с типичными подводными камнями на практике:

- Слишком медленная последовательность остановки приложения: https://labs.iximiuz.com/challenges/docker-graceful-container-shutdown
- Потеря сигналов при их передаче процессам: https://labs.iximiuz.com/challenges/graceful-termination-for-nodejs-container
- Некорректно работающий entrypoint-скрипт: https://labs.iximiuz.com/challenges/graceful-termination-for-container-with-entrypoint

Приятного хаккинга! 🚀

👉 DevOps Portal

Шпаргалка по SSH-туннелям

Забавный факт: с появлением ИИ-агентов и песочниц я стал пользоваться SSH даже чаще – это по-настоящему фундаментальная технология.

👉 DevOps Portal

Как правильно работать с резервным копированием в облаке?

25 июня приглашаем на бесплатный вебинар от MWS Cloud Platform всех, кто работает с облаками.

⚫️Развеем мифы, разберём лучшие современные подходы и инструменты.

⚫️Обсудим интеграцию в процессы, консистентность, точечное восстановление и безопасность. Поговорим о плюсах нативных облачных инструментов.

⚫️Проведём демо в MWS Cloud Platform и ответим на ваши вопросы.

Зарегистрируйтесь, чтобы не пропустить!

⏰ 25 июня в 14:00 (мск)

✅ Зарегистрироваться

Kubernetes NodeLocal DNSCache: как это работает

Когда речь заходит о производительности, в Kubernetes важен каждый DNS-запрос.

Без NodeLocal DNSCache поды отправляют DNS-запросы на Service IP kube-dns/CoreDNS.

Эти запросы проходят через kube-proxy, правила DNAT и conntrack, прежде чем попасть в CoreDNS.

В загруженных кластерах это может приводить к дополнительным задержкам и увеличивать нагрузку на таблицу conntrack.

NodeLocal DNSCache решает эту проблему, разворачивая локальный DNS-кеш на каждой ноде в виде DaemonSet.

В результате поды обращаются не напрямую к CoreDNS, а к локальному DNS-кешу на той же ноде.

Основные преимущества:
- Сокращает среднее время DNS-резолвинга, поскольку многие запросы обрабатываются локально из DNS-кеша.
- Снижает нагрузку на CoreDNS.
- Помогает избежать переполнения таблицы conntrack, так как соединения между подами и локальным DNS-кешем не создают записей в conntrack.
- DNS-запросы к внешним доменам могут форвардиться напрямую, без участия CoreDNS.

Примечание: NodeLocal DNSCache не включён в Kubernetes по умолчанию.

Для его использования необходимо вручную развернуть DaemonSet с NodeLocal DNSCache (за исключением некоторых managed-решений, например GKE Autopilot, где эта функциональность уже включена по умолчанию).

👉 DevOps Portal

Pod Affinity vs Pod Anti-Affinity

В Kubernetes

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

Вот самый простой способ запомнить
Pod Affinity = держать поды вместе
Pod Anti-Affinity = разносить поды друг от друга

Когда использовать Pod Affinity?

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

Когда использовать Pod Anti-Affinity?

Используйте, когда нужна высокая доступность.
Например, несколько реплик backend-сервиса распределяются по разным нодам, чтобы отказ одной ноды не положил всё приложение.

👉 DevOps Portal

Gateway API vs Ingress Controller

Вот ключевое различие, которое важно понимать

В Kubernetes объект Ingress лишь описывает правила маршрутизации.

Фактическая обработка и маршрутизация трафика выполняется Ingress Controller, который одновременно выступает и контроллером, и прокси-сервером.

С Gateway API процесс выглядит почти так же.

Вы создаёте такие ресурсы, как Gateway и HTTPRoute, чтобы управлять маршрутизацией и потоком трафика.

Затем контроллер Gateway API (NGINX Gateway Fabric) преобразует эти конфигурации в реальные правила маршрутизации и необходимую сетевую инфраструктуру.

Но здесь есть важное отличие в архитектуре NGINX Gateway Fabric.

У него control plane и data plane разделены.

Когда вы создаёте ресурс Gateway, контроллер автоматически разворачивает выделенный pod с NGINX (data plane), который непосредственно обрабатывает входящий трафик.

В случае с Ingress сам контроллер одновременно выполняет роль прокси и обрабатывает трафик.

👉 DevOps Portal

DevOps-инструмент недели: SpecKit

Инструменты для AI-кодинга часто упускают то, что вам действительно нужно.

Spec Kit — это open-source тулкит от GitHub, который ставит требования к проекту на первое место.

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

Что умеет Spec Kit
- Проводит агентов через структурированный workflow: Spec → Plan → Tasks → Implement
- Использует файл правил для определения проектных требований и ограничений, которым должен соответствовать каждый этап
- Выявляет пробелы и недостающие требования ещё до начала разработки
- Генерирует чек-листы требований для валидации результата
- Поддерживает более 30 AI-инструментов для разработки, включая Claude Code, Copilot, Cursor и Codex.

Начать можно здесь: https://github.com/github/spec-kit

👉 DevOps Portal

В этом туториале вы узнаете, как настроить событийное trace-based тестирование в Kubernetes с помощью Tracetest и Testkube

https://tracetest.io/blog/event-driven-kubernetes-testing-with-testkube-and-tracetest

👉 DevOps Portal

Зоопарк решений растёт, а команда — нет

Одни сервисы развёрнуты в облаке, другие — на своих серверах, а третьи – в изолированном контуре. Чем больше «зоопарк», тем сложнее управлять такой инфраструктурой. Вместо того, чтобы нанимать нового DevOps-инженера, можно автоматизировать рутинные операции.

30 июня на вебинаре мы представим сервис, который поможет автоматически управлять лоскутной инфраструктурой в режиме «одного окна».

Мы покажем, как с помощью MWS B2B Store:

1️⃣ Деплоить сервисы в VMware и K8s через Terraform as a Service
2️⃣ Автоматически «раскатывать» обновления в изолированные контуры
3️⃣ Контролировать, кто и как использует лицензии на серверное ПО
4️⃣ Управлять инстансами из разной инфраструктуры в едином окне

Вместо слайдов — живое демо. Вы сможете задать любые вопросы и разобрать ответы со спикерами.

⏰ 30 июня в 11:00

Будет полезно: CTO, директорам по инфраструктуре, DevOps-инженерам и тимлидам инфраструктурных команд.

Регистрируйтесь по ссылке

Если вы работаете в DevOps, то SLSA — это концепция безопасности, которую обязательно нужно знать.

Сегодня злоумышленники всё чаще атакуют CI/CD-пайплайны ещё до того, как код попадает в продакшен-кластеры.

Недавний компромисс цепочки поставок npm-пакетов TanStack в 2026 году – наглядный тому пример.

Когда ваш CI-пайплайн собирает контейнерный образ и публикует его в реестр,

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

Для большинства команд доказать это невозможно.

Фреймворк SLSA создан именно для решения этой проблемы.

В этой статье разобрали:

- Что такое SLSA Provenance и уровни доверия
- Как внедрить SLSA в ваш CI/CD-пайплайн
- Как проверять Provenance в Kubernetes с помощью Admission Policies
- Три инцидента в цепочке поставок ПО, о которых должен знать каждый DevOps-инженер

Читайте здесь: https://newsletter.devopscube.com/p/slsa-explained

👉 DevOps Portal

Изучите все основные концепции Prometheus за 8 минут

В этой статье вы узнаете:
- Что представляет собой архитектура Prometheus?
- Сервер Prometheus
- База данных временных рядов (TSDB)
- Таргеты в Prometheus
- Экспортеры Prometheus
- Механизм Service Discovery в Prometheus
- Prometheus Pushgateway
- Клиентские библиотеки Prometheus
- Alertmanager
- PromQL

Подробная статья: https://devopscube.com/prometheus-architecture/

👉 DevOps Portal

Быстрый совет по Linux

Хотите понять, что именно запустится, когда вы введёте команду?

Используйте:

$ which ssh

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

Удобный способ проверить пути к командам, алиасы и разобраться с проблемами в окружении shell.

👉 DevOps Portal

Как ИИ меняет инфраструктуру дата-центров

Рост ИИ-нагрузок требует изменений не только на уровне разработки, но и на уровне всей инфраструктуры.

На infra.conf’26 Яндекс анонсировали, как адаптирует физическую и ML-инфраструктуру для дальнейшего масштабирования ИИ-сервисов.

Что меняется 👇
- Компания переходит к концепции кампусов дата-центров. Такой подход позволяет наращивать мощность до 180 МВт, что является рекордным показателем для России.
- В дата-центрах внедряется жидкостное охлаждение. Оно обеспечивает более эффективное терморегулирование вычислительного оборудования и помогает снижать энергопотребление.
- Для ML-разработчиков запущен внутренний сервис Dev Cluster. Он ускоряет проведение экспериментов и сокращает время разработки моделей.

Изменения затрагивают как физическую инфраструктуру, так и внутренние платформенные инструменты, необходимые для развития ИИ.

👉 DevOps Portal