🧑‍💻 Используем 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

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

⚡️ Grafana на ObservabilityCON

На ObservabilityCON 2025, прошедшей с 7 по 9 октября, Grafana Labs представила несколько новинок:

• ИИ-агент, который помогает писать запросы, строить дашборды и расследовать инциденты с использованием естественного языка.

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

• Добавлены новые источники данных, такие как MongoDB, Oracle, и Snowflake.

• Расширенные функции управления доступом и соответствия требованиям для корпоративных клиентов.

➡️ Блог разрабов

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

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

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

#пятничный_деплой

💻 Вакансия недели

У нас в канале много интересных вакансий. Вот одна из них:

Нужен Senior SRE с опытом администрирования Linux от трёх лет. Обязательно: опыт администрирования MySQL и Kubernetes. Удалёнка и от 300 000 ₽.

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

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

🐳 Как работает Docker изнутри

Docker Client отправляет команды docker build, docker pull, docker run Docker демону, который работает на Docker хосте. Демон отвечает за создание и запуск контейнеров, а также за загрузку образов из Docker Registry, например, Docker Hub или других репозиториев.

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

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

#архитектура_на_салфетке

🧩 Microsoft Defender перепутал версии SQL Server

Microsoft подтвердили баг, из-за которого встроенный Microsoft Defender начал ошибочно помечать SQL Server 2017 и 2019 как End-of-Life.

Алгоритм решил, что поддержка закончилась, хотя в реальности SQL Server 2019 жив до 2030 года, а 2017 — до 2027.

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

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

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

#пятничный_деплой

🖥 JSON Crack — визуализируйте данные

JSON Crack — это сервис сразу превращает данные в наглядное дерево: можно раскрывать узлы, искать нужные поля и экспортировать схему как изображение. Всё работает прямо в браузере — без отправки данных на сервер.

Кроме JSON поддерживаются YAML, XML, CSV и TOML. Есть валидатор, конвертер и генератор типов для TypeScript и Go. Отличный инструмент, если нужно быстро разобраться в структуре API или объяснить коллегам, как устроен ответ сервера.

➡️ Визуализировать свой JSON

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

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

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

О чем спорили и размышляли.

— Вышел OpenSSH 10.2

Исправления критических ошибок, влияющих на использование ControlPersist и поддержка PKCS#11.

— Обновления дистрибутивов

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

— Grafana на ObservabilityCON

— Microsoft Defender начал ошибочно помечать SQL Server 2017 и 2019 как End-of-Life

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

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

⚙️ Структурный diff, который понимает код

Разбор изменений скриптов и быстрая интеграция pull request-ов — часть ежедневной рутины. Классические diff-утилиты путаются в кавычках, списках и многострочных изменениях, а ручное разрешение конфликтов ­чаще раздражает, чем помогает.

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

Он построен на базе tree-sitter — парсера, поддерживающего десятки языков программирования, и анализирует файлы на уровне синтаксиса.

Пример использования:

difft simple_1.js simple_2.js

или для git:

difft git main feature-branch

➡️ Сравнить файлы

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

#root@prompt

🛠 Bun 1.3 упрощает деплой JS-приложений

Bun 1.3 решает несколько проблем, с которыми DevOps сталкивается при работе с Node.js-приложениями. Разберём, какие фичи добавили.

Главная фича для деплоя — компиляция в standalone executable. Вместо образа с Node.js, npm install и гигабайтом зависимостей получаете один бинарник:

bun build --compile ./app.ts --outfile myapp

Также кросс-компиляция из коробки, собираете на CI под все платформы:

bun build --compile --target=linux-x64 ./app.ts --outfile app-linux
bun build --compile --target=darwin-arm64 ./app.ts --outfile app-macos
bun build --compile --target=windows-x64 ./app.ts --outfile app.exe

Не нужно тащить драйверы для PostgreSQL, MySQL, SQLite и Redis. Всё встроено, zero dependencies:

import { sql, redis } from "bun";

await redis.set("cache_key", data);
const users = await sql`SELECT * FROM users`;

В версии 1.3 снизили потребление памяти на 10-30% для популярных фреймворков (Next.js -28%, Elysia -11%). Idle CPU тоже оптимизировали — приложение не жрёт процессор в режиме ожидания.

➡️ Подробнее про обновление

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

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