Диски не растут без предела

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

• Внутренний реестр хранит две сборки на контейнер, удаляет сборки удалённых источников и перестаёт принимать новые сборки, когда его диск заполнен на 90%.
• Docker-узлы удаляют образы, которые никто не использовал 12 часов. У каждого контейнера остаётся образ, на котором он работает, и один для отката.
• Логи контейнеров на Docker-узлах ограничены по размеру, в том числе у контейнеров, созданных до Opfield или в обход него. Nginx-узлы держат логи маршрутов в пределах лимита и удаляют логи удалённых маршрутов.
• WAL и слоты репликации Postgres больше не заполняют диск базы.
• Housekeeping держит собственные данные Opfield в пределах, даже когда он выключен, и запускается сразу, как только диск Opfield заполнен на 90%. Он же показывает, чем занят каждый диск: самые большие таблицы, Redis, логи контейнеров и старые образы на каждом узле.

Новые встроенные алерты предупреждают заранее: заполнение диска на 85% (для каждого диска данных узла), переполненный диск Opfield, переполненный диск базы данных и остановившийся Housekeeping.

Защита консоли для агентов

Ассистент и MCP-клиенты могут выполнять команды в консоли узла. Команды выполняются от root, так что агент действительно может починить узел. Но Docker, containerd и Podman в этой консоли скрыты: команда с Docker отклоняется, а в ответе указан инструмент Opfield, которым нужно воспользоваться.

Это защита от случайностей, а не граница безопасности. Она не даёт агенту по ошибке изменить управляемый контейнер в обход Opfield. Кроме того, агенты больше не могут выполнять команды по SSH на хостах, которые являются узлами Opfield.

Если управляемый контейнер всё же остановят, изменят или удалят вручную, сработает новый встроенный алерт «Container changed outside Opfield» с пояснением, что это значит.

Порядок правил в списках доступа

Правила списка доступа проверяются сверху вниз, срабатывает первое совпадение. Раньше порядок нельзя было поменять, и разрешающее правило, добавленное после широкого запрета, не срабатывало никогда. Теперь правила можно переставлять в интерфейсе, через API и MCP, а правила, которые никогда не сработают, помечаются.

Порядок переключения баз данных и хранилищ

Для управляемых Postgres, key-value хранилищ, ClickHouse и S3-хранилищ с доступностью теперь можно задать порядок переключения: какой сервер первым берёт работу на себя, если основной упал.

Реестр в S3

Внутренний реестр может хранить данные в S3, а не на диске хоста Opfield. При смене хранилища проверяется каждый образ, который реестр держит для рабочих нагрузок.

Pages и страницы ошибок

Проекты Pages отдают собственный 404.html для несуществующих путей, со статусом 404.

Все страницы, которые nginx генерирует сам (ошибки, отказ в доступе, недоступный upstream, сервер по умолчанию), теперь оформлены как страницы Opfield. Собственные страницы ошибок ваших приложений проходят без изменений.

Git-источники

• Контейнер с Git-источником можно откатить на предыдущую сборку: на вкладке Source, через API или MCP.
• Упавшая сборка показывает шаг Dockerfile, на котором она упала, и код выхода, а источник объясняет, почему сборка не удалась или ничего не развернула.
• Переменные окружения, секреты и тома можно задать до первой сборки, а первая сборка запускается сразу.
• Политика безопасности сборок может блокировать только уязвимости, для которых есть исправление, — для пакетов приложения или для всех пакетов.

Ещё в этом релизе

Маршруты за Cloudflare видят настоящий IP клиента в списках доступа, лимитах запросов и логах. Управляемый Postgres работает на собственных образах Opfield, а PostGIS и pgRouting ставятся по запросу на вкладке Extensions.

Что важно знать перед обновлением: архивы контейнеров теперь в формате Opfield (.ofca). Архивы, выгруженные предыдущими версиями, импортировать нельзя.

Self-hosted-инсталляции обновляются как обычно. Управляемые облачные инсталляции обновятся в своё окно обслуживания.

Что вы получаете

Управляемая инсталляция — это полноценный Opfield той же версии, что и self-hosted, по адресу <name>.opfield.cloud. Она покупается и управляется в аккаунт-портале вместе с платным лицензионным ключом (Personal, Business или Enterprise). С Community она недоступна.

• Регион: Финляндия. Германия в планах.
• Вход через аккаунт Opfield. Владелец входит в инсталляцию тем же аккаунтом, что и в портал.
• Ежедневные бэкапы. Бэкап делается каждый день, его можно сделать и вручную, а восстановление запускается из портала. После удаления последний бэкап хранится ещё несколько дней, так что инсталляцию можно вернуть.
• Обновления в ваше окно обслуживания. Вы выбираете день и час (UTC). Opfield делает бэкап, обновляется и возвращается уже на новой версии. Можно обновиться и сразу.
• Узлы остаются вашими. Свои серверы вы подключаете одноразовыми токенами из портала. Рабочие нагрузки, базы и хранилища работают на них, а не на управляемой ВМ.

Тарифы

Цены указаны за месяц, сверх лицензионного ключа, и продлеваются вместе с ключом.

Двенадцать месяцев стоят как одиннадцать. Перейти со Standard на Extended можно в любой момент, доплатив разницу за остаток периода; Opfield один раз перезапустится. Переход на меньший тариф происходит в конце оплаченного периода.

Почта включена

Opfield отправляет системные письма: коды входа, ссылки для установки и сброса пароля, приглашения. Self-hosted-инсталляции для этого нужен SMTP-провайдер. Управляемая инсталляция отправляет их сразу, с адреса <name>@mail.opfield.cloud, на обоих тарифах и без доплаты.

Лимитов с запасом хватает для системной почты, а репутация общего отправителя остаётся чистой:

• Standard: 500 писем в месяц, 50 в день, 25 в час.
• Extended: 2000 в месяц, 200 в день, 50 в час.

Свой домен

Инсталляция может отвечать на вашем домене, например ops.example.com. Добавьте домен на странице инсталляции, создайте указанную там CNAME-запись, и Opfield получит для него сертификат. Адрес на opfield.cloud продолжит работать. Ключи доступа (passkeys) привязаны к адресу, поэтому после смены их нужно добавить заново — страница предупредит об этом заранее.

ИИ включён

В Opfield есть встроенный ИИ-ассистент и MCP-сервер для ваших агентов. Обоим нужна модель. На управляемой инсталляции Opfield Cloud AI уже подключён:

• Free — с каждой управляемой инсталляцией: использование моделей включено.
• S — $9 в месяц.
• M — $29 в месяц, вдвое больше использования, чем в S.

Моделей две: Opfield Swift для быстрых повседневных задач и Opfield Heavy для длинных и сложных. Использование показывается в процентах для каждого окна, вместе со временем сброса. Когда окно исчерпано, ассистент об этом скажет и снова заработает после сброса. Всё остальное в Opfield продолжает работать.

Как начать

В аккаунт-портале включите «Host it in our cloud» при покупке ключа или нажмите «Add managed cloud» на странице уже купленного ключа. После оплаты инсталляция настраивается автоматически, а когда она будет готова, придёт письмо. Тарифы и цены есть и на странице с ценами.

Те же правила, что и для человека

Отдельной модели прав для агентов нет. MCP-клиент подключается к https://<your-opfield>/api/mcp и входит через OAuth от имени пользователя. На экране согласия пользователь выбирает, какие права получит клиент, и эти права никогда не превышают его собственные. Доступ, ограниченный папками, узлами или отдельными ресурсами, работает так же: агент с доступом к папке одного приложения видит только её. Агент может вызвать get_my_access и узнать, что ему выдано и где он может создавать ресурсы.

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

MCP-эндпоинт принимает только OAuth-токены, выпущенные для него; токены REST API там не работают. Кроме того, у пользователя должно быть право на MCP, так что администратор решает, кому вообще можно подключать агентов.

Всё попадает в журнал аудита

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

Защита от случайностей

Права определяют, что агенту можно. Но некоторые ошибки случаются и в рамках прав, поэтому в Opfield есть дополнительные предохранители:

• Защита консоли. Агенты могут выполнять команды в консоли узла от root и чинить узел. Docker, containerd и Podman там скрыты, а команда с Docker отклоняется с указанием инструмента Opfield, который нужно использовать. Это защита от случайностей, а не граница безопасности: она не даёт агенту изменить управляемый контейнер в обход Opfield.
• Без SSH на узлы. Агенты не могут выполнять команды по SSH на хостах, которые являются узлами Opfield. Для этого есть консоль узла с защитой.
• Изменения в обход Opfield видны. Если управляемый контейнер всё же остановят, изменят или удалят вручную, сработает встроенный алерт «Container changed outside Opfield».
• Безопасные повторы. Операции создания принимают ключ идемпотентности, поэтому агент, повторивший запрос после таймаута, не создаст дубликат.

Инструменты Docker вместо shell

Большая часть работы агента с нагрузками идёт через отдельные инструменты, а не команды shell: список контейнеров на всех Docker-узлах, логи и метрики, перезапуск, обновление образа, настройка, деплойменты со слотами и откатом, Compose-проекты, тома, сети и Git-источники со сборками. Поскольку это операции Opfield, маршруты, Secure Links и доступность после изменения остаются согласованными, а каждый шаг попадает в аудит.

Перед изменениями агенты могут прочитать документацию и навыки Opfield прямо через MCP.

Пример: сервис падает

Пользователь пишет агенту: «Billing API с утра отвечает 502. Разберись и почини». Типичная сессия:

1. find_resource находит маршрут и контейнер за ним; get_route показывает upstream.
2. get_docker_container показывает, что контейнер постоянно перезапускается, а его Git-источник в 07:40 развернул новую сборку.
3. get_docker_container_logs показывает, что процесс завершается при старте: не хватает новой обязательной переменной окружения.
4. Агент сообщает об этом и предлагает два варианта: откатиться на предыдущую сборку или добавить переменную.
5. Пользователь выбирает откат. Агент вызывает manage_docker_source с rollback, затем снова проверяет логи и маршрут: контейнер работает, маршрут отвечает 200. Откат виден в журнале аудита под именем пользователя.

Никому не понадобился shell-доступ к серверу, и агент не вышел за пределы прав самого пользователя.

Как начать

Добавьте MCP-сервер в свой клиент, указав адрес вашего Opfield, войдите и выберите права. Начните с прав только на чтение, посмотрите в журнале аудита, что делает агент, и расширяйте доступ по мере появления уверенности. Если не хочется настраивать клиент, встроенный в Opfield ассистент использует те же инструменты и те же правила.