DevOps 413
302 subscribers
17 photos
5 videos
13 links
Опыт инженера изнутри: DevOps-практика, инфраструктура, конференции и карьера в IT

https://youtube.com/@devops413
Download Telegram
Channel created
Привет! 👋
🧩 Обо мне: в IT 8 лет, в DevOps 4 года, до инженера выросла из техподдержки. Без профильного высшего, все знания - самообучение и практика.
Работала в Yota, Skyeng, X5, Т1 💙.

Помогаю начинающим специалистам — менторю:
👉 Профиль на getmentor.dev
Также являюсь ментором в @womenintechrus.

🖼️ О чём посты
• реальные рабочие кейсы
• советы для тех, кто учится DevOps с нуля
• инциденты и разборы из практики
• заметки о карьере в IT

🎥 Дополнительные материалы:
Интервью для Slurm
Please open Telegram to view this post
VIEW IN TELEGRAM
6🔥1
В свободное от работы время я помогаю начинающим специалистам начать или продолжить погружение в DevOps.
Вот мой базовый чек-лист, который я даю каждому менти 👇

🧠 1. DevOps как методология
Стоит понимать, какие задачи решает DevOps и зачем бизнесу нужна эта культура. DevOps это методология, DevOps инженер - специалист, который внедряет эту методологию.

⚙️ 2. CI/CD
Теория, чем CDL отличается от CDP.

🐧 3. Linux
Обязательно. Без уверенного владения Linux двигаться дальше тяжело.
🔗 Полезная карта для навигации по темам: roadmap.sh/linux

🕸 4. Сети
Основы, без которых не получится понимать ни контейнеризацию, ни инфраструктуру:
• DHCP
• DNS
• TCP/IP
• NAT
• iptables
🧩 Для практики сетей рекомендую отличный симулятор: miminet.ru

📦 5. Контейнеризация и виртуализация
Важно знать разницу и когда что использовать.

🖼 6. Docker
Минимальный набор для старта:
• docker image
• docker compose
• docker run
• dockerfile
• docker volumes

🧩 Полная карта компетенций DevOps: roadmap.sh/devops

‼️ Главное — практика.
Почти каждый менти, с которым я общалась, отмечал, что без неё теория не усваивается.
Основные инструменты и технологии — это логические абстракции, и пока не “потрогаешь руками”, в голове не складывается картина.

Если этот пост оказался полезным — поставьте реакцию.
Так я пойму, что стоит подготовить подборку практических задач и список отборных статей для самообучения.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥14👍126
👉 Кейс: Мигрируем тома в Kubernetes

Разбираем реальную задачу. Задача для middle и выше: миграция данных между томами в рамках смены CSI.

🎯 Задача: Перенести данные из старого в новый PVC, созданный уже новым CSI-драйвером. Без потерь и с минимальным временем простоя.
Как будете декомпозировать задачу и какие инструменты будете использовать? Предлагаю использовать утилиты pv-migrate и rename-pvc.

🧠 Декомпозиция:

1. Подготовка: Создать новый PVC в целевом хранилище. Убедиться, что поды, использующие старый том, остановлены.
2. Миграция: Перекачать данные из старого PVC в новый.
3. Переключение: "Подменить" старый том новым для рабочей нагрузки.
4. Финал: Протестировать и убрать старые артефакты.

🛠 Инструмент: pv-migrate

Это утилита, которая превращает сложный процесс в одну команду. Её магия в том, что она:
* Автоматически создаёт мигрирующий Pod с доступом к обоим томам (источнику и назначению).
* Сама выбирает стратегию копирования (например, mnt2 — монтирует оба тома в один под и использует rsync).
* Берет на себя: проверки, мониторинг прогресса, очистку за собой.

По сути, вы говорите "скопируй вот этот том в тот", а pv-migrate делает всё остальное. Проще не бывает!

📋 План действий и команды

⚠️ Золотое правило: "7 раз отмерь — 1 раз отрежь". Даже на dev потеря данных — это боль. Не забываем о бэкапах!

1. Останавливаем нагрузку.

kubectl scale deploy -n user-ns app --replicas=0

2. Подготавливаем новый PVC с идентичными labels, используя новый StorageClass.
3. Запускаем миграцию.

NAMESPACE=user-ns
PVC_NAME="app-pv"

kubectl pv-migrate \
--strategies mnt2 \
--source-namespace=$NAMESPACE \
--source=$PVC_NAME \
--dest-namespace=$NAMESPACE \
--dest=$PVC_NAME-new

Ждём успешного завершения. В логах будет виден прогресс.
4. "Переключаем" тома. Переименовываем PVC, чтобы приложение начало использовать новый том.

# Переименовываем старый PVC
kubectl rename-pvc --yes -n $NAMESPACE $PVC_NAME $PVC_NAME-old

# Переименовываем новый PVC
kubectl rename-pvc --yes -n $NAMESPACE $PVC_NAME-new $PVC_NAME

5. Запускаем приложение.

kubectl scale deploy -n user-ns app --replicas=1

6. Проверяем, что под поднялся и данные на месте.
7. Удаляем старый PVC, когда уверены, что он больше не нужен.

💎 Итог

Весь процесс миграции свелся к нескольким командам. Утилита pv-migrate скрывает за собой всю сложность и позволяет делать рискованные операции предсказуемо и безопасно.

Sources: pv-migrate | rename-pvc
👍4❤‍🔥1
🖼️ Docker vs Kubernetes 🖼️

На днях ко мне обратились два инженера — обсуждали автоматизацию деплоя в их организации. После нескольких рекомендаций прозвучал классический холиварный вопрос: Docker или Kubernetes? Когда пора переходить на кубер?

Я вижу, что это до сих пор одна из самых горячих тем на конференциях. И не просто так! Я решила сравнить.

🔍 Ключевым параметры:
Кластеризация
🖼️ Да
🖼️ Да

Сложность настройки
🖼️ Низкая
🖼️ Высокая — требует экспертизы

Автомасштабирование
🖼️ Ручное или базовое
🖼️ HPA, VPA, Cluster Autoscaler

Self-healing
🖼️ Ограниченное (restart policy)
🖼️ Продвинутое (liveness, readiness)

Управление конфигами
🖼️ Docker Configs/Secrets
🖼️ ConfigMaps, Secrets + GitOps

Обновления
🖼️ Через docker-compose / скрипты
🖼️ Rolling updates / Canary / GitOps

Экосистема
🖼️ Ограниченная
🖼️ Огромная (Operators, Helm, CRD)

💰 Что насчёт стоимости?

Ведь DevOps — это в том числе про оптимизацию ресурсов.

Kubernetes:

Легковеснее при правильной настройке, оптимальная утилизация = экономия денег
Дорогой специалист: опытный K8s-инженер стоит 250-400k₽+

Docker:

Дешевле на старте: минимальные требования к инфраструктуре и экспертизе, базовые знания Docker есть у большинства
Хуже утилизация ресурсов: нет динамического распределения, часто "резервируют с запасом", ручное управление: масштабирование и балансировка требуют больше времени DevOps'а

📊 Когда пора переезжать на Kubernetes?

Одной причины недостаточно — это всегда совокупность факторов:
1. Динамическое масштабирование
2. Многокластерность и распределённость
3. Рост команды и процессов
4. Self-healing и Zero-downtime
5. Сложная сетевая топология
6. Compliance и изоляция

⚠️ Когда НЕ нужен Kubernetes?

- Монолит или 2-3 микросервиса без планов роста
- Небольшая команда
- Нет особых/специфичных требований к инфраструктуре

В таких случаях Docker + хороший мониторинг закроют 90% задач без оверинжиниринга.

Согласны?) Узнали? 😬Жду холиварные контраргументы в комментариях!!!👇
Please open Telegram to view this post
VIEW IN TELEGRAM
👍72🔥2🤓1
Обожаю мемасы, но годных айтишных мало, а про DevOps еще меньше 😭
Я наскребла парочку для вас, поделитесь своими 🙏
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
😁9🤣2💅1
Forwarded from Women in Tech (WiT)
5 ноября в 18:00 MSK состоится вебинар на тему «Запуск приложений в Docker»

🚀 Вебинар будет полезен разработчикам, администраторам и инженерам, а также всем, кто хочет познакомиться с Docker.

В роли спикера выступит Юлия Брунер:
DevOps инженер в компании T1
Автор телеграм канала об IT @devops413
Ментор

На вебинаре:
👉 Разберем базовые абстракции докера
👉 Соберем образ и запустим свое приложение в контейнере
👉 Разберем частые ошибки и лучшие практики

🔗Подключайтесь по ссылке
🗓 Добавляйте в календарь

Если вам не хватило места в Zoom, подключайтесь к трансляции в Telegram @wit_streams

⏺️ Запись будет

#DataScience #QA #DevOps
9👍2💅2🔥1🏆1👀1