DevOps, как сам? Как строили мост между разработкой и эксплуатацией
Меня зовут Георг Гаал, я член ПК DevOpsConf. Я энтузиаст информационных технологий со школьной скамьи. Меня эта тема очень зажгла, когда я в первый раз сел за компьютер и осознал, что вообще не понимаю, как он функционирует. Сегодня я попытаюсь на примерах из своего опыта рассказать про эволюцию DevOps, актуальных трендах и о том, как оставаться востребованным в профессии.
https://habr.com/ru/companies/oleg-bunin/articles/891422/
📲 Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
Меня зовут Георг Гаал, я член ПК DevOpsConf. Я энтузиаст информационных технологий со школьной скамьи. Меня эта тема очень зажгла, когда я в первый раз сел за компьютер и осознал, что вообще не понимаю, как он функционирует. Сегодня я попытаюсь на примерах из своего опыта рассказать про эволюцию DevOps, актуальных трендах и о том, как оставаться востребованным в профессии.
https://habr.com/ru/companies/oleg-bunin/articles/891422/
📲 Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
👍4❤1
SnapScheduler — это контроллер Kubernetes, который автоматически создает снапшоты PVC (PersistentVolumeClaim) по расписанию, используя встроенный механизм
Основные возможности:
- Создание снапшотов PVC по расписанию (cron).
- Поддержка нескольких расписаний для одного PVC.
- Возможность настройки политики хранения (retention policy).
- Не требует изменений в приложении или манифестах PVC.
Как это работает:
Вы создаете ресурс
- Селектор PVC.
- Cron-расписание.
- Максимальное количество снапшотов для хранения.
Контроллер следит за расписанием и создает
Пример использования:
Такой манифест будет создавать снапшоты каждые 6 часов для всех PVC с лейблом
https://github.com/backube/snapscheduler
📲 Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
VolumeSnapshot. Он не зависит от CSI-драйвера, пока тот поддерживает VolumeSnapshot, и работает с любым сторедж-классом, поддерживающим снапшоты.Основные возможности:
- Создание снапшотов PVC по расписанию (cron).
- Поддержка нескольких расписаний для одного PVC.
- Возможность настройки политики хранения (retention policy).
- Не требует изменений в приложении или манифестах PVC.
Как это работает:
Вы создаете ресурс
SnapshotSchedule, в котором указываете:- Селектор PVC.
- Cron-расписание.
- Максимальное количество снапшотов для хранения.
Контроллер следит за расписанием и создает
VolumeSnapshot объекты автоматически.Пример использования:
apiVersion: snapscheduler.backube/v1
kind: SnapshotSchedule
metadata:
name: example-schedule
spec:
schedule: "0 */6 * * *"
snapshotTemplate:
labels:
createdBy: snapscheduler
pvcSelector:
matchLabels:
snapshot: "true"
retention:
maxCount: 5
Такой манифест будет создавать снапшоты каждые 6 часов для всех PVC с лейблом
snapshot=true, и хранить максимум 5 последних.https://github.com/backube/snapscheduler
📲 Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
👍2
🚑 HEALTHCHECK: Спасательный круг или выстрел в ногу?
Продолжаем тему стабильности. Сегодня про Healthchecks (в Docker) и Probes (в K8s).
Казалось бы, что сложного? Написал
Разберем две крайности и как делать правильно.
❌ Ошибка №1: "Зомби-апокалипсис" (Слишком слабый чек)
Вы проверяете только то, что процесс веб-сервера запущен и порт слушается.
🔘 Сценарий: У приложения отвалился коннект к БД (pool exhaustion), или случился дедлок внутри кода.
🔘 Итог: Хелсчек проходит (порт-то открыт!), балансировщик продолжает лить трафик на под, а пользователи получают 500-ки.
🔘 Лечение: Чек должен проверять работоспособность логики, а не просто наличие процесса.
❌ Ошибка №2: "Эффект Домино" (Слишком жадный чек)
Вы решили быть умными и в
🔘 Сценарий: База данных немного приуныла (медленные запросы).
🔘 Итог: Хелсчеки всех 50 подов начинают тайм-аутить. Kubernetes думает: "Ага, поды сдохли!" и начинает их перезагружать.
🔘 Финал: Все поды рестартуют одновременно, ломятся устанавливать соединения к и так лежащей базе и добивают её окончательно. Congratulations, you played yourself.
✅ Как делать правильно: Liveness vs Readiness
В Kubernetes (да и в грамотном Docker Compose) эти понятия разделены. Это фундамент.
1. Liveness Probe (Я жив?)
🔘 Цель: Понять, не завис ли процесс намертво.
🔘 Действие при сбое: РЕСТАРТ контейнера.
🔘 Что проверять: Очень легкий запрос. "Я могу отвечать на HTTP?". Не трогайте тут базу данных! Если база лежит, рестарт бэкенда не поможет ей подняться.
2. Readiness Probe (Я готов работать?)
🔘 Цель: Понять, можно ли пускать на меня трафик.
🔘 Действие при сбое: УБРАТЬ из балансировки (не убивать!).
🔘 Что проверять: Вот тут проверяем зависимости. Есть коннект к БД? Прогрелся кэш? Если нет, просто временно не шлите на меня юзеров.
📝 Пример (K8s Manifest):
💡 Главный совет
Никогда не делайте зависимость Liveness-пробы от внешних сервисов. Если у вас упал сторонний API, ваш сервис не должен уходить в циклическую перезагрузку. Он должен просто перестать говорить, что он
#k8s #devops #fails #stability #bestpractices
📲 Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
Продолжаем тему стабильности. Сегодня про Healthchecks (в Docker) и Probes (в K8s).
Казалось бы, что сложного? Написал
curl -f http://localhost/ || exit 1 и пошел пить кофе. Но именно такие "простые" решения часто становятся причиной того, что ваш прод лежит, хотя нагрузка детская.Разберем две крайности и как делать правильно.
❌ Ошибка №1: "Зомби-апокалипсис" (Слишком слабый чек)
Вы проверяете только то, что процесс веб-сервера запущен и порт слушается.
❌ Ошибка №2: "Эффект Домино" (Слишком жадный чек)
Вы решили быть умными и в
/health эндпоинт засунули проверку коннекта к Базе, Редису и S3.✅ Как делать правильно: Liveness vs Readiness
В Kubernetes (да и в грамотном Docker Compose) эти понятия разделены. Это фундамент.
1. Liveness Probe (Я жив?)
2. Readiness Probe (Я готов работать?)
📝 Пример (K8s Manifest):
livenessProbe:
httpGet:
path: /health/live # Максимально тупой ответ 200 OK
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
readinessProbe:
httpGet:
path: /health/ready # Проверка БД, очередей и т.д.
port: 8080
initialDelaySeconds: 10
periodSeconds: 10
failureThreshold: 3
💡 Главный совет
Никогда не делайте зависимость Liveness-пробы от внешних сервисов. Если у вас упал сторонний API, ваш сервис не должен уходить в циклическую перезагрузку. Он должен просто перестать говорить, что он
Ready, или отдавать ошибку юзеру, оставаясь "живым".#k8s #devops #fails #stability #bestpractices
📲 Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7❤2
Какую функцию выполняет ReplicaSet?
Функция ReplicaSet (RS) в Kubernetes заключается в обеспечении стабильного количества экземпляров подов в кластере. RS является основным компонентом Kubernetes, который используется для развертывания Stateless-приложений. Он обеспечивает непрерывную доступность приложения, автоматически запуская новые экземпляры подов в случае их выхода из строя. Без использования RS такие поды пришлось бы запускать вручную, что затруднило бы поддержание доступности приложения для пользователей.
Что такое пространство имен (namespaces)? Почему не стоит использовать одно namespace для всех приложений?
Пространства имен позволяют разделить кластер на виртуальные группы, внутри которых можно объединять приложения по нужному принципу. Таким образом, создается возможность изолировать различные группы приложений друг от друга. Например, благодаря этой функции можно создать приложение с одинаковым именем в двух разных пространствах.
Если использовать только одно пространство имен, которое было задано по умолчанию при запуске кластера, со временем может стать сложно ориентироваться во всех приложениях, запущенных в нем. Группировка приложений в разных пространствах имен упрощает работу: например, можно разместить приложение мониторинга в одном пространстве, а приложения, связанные с информационной безопасностью, в другом.
Еще один случай, когда несколько пространств имен могут пригодиться, — это ситуация, когда несколько команд работают с одним кластером.
📲 Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
Функция ReplicaSet (RS) в Kubernetes заключается в обеспечении стабильного количества экземпляров подов в кластере. RS является основным компонентом Kubernetes, который используется для развертывания Stateless-приложений. Он обеспечивает непрерывную доступность приложения, автоматически запуская новые экземпляры подов в случае их выхода из строя. Без использования RS такие поды пришлось бы запускать вручную, что затруднило бы поддержание доступности приложения для пользователей.
Что такое пространство имен (namespaces)? Почему не стоит использовать одно namespace для всех приложений?
Пространства имен позволяют разделить кластер на виртуальные группы, внутри которых можно объединять приложения по нужному принципу. Таким образом, создается возможность изолировать различные группы приложений друг от друга. Например, благодаря этой функции можно создать приложение с одинаковым именем в двух разных пространствах.
Если использовать только одно пространство имен, которое было задано по умолчанию при запуске кластера, со временем может стать сложно ориентироваться во всех приложениях, запущенных в нем. Группировка приложений в разных пространствах имен упрощает работу: например, можно разместить приложение мониторинга в одном пространстве, а приложения, связанные с информационной безопасностью, в другом.
Еще один случай, когда несколько пространств имен могут пригодиться, — это ситуация, когда несколько команд работают с одним кластером.
📲 Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
👍2🔥2
Furiko
Это современный планировщик заданий Kubernetes, созданный с нуля для гибкости, расширяемости и надёжности. Он спроектирован для запуска заданий с различными политиками повторения, управления историей запусков и предоставления пользовательского интерфейса для просмотра и администрирования заданий.
Furiko состоит из следующих компонентов:
- QueueJob Controller: абстракция заданий, которые можно ставить в очередь с масштабируемой логикой запуска.
- CronJob Controller: надёжный планировщик повторяющихся заданий с CRON-подобной семантикой.
- Web UI: удобный пользовательский интерфейс для управления заданиями и их выполнениями.
- CLI: утилита командной строки для взаимодействия с заданиями Furiko.
https://github.com/furiko-io/furiko
📲 Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
Это современный планировщик заданий Kubernetes, созданный с нуля для гибкости, расширяемости и надёжности. Он спроектирован для запуска заданий с различными политиками повторения, управления историей запусков и предоставления пользовательского интерфейса для просмотра и администрирования заданий.
Furiko состоит из следующих компонентов:
- QueueJob Controller: абстракция заданий, которые можно ставить в очередь с масштабируемой логикой запуска.
- CronJob Controller: надёжный планировщик повторяющихся заданий с CRON-подобной семантикой.
- Web UI: удобный пользовательский интерфейс для управления заданиями и их выполнениями.
- CLI: утилита командной строки для взаимодействия с заданиями Furiko.
https://github.com/furiko-io/furiko
📲 Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
👍3
Устранение проблем с отсутствующими логами Kubernetes в Elasticsearch
Отсутствующие логи могут стать настоящей проблемой для многих пользователей Kubernetes. В этой статье мы разберемся, почему это происходит, и как этого избежать.
Я исследовал случай отсутствующих логов Kubernetes в Elasticsearch, который в моем случае агрегирует логи для подов Kubernetes. У меня стандартная настройка Elasticsearch и Fluentd, и время от времени в Elasticsearch появляется пропуск, когда в течение нескольких секунд нет логов.
https://povilasv.me/troubleshooting-missing-kubernetes-logs-in-elasticsearch/
📲 Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
Отсутствующие логи могут стать настоящей проблемой для многих пользователей Kubernetes. В этой статье мы разберемся, почему это происходит, и как этого избежать.
Я исследовал случай отсутствующих логов Kubernetes в Elasticsearch, который в моем случае агрегирует логи для подов Kubernetes. У меня стандартная настройка Elasticsearch и Fluentd, и время от времени в Elasticsearch появляется пропуск, когда в течение нескольких секунд нет логов.
https://povilasv.me/troubleshooting-missing-kubernetes-logs-in-elasticsearch/
📲 Мы в MAX
#devops #девопс
Подпишись 👉@i_DevOps
👍3
🛠 Git Cheat Sheet: 12 команд, которые должен знать каждый DevOps
📂 Начало работы
•
•
• Совет: Используйте
🔄 Основной цикл (Commit & Sync)
•
•
•
• Важно:
🌿 Ветвление и слияние
•
•
•
🔍 Диагностика и откат
•
•
•
• ⚠️ Осторожнее с флагом
💡Лайфхак: Вместо того чтобы вручную проверять статус в каждом проекте, настройте себе алиасы в
#git #devops #cheatsheet #programming #automation
📲 Мы в MAX
Подпишись 👉@i_DevOps
📂 Начало работы
•
git init - создаем новый репозиторий. Помните, что это просто создает скрытую папку .git.•
git remote - связываем локальный код с удаленным сервером (GitHub/GitLab).• Совет: Используйте
git remote -v, чтобы проверить, куда вы пушите код.🔄 Основной цикл (Commit & Sync)
•
git add - добавляем изменения в индекс (staging).•
git commit - фиксируем изменения. Пишите осмысленные сообщения! "Fixed bug" - плохо, "Fix: update nginx config for timeout issue" - хорошо.•
git push / git pull - отправка и получение изменений.• Важно:
git pull - это на самом деле fetch + merge.🌿 Ветвление и слияние
•
git branch - работа с ветками. В DevOps мы часто используем feature-branches.•
git checkout - переключение между ветками. (Кстати, в новых версиях Git для этого чаще используют git switch).•
git merge - объединение веток.🔍 Диагностика и откат
•
git status - ваша любимая команда. Показывает, что происходит прямо сейчас.•
git fetch - забирает данные из репозитория, но не меняет ваш локальный код. Безопасный способ проверить обновления.•
git reset - откат изменений.• ⚠️ Осторожнее с флагом
--hard, он удаляет изменения безвозвратно!💡Лайфхак: Вместо того чтобы вручную проверять статус в каждом проекте, настройте себе алиасы в
.bashrc или .zshrc. Например:alias gs='git status'alias gl='git log --oneline --graph --all'#git #devops #cheatsheet #programming #automation
📲 Мы в MAX
Подпишись 👉@i_DevOps
👍10
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
Хотя 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
👍7
Основы виртуализации. Часть 1
1.Основы виртуализации. Введение
2.Основы виртуализации. История развития виртуализации
3.Основы виртуализации. Серверы
4.Основы виртуализации. Виртуальные машины
5.Основы виртуализации. Гипервизоры второго типа
6.Основы виртуализации. Лабораторная работа №1. Создаем VM
7.Основы виртуализации. Гипервизоры первого типа
8.Основы виртуализации. Лабораторная работа №2. ESXi
источник
📲 Мы в MAX
Подпишись 👉@i_DevOps
1.Основы виртуализации. Введение
2.Основы виртуализации. История развития виртуализации
3.Основы виртуализации. Серверы
4.Основы виртуализации. Виртуальные машины
5.Основы виртуализации. Гипервизоры второго типа
6.Основы виртуализации. Лабораторная работа №1. Создаем VM
7.Основы виртуализации. Гипервизоры первого типа
8.Основы виртуализации. Лабораторная работа №2. ESXi
источник
📲 Мы в MAX
Подпишись 👉@i_DevOps
👍5
MLOps — дитя DevOps и ML
Один ML-проект в проде вам или два другому? Внедрение машинного обучения в производственную среду остаётся одной из главных проблем индустрии. По статистике, 80% ML-проектов никогда не доходят до продакшена. Однако хитрые опсы и тут решили выделиться, и в результате появился MLOps — методология, которая поможет вам сократить путь от эксперимента до деплоя с месяцев до дней. В этой статье мы пройдёмся по верхам MLOps и посмотрим на фундаментальные принципы и конкретные инструменты.
https://habr.com/ru/companies/ruvds/articles/990814/
📲 Мы в MAX
Подпишись 👉@i_DevOps
Один ML-проект в проде вам или два другому? Внедрение машинного обучения в производственную среду остаётся одной из главных проблем индустрии. По статистике, 80% ML-проектов никогда не доходят до продакшена. Однако хитрые опсы и тут решили выделиться, и в результате появился MLOps — методология, которая поможет вам сократить путь от эксперимента до деплоя с месяцев до дней. В этой статье мы пройдёмся по верхам MLOps и посмотрим на фундаментальные принципы и конкретные инструменты.
https://habr.com/ru/companies/ruvds/articles/990814/
📲 Мы в MAX
Подпишись 👉@i_DevOps
👍5❤3
🧪 K8E — это форк проекта K3s, предназначенный для локального тестирования.
Он не требует root-доступа и не использует systemd.
Также вы можете легко собрать и запустить его без сетевого подключения (air-gap режим).
Основные особенности:
- Без root-доступа
- Без systemd
- Один бинарник
- Простой запуск кластера:
- Не требует внешней сети
- Поддерживает полностью автономную сборку
Если вы когда-либо хотели поднять Kubernetes-кластер за пару секунд и без привилегий — этот инструмент идеально подойдёт для тестов и локальной разработки.
https://github.com/xiaods/k8e
📲 Мы в MAX
Подпишись 👉@i_DevOps
Он не требует root-доступа и не использует systemd.
Также вы можете легко собрать и запустить его без сетевого подключения (air-gap режим).
Основные особенности:
- Без root-доступа
- Без systemd
- Один бинарник
- Простой запуск кластера:
k8e server &- Не требует внешней сети
- Поддерживает полностью автономную сборку
Если вы когда-либо хотели поднять Kubernetes-кластер за пару секунд и без привилегий — этот инструмент идеально подойдёт для тестов и локальной разработки.
https://github.com/xiaods/k8e
📲 Мы в MAX
Подпишись 👉@i_DevOps
👍5❤1
Media is too big
VIEW IN TELEGRAM
Zed — это высокопроизводительный текстовый редактор, ориентированный на разработчиков. Он написан на Rust и использует пользовательский движок рендеринга на базе GPU для достижения минимальных задержек. Архитектура Zed основана на многопоточности и асинхронности, что позволяет редактору эффективно использовать ресурсы современных многоядерных систем.
Редактор также разрабатывается с упором на совместную работу в реальном времени: Zed предлагает встроенные функции для коллаборации между разработчиками — от редактирования кода до видеозвонков. Это делает его особенно удобным для удалённых команд.
Среди особенностей:
- Мгновенный отклик и плавная анимация благодаря GPU-рендерингу
- Полноценная поддержка нескольких курсоров и мощное автодополнение
- Интеграция с языковыми серверами (LSP)
- Глубокая коллаборативность: совместное редактирование, общие терминалы, голос и видео
https://github.com/zed-industries/zed
📲 Мы в MAX
Подпишись 👉@i_DevOps
Редактор также разрабатывается с упором на совместную работу в реальном времени: Zed предлагает встроенные функции для коллаборации между разработчиками — от редактирования кода до видеозвонков. Это делает его особенно удобным для удалённых команд.
Среди особенностей:
- Мгновенный отклик и плавная анимация благодаря GPU-рендерингу
- Полноценная поддержка нескольких курсоров и мощное автодополнение
- Интеграция с языковыми серверами (LSP)
- Глубокая коллаборативность: совместное редактирование, общие терминалы, голос и видео
https://github.com/zed-industries/zed
📲 Мы в MAX
Подпишись 👉@i_DevOps
👍2❤1🤡1