DevOps

Bruno — это новый, современный и удобный инструмент для работы с API. В отличие от Postman и аналогов, Bruno хранит все данные локально в виде обычных файлов и папок, что позволяет легко версионировать их с помощью Git. Основные особенности: - Локальное хранение данных без облака - Полная совместимость с Git - Высокая производительность и минималистичный интерфейс - Открытый исходный код https://github.com/usebruno/bruno #devops #девопс 📲 Мы в MAX Подпишись 👉@i_DevOps

Yandex B2B Tech представила Monium — платформу observability для мониторинга ИТ-систем, которая изначально была разработана командой Yandex Infrastructure для мониторинга критических сервисов внутри Яндекса, а теперь она доступна всем внешним пользователям. Что по цифрам: • До 3 млрд семплов метрик в секунду • Около 44 млн спанов трассировки • До 60 ГБ логов ежесекундно • Порядка 16 тысяч внутренних пользователей Платформа объединяет метрики, логи и трейсы в одном интерфейсе и помогает быстрее находить причину инцидентов. Поддерживаются стандарты Prometheus и OpenTelemetry, что упрощает интеграцию с существующими DevOps-конвейерами. Среди первых внешних тестовых пользователей — ОТП Банк. По прогнозам Gartner, к 2027 году до 80% крупных компаний будут использовать observability-платформы для управления рисками стабильности сервисов.

Трюки для ускорения Docker-образов на проде Контейнеры это сердце современных приложений. Но тяжёлые образы = медленные деплои и высокие затраты. Как ускорить образы без боли? Мультистейдж билды - must have Используй multi-stage builds, чтобы собрать приложение в одном контейнере, а продакшн-образ сделать минимальным: # Сборка FROM golang:1.22 as builder WORKDIR /app COPY . . RUN go build -o app # Продакшн FROM alpine:latest WORKDIR /app COPY --from=builder /app/app . CMD ["./app"] Минимизируй базовые образы Выбирай облегчённые базовые образы: - alpine вместо ubuntu - distroless для максимальной безопасности и минимального веса Оптимизируй порядок слоёв Чем выше изменяемость, тем ниже слой: - Сначала COPY go.mod, npm package.json, установка зависимостей - Потом COPY . . с кодом проекта Это позволяет кэшировать большую часть слоёв даже при частых изменениях кода. Чисть за собой Всегда удаляй временные файлы и зависимости для сборки: RUN apt-get install -y build-essential && \ make build && \ apt-get remove --purge -y build-essential && \ apt-get autoremove -y && \ apt-get clean Сжимай образы Используй docker-slim, он автоматически оптимизирует образ, удаляя всё ненужное: docker-slim build --http-probe my-app:latest Как применять и чего избегать - В продакшне старайся держать образы <100MB - Не добавляй лишние пакеты “на всякий случай” - Проверяй образы на уязвимости: trivy image your-app:tag #devops #девопс 📲 Мы в MAX Подпишись 👉@i_DevOps

💡McFly - это улучшенная история командной строки с возможностями поиска на основе временной оси, контекста и машинного обучения. McFly заменяет стандартную историю bash с возможностью быстрого поиска по истории команд с учётом контекста текущего каталога, времени и других факторов. Он написан на Rust и работает в терминале с поддержкой fzf-подобного интерфейса. • Поддерживает: - Bash - Zsh - Fish • Возможности: - Умный поиск по истории команд. - Учёт текущего каталога и других факторов. - Простое подключение к вашему shell. • Установка: Доступен через Homebrew, AUR, Nix и другие. https://github.com/cantino/mcfly #devops #девопс 📲 Мы в MAX Подпишись 👉@i_DevOps

🚀 Ускоряем CI/CD пайплайны на GitHub Actions: кеширование по-взрослому CI тормозит? Пайплайн гоняет npm install по 5 минут? Пора серьёзно поговорить о кешировании в GitHub Actions. GitHub Actions — мощный инструмент, но без кеша даже самый простой билд превращается в черепаху. Разберёмся, как грамотно использовать actions/cache, чтобы выжать максимум скорости. 🔧 Основы кеширования GitHub предоставляет официальный экшен actions/cache, который позволяет сохранять каталоги между запусками воркфлоу. Ключевое понятие здесь — ключ кеша (cache key). Пример:

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

Что тут происходит: - path — папка, которую кешируем (`~/.npm`). - key — уникальный ключ, зависящий от lock-файла. - restore-keys — запасной вариант, если точного совпадения ключа нет. ⚡ Трюки для ускорения 1. Разделяй кеш по задачам. Не пихай всё в один архив. Кешируй отдельно npm, node_modules, dist/ — это гибко и эффективно. 2. Для Docker-образов — кешируй слои. Используй BuildKit и флаг --cache-to, --cache-from. Пример:

- name: Build Docker image
  run: |
    docker buildx build \
      --cache-from=type=gha \
      --cache-to=type=gha,mode=max \
      -t my-app .

3. Осторожно с ключами. Часто меняющийся ключ = каждый раз новый кеш = медленно. Сделай разумный баланс между стабильностью и свежестью. 4. Тестируй локально. Используй act, чтобы отлаживать воркфлоу на локалке — сэкономишь время и нервы. ✅ Вывод Кеш в GitHub Actions — не волшебная пуля, но при правильной настройке он может сократить время CI в разы. Следи за размером кеша, обновляй ключи с умом и профилируй пайплайн. И не забывай: кеш — твой друг, пока ты его контролируешь. #devops #девопс 📲 Мы в MAX Подпишись 👉@i_DevOps

Kubernetes: как не угробить прод с неправильными Liveness/Readiness пробыми 🧟‍♂️ Если ваши поды «умирают» слишком рано или слишком долго не проходят readiness, возможно, вы не до конца понимаете, как работают пробы в Kubernetes. А между тем, это критично для uptime и стабильности продакшена. 📌 Пробы - не «просто пинги» - livenessProbe отвечает за "жив ли под". Если не проходит - kubelet убивает контейнер. - readinessProbe - "готов ли под принимать трафик". Пока не готов - не пускается в сервис. Неправильная настройка может привести к: - бесконечным перезапускам (flapping), - недоступности сервиса после деплоя, - ненужной нагрузке на кластер. 🛠 Типичные ошибки 1. Тот же эндпоинт для обеих проб Readiness может требовать больше инициализации. Разделяйте эндпоинты: /healthz/live и /healthz/ready - хорошая практика. 2. Слишком агрессивные тайминги initialDelaySeconds, timeoutSeconds, failureThreshold - не забывайте учитывать холодный старт (особенно при Java, .NET, DB init). 3. Тестирование только на dev/stage На проде нагрузка выше, сеть может вести себя иначе. Профиль подов должен учитывать real-world сценарии. 4. Liveness вместо retries Liveness не замена retry-логике в приложении. Используйте circuit breakers, retries и grace periods на уровне сервиса. ✅ Как делать правильно - Используйте простые GET-запросы, без heavy логики. - Не тестируйте зависимости (БД, внешние API) в liveness - пусть это останется за readiness. - Применяйте terminationGracePeriodSeconds и preStop hook, чтобы избежать резкого отключения. 🧩 Стартовый шаблон для readiness/liveness

livenessProbe:
  httpGet:
    path: /healthz/live
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5
  timeoutSeconds: 2
  failureThreshold: 3

readinessProbe:
  httpGet:
    path: /healthz/ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5
  timeoutSeconds: 2
  failureThreshold: 3

Вывод: Настройка prob - это не ритуал ради YAML-а. Это инструмент стабильности и доступности. Подходите к ним осознанно, валидируйте на нагрузке и помните, что "здоровый" под ≠ "готовый к трафику". #devops #девопс 📲 Мы в MAX Подпишись 👉@i_DevOps

🚀 Подборка полезных IT каналов в Max Системное администрирование, DevOps 📌 https://max.ru/i_odmin Все для системного администратора https://max.ru/bash_srv Bash Советы https://max.ru/sysadminof Книги для админов, полезные материалы https://max.ru/i_odmin_book Библиотека Системного Администратора https://max.ru/i_devops DevOps: Пишем о Docker, Kubernetes и др. 1C разработка 📌 https://max.ru/odin1c_rus Cтатьи, курсы, советы, шаблоны кода 1С Программирование C++📌 https://max.ru/cpp_lib Библиотека C/C++ разработчика Программирование Python 📌 https://max.ru/python_of Python академия. https://max.ru/BookPython Библиотека Python разработчика Java разработка 📌 https://max.ru/bookjava Библиотека Java разработчика GitHub Сообщество 📌 https://max.ru/githublib Интересное из GitHub Базы данных (Data Base) 📌 https://max.ru/database_info Все про базы данных Фронтенд разработка 📌 https://max.ru/frontend_1 Подборки для frontend разработчиков Библиотеки 📌 https://max.ru/programmist_of Книги по программированию https://max.ru/proglb Библиотека программиста https://max.ru/bfbook Книги для программистов Программирование 📌 https://max.ru/bookflow Лекции, видеоуроки, доклады с IT конференций https://max.ru/itmozg Программисты, дизайнеры, новости из мира IT https://max.ru/php_lib Библиотека PHP программиста 👨🏼‍💻👩‍💻 Шутки программистов 📌 https://max.ru/itumor Шутки программистов Защита, взлом, безопасность 📌 https://max.ru/thehaking Канал о кибербезопасности https://max.ru/xakkep_1 Хакер Free Книги, статьи для дизайнеров 📌 https://max.ru/odesigners Статьи, книги для дизайнеров Математика 📌 https://max.ru/Pomatematike Канал по математике https://max.ru/phismat_1 Обучающие видео, книги по Физике и Математике Вакансии 📌 https://max.ru/progjob Вакансии в IT Мир технологий 📌 https://max.ru/mir_teh Канал для любознательных Бонус 📌 https://max.ru/piterspb_78 Свежие новости Санкт-Петербурга https://max.ru/mockva_life Свежие новости Москвы

Wal-listener — это инструмент для прослушивания логов транзакций PostgreSQL (WAL) и конвертации их в удобный для обработки формат JSON. Возможности - Прослушивание изменений в PostgreSQL в режиме реального времени. - Поддержка нескольких слотов репликации. - Удобный вывод в формате JSON. - Готов к использованию в качестве сервиса. Пример использования 1. Создаём слот репликации:

   SELECT * FROM pg_create_logical_replication_slot('test_slot', 'wal2json');
   

2. Запускаем wal-listener:

   wal-listener --dsn "host=localhost port=5432 user=postgres dbname=test" --slot test_slot
   

3. Получаем JSON-объекты при изменениях в базе данных. https://github.com/ihippik/wal-listener #devops #девопс 📲 Мы в MAX Подпишись 👉@i_DevOps

Kubernetes в проде: 7 ошибок, которые совершают даже опытные Если ты деплоишь сервисы в Kubernetes, скорее всего, ты уже наступал на эти грабли. А если нет — вот чеклист, чтобы не наступить. 1. Не включён livenessProbe и readinessProbe Без этих пробы Kubernetes не понимает, когда перезапустить контейнер или исключить под из сервисов. В итоге — трафик идёт в мёртвые инстансы, а ты ловишь 500-е.

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 3
  periodSeconds: 10

2. resources.requests и limits не заданы Если не выставить ресурсы, поды будут жрать всё подряд, а kube-scheduler может завалить ноды. Определи baseline и поставь лимиты с запасом:

resources:
  requests:
    cpu: "100m"
    memory: "128Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"

3. Один replica на под в проде Если у тебя только один реплика, ты не в HA. Любая перезагрузка = даунтайм. Минимум две — лучше три. 4. latest тег образа image: myapp:latest — это лотерея. K8s не знает, что образ поменялся, и не перезапускает поды. Используй versioned теги (`v1.2.3`) или внедри CI, который автоматически делает новый тег и rollout. 5. Нет ограничений по PodDisruptionBudget Без PDB можно случайно прибить все поды при drain'е ноды или апдейте. Добавь минимум 1 живой под:

minAvailable: 1

6. Логи в /var/log или вообще stdout игнорируется Всё, что не идёт в stdout/stderr, теряется. Используй sidecar'ы или shipper'ы типа Fluent Bit, если хочешь нормальный логинг. 7. Секреты хранятся в plaintext в Git Kubernetes Secret — это base64, а не шифрование. Либо используй sealed-secrets, либо интеграцию с HashiCorp Vault, SOPS или AWS KMS. Вывод: Даже базовые настройки могут сыграть злую шутку, если их игнорировать. Сделай себе шаблон Helm-чарта или Kustomize-паттерн, в котором всё это будет по умолчанию. И не забудь периодически пересматривать best practices — K8s развивается 🔄 #devops #девопс 📲 Мы в MAX Подпишись 👉@i_DevOps

🆕 Bun Shell - кроссплатформенный shell прямо в JavaScript Bun Shell - это встроенный интерпретатор shell-команд в Bun, позволяющий писать скрипты на JavaScript/TypeScript с лаконичным синтаксисом: import { $ } from "bun"; await $`ls *.js`; Основные возможности: • Кроссплатформенность: работает на Windows, macOS и Linux. • Поддержка переменных, редиректов, пайпов и шаблонов. • Безопасность: автоматическое экранирование переменных. • Взаимодействие с объектами JavaScript: Response, ArrayBuffer, Blob. • Встроенные команды: cd, rm, echo и другие. Пример использования с переменной: const filename = "example.txt"; await $`cat ${filename}`; https://bun.sh/blog/the-bun-shell #devops #девопс 📲 Мы в MAX Подпишись 👉@i_DevOps

🚀 Разворачиваем Kubernetes-кластер за 5 минут с помощью Proxmox и k3s! Автор статьи показывает, как быстро поднять кластер с помощью Proxmox и лёгкого дистрибутива K3s. Всё максимально просто: - Устанавливаем Proxmox VE - Создаём шаблон VM с Ubuntu - Автоматизируем деплой через cloud-init - Настраиваем кластер K3s в пару кликов 🔥 Идеально для домашней лаборатории или быстрой отладки! 00:04 Introduction 00:18 Why Use Mini PCs Over Cloud Computing for Personal / Hobby Projects 01:13 Installing Proxmox and Setting Up Cluster 02:12 Creating a VM for Kubernetes Worker Node 03:38 Installing Kubernetes on Ubuntu Server 04:14 Joining the New Node to the Kubernetes Cluster 05:19 Potential Applications of Your New Setup 05:30 Upcoming Projects and Channel Focus 06:02 Measuring Power Consumption with a Smart Plug 06:07 Conclusion and Farewell https://dev.to/mihailtd/set-up-a-kubernetes-cluster-in-under-5-minutes-with-proxmox-and-k3s-2987 #devops #девопс 📲 Мы в MAX Подпишись 👉@i_DevOps

Практикум по работе с Bare Metal: как быстро развернуть гипервизор, базовые настройки и рекомендации 📌 25 февраля, 17:00 (мск) На вебинаре расскажем, для каких задач стоит использовать Bare Metal серверы, как решение реализовано в VK Cloud, а также в прямом эфире покажем, какие моменты ускоряют настройку и запуск виртуальных машин. Что еще обсудим ⚫️Сценарии применения, преимущества и особенности Bare Metal в контексте высоких нагрузок и оптимизации бюджета ⚫️Как настроить сеть: полный контроль и сохранение гибкости   Популярные ошибки развертывания, и как их избежать ⚫️Приходите на вебинар, чтобы научиться быстро настраивать Bare Metal серверы. Сейчас как все узнаю

CI/CD в 3 раза быстрее: секреты оптимизации GitHub Actions GitHub Actions - мощный инструмент, но даже продвинутые пайплайны часто работают медленнее, чем могли бы. Потери времени = потери денег и developer experience. Вот как ускорить ваши воркфлоу без потери функциональности. 1. Используйте concurrency и cancel-in-progress concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: true Это позволит отменять старые запуски одного и того же воркфлоу на той же ветке — особенно полезно при пушах в PR. Экономим минуты на каждом коммите. 2. Кешируйте всё, что можно - name: Cache pip packages uses: actions/cache@v3 with: path: ~/.cache/pip key: ${{ runner.os }}-pip-${{ hashFiles('**/requirements.txt') }} restore-keys: | ${{ runner.os }}-pip- То же касается node_modules, cargo, .m2, gradle — любые зависимости можно кэшировать, особенно если они скачиваются каждый раз. 3. Не бойтесь matrix + fail-fast: false Запускайте параллельно всё, что можно: тесты на разных версиях языка, разных ОС, разных архитектурах. strategy: matrix: python-version: [3.10, 3.11] os: [ubuntu-latest, macos-latest] fail-fast: false 4. Reusable workflows > копипаста Выносите повторяющиеся шаги в отдельные .yml-воркфлоу и переиспользуйте их через workflow_call. Это упрощает поддержку и уменьшает ошибки. 5. Запускайте воркфлоу только при нужных событиях on: push: branches: [main] paths: - 'src/**' - '.github/workflows/**' Зачем триггерить CI, если изменился только README? Оптимизация CI/CD - это не про «поиграться с YAML». Это способ сэкономить время команды, ускорить релизы и избежать выгорания из-за бесконечного ожидания. Чем быстрее обратная связь - тем лучше продукт. #devops #девопс 📲 Мы в MAX Подпишись 👉@i_DevOps

Cilicon - это приложение для macOS, использующее фреймворк виртуализации Apple для создания, предоставления и запуска эфемерных виртуальных машин CI с производительностью, близкой к нативной. В настоящее время оно поддерживает Github Actions, Buildkite Agent, GitLab Runner и произвольные скрипты. В зависимости от ваших настроек, вы сможете запустить свой собственный CI в считанные минуты 🚀. https://github.com/traderepublic/Cilicon #devops #девопс 📲 Мы в MAX Подпишись 👉@i_DevOps

Kubernetes: правильный подход к ресурсным лимитам и requests 🔧 Часто недооценённая, но критичная тема для стабильности и производительности кластеров. Неверные значения requests и limits приводят либо к перерасходу ресурсов, либо к OOM, Throttling и подам, которые бесконечно перезапускаются. Особенно больно это бьёт по продакшену. 🚀 Как правильно настраивать ресурсы: 1. Понимай разницу между requests и limits: - requests — это гарантированный минимум, который получит контейнер. - limits — это максимум, выше которого контейнер не сможет использовать (CPU throttling или OOMKill для памяти). 2. CPU — без жестких лимитов: - Лучше не указывать limits.cpu, чтобы избежать throttling. - Но обязательно ставь requests.cpu, чтобы kube-scheduler мог правильно распланировать нагрузку. 3. Memory — всегда с лимитом: - Память не отбирается — контейнер либо получает всю, либо OOM. - Обязательно ставь и requests.memory, и limits.memory. 4. Используй VPA (Vertical Pod Autoscaler): - Он поможет подобрать адекватные значения ресурсов на основе истории. - ⚠️ На проде использовать осторожно — часто в "recommendation only" режиме. 5. Метрики в помощь: - Используй kubectl top, metrics-server, Prometheus/Grafana для анализа потребления. - Наблюдай за container_cpu_usage_seconds_total, container_memory_usage_bytes. 6. Профилируй и оптимизируй: - Легковесный nginx или sidecar не должен просить 500Mi памяти. - Java-приложение без указанных лимитов съест весь узел. 🧠 Вывод: Грамотно выставленные ресурсы — это баланс между надёжностью и эффективным использованием нод. Не копируй requests/limits вслепую из интернета — мерь, анализируй, настраивай под свой ворклоад. 📲 Мы в MAX Подпишись 👉@i_DevOps

Когда стандартное облако не работает. Типовая ситуация: — нужно масштабирование без переноса всей инфраструктуры; — база должна остаться на выделенном железе; — фронт — в публичном облаке; — SLA высокий, но бюджет не бесконечный. Стандартные решения в таких случаях не помогают. Нужна архитектура под задачу, а не «коробочное решение» для всех. В канале DataSpace мы разбираем: — как онлайн-ритейлер выдержал рост нагрузки в 10 раз без деградации сервисов — где гибридная модель действительно оправдана — как быстро сравнить разные варианты конфигурации стоимости — какие ошибки чаще всего допускают при выборе провайдера Если отвечаете за инфраструктуру или эксплуатацию, будет полезно подписаться — @dataspace_ru

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