🎓 Какая разница у бакалавра и самоучки

Университетские курсы по DevOps? Почти не существует. CS-программы учат алгоритмы, структуры данных, иногда сетевые основы. Всё полезно, но… попробуйте найти в типичном универе лекцию по Kubernetes, Terraform или GitOps.

Поэтому DevOps-инженеры чаще всего — самоучки. Учебники заменяет документация AWS и GitHub-репозитории с примерами. Реальные навыки приходят через «сгоревший прод», ночные деплои и баги в пайплайне.

Но спор никто не забывал. Одни говорят:

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

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

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

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

🐸Библиотека devops'a

#холиварня

💼 Золото, а не вакансии

Для вас самый сок из нашего канала с вакансиями:

Полмиллиона за SRE/DevOps'a

DevOps Engineer на Кипр

🐸Библиотека devops'a

#вакансия_недели

🐙 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

#пульс_индустрии

🚨 570 ГБ данных утекают из GitLab

Группа Crimson Collective заявила о похищении ~570 ГБ данных из внутреннего GitLab-инстанса Red Hat, используемого подразделением консультационных услуг. В числе утечек — отчёты клиентов (CERs), конфигурации и внутренние коммуникации.

В Red Hat подтвердили инцидент, пояснив, что взлом затронул GitLab-инстанс, используемый только в рамках подразделения консультационных услуг, и что инстанс не был публичным сервисом Red Hat.

Ошибки и слабые стороны

• Держать в одном месте огромное количество внутренних репозиториев, включая отчёты клиентов и конфигурационные материалы — всегда риск.

• По заявлению злоумышленников, они пытались связаться с Red Hat с требованием выкупа, но получили шаблонный ответ и инструкцию подать отчет об уязвимости. Заявляется, что тикет непрерывно переназначался.

• Компания утверждает, что после обнаружения приступила к изоляции и принятию мер. Но вопрос: как быстро был установлен сам факт вторжения? Если задержка была ощутимой — ущерб мог быть намного больше.

Что можно сделать

• Каждому пользователю и процессу нужно давать максимально ограниченный доступ: только то, что требуется прямо сейчас. Да, это налагает нагрузку на управление, но снижает риск масштабной кражи данных.

• Слежка за нехарактерной активностью, анализ аномалий, срабатывания по подозрительным запросам, частотам доступа, скачиваниям.

• Даже если данные украдены, шифрование может сделать их бессмысленными для злоумышленников.

• Клиенты, чьи данные могли быть скомпрометированы, должны быть уведомлены. Лучше быть честным и открытым.

➡️ Источник

🐸Библиотека devops'a

#разбор_полётов

🤔 Нетривиальный вопрос с собеседования

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

Что происходит в 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

#задача_со_звёздочкой

🆕 Материалы недели

Вспоминаем что было за эту неделю кратким дайджестом.

— Linux 6.17

— Конец эпохи диалап

— Как вайб-кодинг меняет рынок IT-образования

— Вышел релиз-кандидат Argo CD 3.2.0

— Утечка у Red Hat

🐸Библиотека devops'a

#дайджест_недели

✨ Итоги недели

Вспомните самый яркий момент или открытие последних дней. Может, это была неожиданная новость, полезный туториал или просто интересная идея? Расскажите, чем вдохновились или что заставило задуматься.

Ждём вас в комментах 👇

🐸Библиотека 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

🐧 Осенние апдейты

Сразу несколько дистрибутивов отметились обновлениями.

— 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

#пульс_индустрии

😊 Вопрос или анекдот

Напоминаем, что у нас есть гугл-форма, в которой можно задать вопрос сообществу или поделиться историей или рассмешить админа свежим анекдотом. Анекдоты по теме девопсинга могут попасть в отдельную подборку.

🐸Библиотека devops'a

#dev_null

⚙️ Как получить середину файла в Bash

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

body специально создан для того, чтобы показать центральные строки файла — с настройками контекста, подсветкой, номерами строк и именами файлов.

Пример:

body -C5 app.log

Скрипт найдёт середину файла

🐸Библиотека 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

#арсенал_инженера

⚠️ 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

#разбор_полётов

🔍 50 фраз, из-за которых ваше резюме летит в корзину

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

➡️ В статье про все клише, которые стоит убрать из резюме

🐸 Библиотека devops'a

🐳 Что такое 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

#арсенал_инженера

🇮🇹 В Италии есть свой X11

На реддите пользователь внезапно нашёл логотип X11 / Xorg — системы, через которую десятилетиями проходили все окна Linux.

Но дело в логотипе, а в его расположении — на вывеске торгового центра. Почему он там оказался и кто в этом виновен история умалчивает.

💬 А вы встречали логотипы или названия IT-компаний в реальной жизни — не на конференциях, а случайно?

🐸 Библиотека 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

#задача_со_звёздочкой