Библиотека девопса | DevOps, SRE, Sysadmin

🐧 Осенние апдейты Сразу несколько дистрибутивов отметились обновлениями. — openSUSE Leap 16 Новый установщик Agama, переход на архитектуру x86-64-v2, общий код с SUSE Linux Enterprise и двухлетний цикл поддержки. — Ubuntu Touch OTA-10 Минорный релиз, нацеленный на стабильность и подготовку к переходу на базу Ubuntu 24.04. Главная новинка — встроенный upgrader, который позволит легко обновиться до следующей версии, как только она выйдет. — MiniOS Flux 5.1 Главное улучшение — система снова стабильно запускается в любых условиях: через Ventoy, с BIOS и даже на старом железе. — BSD Router Project 1.99.5 В релизе улучшена работа BGP и OSPF, обновлены пакеты FRRouting и pf, добавлены свежие драйверы и оптимизировано использование памяти. 🐸Библиотека devops'a #пульс_индустрии

☸️ Kubernetes Cleanup — когда кластер захламился Иногда после тестов или экспериментов проще всё удалить и обнулить кластер, чем вычищать ресурсы по одному. Удалить все ресурсы в namespace:

kubectl delete all --all -n <namespace>

Удалить все ресурсы во всех namespace’ах:

kubectl delete all --all --all-namespaces

Очистить хвосты — ConfigMap, Secrets, PVC, Jobs и т.п:

kubectl delete configmap,secret,pvc,pv,job,cronjob --all --all-namespaces

Удалить все namespace’ы кроме системных:

for ns in $(kubectl get ns --no-headers | awk '!/kube-system|kube-public|kube-node-lease|default/ {print $1}'); do
  kubectl delete ns $ns
done

🐸Библиотека devops'a #root@prompt

✨ Итоги недели Вспомните самый яркий момент или открытие последних дней. Может, это была неожиданная новость, полезный туториал или просто интересная идея? Расскажите, чем вдохновились или что заставило задуматься. Ждём вас в комментах 👇 🐸Библиотека devops'a #голосование_за_контент

🆕 Материалы недели Вспоминаем что было за эту неделю кратким дайджестом. — Linux 6.17 — Конец эпохи диалап — Как вайб-кодинг меняет рынок IT-образования — Вышел релиз-кандидат Argo CD 3.2.0 — Утечка у Red Hat 🐸Библиотека devops'a #дайджест_недели

🚀 Курс «ИИ-агенты для DS-специалистов» уже стартовал Первый вебинар успешно прошёл, участники уже начали разбираться, как использовать ИИ-агентов в реальных проектах. Но всё самое интересное только начинается! 🔥 Впереди 4 мощных занятия — с практикой, инсайтами и разбором кейсов от экспертов. 💸 Сейчас действует специальная цена → 69.000 ₽ вместо 79.000 ₽. ⏳ Осталось всего 4 места. Не упустите шанс прокачаться в том, что будет определять будущее индустрии. 👉 Забронировать место на курсе

🤔 Нетривиальный вопрос с собеседования Сегодня попробуем ответить на такой вопрос:

Что происходит в Kubernetes, когда под не проходит liveness probe

Большинство кандидатов отвечают: «Он перезапускается». Но это — только верхушка айсберга. Под капотом Kubernetes: 1. Когда liveness probe проваливается kubelet сообщает об этом API Server, который записывает Pod как unhealthy в etcd. 2. Дальше kubelet через containerd/CRI-O убивает контейнер и проверяет restartPolicy: если можно — перезапускает, если нет — Pod считается завершённым. 3. Контроллер ReplicaSet видит, что живых Pod’ов меньше, и создаёт новый. 4. Scheduler выбирает подходящий узел, а kube-proxy убирает сбойный Pod из маршрутов сервиса. 5. В kubectl describe pod появляются события, но если Prometheus не следит за ними — узнаете о проблеме только от пользователей. Сеньор-уровень — это не про YAML, а про понимание того, что конкретно происходит. 🐸Библиотека devops'a #Задача_со_звёздочкой

🚨 570 ГБ данных утекают из GitLab Группа Crimson Collective заявила о похищении ~570 ГБ данных из внутреннего GitLab-инстанса Red Hat, используемого подразделением консультационных услуг. В числе утечек — отчёты клиентов (CERs), конфигурации и внутренние коммуникации. В Red Hat подтвердили инцидент, пояснив, что взлом затронул GitLab-инстанс, используемый только в рамках подразделения консультационных услуг, и что инстанс не был публичным сервисом Red Hat. Ошибки и слабые стороны • Держать в одном месте огромное количество внутренних репозиториев, включая отчёты клиентов и конфигурационные материалы — всегда риск. • По заявлению злоумышленников, они пытались связаться с Red Hat с требованием выкупа, но получили шаблонный ответ и инструкцию подать отчет об уязвимости. Заявляется, что тикет непрерывно переназначался. • Компания утверждает, что после обнаружения приступила к изоляции и принятию мер. Но вопрос: как быстро был установлен сам факт вторжения? Если задержка была ощутимой — ущерб мог быть намного больше. Что можно сделать • Каждому пользователю и процессу нужно давать максимально ограниченный доступ: только то, что требуется прямо сейчас. Да, это налагает нагрузку на управление, но снижает риск масштабной кражи данных. • Слежка за нехарактерной активностью, анализ аномалий, срабатывания по подозрительным запросам, частотам доступа, скачиваниям. • Даже если данные украдены, шифрование может сделать их бессмысленными для злоумышленников. • Клиенты, чьи данные могли быть скомпрометированы, должны быть уведомлены. Лучше быть честным и открытым. ➡️ Источник 🐸Библиотека devops'a #разбор_полётов

🐸Библиотека devops'a #пятничный_деплой

Расскажут инженеры MWS Cloud Platform ⬜️ в 8-й серии реалити-проекта для инженеров — Building the Cloud. 📅 Когда: 9 октября в 13:00 📍 Где: Онлайн Вы узнаете: ⏺️чем реализация ванильного Kubernetes отличается от управляемого сервиса, предоставляемого в облаке; ⏺️какую архитектуру выбрали для managed-решения в облаке MWS Cloud Platform; ⏺️как реализовали жизненный цикл кластеров, мульти-тенанси и интеграции с другими облачными сервисами — Artifact Registry, IAM, Compute, VPC. 🎁 Розыгрыш фирменного мерча — за лучший вопрос в чате. Будет особенно полезно DevOps- и Cloud Native-инженерам, а также всем, кто интересуется облачными технологиями. ➡️Зарегистрироваться

🐙 Argo CD 3.2.0-rc1 Вышел релиз-кандидат Argo CD 3.2.0. В нём добавили несколько полезных фич: • Progressive Sync в ApplicationSet теперь умеет удалять приложения по порядку • улучшены debug-логи статуса ApplicationSet • CLI получил поддержку Server-Side Diff и новую команду get-resource • контроллер теперь может брать более свежую ревизию при повторном sync • появились health-check для DatadogMetric и CronJob, включая действия suspend/resume/terminate ➡️ Анонс разработичков 🐸Библиотека devops'a #пульс_индустрии

💼 Золото, а не вакансии Для вас самый сок из нашего канала с вакансиями: Полмиллиона за SRE/DevOps'a DevOps Engineer на Кипр 🐸Библиотека devops'a #вакансия_недели

🎓 Какая разница у бакалавра и самоучки Университетские курсы по DevOps? Почти не существует. CS-программы учат алгоритмы, структуры данных, иногда сетевые основы. Всё полезно, но… попробуйте найти в типичном универе лекцию по Kubernetes, Terraform или GitOps. Поэтому DevOps-инженеры чаще всего — самоучки. Учебники заменяет документация AWS и GitHub-репозитории с примерами. Реальные навыки приходят через «сгоревший прод», ночные деплои и баги в пайплайне. Но спор никто не забывал. Одни говорят:

Без CS ты всего лишь оператор Jenkins, который не понимает, почему сломалась сеть

Другие отвечают:

Без практики ты вечный студент, который знает теорему CAP, но не умеет восстановить кластер

💬 А вы что думаете: для DevOps сегодня важнее академическая база или способность быстро тушить пожары в продакшене? 🐸Библиотека devops'a #холиварня

👾 AI-агенты — настоящее, о котором все говорят! Уже 3 октября стартует второй поток нашего нового курса «AI-агенты для DS-специалистов». Это продвинутая программа для тех, кто хочет получить прикладной опыт с LLM и решать сложные задачи. На обучении вы соберёте полноценные LLM-системы с учётом особенностей доменных областей, получите hands-on навыки RAG, Crew-AI / Autogen / LangGraph и агентов. 🎓 В рамках курса вы научитесь: 1️⃣ адаптировать LLM под разные предметные области и данные 2️⃣ собирать свою RAG-систему: от ретривера и реранкера до генератора и оценки качества 3️⃣ строить AI-агентов с нуля — на основе сценариев, функций и взаимодействия с внешней средой Научитесь применять похожие подходы в разных доменных областях, получите фундамент для уверенного прохождения NLP system design интервью и перехода на следующий грейд. 🗓️ Завтра первый вебинар, успевайте залететь в ряды ИИ-первопроходцев 👈🏻

⚙️ Зачем нужен Control Plane в Kubernetes Когда говорят о Kubernetes, чаще всего представляют себе кластер из множества узлов, где запускаются контейнеры. Но вся эта система работает не сама по себе — ей нужен мозг, управляющий всеми процессами. Этим мозгом и является Control Plane. Control Plane — это набор компонентов, которые принимают решения о том, что, где и как должно выполняться в кластере. Если рабочие узлы можно сравнить с мускулами, то Control Plane — это нервная система и голова. В состав Control Plane входят: • kube-apiserver — главный вход в кластер. Все команды kubectl и взаимодействия с API проходят через него. Он обеспечивает проверку запросов, аутентификацию и валидацию. • etcd — распределённое хранилище, где держится всё состояние кластера. По сути, это “база данных” Kubernetes, в которой записано, какие ресурсы есть, какое у них состояние и какие должны быть цели. • kube-scheduler — отвечает за то, на какой рабочий узел попадут новые поды. Он анализирует доступные ресурсы, ограничения, правила и принимает решение. • kube-controller-manager — набор контроллеров, которые следят, чтобы желаемое состояние совпадало с фактическим. Например, если вы сказали, что должно быть три пода, а осталось два, контроллер поднимет третий. • cloud-controller-manager (опционально) — компонент для интеграции с облаками (AWS, Azure, GCP и др.), который умеет управлять балансировщиками, дисками и сетями в зависимости от платформы. Главная сила Control Plane в том, что он реализует декларативную модель управления. Вы описываете в манифесте YAML, что «хочу три реплики приложения», а Control Plane сам добивается этого состояния: запускает поды, следит за их здоровьем и пересоздаёт при сбоях. Любое действие с кластером — от деплоя приложения до масштабирования или обновления — в конечном счёте проходит через Control Plane. И если он работает стабильно, то и весь кластер предсказуемо выполняет ваши инструкции. 🐸Библиотека devops'a #Арсенал_инженера

🚑 Как проверить, жив ли сервис в Kubernetes за одну команду Обычно, чтобы понять, доступен ли сервис внутри кластера, приходится делать port-forward или искать под с установленным curl. Но есть более короткий путь:

kubectl run curl --rm -it --image=alpine/curl -- -sS myservice.default:8443

👉 А вы чаще используете для диагностики kubectl exec, port-forward или держите отдельный debug-pod? 🐸Библиотека devops'a #root@prompt

🎓 Как вайб-кодинг меняет рынок IT-образования За последние годы подход к обучению программированию меняется быстрее, чем сами языки. На смену долгим упражнениям с синтаксисом приходит работа с идеями и концепциями, где код во многом генерируется автоматически. Этот сдвиг называют «вайб-кодингом». Он уже влияет на университетские программы, онлайн-курсы и требования к выпускникам. ➡️ В статье о том, что стоит за этим термином и как он меняет обучение IT-специалистов.

Есть поле int _counter; инкрементируется из нескольких потоков. Требование: корректный подсчёт, минимальные накладные расходы, без блокировок. Что выбрать? 👾 — Объявить _counter как volatile и использовать ++_counter 👍 — Использовать Interlocked.Increment(ref _counter) 🥰 — Оборачивать ++_counter в lock ⚡️ — Вставить Thread.MemoryBarrier() до и после ++_counter Библиотека задач по DevOps

📎 Как дебажить distroless-контейнеры в Kubernetes Distroless-образы стали популярны благодаря минимализму: внутри только ваше приложение и рантайм: Java, Go, Node.js. Никакого bash, curl или apt. Это повышает безопасность, ускоряет скачивание и снижает поверхность атаки. Но у такого подхода есть обратная сторона — как отлаживать контейнер без шелла и утилит? В обычном контейнере вы просто делаете kubectl exec -it pod -- bash и изучаете логи, процессы, сетевые соединения. В distroless — так не получится: шелла и инструментов там нет. Kubernetes позволяет «прикреплять» временные контейнеры к работающему Pod без его рестарта. Вы можете подключить образ с нужными утилитами и дебажить приложение вживую:

kubectl debug pod/<имя-пода> -it --image=busybox --target=<контейнер>

Эфемерный контейнер делит тот же namespace, что и приложение, поэтому вы получаете доступ к файловой системе, процессам и сети. После завершения отладки контейнер исчезает. 🐸Библиотека devops'a #арсенал_инженера

📡 Конец эпохи диалап Компания AOL официально прекращает поддержку dial-up — того самого интернета с писком модема и долгим ожиданием соединения. В 90-е и начале 2000-х это был главный способ выйти в сеть, и многие именно с него начинали знакомство с интернетом. Dial-up остаётся в прошлом — вместе со звуками соединения и лимитированными тарифами на часы онлайна. ❓А когда вы в последний раз пользовались dial-up интернетом 📎 Источник 🐸Библиотека devops'a #dev_null

🐧 Linux 6.17 Линус Торвальдс объявил релиз Linux 6.17. По его словам, неделя вышла спокойной: никаких «бомб», только ровная полировка. Самое заметное — фиксы гонок в Bluetooth, которые могли приводить к use-after-free. Плюс привычный набор мелочей: драйверы (в основном GPU и сеть), файловые системы, ядро и память, апдейты selftests. ➡️ Анонс обновления 🐸Библиотека devops'a #пульс_индустрии