DevOps *

Привет! Я Владимир Мокроусов, сисадмин в группе компаний «Синтека». Мы создаем софт для строительной отрасли и активно используем в работе ИИ-модели. 

Недавно мы сделали единый доступ к моделям на базе LiteLLM. В статье расскажу, как собрали эту схему, на какие грабли наступили с лимитами и блокировками и что пришлось контролировать, чтобы всё работало.

Пять минут на ручной пинг, десять — на поиск релизного чек‑листа, еще день — на MR, о котором все забыли. По отдельности это мелочи. Вместе — заметная часть time‑to‑market.

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

Разработка при этом может идти быстро. Time‑to‑market растягивается в паузах: между аналитикой и разработкой, разработкой и тестированием, в ожидании ревью и согласований.

Представьте ситуацию: вы в одиночку или вместе с командой запускаете своё приложение или сервис, и через какое-то время инструмент, с которого вы стартовали для проверки гипотезы (например, тот же Lovable) становится тесен. Это значит, что пора переходить на другой. Но какой? Vercel? Railway? Fly.io? Porter? Или всё же остановить свой выбор на Heroku? Эти платформы обещают примерно одно и то же — «просто дай код, нажим кнопку, чтобы задеплоить, а мы разберёмся». И уже потом внезапно оказывается, что один инструмент не подходит под ваш профиль трафика, у другого философия релизов не ложится на культуру команды, у третьего управляемая БД — это на самом деле не совсем managed.

Герои магии и меча этой статьи: Heroku, Vercel, Fly.io, Railway и Porter. Они появлялись на рынке именно в этом порядке, и такая последовательность отражает то, как менялись подходы к построению приложений за последние пятнадцать лет. Каждая платформа в своё время решала конкретную боль индустрии, и это намертво вшито в архитектуру решения.

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

В Docker Desktop 4.86 пункт Docker VMM в настройках остался прежним, а движок под ним поменялся целиком: с версий 4.35–4.85 за ним стоял libkrun, с 4.86 собственный гипервизор Docker. Публичная бета анонсирована 12 августа, доступна на Mac и Windows.До этого Docker Desktop всегда опирался на чужой VMM: libkrun на технике Apple, Hyper-V или WSL на Windows, а Linux-версия собрана на KVM и QEMU.

Отсюда и разница в поведении между платформами, которую все давно принимают как данность.

Недавно я рассказывал про Sheeternetes — оркестратор, у которого control plane живёт в таблицах. Здесь — про следующий логичный шаг: паттерн «оператор», применённый к самим таблицам. Настоящий полноценный Sheeternetes-оператор. Не скрипт внутри таблицы, а внешний контроллер, который приводит табличку к желаемому состоянию.

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

Приветствуем, Хабр.

У нас вышла долгожданная новинка, посвящённая методологии «SRE» — Site Reliability Engineering. Книга называется «SRE. Новый подход к управлению инфраструктурой». Написал эту книгу выдающийся инженер Павел Рудницкий, автор «Инфраструктурного блога», разработчик с 25-летним стажем, практиковавший DevOps, когда это ещё не было мейнстримом.

Как многие из вас знают, искусство SRE зародилось в компании Google приблизительно в середине нулевых, суть его заключается в обеспечении бесперебойной работы сайтов и сервисов даже в условиях частичных отказов, текущего ремонта и в процессе выкатывания обновлений.

Пошаговое руководство по развертыванию JupyterLab на GPU-сервере. Рассказываем про настройку JupyterHub, драйверов NVIDIA, безопасности (Nginx/SSL), лимитов ресурсов и мониторинга.

Мониторинг зелёный, балансировщик отвечает, сертификат на месте — а пользователи пишут, что портала нет. Через сорок минут выясняется: часть клиентов получает новый адрес, часть — старый. Разъехался DNS. Разбираемся, почему резолвер стоит считать частью контура управления доступом, а не подписью к IP.

Хабр, привет! Есть такой тип проектов, которые начинаются со слов «а что если» и заканчиваются тем, что ты в три часа ночи объясняешь kubelet-у, что таблица — это его новый control plane. Так вышло и тут, всё родилось из субботней шутки в одном телеграм-канале по кубернетесу.

Правила игры простые: раз весь мир можно создать в эксельке, то пускай всё состояние кластера живёт внутри электронной таблицы. Не «метаданные в таблице», не «экспорт в CSV» — а буквально: Deployments, Nodes, Pods, Events — это вкладки Google Sheets (или листы Excel). Планировщик читает и пишет ячейки. kubectl-подобная утилита ходит в таблицу. И — вот это ключевое — на другом конце крутятся настоящие Docker-контейнеры. Таблица не симулирует кластер. Таблица и есть кластер.

Проект называется Sheeternetes. Это, конечно, шутка. Но шутка, которая компилируется, проходит тесты и переживает падение ноды.

Ниже — как это устроено, как это поднять у себя за пять минут, как оно работает на bare metal без интернета (в Excel и LibreOffice), как связать несколько таблиц-кластеров в федерацию с живой миграцией, почему контейнеры можно хранить прямо в ячейках, — и что это внезапно выросло в целый фонд с 30 проектами, стандартом контейнеров и системой сертификации.

Обычный вечер понедельника. Я уже собирался уходить домой после работы, как вдруг зацепился за разговор коллег о неком Gemini Notebook. Стало интересно, что это, как люди им пользуются, а главное — надо ли оно мне. Глянул пару обзорных видео, послушал про его плюсы, чудеса и все такое прочее, но больше всего зацепил меня тезис о том, что окно контекста у этой штуки — миллион токенов. Вечер перестал быть томным.

Привет, Хабр! Меня зовут Вадим Гартман, я бэкенд-разработчик в Selectel. Недавно стал одним из ответственных за поддержку terraform-provider со стороны выделенных серверов, при том что ранее работал вообще в другом направлении. Я старался быстро влиться в проект, и будто бы ИИ-RAG-инструмент, способный обрабатывать и анализировать структуры огромных монолитов, появился очень кстати.

В общем, мы с Gemini Notebook встретились в странный период моей жизни. А что из этого вышло — читайте в этой статье.

Проверял, что видно про домен заказчика снаружи, и выписал имена из журналов Certificate Transparency. В списке оказались jenkins, gitlab-runner и пара стендов с именами вида test-2 — ни одного из них в публичном DNS не было.

Имя знает не только команда. Его знает весь интернет, причём с того момента, как вы выпустили на этот хост TLS-сертификат.

Разговор с Claude Code остаётся на той машине, где начат. Разбираю, почему облачная папка эту задачу не решает, и шесть граблей, на которые я наступил, пока делал перенос сессий, памяти и инструментов между Linux, Windows и macOS.

Разговор о том, кто на самом деле контролирует облако, часто начинается с регионов: где выполняется рабочая нагрузка и где хранятся её данные. Но выбор региона — только часть картины, архитектура платформы значит ровно столько же. Особенно важно, как она разделяет между кластерами ответственность за управление, исполнение, сборку и наблюдаемость.

Недавняя публикация сообщества CNCF, «От резидентности данных к цифровому суверенитету: архитектурные паттерны для cloud native-платформ», хорошо это обосновала. Под такими режимами, как EU Data Act, NIS-2, DORA и UK Data (Use and Access) Act, платформенным командам теперь приходится показывать не только то, где выполняются рабочие нагрузки. Нужно показать и то, как платформу эксплуатируют, защищают и по каким правилам ею распоряжаются, вплоть до плоскости управления.

Та статья изложила требования и представила паттерн «кластер на тенант» как один из способов провести границы изоляции. Команда VK Cloud перевела статью, в которой на те же требования смотрят под другим, но дополняющим углом: что происходит, если считать контроль над платформой свойством топологии её плоскостей. В качестве примера, который можно изучить самому, авторы берут OpenChoreo, внутреннюю open source-платформу разработки и проект CNCF Sandbox. Впрочем, сами архитектурные идеи применимы широко.

Привет, Хабр! Меня зовут Завур, я фронтенд-разработчик в Selectel. Каждый день я работаю в привычной многим среде разработки VS Code. Однако в личных проектах, которые создаю для исследования новых инструментов и методов написания кода, часто использую Cursor.

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

Давайте посмотрим, как на практике выглядит реализация идеи с помощью Devin, и попробуем разобраться, действительно ли перед нами потенциальный конкурент Cursor.

Любой, кто ставил софт в Linux, набирал apt install или pacman -S. Внешне разница косметическая: одни команды длинные, другие короткие. Но за этими командами стоят две принципиально разные инженерные философии.

Почему pacman ощутимо быстрее, но при этом опаснее в руках новичка? Почему Arch категорически запрещает частичные обновления, а Debian их даже не замечает? И почему один менеджер задаёт вопросы про конфиги, а другой молча подкладывает .pacnew?

Разбираем, что происходит внутри при установке пакета: форматы архивов, базы данных, решатели зависимостей, скрипты и хуки. Погружаемся в устройство apt/dpkg и pacman/libalpm глубже, чем в большинстве туториалов.

Падает один шлюз - и дежурному прилетает пачка уведомлений: молчат хосты за ним, гаснет uptime-монитор, срабатывают метрические пороги, горит SLO. Событие одно, уведомлений десятки. Разбираю, как собрать такой каскад в одну карточку инцидента и почему наивная реализация ломается: почему группировать надо по верхнему упавшему предку, а не по прямому родителю; что делать, когда события приходят в обратном порядке; почему “молчит, потому что за него сказал корень” и “не эскалируется, потому что родитель лежит” - это два разных состояния, которые нельзя склеивать; и где в такой системе обязательно выбирать шум вместо тишины. С кодом обхода графа, схемой таблиц и списком граблей.

29 августа Anthropic разослала еженедельный дайджест по Claude Code. Пересказ на русском: /resume подхватывает терминальную сессию в десктопном приложении, сессию на своей машине можно запустить с телефона через Remote Control, субагенту можно дать собственную память между сессиями строкой memory в frontmatter, а /color и /rename помогают различать несколько открытых терминалов. Плюс версии 2.1.243–2.1.248: режим --restricted, автоматический баг-репорт, редактирование правил авторежима из /permissions, часовой prompt cache, zstd-сжатый бинарник CLI и починенные десктопные сессии.

Статья посвящена завершению поддержки ingress-nginx и рассматривает это событие не просто как необходимость заменить один Kubernetes-компонент на другой, а как повод пересмотреть архитектуру маршрутизации в Kubernetes-платформе. В статье показано, как со временем простой Ingress превращается в набор NGINX-specific annotations и накопленного технического долга, который сложно поддерживать и объяснять. Так же разбираются возможности Gateway API, разделение ответственности между Platform-командой и разработчиками, а также подходы к миграции существующей инфраструктуры. Особое внимание уделяется аудиту текущих Ingress, постепенному внедрению новой модели и отказу от массовой миграции ради миграции. Основная идея статьи — не просто перенести сотни Ingress в HTTPRoute, а использовать изменения для построения более понятной, управляемой и масштабируемой Kubernetes-платформы.

В рабочем чате: «Сайт не открывается, сертификат истёк», следом — скриншот с 502. Первый рефлекс — certbot renew и перезагрузить nginx. Иногда помогает. Иногда сайт после этого не поднимается совсем.

Дело в том, что «всё из-за сертификата» — это на самом деле две разные поломки с разными решениями: сертификат не продлился или продлился, но сервер отдаёт старое. В выдаче их валят в кучу, поэтому советы вроде «просто сделай certbot renew» либо не помогают, либо роняют сайт по-настоящему.

Разбираем по шагам: как за десять минут понять, какая из двух у вас, вернуть HTTPS и настроить продление так, чтобы это не повторилось.

Один и тот же артефакт разворачивается монолитом и кластером микросервисов. Те же модули, один дашборд на все воркеры, горячая замена без рестарта контейнера.

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

Обычно эту плоскость собирают заново: Prometheus, Grafana, самописный health-контроллер, скрипт деплоя, чат-бот для рестартов. Времени уходит столько же, сколько на сам распил.

redb.Tsak предлагает другой обмен: плоскость эксплуатации живёт в рантайме, и она одна и та же независимо от того, запущен у вас один воркер или девять. Кластер, дашборд, REST API, CLI, пробы, метрики и трассировка не зависят от выбранной топологии. Вы решаете, как нарезать процессы, а не как их потом обслуживать.

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