Обновления, резервное копирование и восстановление

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

До выбора частоты копирования и окна обновления определите целевую точку восстановления — допустимую потерю данных — и целевое время восстановления. Критерий успеха — проверенное восстановление, а не просто наличие архивных файлов.

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

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

Создавайте резервные копии следующих компонентов:

PostgreSQL;
постоянные тома с артефактами и конфигурацией Opfield;
ключи шифрования и главные ключи PKI;
том с идентичностью Relay;
резервные копии баз данных, созданные средствами их движков;
конфигурация внешних DNS, поставщика идентификации, электронной почты, реестра и SIEM, которая хранится вне Opfield.

Проверка восстановления должна подтвердить вход, расшифровку, повторное подключение нод, авторизацию Relay, работу Routes и сертификатов, привязки управляемых баз данных и непрерывность аудита. Резервная копия, которую ни разу не восстанавливали, не является планом восстановления.

Данные баз данных не входят в этот набор. На тарифах Personal и выше резервное копирование баз данных создаёт по расписанию штатные резервные копии управляемых и внешних баз PostgreSQL, Redis и ClickHouse в подключённом хранилище; на Community, а также для движков, которым нужно восстановление на момент времени, используйте штатные средства движка. См. Управляемые и внешние базы данных: сравнение.

Встроенные функции и дорожная карта

Подключения к хранилищам и управляемое объектное хранилище, а также резервное копирование и восстановление баз данных доступны в 2.11 на тарифах Personal и выше. Экспорт конфигурации Opfield для переноса на другой экземпляр ожидается в 2.12 на всех тарифах; это ориентир дорожной карты, а не доступная сегодня операция.

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

Соберите комплект восстановления

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

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

Комплект восстановления для ручной установки Compose

В ручном установщике используются службы app, relay, registry, postgres и redis, а также следующие постоянные тома:

Том	Для чего он нужен при восстановлении
`postgres_data`	пользователи, ресурсы, желаемое состояние, Tasks и метаданные аудита
`gateway_data`	загруженные артефакты, сгенерированная конфигурация, TLS и состояние приложения
`gateway_relay_identity`	идентичность локального Relay, общая для `app` и `relay`
`gateway_relay_state`	рабочее состояние локального Relay
`gateway_registry_data`	слои и манифесты приватного реестра
`gateway_registry_auth`	материалы подписи токенов реестра
`redis_data`	постоянное состояние Redis; полезно для согласованного полного восстановления, но не заменяет PostgreSQL

Сохраните также .env и использованный файл docker-compose.yml; и установщик, и ручная установка хранят его рядом с .env, при установке скриптом — по умолчанию в /opt/gateway. В .env находятся критичные для восстановления секреты: шифруйте его резервную копию отдельно и не прикладывайте к обращениям в поддержку.

Следующий пример создаёт короткое окно согласованной офлайн-копии. Выполняйте команды из каталога с ручным Compose-файлом:

mkdir -p gateway-recovery/{gateway_data,gateway_relay_identity,gateway_relay_state,gateway_registry_data,gateway_registry_auth,redis_data}
cp .env docker-compose.yml gateway-recovery/
chmod 700 gateway-recovery
chmod 600 gateway-recovery/.env

docker compose -f docker-compose.yml stop app relay registry
docker compose -f docker-compose.yml exec -T postgres \
  pg_dump -U gateway -d gateway -Fc > gateway-recovery/postgres.dump
docker compose -f docker-compose.yml stop redis
docker compose -f docker-compose.yml cp --archive app:/var/lib/gateway/. gateway-recovery/gateway_data/
docker compose -f docker-compose.yml cp --archive app:/var/lib/gateway-relay/. gateway-recovery/gateway_relay_identity/
docker compose -f docker-compose.yml cp --archive relay:/var/lib/gateway-relay/state/. gateway-recovery/gateway_relay_state/
docker compose -f docker-compose.yml cp --archive registry:/var/lib/registry/. gateway-recovery/gateway_registry_data/
docker compose -f docker-compose.yml cp --archive app:/var/lib/gateway-registry-auth/. gateway-recovery/gateway_registry_auth/
docker compose -f docker-compose.yml cp --archive redis:/data/. gateway-recovery/redis_data/
docker compose -f docker-compose.yml start redis registry app relay

Перенесите gateway-recovery в зашифрованное хранилище вне хоста и проверьте там контрольную сумму. Этот пример не копирует базы данных на нодах хранилища — для данных приложений используйте штатные средства соответствующего движка.

Для восстановления на чистом совместимом хосте сначала верните .env и тот же Compose-файл, создайте остановленные Containers, скопируйте постоянные данные, запустите PostgreSQL и импортируйте дамп, а затем запускайте остальной контур управления:

docker compose -f docker-compose.yml create

docker compose -f docker-compose.yml cp --archive gateway-recovery/gateway_data/. app:/var/lib/gateway
docker compose -f docker-compose.yml cp --archive gateway-recovery/gateway_relay_identity/. app:/var/lib/gateway-relay
docker compose -f docker-compose.yml cp --archive gateway-recovery/gateway_relay_state/. relay:/var/lib/gateway-relay/state
docker compose -f docker-compose.yml cp --archive gateway-recovery/gateway_registry_data/. registry:/var/lib/registry
docker compose -f docker-compose.yml cp --archive gateway-recovery/gateway_registry_auth/. app:/var/lib/gateway-registry-auth
docker compose -f docker-compose.yml cp --archive gateway-recovery/redis_data/. redis:/data

docker compose -f docker-compose.yml up -d postgres
docker compose -f docker-compose.yml cp gateway-recovery/postgres.dump postgres:/tmp/gateway.dump
docker compose -f docker-compose.yml exec -T postgres \
  pg_restore -U gateway -d gateway --clean --if-exists /tmp/gateway.dump

docker compose -f docker-compose.yml up -d redis registry app relay

Сначала используйте ту же версию. Проверьте вход, расшифровку секретов, идентичность Relay и свежие подключения нод до обновления. Владельцы файлов могут различаться между хостами; при ошибке прав сравните владельцев внутри исходных и восстановленных Containers, не открывая запись всем пользователям.

Процедура обновления Opfield

Прочитайте примечания к выпуску и требования к промежуточным версиям.
Подтвердите активный канал обновлений и целевую версию, а для установки, у которой есть или был платный тариф, — доступность службы лицензирования для Opfield; см. Условия обновления в 2.11. При переходе с 2.10 сначала выполните шаги из раздела Обновление с 2.10.
Проверьте свежие резервные копии PostgreSQL и постоянных томов.
Запишите текущие версии и дайджесты образов Opfield, Relay и демонов.
Проверьте состояние PostgreSQL, Redis, Relay и диска.
Переводите клиентские службы в режим обслуживания, только если этого требует обновление.
Примените поддерживаемое обновление, не заменяя постоянные тома и главные ключи.
Дождитесь готовности Opfield и завершения миграции схемы.
Проверьте Relay, вход, начальную загрузку Dashboard, повторное подключение нод, Routes и привязки баз данных.
Отключайте режим обслуживания только после внешней проверки.

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

Условия обновления в 2.11

Каждое обновление Opfield сначала авторизует целевой выпуск в службе лицензирования license.thesqlabs.com. Это касается и обновлений, запущенных из Console, и повторного запуска установщика. Opfield проверяет подписанный выпуск до изменения хоста:

Платные установки: установка, у которой есть или была платная активация, — в том числе истёкшая, отозванная, перенесённая или деактивированная, — получает коммерческое ядро для целевой версии, поэтому её существующие платные ресурсы продолжают работать после обновления. Opfield проверяет подпись, версию, размеры и хеши ядра и принимает авторизацию только в виде подписанного состояния лицензии для этого запроса. Такой установке служба лицензирования нужна во время обновления: если служба недоступна, отказывает в выпуске или возвращает состояние, которое не проходит проверку, обновление останавливается до каких-либо изменений, а текущий Opfield продолжает работать. Opfield никогда незаметно не заменяет платную установку на Community, поэтому на время окна обновления разрешите исходящие соединения со службой лицензирования.
Установки Community: установка, у которой никогда не было платного тарифа, обновляется как Community. Если у неё нет лицензионного ключа, платного тарифа в состоянии лицензии и коммерческого ядра на хосте, она обновляется и тогда, когда служба лицензирования недоступна, потому что ничего закрытого не загружает. Отказ службы или состояние лицензии, не прошедшее проверку, всё равно останавливают обновление.
Выполняющиеся операции: после загрузки образов и до изменения хоста Opfield ждёт завершения выполняющихся и ожидающих операций оркестрации — blue/green-развёртываний и вывода их прежних слотов, операций Compose, действий Workload Availability, миграций и развёртываний сборок. Ожидание длится до 15 минут по умолчанию или до самого позднего срока, объявленного выполняющейся операцией, но не более 60 минут. Экран обновления показывает операции, которых он ждёт. Новые операции оркестрации во время ожидания отклоняются с кодом GATEWAY_UPDATING. Администратор может завершить ожидание раньше кнопкой Update now; после перезапуска Opfield продолжит или согласует прерванные операции.
Свободное место на диске: перед заменой приложения обновление делает снимок базы данных Opfield, и для него нужно свободное место в файловой системе с каталогом Opfield: размер базы данных плюс 10% плюс 256 МиБ. Если места меньше, обновление останавливается до каких-либо изменений, а журналы контейнера обновления сообщают, сколько места нужно.

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

Ожидание выполняющихся операций, проверка свободного места и снимок базы данных, описанный ниже, выполняет механизм обновления той версии, которая сейчас работает. Поэтому они действуют для обновлений, запущенных начиная с 2.11, но не для обновления с 2.10; см. Обновление с 2.10.

Автоматический откат и снимок базы данных

Непосредственно перед запуском новой версии обновление записывает снимок базы данных Opfield в формате pg_dump custom в файл .gateway-foundation-backups/pre-update-<time>/gateway-db.dump в каталоге Opfield, рядом с сохранёнными .env и docker-compose.yml. Если новая версия не становится работоспособной примерно за пять минут, контейнер обновления выполняет откат: восстанавливает .env и docker-compose.yml, останавливает все службы Compose, кроме postgres, удаляет базу данных gateway и создаёт её заново из снимка. Поэтому прежняя версия никогда не работает со схемой, изменённой миграциями новой версии. Данные, записанные после снимка, теряются.

Снимок удаляется после успешного обновления или восстановления, а следующее обновление удаляет оставшиеся снимки старше 7 дней. Если перенесённую базу данных не удаётся удалить, прежняя версия запускается на ней, как раньше, а снимок сохраняется. Если восстановление не удалось уже после удаления базы, Opfield остаётся остановленным, а снимок сохраняется: устраните причину, указанную в журналах контейнера обновления, и восстановите базу из каталога Opfield:

docker compose exec -T postgres psql -U gateway -d postgres -c 'DROP DATABASE IF EXISTS gateway WITH (FORCE)'
docker compose exec -T postgres pg_restore --create --exit-on-error -U gateway -d postgres < .gateway-foundation-backups/pre-update-<time>/gateway-db.dump
docker compose up -d

Снимок защищает только само обновление. Сохраняйте и резервные копии PostgreSQL из комплекта восстановления.

Обновление с 2.10

Обновление с 2.10.x выполняет механизм обновления 2.10.x. Он не ждёт выполняющихся операций и не делает снимок базы данных Opfield, поэтому подготовьтесь к обновлению сами.

Перед обновлением

В каталоге Opfield (по умолчанию /opt/gateway) создайте резервную копию базы данных и сохраните копию .env, в которой хранится PKI_MASTER_KEY:
Окно терминала
```
docker compose exec -T postgres pg_dump -Fc -U gateway gateway > gateway-2.10.dump
cp .env env-2.10.backup
```
Не запускайте развёртывания, резервное копирование и миграции Docker, пока идёт обновление.
На платной установке убедитесь, что хост Opfield может обратиться к службе лицензирования: обновление загружает подписанное коммерческое ядро 2.11 и останавливается до замены приложения, если служба недоступна. Установки Community, у которых никогда не было платного тарифа, обновляются без неё.
На Community прочитайте раздел Обновление установки Community с 2.10: начиная с 2.11 базы данных (включая внешние подключения, сохранённые в 2.10), хранилища, интеграция с GitLab, а также Plan Mode, Scenarios и Sandboxes в AI Workspace требуют тарифа Personal или выше. Их записи остаются в базе данных и снова становятся доступны с ключом Personal или выше.

Обновление применяет миграции базы данных 2.11. Существующие данные, которые 2.11 больше не допускает, — например, две рабочие нагрузки на одном порту хоста ноды, два включённых Routes с одним именем на ноде или несколько активных запусков резервного копирования одной политики, — отмечаются в журнале аудита, а не приводят к сбою обновления; см. Конфликты, разрешённые при обновлении до 2.11.

Если обновление откатилось, 2.10.x снова запускается на уже перенесённой базе данных и сохраняет свои права и действующую лицензию; повторное обновление возвращает всё, что было в 2.11. Устраните причину, указанную в журналах контейнера обновления, и обновите Opfield ещё раз. Чтобы вместо этого вернуться к состоянию до обновления, верните сохранённый .env, остановите все службы, кроме postgres (docker compose stop app relay registry redis), восстановите gateway-2.10.dump командами DROP DATABASE и pg_restore из раздела Автоматический откат и снимок базы данных и выполните docker compose up -d.

Порядок обновления

Обновите Opfield.
Обновите демоны нод кнопкой Nodes > Update Nodes: она показывает все ноды Docker, Nginx, хранилища и мониторинга, для которых есть более новый демон, и обновляет выбранные вместе.
Обновите Relay Pool кнопкой Settings > General > Update Relay Pool.

Не обновляйте демоны нод и Relay раньше Opfield: Relay 2.11 требует Opfield 2.11, а многим функциям и исправлениям 2.11 нужны выпуски Docker, Nginx и Relay той же версии. Relay из 2.10 сохраняют 15-минутную аренду политики Relay, пока их не обновят.

После обновления демонов и Relay:

Первое применение проекта Compose, даже с неизменённой ревизией, один раз пересоздаёт его службы, потому что они получают новые настройки журналов и метку с дайджестом собственной конфигурации; последующие ревизии пересоздают только изменённые ими службы; см. Поддерживаемая конфигурация Compose. Маршрутизаторы Deployments перестают ограничивать размер тела запроса при следующем развёртывании, переключении слота или перезапуске.
Политики Docker Availability сами переходят в режим аренды, когда все ноды Docker, ноды Ingress и Relay рабочей нагрузки отработают на 2.11 две минуты. На каждой ноде Docker нужен сторожевой процесс аренды: установщик ноды Docker ставит его сам, а Docker-демон 2.11, запущенный от root с systemd или OpenRC, устанавливает его самостоятельно. Иначе политика показывает ноду в списке Excluded nodes; повторно запустите на ней установщик ноды Docker через sudo с тем же --user. В режиме аренды каждая нода политики должна достигать каждого Relay. См. Переключение на уровне данных.
Нодам хранилища нужен исходящий HTTPS к ghcr.io, чтобы загрузить исполнитель резервного копирования. Остальные сторонние образы среды выполнения сначала загружаются из зеркала Opfield на ghcr.io, а при неудаче — из Docker Hub.
Внешние подключения PostgreSQL и Redis с TLS, созданные до 2.11, остаются без проверки сертификата и показывают предупреждение. Запустите проверку одной кнопкой или добавьте частный CA; см. Проверка TLS-сертификатов.
У моделей Claude Fable 5.1 и Opus 5.5, опубликованных в Opfield Inference до 2.11, отключены инструменты; откройте и сохраните их ещё раз.

Права после обновления

Группы, пользователи, API-токены и OAuth-разрешения, у которых было устаревшее имя скоупа, получили его замену, а устаревшие имена ещё два выпуска принимаются на входе. Скрипты, которые читают имена скоупов обратно, должны ожидать новые имена. См. Устаревшие имена скоупов.
Некоторые замены шире прежних скоупов. Проверьте группы, права пользователей, API-токены и OAuth-разрешения, у которых было что-то из этого:
- integrations:gitlab:ci:edit, :variables:edit, :variables:delete, :webhooks:manage и :registry:manage стали integrations:gitlab:repo:write: это право также позволяет делать коммиты в файлы репозитория и менять конфигурацию CI, переменные CI/CD, вебхуки и настройки реестра. CI-токен, который только чистил реестр, теперь может отправлять коммиты.
- integrations:gitlab:ci:view стал integrations:gitlab:repo:read, который также читает файлы репозитория.
- integrations:gitlab:sync, :github:sync и :git:sync стали правом manage соответствующего коннектора: настройки, токены, список разрешённых репозиториев, проверка и удаление.
- nodes:config:edit стал nodes:manage, который также устанавливает Secure Runtime, меняет служебные адреса, а для размещённых виртуальных машин управляет питанием, размером и восстановлением снимков.
- proxy:advanced:bypass и proxy:raw:bypass оба стали proxy:unrestricted, поэтому любой из них теперь снимает оба ограничения.
- proxy:templates:create, :edit и :delete стали proxy:templates:manage — это любые операции с шаблонами nginx.
- notifications:alerts:create, :edit и :delete стали notifications:alerts:manage, а notifications:webhooks:create, :edit и :delete — notifications:webhooks:manage, который также раскрывает адреса и заголовки вебхуков и содержимое доставок.
- docker:containers:folders:manage стал docker:folders:manage, который охватывает папки всех типов ресурсов Docker.
integrations:gitlab:variables:view стал integrations:gitlab:repo:read и больше не читает значения переменных CI/CD; для чтения значений нужен integrations:gitlab:repo:write.
Любое право на действие, кроме создания, теперь подразумевает право просмотра своего семейства с тем же уточнением: группа или токен, у которых было только право на удаление, изменение, управление или запуск, теперь также видят эти ресурсы в списках и могут их открыть. Проверьте разрешения, которые давали только удаление.
Встроенные группы получают новые права автоматически, пользовательские — нет. Где нужно, выдайте diagnostics:view и diagnostics:logs для диагностики Opfield, databases:backups:view, :manage, :run и :restore, nodes:backups:execute, а также storage:view, :create, :edit, :delete, :iam, storage:objects:* и storage:credentials:use. storage:credentials:reveal включает storage:credentials:use.
Токен никогда не видит больше, чем учётная запись, которая его создала, а право на создание при делегировании больше не считается правом просмотра: токены пользователей, у которых доступ сузился, теряют этот доступ.
Источники Git, сохранённые после обновления, собираются автоматически, только пока у сохранившей их учётной записи есть use на репозиторий; вебхуки и автоматические развёртывания проверяют учётную запись, которая их настроила.
Для развёртывания или обновления Deployment с новым образом, командой или окружением, а также для смены образа контейнера нужны права на окружение и секреты; для подключения контейнера к сетям нужно право на изменение сети. SQL с правом записи во внешнем PostgreSQL выполняется по одному оператору, а для изменения схемы или ролей нужно право администратора.
Ограничения тарифа Community — 25 управляемых нод, 3 пользователя и 1 пользовательская группа прав (в 2.10 было 100, 10 и 5). Существующее ничего не удаляется; создать больше нельзя.

Изменённое поведение

TLS для неизвестных имён. Ноды Ingress отклоняют TLS-рукопожатие для имён хостов, которые не обслуживает ни один Route. Клиенты и балансировщики, которые подключаются по IP-адресу по HTTPS без SNI или рассчитывают на сайт по умолчанию, получают отказ. Ноды, в nginx которых уже есть свой сервер по умолчанию на порту 443, пропускают это с предупреждением. См. Ресурсы Route.
Ограничения Compose. Проекты Compose не могут использовать сеть хоста и внутренние сети Opfield (gateway-secure-links, gateway-db-*, gateway-storage-*), задавать зарезервированные метки Opfield и переменные клиента Docker, например DOCKER_HOST, DOCKER_CONFIG, BUILDKIT_* и COMPOSE_*. Существующие проекты, нарушающие эти правила, продолжают работать, их можно остановить и удалить, но новая ревизия, применение, запуск и перезапуск отклоняются, пока проект не исправлен, — в том числе первое применение после обновления Docker-демона. См. Поддерживаемая конфигурация Compose.
Проверка директив nginx. Содержимое шаблонов nginx и расширенная конфигурация Additional Route проверяются так же, как конфигурация Route: без proxy:unrestricted запрещённые директивы отклоняются, а журналы nginx можно писать только в /var/log/nginx. Шаблоны, сохранённые до обновления, продолжают отображаться в сохранённом виде.
Аренда политики Relay. Relay работают без Opfield 72 часа по умолчанию (Settings > Relay, от 1 часа до 7 дней); см. Relay без Opfield.
Автоматическая очистка. История операций — завершённые сборки с журналами, операции Compose, Availability и хостинга, доставки вебхуков — хранится 90 дней, а просроченные OAuth-разрешения и OAuth-клиенты, так и не завершившие авторизацию, удаляются. Если нужна более длинная история, измените Settings > Features > Housekeeping до первого запуска; см. Автоматическая очистка и хранение.
Продление сертификатов Internal PKI. Сертификаты Internal PKI, привязанные к Routes, автоматически перевыпускаются до истечения срока, если у Opfield есть закрытый ключ; для существующих привязок автопродление включено.
Ротация токенов GitLab. Токены GitLab со скоупом api или self_rotate, срок которых истекает в ближайшие 14 дней, Opfield ротирует сам и отзывает старый токен. Если тот же токен используется где-то ещё, выдайте Opfield отдельный; см. Срок действия и ротация токенов.
Настройки. Сохранение настроек перезапускает Opfield, только если переключается внутренний HTTPS или меняется Public URL при включённом внутреннем HTTPS. Способы входа, MFA, поставщик OIDC и выдача учётных записей перенесены в Settings > Authentication, структурированное журналирование находится в Settings > Features, а Authentication email (SMTP) теперь называется SMTP configuration.
API. Чтение ноды больше не возвращает данные токена регистрации, пустое обновление ноды возвращает 400, а некорректный идентификатор — 404. Изменения окружения, пересоздание и ревизии Compose возвращают 409, пока целью владеет развёртывание сборки. Неизвестный путь /api возвращает 404 в формате JSON.
Docker Availability больше не помечена как Tech Preview, а сборки больше нельзя закреплять на Dashboard и в боковой панели.

Конфликты, разрешённые при обновлении до 2.11

Opfield 2.11 соблюдает несколько правил уникальности в своей базе данных, а не только в коде приложения, поэтому они действуют и тогда, когда запросы одновременно обрабатывают несколько процессов Opfield. Обновление никогда не завершается ошибкой из-за существующих данных, нарушающих эти правила: миграция 0207 сохраняет самую раннюю запись, помечает или переименовывает остальные и записывает каждый случай в журнал аудита. После обновления найдите в журнале аудита эти действия и устраните то, о чём они сообщают.

Правило после обновления	Что обновление сделало с существующими конфликтами	Действие в аудите
Два включённых Routes на одной ноде Ingress не могут обслуживать одно имя (`409 PROXY_HOST_DOMAIN_CONFLICT`)	Самый ранний Route сохраняет имя. Более поздние сохраняют конфигурацию и остаются помеченными, пока не изменятся их имена или нода. Отключённый такой Route нельзя снова включить, пока это имя обслуживает другой включённый Route. nginx обслуживает только один из них, поэтому уберите имя из одного Route или отключите его	`proxy_host.domain_conflict`
У политики резервного копирования одно копирование в очереди или в работе (`409 BACKUP_ALREADY_RUNNING`), а восстановление в новую базу с данным именем выполняется только одно (`409 BACKUP_RESTORE_ALREADY_RUNNING`)	Продолжается один активный запуск: выполняющийся — а не ожидающий в очереди, иначе самый новый. Остальные помечены как неудачные с фазой `superseded`, освобождают исполнителя, а их задания отменяются	`database.backup.superseded`
Имена управляемых хранилищ уникальны в пределах ноды хранилища (`409 MANAGED_STORAGE_NAME_IN_USE`)	Самый ранний кластер сохраняет имя. Более поздние вместе с их подключениями хранилища переименованы с первым свободным суффиксом `-2`, `-3`, …	`storage.managed.renamed_duplicate`
Порт хоста на ноде принадлежит одному развёртыванию, управляемому хранилищу или управляемой базе данных (`409 DEPLOYMENT_HOST_PORT_IN_USE`, `MANAGED_STORAGE_PORT_CONFLICT` или `MANAGED_DATABASE_PORT_CONFLICT`)	Самая ранняя рабочая нагрузка сохраняет порт. Более поздние продолжают работать и помечены; перенесите одну из них на другой порт	`node.host_port_conflict`
Сертификат, который использует Route, удалить нельзя (`409 CERT_IN_USE`)	Устранять нечего: прежнюю проверку теперь соблюдает и база данных	—

Порты хоста, которые Docker-демон выбирает для управляемой базы данных, не совпадают с портами, зарезервированными другими рабочими нагрузками на этой ноде. Если опубликованный порт управляемой базы данных всё же конфликтует с резервированием другой нагрузки, он указывается в managed.hostPortConflicts подключения к базе данных вместе с нагрузкой, которая его занимает.

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

Обновление до 2.11.1

2.11.1 переводит привязки баз данных и хранилища на один общий коннектор защищённых связей на каждой ноде Docker и добавляет связи контейнеров. Сначала обновите Opfield, затем Docker-демоны. Что происходит на каждой ноде после обновления её Docker-демона:

Каждая рабочая нагрузка с привязкой базы данных один раз пересоздаётся, по одной на каждой ноде: следующая — после того как предыдущая работает исправно. Deployments выкатываются по схеме blue/green без простоя; автономные Containers и службы Compose один раз перезапускаются, поэтому планируйте обновление нод с такими нагрузками с учётом этого.
Каждая рабочая нагрузка с привязкой хранилища, созданной до 2.11.1, один раз пересоздаётся сразу после перехода её привязки. Привязкам, созданным в 2.11.1, пересоздание не нужно.
Имена переменных и учётные данные не меняются, и ничего делать вручную не нужно. Не удаляйте прежние сети связей и контейнеры сами.
Откат Docker-демона до 2.11.0 автоматически возвращает его связи обратно, с одним пересозданием каждой рабочей нагрузки. На одной ноде одновременно пересоздаются не больше четырёх рабочих нагрузок — это предел одновременных команд демона, — поэтому на ноде с большим числом связанных Deployments последние переподключаются немного позже.
Последующие обновления коннектора сохраняют открытые соединения связей до 30 минут, после чего закрывают их один раз.

Новые сети связей используют собственный диапазон адресов, по умолчанию 10.213.x.x (/16). Если он пересекается с сетью, доступной с ваших нод через маршрут по умолчанию, задайте docker.secure_links.subnet_pool до обновления Docker-демона, чтобы перенесённые связи сразу использовали ваш диапазон (более ранние демоны этот ключ игнорируют); см. Общий коннектор и сети связей.

Обновления демонов и Relay

Обновляйте по одному домену отказа. Для участников Relay Pool последовательно выводите каждого участника из обслуживания, обновляйте, проверяйте и возвращайте его, прежде чем переходить к следующему. Для обычных нод после повторного подключения проверяйте ресурсы, относящиеся к их роли. Не обновляйте одновременно все ноды Ingress, ноды хранилища или участников Relay, если для среды не проверен независимый путь восстановления.

Кнопка Nodes > Update Nodes обновляет демоны нескольких нод вместе, а обновление демона для отключённой ноды, ноды Relay и ноды, на которой этот выпуск уже работает, Opfield отклоняет; см. Обновления демонов. После обновления Opfield обновите демоны нод раньше Relay Pool, особенно при переходе с 2.10: обновление Relay Pool обновляет и локальный Relay, сразу пересоздавая его, пока он работает на релизе старше 2.11.1, а актуальные демоны переподключаются к нему за доли секунды; см. Relay и Relay Pool. Обновления демонов и Relay на нодах, участвующих в переключении на уровне данных, Opfield выполняет по одному участнику каждой политики Availability, поэтому обновление может ждать своих участников аренды.

Процедура восстановления

Подготовьте чистую совместимую среду Opfield.
Восстановите PostgreSQL и постоянные тома из одной точки восстановления.
Восстановите материалы идентичности шифрования, PKI и Relay с исходными правами доступа.
Запустите внутренние зависимости, Opfield и Relay в документированном порядке.
До разрешения изменений проверьте вход и расшифровку.
Разрешите управляемым нодам повторно подключиться с существующими идентичностями.
Согласуйте с желаемым состоянием Routes, сертификаты, рабочие нагрузки, привязки баз данных, уведомления и интеграции.
При необходимости восстановите базы данных приложений средствами их движков.
Подтвердите непрерывность аудита и зафиксируйте событие восстановления.

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

Решение об откате

До обновления определите измеримое условие отката: неудачная миграция, невозможность расшифровать существующие секреты, сбой авторизации Relay, несовместимое состояние демона, неработающие клиентские Routes или другой явный сигнал. Храните ссылки на предыдущие одобренные образы и соответствующую резервную копию до завершения периода наблюдения за новым выпуском.

Откат приложения и откат данных — разные операции. Кроме автоматического отката обновления, которое так и не стало работоспособным, возврат прежнего образа Opfield не отменяет завершённую миграцию схемы PostgreSQL, а возврат рабочей нагрузки к прежнему артефакту не откатывает изменяемые тома или данные базы. Соблюдайте правила совместимости конкретного выпуска и восстанавливайте данные только из согласованной точки восстановления, когда этого требует целостность.

Проверка оператора после обновления

Слой	Необходимое доказательство
Идентичность	Существующие пользователи входят; MFA, OAuth и расшифровка работают
Плоскость управления	Миграции завершены; фоновые планировщики и аудит продолжают работу
Relay и ноды	Версии совместимы; ноды подключились и передали свежий инвентарь
Клиентский трафик	Внешние DNS, TLS, состояние Route и ответ приложения проверены успешно
Данные	Управляемые базы данных работоспособны, приложения выполняют запросы через привязки
Автоматизация	Используемые сборки, вебхуки, уведомления и соединители источников работают

Если проверка не проходит, зафиксируйте наблюдаемый сигнал и соответствующий слой: страницу Task и её журналы для операции, состояние владельца ресурса для нод, Routes или баз данных либо внешний запрос для клиентского пути. Не продолжайте обновление следующего домена отказа и не удаляйте прежние образы или резервную копию; выполните документированный откат или восстановление для затронутого слоя.

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