DevOps

HULL - Helm Uniform Layer Library Этот репозиторий содержит библиотечную диаграмму Helm под названием HULL. Она предназначена для упрощения создания, поддержки и настройки объектов Kubernetes в Helm-диаграммах и может быть добавлена к любой Helm-диаграмме в качестве дополнения для расширения функциональности без риска нарушения существующих конфигураций Helm. Сама диаграмма и вся связанная с ней документация находятся в папке hull, которая является корневой директорией библиотечной Helm-диаграммы HULL. https://github.com/vidispine/hull #devops #девопс 📲 Мы в MAX Подпишись 👉@i_DevOps

Kubernetes: секреты быстрого rollback без боли и даунтайма 🔄 Rollback — неотъемлемая часть стабильного продакшена. Но сколько раз он превращался в хаос? Рассмотрим, как грамотно настроить откат в Kubernetes, чтобы не терять трафик, не ловить панику и не тратить часы на ручное восстановление. 🔹 1. Стратегия деплоя имеет значение По умолчанию Deployment использует стратегию RollingUpdate. Это безопасно, но не всегда быстро. Убедись, что параметры maxUnavailable и maxSurge оптимальны:

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 0

➡️ Это даст zero downtime, но при большом количестве реплик откат будет медленным. Подстрой под нагрузку. 🔹 2. Используй kubectl rollout undo Kubernetes хранит предыдущие ReplicaSets, так что простой rollback — дело одной команды:

kubectl rollout undo deployment my-app

Проверь текущую ревизию:

kubectl rollout history deployment my-app

📝 Храни истории изменений в git — манифесты должны быть version-controlled. 🔹 3. Хелм под капотом? Настрой helm rollback Если ты используешь Helm, rollback проще:

helm rollback my-release 1

❗️Важно: иногда rollback не возвращает ConfigMap или Secret, если они были изменены. Используй флаг --recreate-pods или закладывай изменения в values.yaml через hash-аннотации. 🔹 4. Прогревай rollback заранее На preprod окружении сделай dry-run откатов. Проверь: - есть ли живая предыдущая ревизия - не изменились ли зависимости (например, база данных) - как себя ведёт app после downgrade 🔹 5. Автоматизируй возврат Сценарий: новая версия падает по хелсчекам. Вместо ручного вмешательства — automation: - Настрой alertmanager на провал readiness/liveness - Свяжи с Argo Rollouts или Spinnaker, чтобы триггерить rollback автоматически ✅ Вывод: грамотный rollback — это не кнопка “назад”, а часть CI/CD культуры. Обеспечь: - контроль версий манифестов - мониторинг после деплоя - rollback как часть стратегии, а не костыль #devops #девопс 📲 Мы в MAX Подпишись 👉@i_DevOps

CI/CD пайплайны на стероидах: 5 фишек для ускорения сборок 🚀 ⏱ Устали ждать, пока пройдут все джобы в CI? Время — деньги, особенно на продакшене. Вот 5 проверенных способов прокачать скорость и стабильность пайплайнов. 1. Кэширование зависимостей — must have Кэшируйте node_modules, .m2, Docker-слои или Python virtualenv. В GitHub Actions:

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

2. Matrix strategy для параллельных задач Разбейте тесты по окружениям, версиям или компонентам:

   strategy:
     matrix:
       python: [3.9, 3.10]
   

3. Docker Layer Caching (DLC) В GitLab CI включайте DLC:

   variables:
     DOCKER_DRIVER: overlay2
     DOCKER_TLS_CERTDIR: ""
   services:
     - docker:dind
   

4. Пропускайте джобы при отсутствии изменений Нет изменений в директории — не триггери билд. В GitHub Actions:

   on:
     push:
       paths:
         - 'src/**'
         - '!docs/**'
   

5. Self-hosted runners для тяжёлых задач Сильная машина с нужными зависимостями сэкономит десятки минут. Плюс — контроль среды и логирования. Вывод: Оптимизация CI/CD — это не про магию, а про дисциплину: кэш, параллелизм, условные шаги и правильные раннеры. Регулярно профилируйте пайплайны и фиксируйте bottlenecks. #devops #девопс 📲 Мы в MAX Подпишись 👉@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 📲 Мы в 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