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 📲 Мы в MAX Подпишись 👉@i_DevOps

⚡️Платите меньше за хранение логов и бэкапов Выберите подходящий класс хранилища в Selectel S3 и сократите расходы на хранение до 30%. Первый месяц по акции «миграционные каникулы» — бесплатно. 👉 Оставьте заявку и перенесите данные в Selectel: https://slc.tl/2devp Реклама. АО "Селектел". erid:2W5zFGL2WQ1

🔥 Ускоряем сборку 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, локальную сборку и деплой. Чем меньше слоёв изменяется - тем быстрее весь процесс. 📲 Мы в MAX Подпишись 👉@i_DevOps

🚀 Kubernetes под ML-нагрузки на bare metal + H100: пошагово и без прикрас Если вы строите ML-платформу в корпоративной среде (RBAC, изоляция, безопасность) и при этом хотите нормально утилизировать GPU - в Совкомбанк Технологии поделились реальным опытом: что пробовали, где «сломалось», и к какой архитектуре в итоге пришли. Что внутри: • почему идея держать две ML-платформы в одном кластере (taints/labels) упирается в конфликты компонентов и риски ИБ; • как разнесли всё на два независимых кластера, чтобы обновления и безопасность не превращались в боль; • практический гайд по установке драйверов NVIDIA и типовым ошибкам (DKMS, модуль ядра, container runtime и т.д.); • деплой GPU Operator; • самое вкусное - MIG на H100: как включать профили через label’ы нод, какие профили выбирать под inference/training и что делать, когда MIG-инстанс недоступен (Pending, failover/retry и т.п.); • в конце - базовые шаги по деплою Kubeflow 1.10 и что ожидать в дебаге. 🧩 Это тот редкий материал, где есть и «как сделать», и «почему так делать не стоит», и конкретные команды. Читать: https://habr.com/ru/companies/sovcombank_technologies/articles/994534/ 📲 Мы в MAX Подпишись 👉@i_DevOps

🚀 Ищем Kubernetes Platform Engineer (Middle+/Senior) в 2ГИС В команде Infrastructure & Operations мы строим внутреннюю PaaS-платформу для Data Services: PostgreSQL, Redis, Kafka, ClickHouse. Наша цель — сделать DBaaS и DS self-service, надёжной и стандартизированной частью платформы для десятков продуктовых команд. Что будешь делать: <ul><li>Развивать PaaS на базе Kubernetes</li></ul><ul><li>Автоматизировать lifecycle DS (deploy, scale, backup, restore)</li></ul><ul><li>Строить DBaaS (начинаем с PostgreSQL)</li></ul><ul><li>Внедрять GitOps, IaC и платформенные стандарты</li></ul><h3>Наш стек</h3>Kubernetes, GitLab CI/CD, Terraform, Ansible, ELK, Vault, S3. Ищем инженера, который понимает Kubernetes как платформу, работал со stateful-нагрузками и тюнил PostgreSQL. Удалёнка или офис. Белая зарплата, ДМС, обучение и конференции — всё по-взрослому. 👉Откликайся Другие инженерные инсайты от 2ГИС →в Telegram-канале RnD

🔥 Как ускорить 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 📲 Мы в MAX Подпишись 👉@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 📲 Мы в MAX Подпишись 👉@i_DevOps

Блокировка состояния Terraform с использованием S3 (без DynamoDB) В этом посте мы рассмотрим: - Зачем нужна блокировка состояния Terraform - Блокировка состояния с помощью DynamoDB - Блокировка состояния только с использованием S3, без DynamoDB - Когда стоит использовать DynamoDB - Когда можно обойтись только S3 - Лучшие практики хранения state-файлов в S3 https://devopscube.com/terraform-state-locking-with-s3/ 📲 Мы в MAX Подпишись 👉@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 станет надёжной, устойчивой и более предсказуемой. Это особенно важно при масштабировании инфраструктуры и работе в команде. 📲 Мы в MAX Подпишись 👉@i_DevOps

🛠Построение 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 📲 Мы в MAX Подпишись 👉@i_DevOps

26 февраля — Deckhouse User Community meetup #4. Это митап для тех, кто хочет понимать Kubernetes глубже. Зарегистрироваться Эксперты Deckhouse и приглашённые спикеры расскажут, как запускать K8s поверх любых дистрибутивов, эксплуатировать платформу в одиночку, развёртывать домашнюю виртуализацию на бюджетном железе и грамотно подходить к безопасности. И покажут: на митапе будет работать зона «Попробуй сам», где можно протестировать работу Deckhouse Kubernetes Platform Community Edition своими руками.

Путь в DevOps: полное руководство для новичков с НУЛЯ 00:00 - Вступление 00:14 - Всевозможные компетенции DevOps Инженера 00:44 - Кому проще стать DevOps Инженером 02:29 - Что учить по минимуму и в каком порядке 10:27 - 1. Основы Networking TCP/IP 11:46 - 2. Администрирование Windows 12:38 - 3. Основы Linux 13:28 - 4. Ansible 13:56 - 5. Git 14:26 - 6. GitHub 14:52 - 7. CI/CD: GitHub Actions, GitLab CI/CD 15:29 - 8. Docker + DockerHub 16:16 - 9. Kubernetes + Helm + ArgoCD 17:04 - 10. AWS: Amazon Web Services 19:12 - 10. GCP: Google Cloud Platform 20:27 - 10. Azure: Microsoft Azure 21:38 - 11. Terraform + Terragrunt 22:42 - 12. Python 23:09 - Как стать профессиональным DevOps Ннженером 24:37 - Девопс это хорошее будущее вашей карьеры источник 📲 Мы в MAX Подпишись 👉@i_DevOps

Zed — это высокопроизводительный текстовый редактор, ориентированный на разработчиков. Он написан на Rust и использует пользовательский движок рендеринга на базе GPU для достижения минимальных задержек. Архитектура Zed основана на многопоточности и асинхронности, что позволяет редактору эффективно использовать ресурсы современных многоядерных систем. Редактор также разрабатывается с упором на совместную работу в реальном времени: Zed предлагает встроенные функции для коллаборации между разработчиками — от редактирования кода до видеозвонков. Это делает его особенно удобным для удалённых команд. Среди особенностей: - Мгновенный отклик и плавная анимация благодаря GPU-рендерингу - Полноценная поддержка нескольких курсоров и мощное автодополнение - Интеграция с языковыми серверами (LSP) - Глубокая коллаборативность: совместное редактирование, общие терминалы, голос и видео https://github.com/zed-industries/zed 📲 Мы в MAX Подпишись 👉@i_DevOps

Собрал основные концепции Docker в одну диаграмму 📲 Мы в MAX Подпишись 👉@i_DevOps

🧪 K8E — это форк проекта K3s, предназначенный для локального тестирования. Он не требует root-доступа и не использует systemd. Также вы можете легко собрать и запустить его без сетевого подключения (air-gap режим). Основные особенности: - Без root-доступа - Без systemd - Один бинарник - Простой запуск кластера: k8e server & - Не требует внешней сети - Поддерживает полностью автономную сборку Если вы когда-либо хотели поднять Kubernetes-кластер за пару секунд и без привилегий — этот инструмент идеально подойдёт для тестов и локальной разработки. https://github.com/xiaods/k8e 📲 Мы в MAX Подпишись 👉@i_DevOps

MLOps — дитя DevOps и ML Один ML-проект в проде вам или два другому? Внедрение машинного обучения в производственную среду остаётся одной из главных проблем индустрии. По статистике, 80% ML-проектов никогда не доходят до продакшена. Однако хитрые опсы и тут решили выделиться, и в результате появился MLOps — методология, которая поможет вам сократить путь от эксперимента до деплоя с месяцев до дней. В этой статье мы пройдёмся по верхам MLOps и посмотрим на фундаментальные принципы и конкретные инструменты. https://habr.com/ru/companies/ruvds/articles/990814/ 📲 Мы в MAX Подпишись 👉@i_DevOps

⚡️ Apache Camel в архитектуре решений бэкенда 📅 4 февраля | 20:00 мск | бесплатно Хотите строить надёжные и гибкие интеграции между сервисами без лишней сложности? На вебинаре разберём: - Роль Apache Camel в современной backend-архитектуре - Enterprise Integration Patterns и их практическое применение - Типовые сценарии: синхронные и асинхронные интеграции - Camel как связующее звено между микросервисами, брокерами сообщений и внешними системами - Архитектурные преимущества и реальные ограничения использования Apache Camel ✅ После вебинара вы сможете: - Определять, когда Apache Camel — правильный архитектурный выбор - Проектировать интеграционные потоки на основе проверенных паттернов - Строить устойчивые и слабо связанные backend-решения - Принимать осознанные архитектурные решения в области интеграций 👉 Регистрируйтесь https://vk.cc/cU2J9n Занятие приурочено к старту курса "Software Architect", обучение на котором позволит освоить компетенции архитектора по моделированию и построению отказоустойчивых, масштабируемых и хорошо интегрируемых информационных систем. Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Основы виртуализации. Часть 1 1.Основы виртуализации. Введение 2.Основы виртуализации. История развития виртуализации 3.Основы виртуализации. Серверы 4.Основы виртуализации. Виртуальные машины 5.Основы виртуализации. Гипервизоры второго типа 6.Основы виртуализации. Лабораторная работа №1. Создаем VM 7.Основы виртуализации. Гипервизоры первого типа 8.Основы виртуализации. Лабораторная работа №2. ESXi источник 📲 Мы в MAX Подпишись 👉@i_DevOps

Deckhouse Prom++: мы добавили плюсы к Prometheus и сократили потребление памяти в 7,8 раза Хотя Prometheus и стал стандартом мониторинга для микросервисов в Kubernetes, он потребляет слишком много ресурсов. А что, если мы скажем, что добавили пару плюсов к Prometheus и получили почти бесплатный мониторинг? Prometheus для хранения 1 миллиона метрик, собираемых раз в 30 секунд на протяжении 2 часов, требуются 500 МБ на диске и 5 ГБ памяти. Нам показалось, что это слишком много. Вместо этого хотелось получить «бесплатный» мониторинг, который не будет требовать значительных затрат на инфраструктуру. Больше двух лет мы работали над этой задачей. Её результатом стал Deckhouse Prom++. Это Open Source-система мониторинга, которой в среднем требуется в 7,8 раза меньше памяти и в 2,2 раза меньше ресурсов CPU, чем Prometheus v2.53. И здесь ещё есть пространство для оптимизации. В статье мы расскажем, как появилась идея Deckhouse Prom++, что уже получилось оптимизировать, какие результаты показывает наше решение по сравнению с Prometheus и VictoriaMetrics, а также о ближайших планах. https://habr.com/ru/companies/flant/articles/878282/ 📲 Мы в MAX Подпишись 👉@i_DevOps

👩‍💻 В Kubernetes приложения редко падают сами по себе. Чаще проблемы начинаются с трафика: запросы не доходят, ingress ведёт себя непредсказуемо, диагностика превращается в гадание. И в этот момент становится понятно, что поверхностного знания Service и Ingress уже недостаточно. На открытом уроке OTUS: - разберём, как Kubernetes организует общение с приложениями внутри кластера и с внешним миром. - поговорим о маршрутизации трафика, Service Discovery и архитектуре Ingress-контроллеров. - покажем, почему Ingress — это не просто входная точка, и как он расширяется через CRD и кастомные контроллеры. Что вас ждет на занятии: - получите целостное понимание сетевого взаимодействия в Kubernetes, - научитесь осознанно выбирать ingress-решения под разные задачи - разберётесь, когда стандартного NGINX недостаточно. - отдельно обсудим современные альтернативы и критерии их выбора - обсудим диагностику проблем с доступностью и трафиком. 📍Встречаемся 3 февраля в 20:00 МСК в преддверии старта курса «Инфраструктурная платформа на основе Kubernetes». Регистрация открыта: https://vk.cc/cTYHkh Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576