🛠Построение CI/CD-фреймворка MLOps уровня Enterprise (MLflow + Kubeflow)

Разработка MLOps-фреймворка в масштабах предприятия — непростая задача. Она требует интеграции множества компонентов: обработки данных, экспериментов, мониторинга и CI/CD. В этом посте рассказывается, как объединить MLflow, Kubeflow, Seldon Core, GitHub Actions и другие инструменты для построения полноценного MLOps-пайплайна.

Архитектура

Архитектура построена на:

- MLflow — для логирования и управления экспериментами
- Kubeflow Pipelines — для оркестрации пайплайнов
- Seldon Core — для деплоя моделей в Kubernetes
- MinIO — объектное хранилище для артефактов
- GitHub Actions — для CI/CD
- Prometheus + Grafana — мониторинг моделей

Компоненты развернуты в Kubernetes-кластере с использованием Helm.

Поток разработки

1. Подготовка данных — скрипты ETL обрабатывают сырые данные и сохраняют в MinIO.
2. Обучение модели — тренинг происходит в Kubeflow, результаты логируются в MLflow.
3. Тестирование и валидация — автоматизированные проверки модели.
4. CI/CD — GitHub Actions запускает пайплайны при изменении кода или модели.
5. Деплой — модель деплоится через Seldon Core, становится доступной по REST/gRPC.
6. Мониторинг — метрики поступают в Prometheus и отображаются в Grafana.

Преимущества подхода

- Реплицируемость и трассировка экспериментов
- Централизованное хранилище артефактов
- Автоматизация развёртывания моделей
- Мониторинг производительности и дрифта

Заключение

Такой фреймворк обеспечивает устойчивую MLOps-инфраструктуру, подходящую как для небольших команд, так и для крупных корпораций. Он позволяет быстрее и безопаснее доставлять ML-модели в продакшен.

https://rkmaven.medium.com/building-an-enterprise-level-mlops-ci-cd-framework-mlflow-kubeflow-fb1cdd1f74fc

#devops #девопс

Подпишись 👉@i_DevOps

💡 Лучшие практики работы с Helm: что нужно знать

Если вы используете Helm для управления приложениями в Kubernetes, крайне важно следовать ряду проверенных практик, чтобы обеспечить поддержку, масштабируемость и безопасность ваших чартов.

📦 1. Структура директорий чарта
Соблюдайте стандартную структуру чарта Helm:

mychart/
  charts/
  templates/
  values.yaml
  Chart.yaml
  README.md

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

🧩 2. Разделяйте общие шаблоны
Используйте _helpers.tpl для определения общих шаблонов, таких как аннотации, метки и имена ресурсов. Это снижает дублирование и упрощает сопровождение:

{{/* Генерация полного имени */}}
{{- define "mychart.fullname" -}}
{{- printf "%s-%s" .Release.Name .Chart.Name | trunc 63 | trimSuffix "-" -}}
{{- end -}}

⚙️ 3. Используйте параметры в values.yaml
Делайте чарты гибкими, передавая конфигурации через values.yaml. Никогда не хардкодьте значения в шаблонах.

🧪 4. Валидация values.yaml
Добавляйте проверку обязательных значений с помощью required:

{{ required "Variable mychart.image.repository is required" .Values.image.repository }}

🔍 5. Используйте шаблоны if/else разумно
Старайтесь не перегружать шаблоны логикой. Разделяйте шаблоны на несколько файлов, если они становятся слишком сложными.

🗃️ 6. Не добавляйте чарт в шаблон напрямую
Вместо включения зависимостей в директорию charts/, указывайте их в Chart.yaml и используйте helm dependency update.

🛑 7. Не хардкодьте версии образов
Передавайте версию через values.yaml. Это повышает гибкость CI/CD:

image:
  repository: nginx
  tag: "1.21.1"

🔒 8. Управление чувствительными данными
Не храните пароли и токены в values.yaml. Используйте секреты Kubernetes или инструменты типа Sealed Secrets или External Secrets.

🔁 9. Helm hooks
Helm предоставляет хуки для выполнения задач до/после установки. Используйте их, например, для миграций БД. Пример:

annotations:
  "helm.sh/hook": pre-install

🧹 10. Чистка старых релизов
Используйте helm uninstall и регулярно проверяйте статус релизов с помощью helm list. Это помогает избегать конфликта имён и мусора.

🧪 11. Тестирование чарта
Добавляйте unit-тесты с помощью helm unittest и не забывайте про проверку синтаксиса:

helm lint .

🔄 12. Автоматизация через CI/CD
Интегрируйте Helm в пайплайны CI/CD для установки и обновления чартов — например, с помощью GitLab CI, GitHub Actions, ArgoCD или Flux.


Придерживайтесь этих рекомендаций — и работа с Helm станет надёжной, устойчивой и более предсказуемой. Это особенно важно при масштабировании инфраструктуры и работе в команде.

#devops #девопс

Подпишись 👉@i_DevOps

Блокировка состояния Terraform с использованием S3 (без DynamoDB)

В этом посте мы рассмотрим:

- Зачем нужна блокировка состояния Terraform
- Блокировка состояния с помощью DynamoDB
- Блокировка состояния только с использованием S3, без DynamoDB
- Когда стоит использовать DynamoDB
- Когда можно обойтись только S3
- Лучшие практики хранения state-файлов в S3

https://devopscube.com/terraform-state-locking-with-s3/

#devops #девопс

Подпишись 👉@i_DevOps

• infosec - это один из самых ламповых каналов по информационной безопасности, где говорят об истории ИТ, публикуют актуальные новости и пишут технический материал на разные темы:

- Что из себя представляет официально взломанный iPhone от Apple?
- Кому и для чего выдавалось разрешение на ношение сотового телефона?
- Бесплатные курсы для ИБ специалистов на различные темы;
- Бесплатный бот, который проверит файлы на предмет угроз более чем 70 антивирусами одновременно.

• Присоединяйся, у нас интересно: @it_secur

Проект heynote — это минималистичное CLI-приложение для создания и хранения заметок прямо из терминала. Он позволяет быстро фиксировать мысли или команды без необходимости переключаться на редактор или веб-интерфейс.

📌 Особенности:
- Хранит заметки в простом .txt-файле.
- Поддерживает добавление тегов (`#`) и отметок времени.
- Удобная фильтрация заметок по ключевым словам или датам.
- Возможность настройки пути к файлу хранения.

Пример использования:

heynote "Перезапустить nginx #devops"

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

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

https://github.com/heyman/heynote

#devops #девопс

Подпишись 👉@i_DevOps

Addon Controller

Sveltos Addon Controller позволяет пользователям применять Kubernetes-манифесты к любым кластерам, управляемым Sveltos. Это может быть сделано следующими способами:

- Добавляя YAML-файлы с Kubernetes-ресурсами в ConfigMap или Secret.
- Указывая URL с YAML-ресурсами.
- Указывая Helm-чарт.

Addon Controller – это контроллер Kubernetes, который работает в управляющем кластере (management cluster). Он следит за созданием и обновлением объектов Addon, а также применяет соответствующие манифесты в целевых (managed) кластерах, на которые ссылается Addon.

Возможности

- Поддержка ConfigMap, Secret, URL и Helm-чартов.
- Поддержка переменных через ClusterProfile и ClusterSummary.
- Возможность динамически применять или удалять аддоны при изменении кластера или его свойств.
- Возможность настройки приоритетов применения ресурсов.
- Поддержка зависимостей между ресурсами.
- Поддержка dry-run и прерывания применения при ошибке.

Архитектура

1. Пользователь создает объект ClusterProfile, в котором указывает критерии выбора кластеров.
2. Для каждого подходящего кластера создается объект ClusterSummary, который содержит список Addon объектов.
3. Addon Controller применяет ресурсы, указанные в Addon, к каждому целевому кластеру.


https://github.com/projectsveltos/addon-controller?tab=readme-ov-file

#devops #девопс

Подпишись 👉@i_DevOps

Освойте Linux с Selectel
 
Вы начинающий DevOps-инженер, системный администратор или разработчик? Или только думаете над тем, чтобы начать освоение Linux?
 
Selectel запускает бесплатный курс «Администрирование Linux с нуля». Проходите в комфортном для себя темпе и проверяйте полученные знания на реальных задачах.
 
Чему вы научитесь:
 
– Управлять пакетами и обновлениями программного обеспечения
– Настраивать сети, SSH-соединения и мониторинг системы
– Управлять пользователями, файлами и правами доступа
– Работать с командной строкой Linux и основными утилитами
– Анализировать логи и устранять инциденты
 
Зарегистрируйтесь на курс «Администрирование Linux с нуля» по ссылке
 
Реклама. АО «Селектел», ИНН 7810962785, ERID: 2Vtzqv2HnyP

Как настроить автоматический откат в Ansible

Петя запускает плейбук, чтобы обновить конфигурацию Nginx — и ломает сайт. В конфиге ошибка, сервис не стартует.

Ansible не умеет откатывать изменения сам. Но есть способ настроить автоматический откат — с помощью блоков block, rescue и always.

https://habr.com/ru/articles/900240/

#devops #девопс

Подпишись 👉@i_DevOps

Запускаем Sentry в Kubernetes в Яндекс облаке и храним Nodestore в S3

Sentry — это инструмент для отслеживания ошибок и производительности приложений в реальном времени.

Кратко о Sentry: что это, зачем он нужен
- Отслеживает баги и exceptions в бекенд, веб и мобильных приложениях.

Для кого этот пост
- Этот пост для тех кто хочет перейти с Sentry в docker-compose
- Для тех кто хочет перейти с Nodestore в PostgreSQL

https://habr.com/ru/articles/900526/

#devops #девопс

Подпишись 👉@i_DevOps

Расследование аферы с GitHub: как тысячи «модов» и «кряков» крадут наши данные

Просматривая статьи на тематическом форуме по социальной инженерии, я обнаружил относительно новую схему мошенничества, которая меня потрясла. На GitHub создаются тысячи репозиториев с разными штуками — от модов для Roblox и Fortnite до «взломанных» FL Studio и Photoshop.

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

https://habr.com/ru/companies/flant/articles/899158/

original https://timsh.org/github-scam-investigation-thousands-of-mods-and-cracks-stealing-your-data/

#devops #девопс

Подпишись 👉@i_DevOps

⚡️ Performance Testing в микросервисах: как избежать коллапса под нагрузкой?

Что произойдёт, если на ваш сервис внезапно обрушится поток пользователей? Выдержит ли архитектура или ляжет под нагрузкой? Разбираем, как правильно тестировать производительность микросервисов, чтобы система работала без сбоев!

📅 17 апреля в 20:00
🎓 Открытый вебинар с Сергеем Прощаевым

💡 Что разберём?
✅ Как нагрузка ломает архитектуру и что с этим делать
✅ Главные ошибки при тестировании распределённых систем
✅ Как увеличить RPS и подготовить систему к реальной нагрузке
✅ Инструменты стресс-тестирования и шаблоны конфигурации

🎯 Что получите?
✔️ Понимание, как прогнозировать нагрузку и готовить систему
✔️ Навыки работы с инструментами нагрузочного тестирования
✔️ Готовые шаблоны для тестирования и повышения устойчивости микросервисов

Присоединяйтесь и узнайте, как защитить свой сервис от падений!

👉 Регистрируйтесь по ссылке: https://vk.cc/cKOkqx

Бесплатное занятие приурочено к старту курса Microservice Architecture, обучение на котором позволит освоить микросервисы: Docker, Kafka, API и стать мастером производительных систем.

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

🔥 Как ускорить docker build и сократить размер образа

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


1. Используй multistage build
Разделяй стадии сборки и финальный образ. Это особенно важно при компиляции (Go, Java, Node.js):

# Стадия 1: билд
FROM golang:1.20 as builder
WORKDIR /app
COPY . .
RUN go build -o app

# Стадия 2: минимальный runtime
FROM alpine:latest
COPY --from=builder /app/app /usr/local/bin/app
ENTRYPOINT ["app"]

Образ получается меньше 10 МБ!


2. Минимизируй base image
Используй alpine, distroless, scratch, если не нужен полноценный дистрибутив:

FROM python:3.12-slim

Или вообще:

FROM scratch

3. Правильно расставляй COPY и RUN
Кешируй слои — сначала зависимости, потом исходники:

COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .

Так pip install не будет повторяться при каждом изменении исходников.


4. Убирай мусор и временные файлы
После установки пакетов — чисти кэш:

RUN apt-get update && apt-get install -y ... \
 && rm -rf /var/lib/apt/lists/*

5. Используй .dockerignore
Иначе в билд попадут node_modules, .git, логи и прочее:

.git
node_modules
*.log

Вывод:
Минимизация образа — это не только про размер, но и про безопасность (меньше surface area), скорость CI/CD, стабильность. И не забывай — docker build тоже надо профилировать.

#devops #docker #ci #optimization

Подпишись 👉 @i_DevOps

🔥 Ускоряем сборку Docker-образов: слои и кэш — наши друзья

Когда сборка Dockerfile занимает минуты — это мешает dev-loop'у. А ведь можно сильно ускориться с парой простых правил 👇


🧠 Основные принципы ускорения:

1. Максимально используем кэш
Docker кэширует каждый слой. Если слой не изменился — пересобирать не будет.

➤ Сначала COPY зависимости, потом остальной код:

   COPY requirements.txt .
   RUN pip install -r requirements.txt  # кэшируется

   COPY . .  # некэшируемо при любом изменении в коде
   

2. Объединяем RUN-команды
Меньше слоёв — быстрее сборка и push:

   RUN apt update && apt install -y curl git \
       && rm -rf /var/lib/apt/lists/*
   

3. .dockerignore
Убедись, что не копируешь лишние файлы (например, .git/, tests/, node_modules/):

   .git
   node_modules
   *.log
   __pycache__/
   

4. Меньше COPY, больше multi-stage
Разделяй сборку и runtime — не таскай компиляторы в прод:

   FROM golang:1.20 AS builder
   WORKDIR /app
   COPY . .
   RUN go build -o app

   FROM debian:bullseye-slim
   COPY --from=builder /app/app /usr/bin/app
   CMD ["app"]
   

5. Кэшируй pip/npm/go-пакеты
→ в Dockerfile сначала копируй файл зависимостей, ставь пакеты, только потом — весь код проекта.


📌 Используй эти практики, чтобы ускорить CI/CD, локальную сборку и деплой. Чем меньше слоёв изменяется — тем быстрее весь процесс.


#devops #девопс

Подпишись 👉@i_DevOps

🔥 Как ускорить GitHub Actions на 40% и платить меньше

CI — это не место для медлительности. Особенно когда билд идёт 15 минут, а запусков в день — сотни. Сейчас разберём, как оптимизировать GitHub Actions: быстрее, дешевле, эффективнее.


🔹 1. Используйте actions/cache правильно
Загрузка и компиляция зависимостей — одно из самых дорогих мест. Добавьте кэширование для npm, pip, go mod, docker layers. Пример для Node.js:

- uses: actions/cache@v3
  with:
    path: ~/.npm
    key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-npm-

⚠️ Не кэшируйте build-артефакты, которые зависят от среды (OS, runner version) — это приведёт к нестабильности.


🔹 2. Job matrix + fail-fast: false = контроль над параллелизмом
Matrix позволяет запускать тесты параллельно (например, разные версии Python), а fail-fast: false не останавливает все джобы при первом фейле.

strategy:
  fail-fast: false
  matrix:
    python-version: [3.8, 3.9, 3.10]

🔹 3. Разделяйте пайплайн на reusable workflows
Выносите повторяющуюся логику в .github/workflows/reusable.yml и вызывайте с параметрами. Это уменьшает дублирование и ускоряет поддержку.

- uses: ./.github/workflows/reusable.yml
  with:
    env: staging

🔹 4. Используйте self-hosted runners, если билд тяжёлый
Если у вас сборка Docker-образов весит десятки минут — дешевле и быстрее поднять свои раннеры в EC2 или Kubernetes (особенно с GPU или кастомной средой).

📌 Попробуйте actions-runner-controller для Kubernetes:
https://github.com/actions/actions-runner-controller


🔹 5. Откажитесь от setup-* при каждом запуске
setup-node, setup-go, setup-java — удобны, но каждый раз качают и устанавливают SDK. Замените на preinstalled версии в раннерах или кэшируйте вручную.


✅ Вывод:
Оптимизация GitHub Actions — это про кэш, параллельность и минимизацию накладных расходов. Даже простые изменения могут ускорить пайплайн в 2–3 раза. А главное — вы перестаёте платить за простой.


🔥 Ресурсы:
- Официальная дока по кэшу https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows


#devops #девопс

Подпишись 👉@i_DevOps

⚡ 22 апреля вебинар Luntry: «Безопасность контейнеров и Kubernetes для специалистов анализа качества». 

Пройдем путь от приложения — «чёрного ящика» в контейнерном исполнении до полного понимания, что это за средство, как оно устроено и насколько все хорошо (или плохо) с безопасностью.

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

#реклама
О рекламодателе

Dokploy — Самый простой способ развернуть и управлять вашими контейнерами

Dokploy — это open-source инструмент для деплоя и управления контейнерами, разработанный для упрощения процессов CI/CD и DevOps. Он позволяет разработчикам легко развёртывать, управлять и масштабировать приложения без необходимости писать сложные скрипты или конфигурации.

Возможности:
- 🚀 Быстрый деплой контейнеров
- 🔄 Автоматическое обновление на основе webhook’ов
- 🧩 Простая интеграция с GitHub
- 🔒 Безопасное хранение переменных окружения
- 📦 Поддержка множества приложений
- 🛠️ Web UI и CLI для управления

Как это работает:
1. Подключаете свой репозиторий GitHub.
2. Dokploy следит за изменениями и автоматически деплоит ваше приложение.
3. Управляете всем через простой UI или CLI.

Цель проекта — дать каждому разработчику простой и эффективный способ доставки своего кода в прод.

https://github.com/dokploy/dokploy

#devops #девопс

Подпишись 👉@i_DevOps

Что такое userspace, kernelspace? Чем они отличаются?

Под пользовательским пространством понимается весь код операционной системы, который находится вне ядра.

Большинство Unix-подобных операционных систем (включая Linux) поставляются с разнообразными предустановленными утилитами, средствами разработки и графическими инструментами — это все приложения пространства пользователя.

Все пользовательские приложения (и контейнеризированные, и нет) при работе используют различные данные, но где эти данные хранятся?

Ядро обеспечивает абстракцию для безопасности, оборудования и внутренних структур данных. Например, системный вызов open() используется для получения дескриптора файла в Python, C, Ruby и других языках программирования. Вряд ли бы вы хотели, чтобы ваша программа работала с XFS на уровне битов, поэтому ядро предоставляет системные вызовы и работает с драйверами. Фактически этот системный вызов настолько распространен, что является частью библиотеки POSIX .

Краткое определение:

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

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

#devops #девопс

Подпишись 👉@i_DevOps