DevOps

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

Как устроен Cilium, и какие возможности для выявления неисправностей в продакшене он предлагает? Как организовать эффективный инференс LLM с K8s в домашних условиях и не переплачивать за инфру? Ответы — в докладах первого инженерного митапа Deckhouse User Community. Будет интересно DevOps- и платформенным инженерам, SRE и сисадминам. 20 мая в 19:00 мск | офлайн в Москве и онлайн Митап бесплатный, но регистрация обязательна

🚀 Ускоряем 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 #девопс Подпишись 👉@i_DevOps

❔ Уже работаете с 1С, но не знаете, как настроить взаимодействие с веб-серверами? Платформа 1С может интегрироваться с различными веб-серверами, но каждая такая интеграция требует особого подхода. На открытом вебинаре 28 апреля в 20:00 МСК мы научим вас тонкостям взаимодействия 1С с веб-серверами и расскажем о плюсах и минусах разных вариантов. Это урок для системных администраторов, разработчиков, архитекторов и технических лидеров, желающих повысить эффективность работы с 1С и улучшить инфраструктуру. 🚀Запишитесь на открытый вебинар и получите скидку на программу обучения «DevOps 1С»: https://vk.cc/cL51UV Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

16 главных DevOps-метрик (DORA и не только!) — на чем сосредоточиться и как использовать DevOps‑метрики — это количественные показатели, которые позволяют оценить эффективность, производительность и общее состояние DevOps‑процессов. Они предлагают аналитический взгляд на конвейер поставки программного обеспечения, позволяя командам разработчиков выявлять проблемные места, повышать производительность и принимать решения на основе реальных данных. В этой статье мы поговорим о важности мониторинга DevOps‑метрик и о том, что именно нужно отслеживать. От широко известных метрик, которые приобрели статус стандартных благодаря DORA (DevOps Research and Assessment), до других важных индикаторов — мы предлагаем вашему вниманию исчерпывающее руководство, которое поможет вам измерить и оптимизировать ваши DevOps‑практики. https://spacelift.io/blog/devops-metrics #devops #девопс Подпишись 👉@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 #девопс Подпишись 👉@i_DevOps

👩‍💻 Docker — один из самых мощных инструментов для создания эффективных, масштабируемых и изолированных окружений. Его применяют во всех современных data-проектах, и его знание критически важно для инженера данных. Сегодня Docker стал неотъемлемой частью стека Data-инженера. Он используется для развертывания ETL- и ML-решений, работы с микросервисной архитектурой и создания воспроизводимых рабочих сред. Не зная Docker, вы ограничиваете свои возможности. 📌На открытом вебинаре 29 апреля в 20:00 мск вы узнаете, как использовать Docker для решения data-задач. Мы разберём практические кейсы, научим вас создавать Docker-образы для data-проектов, а также переводить решения в продакшн. ♾ Регистрируйтесь на вебинар и получите скидку на программу обучения «Data Engineer»: https://vk.cc/cL36Uz Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

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 #девопс Подпишись 👉@i_DevOps

Влияние ИИ на процессы разработки: присоединяйтесь к исследованию Online Market Intelligence проводит опрос о влиянии кодовых ИИ-ассистентов на разработку. Исследуется, как эти инструменты влияют на эффективность работы команд и производственные процессы. Для участия необходимо заполнить анкету* и ответить на несколько вопросов. Пройдите опрос и получите шанс стать владельцем iPhone 16 Pro Max. *Принимая участие в опросе Вы становитесь участником розыгрыша под наименованием «Если ты работаешь в IT, пройди опрос и выиграй iPhone 16 Рro Мax». Информация об организаторе розыгрыша, сроках проведения, правилах проведения розыгрыша, количестве призов, сроках, месте, порядке получения призов размещена по ссылке

🎯 Bash-совет дня: быстрое сравнение файлов по хэшу Иногда нужно убедиться, что два файла идентичны. Вместо diff, который сравнивает содержимое построчно, проще сравнить их контрольные суммы. Вот удобная однострочная команда:

[ "$(sha256sum file1 | awk '{print $1}')" = "$(sha256sum file2 | awk '{print $1}')" ] && echo "✅ Файлы одинаковые" || echo "❌ Файлы разные"

📌 Пояснение: - sha256sum — создаёт SHA-256 хэш от файла. - awk '{print $1}' — достаёт только сам хэш (без имени файла). - [...] && ... || ... — условие в стиле bash: если хэши совпадают — выводим "файлы одинаковые", иначе — "разные". 🔥 Подходит для проверки резервных копий, дистрибутивов и любых бинарников. 👉@bash_srv

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 #девопс Подпишись 👉@i_DevOps

Виртуальные машины и контейнеры в одном окружении? Да, это реально!  На вебинаре в среду расскажем и покажем, как виртуализация в экосистеме Deckhouse делает возможным запуск виртуальных машин рядом с контейнерами, обеспечивая единое, управляемое Kubernetes-окружение для построения современного частного облака.  🗓 Дата: 23 апреля, среда ⏰ Время: 12:00 (МСК) 📌 Место: Онлайн, нужна регистрация Обсудим: 🔹 какие возможности по управлению виртуальными машинами есть в Deckhouse; 🔹 для чего нужна совместная работа виртуальных машин и контейнеров; 🔹 какие сценарии виртуализации есть в экосистеме Deckhouse; 🔹 и главное — покажем тестовый стенд и приложение. ✍️ Участники вебинара смогут оставить заявку на тестирование Deckhouse Virtualization Platform или на запуск демоприложения в Deckhouse Kubernetes Platform. Зарегистрироваться

🆕 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 #девопс Подпишись 👉@i_DevOps

23 апреля Магнит OMNI приглашает на Infrastructure MeetUp! На этом мероприятии DevOps-инженеры, платформенные инженеры, системные администраторы и разработчики обсудят, как создать инфраструктуру, устойчивую к сбоям. 🔸В программе: Доклады и дискуссии с участием специалистов из Магнит OMNI, Лаборатории Касперского, Авито, Cloud.ru и других компаний. Спикеры расскажут про устройство инфраструктуры бизнес-сервисов и вспомогательных компонентов, обеспечение отказоустойчивости, развитие Observability в условиях распределенной инфраструктуры, а также использование протоколов, помогающих в нештатных ситуациях. 🔸Что будет? — Разбор болей и кейсов, которые реально работают — Розыгрыш призов (крутейший мерч!) — Панельная дискуссия о том, как повышать устойчивость сервисов — Живой нетворкинг Митап пройдет в гибридном формате: 🔵Офлайн в московском офисе Магнита 🔵 Онлайн 🔸 23 апреля, в 17:30. Не упустите возможность узнать новое и пообщаться с профессионалами! Подробности и регистрация — по ссылке.

🎯 Terraform модули: избавься от копипасты навсегда Terraform — мощный инструмент, но легко скатиться в хаос, когда одни и те же ресурсы повторяются в каждом проекте. Настало время структурировать всё по уму с помощью модулей. Вот как модули помогут тебе: 🧩 Что такое модуль в Terraform? Это переиспользуемый блок кода с входами (variables), выходами (outputs) и логикой, который можно вызывать из любого проекта. Примеры — VPC, ECS-сервис, ALB, CloudWatch-алерты. 📁 Структура модуля:

modules/
├── vpc/
│   ├── main.tf
│   ├── variables.tf
│   └── outputs.tf

🔄 Использование модуля:

module "vpc" {
  source     = "./modules/vpc"
  cidr_block = "10.0.0.0/16"
  region     = "eu-west-1"
}

💡 Полезные практики: - Держи модули в отдельном репозитории (или хотя бы папке) - Дефолтные значения переменных — must-have - Используй terraform-docs для автогенерации документации - Добавляй README.md с примером вызова - Всегда пиши outputs.tf — он пригодится для связи между модулями 🚨 Частые ошибки: - Жестко закодированные значения (не делай так 🙅‍♂️) - Отсутствие версионирования модулей - Слишком "умные" модули (оставляй возможность переопределения) 🏁 Вывод: Модули экономят время, упрощают сопровождение и помогают внедрять best practices по всей инфраструктуре. Один раз запилил модуль — используешь везде. Главное — не превращать модуль в монстра с сотней переменных. 📚 Полезное: - Terraform Module Best Practices #devops #terraform Подпишись 👉@i_DevOps

🧑🏻‍💻Хотите писать гибкий и читаемый код на Python? Пора раскрыть скрытые возможности встроенной библиотеки! На открытом вебинаре 23 апреля в 20:00 мск мы познакомим вас с мощными инструментами стандартной библиотеки Python, которые сэкономят ваше время и помогут писать код без лишних зависимостей. Вы узнаете, как использовать модули, которые оптимизируют работу с данными, текстом и логированием. Мы поговорим о модулях collections, re и logging — встроенных инструментах, которые делают код компактным и понятным. Это важный шаг к переходу на более высокие позиции в разработке. ⚡️Присоединяйтесь к открытому вебинару и получите скидку на большой курс "Python Developer. Basic": https://vk.cc/cKZI4x Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

🚀 Разворачиваем 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 #девопс Подпишись 👉@i_DevOps

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 #девопс Подпишись 👉@i_DevOps

📕Открытый урок о NoSQL с Cassandra для разработчиков, администраторов, специалистов по базам данных, Data engineers, Backend и FullStack-разработчиков. На открытом уроке 21 апреля в 20:00 мск мы погрузимся в тонкости работы c NoSQL в Cassandra. 📗В результате вы: - Узнаете, как работает Cassandra и какие есть особенности про которые никто говорит; - Разберетесь, как избежать и решать проблемы в работе Сassandra; - Освоите техники и лайфхаки в Сassandra на практике. Спикер Дмитрий Гурьянов — Team Lead команды разработки CRM-решений на платформе .NET в Промсвязьбанке, 9+ лет в разработке, работал в Microsoft над продуктом Bing, аспирант кафедры "Системы обработки информации и управления" в МГТУ им. Н.Э. Баумана. 👉Регистрируйтесь прямо сейчас, чтобы не пропустить мероприятие: https://vk.cc/cKWWeo 📙Все участники открытого урока получат скидку на курс "Базы данных" Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

CI/CD под нагрузкой: оптимизация пайплайна для high-load проектов 🚀 Когда репозиторий растёт, а коммиты летят один за другим — CI/CD превращается из помощника в тормоз. Но всё можно оптимизировать. Зачем это нужно: Медленные пайплайны тормозят разработку, повышают стоимость инфраструктуры и раздражают команду. Ниже — конкретные приёмы, как ускорить и облегчить CI/CD для high-load проектов. 🔹 1. Параллельность — наше всё Используй matrix стратегии (в GitHub Actions) или parallel блоки (в GitLab CI). Тестируй сразу на нескольких версиях среды или запускай независимые шаги одновременно. Пример:

strategy:
  matrix:
    python-version: [3.10, 3.11]

🔹 2. Кэшируй агрессивно Настрой кэш зависимостей, Docker-слоёв, результатов компиляции. Это сильно снижает время на сборку. В GitHub Actions:

- uses: actions/cache@v3
  with:
    path: ~/.cache/pip
    key: ${{ runner.os }}-pip-${{ hashFiles('**/requirements.txt') }}

🔹 3. Разделяй и властвуй Разбей монолитный пайплайн на микропайплайны: unit-тесты, линтеры, деплой — по отдельности. Используй needs: только при настоящей зависимости. Это повышает параллельность и устойчивость. 🔹 4. Запускай не всё подряд Добавь paths: или only/except фильтры. Зачем гонять e2e, если изменился только README?

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

🔹 5. Используй артефакты — разумно Вместо перекомпиляции перед каждым шагом, сохраняй и передавай промежуточные сборки. Это особенно полезно для Java/Go/Node проектов. Вывод: Оптимизация пайплайна — не только про скорость. Это про контроль над процессом и уменьшение издержек. Начни с малого — кэш, фильтры, параллельность — и постепенно адаптируй под свой проект. #devops #девопс Подпишись 👉@i_DevOps