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

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

⚡️ Grafana на ObservabilityCON На ObservabilityCON 2025, прошедшей с 7 по 9 октября, Grafana Labs представила несколько новинок: • ИИ-агент, который помогает писать запросы, строить дашборды и расследовать инциденты с использованием естественного языка. • Инструменты для динамического регулирования частоты сбора данных, что позволяет оптимизировать расходы на хранение телеметрии. • Добавлены новые источники данных, такие как MongoDB, Oracle, и Snowflake. • Расширенные функции управления доступом и соответствия требованиям для корпоративных клиентов. ➡️ Блог разрабов 🐸 Библиотека devops'a #пульс_индустрии

💬 Различия между Liveness, Readiness и Startup Probes Одним из популярных вопросов на собесе является вопрос про разницу между Liveness, Readiness и Startup пробы. Давайте разберёмся, что каждая из этих проб делает, когда и как их использовать. 1. Что такое Liveness Probe Цель: проверка, жив ли контейнер. Если контейнер не отвечает на пробу, Kubernetes перезапустит его. Когда использовать: всегда используйте Liveness пробу, чтобы обнаружить ситуации, когда приложение зависает или перестаёт функционировать. Это поможет Kubernetes перезапустить контейнер и избежать длительных сбоев. Пример: если ваше приложение зависает из-за дедлока или других внутренних проблем, Liveness проба поможет автоматически перезапустить контейнер. 2. Что такое Readiness Probe Цель: проверка готовности контейнера принимать трафик. Если контейнер не готов, Kubernetes не будет направлять трафик к этому контейнеру. Когда использовать: используйте Readiness пробу, когда приложению нужно время для инициализации, например, для подключения к базе данных или загрузки конфигураций. Пример: если веб-серверу нужно 10 секунд для подключения к базе данных, настройте Readiness пробу, чтобы Kubernetes не отправлял запросы до завершения этого процесса. 3. Что такое Startup Probe Цель: проверка того, успешно ли контейнер стартовал. Полезно для контейнеров с долгим временем старта. Когда использовать: используйте Startup пробу для контейнеров, которые требуют длительного времени для инициализации, чтобы избежать преждевременных перезапусков. Пример: если ваше приложение загружает большую модель машинного обучения, настройте Startup пробу, чтобы Kubernetes не пытался перезапустить контейнер до окончания загрузки. Опции конфигурации проб 1. initialDelaySeconds Указывает время, которое Kubernetes будет ждать после старта контейнера до первой проверки. Пример: если вашему приложению нужно 10 секунд для начала работы, установите initialDelaySeconds: 10. 2. periodSeconds Интервал между проверками после первой. Пример: если вы хотите проверять контейнер каждые 30 секунд, установите periodSeconds: 30. 3. failureThreshold Указывает, сколько последовательных неудачных проверок Kubernetes допускает до того, как перезапустит контейнер. Пример: если ваше приложение иногда теряет соединение, установите failureThreshold: 3, чтобы избежать перезапусков при временных сбоях. 4. timeoutSeconds Время, которое Kubernetes будет ждать от контейнера, прежде чем считать проверку неудачной. Пример: если приложение может задерживаться с ответом, установите timeoutSeconds: 5, чтобы дать достаточно времени на обработку запроса. Как избежать конфликтов при настройке проб Если настроены все три типа проб, важно убедиться, что они не конфликтуют. Например, если настроена Startup проба, то Liveness и Readiness пробы будут выполняться только после её успешного завершения. Это помогает избежать перезапуска контейнера на этапе инициализации, если приложение запускается медленно. 🐸 Библиотека devops'a #задача_со_звёздочкой

🇮🇹 В Италии есть свой X11 На реддите пользователь внезапно нашёл логотип X11 / Xorg — системы, через которую десятилетиями проходили все окна Linux. Но дело в логотипе, а в его расположении — на вывеске торгового центра. Почему он там оказался и кто в этом виновен история умалчивает. 💬 А вы встречали логотипы или названия IT-компаний в реальной жизни — не на конференциях, а случайно? 🐸 Библиотека devops'a #холиварня

💥 Весь октябрь -40% на курсы для разработчиков в proglib.academy Бери знания под свой стек: Python | алгоритмы | математика для Data Science | архитектура кода.

Пока одни ждут «идеальный момент», другие просто учатся. А потом берут ваши офферы.

⚡️ Пока скидка действует, апдейтни свои навыки

🐳 Что такое Dockerfile Dockerfile — это рецепт сборки Docker-образа. Он описывает, из чего и как собрать изолированную среду — будь то приложение, база данных или целая микросервисная система. Всё строится из простых инструкций:

FROM golang:1.22-alpine   # базовый образ
WORKDIR /app              # рабочая директория
COPY . .                  # копируем файлы
RUN go build -o main .    # собираем проект
CMD ["./main"]            # команда запуска

• FROM — задаёт базовый слой (например, ubuntu, node, golang) • WORKDIR — где выполняются команды • COPY / ADD — добавляют файлы внутрь контейнера • RUN — выполняет команды во время сборки • CMD / ENTRYPOINT — определяют, что запустится при старте контейнера • EXPOSE — сообщает, какие порты слушает контейнер • ENV — задаёт переменные окружения 1. Docker читает Dockerfile построчно. 2. Каждая команда создаёт слой в образе. 3. Эти слои кэшируются — поэтому повторная сборка идёт быстрее. 4. Готовый образ можно запускать как контейнер, передавая параметры и окружение. Что такое слой Каждый слой — это snapshot изменений файловой системы. На нашем примере: 1️⃣ FROM golang:1.22-alpine Docker берёт готовый базовый образ с Golang и Alpine Linux. Это уже несколько слоёв, собранных кем-то раньше: • минимальная система (Alpine) • системные библиотеки • установленный Go-компилятор Эти слои загружаются из Docker Hub и кэшируются локально. Все они read-only — вы их не меняете, просто используете как основу. 2️⃣ WORKDIR /app Создаётся новый слой, где внутри файловой системы появляется папка /app. Теперь все последующие команды будут выполняться именно в ней. Даже если она пуста, Docker фиксирует это изменение файловой структуры как отдельный слой. 3️⃣ COPY . . Docker копирует все файлы из текущей директории (build context) в /app контейнера. Результат — ещё один слой, где лежат исходники вашего проекта. Важно: если вы измените хоть один файл — хэш слоя поменяется, и этот шаг, а также все следующие пересоберутся заново. 4️⃣ RUN go build -o main . Docker запускает внутри контейнера команду go build. Она создаёт бинарник main прямо в /app. После завершения — создаётся новый слой, в котором лежит тот самый скомпилированный файл. Предыдущие слои (с исходниками, библиотеками и т.д.) остаются неизменными. 5️⃣ CMD ["./main"] Это не создаёт новый слой. CMD добавляет метаданные — какую команду Docker должен запустить, когда контейнер стартует docker run image_name. Dockerfile — это сердце контейнеризации. Без него не было бы reproducible-сборок, dev/test окружений и того самого works on my machine. 🐸 Библиотека devops'a #арсенал_инженера

🔍 50 фраз, из-за которых ваше резюме летит в корзину На первый взгляд может показаться, что фраза «пишу чистый код» звучит убедительно и серьезно — но на практике рекрутеры и скрининговые системы давно привыкают к таким штампам и игнорируют их как незначимые. ➡️ В статье про все клише, которые стоит убрать из резюме 🐸Библиотека devops'a

⚠️ Oracle EBS: zero-day Oracle выпустила экстренный патч для E-Business Suite версии 12.2.3–12.2.14. Уязвимость CVE-2025-61882 позволяла удалённое выполнение кода без аутентификации — достаточно открытого порта и доступа к BI Publisher. Эксплуатировалась в реальных атаках, включая кампанию группы Clop, которая крала корпоративные данные через Oracle EBS. Что делать девопсу в таком случае 1. Патчи безопасности нужно применять вне планового цикла, особенно в системах ERP-уровня. CI/CD-пайплайн должен поддерживать fast-lane patching: отдельный процесс для критических обновлений без фризов релиза. 2. Чтобы поставить этот патч, требуется предыдущий CPU-апдейт октября 2023 года. DevOps-команды должны отслеживать “dependency chain” патчей — иначе экстренное обновление просто не применится. 3. Даже после установки фикса: — анализируйте логи доступа к BI Publisher и Concurrent Processing; — внедрите мониторинг системных вызовов и сетевой активности (reverse shell, неожиданные соединения); — настройте оповещения SIEM на команды вроде bash -i или curl | sh ➡️ Новость 🐸Библиотека devops'a #разбор полётов

🧑‍💻 Используем NGINX как AI-прокси За последние годы мир AI расширился до множества провайдеров моделей (LLM), каждый со своими API. Чтобы упростить интеграцию, маршрутизацию и безопасность между приложениями и этими моделями, NGINX предлагает себя как лёгкий AI-прокси: он принимает запросы, трансформирует их (если нужно), маршрутизует, логирует и управляет отказами. Как это работает: • Если клиент шлёт запрос в формате OpenAI, но конечная модель — Anthropic, прокси с помощью NJS-скрипта преобразует вход («OpenAI → Anthropic») и выход обратно. • В конфигурации хранится JSON с правами пользователей: модель A доступна одному, модель B — другому. Прокси проверяет, есть ли у пользователя доступ к запрашиваемой модели. • Если запрос к основной модели неудачен, например, лимит или сбой API, прокси перенаправит на резервную модель по настройкам. • После получения ответа прокси извлекает статистику токенов: prompt, completion, total и записывает её в логи NGINX. Фрагмент конфига:

js_import /etc/njs/aiproxy.js;

server {
    listen 4242;
    default_type application/json;

    location /v1/chat/completions {
        set $aiproxy_user $http_x_user;
        js_content aiproxy.route;
    }

    location /openai {
        internal;
        rewrite ^ /v1/chat/completions;
        proxy_set_header Authorization 'Bearer ${OPENAI_API_KEY}';
        proxy_pass https://api.openai.com;
    }
    location /anthropic {
        internal;
        rewrite ^ /v1/messages;
        proxy_set_header x-api-key ${ANTHROPIC_API_KEY};
        proxy_pass https://api.anthropic.com;
    }
}

Прокси может подгружать права доступа из файла rbac.json, использовать настройки failover и преобразовывать запросы и ответы. ➡️ Блог NGINX 🐸Библиотека devops'a #арсенал_инженера

⚙️ Как получить середину файла в Bash Команды head и tail отлично показывают начало и конец файла. Но иногда нужно не первое и не последнее — а что-то из середины: фрагмент лога, центр дампа или середину отчёта. body специально создан для того, чтобы показать центральные строки файла — с настройками контекста, подсветкой, номерами строк и именами файлов. Пример:

body -C5 app.log

Скрипт найдёт середину файла 🐸Библиотека devops'a #арсенал_инженера

😊 Вопрос или анекдот Напоминаем, что у нас есть гугл-форма, в которой можно задать вопрос сообществу или поделиться историей или рассмешить админа свежим анекдотом. Анекдоты по теме девопсинга могут попасть в отдельную подборку. 🐸Библиотека devops'a #dev_null

🐧 Осенние апдейты Сразу несколько дистрибутивов отметились обновлениями. — 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-инженерам, а также всем, кто интересуется облачными технологиями. ➡️Зарегистрироваться