Обновления нод и поведение при отключении

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

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

Операторские детали: обновление и повторное подключение

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

Когда нода отключается, рабочие нагрузки могут продолжать работать локально, но изменения через Opfield блокируются. Проверьте доступность хоста, службу демона, системное время, идентичность сертификата, DNS и исходящий доступ к Relay. Не удаляйте запись ноды, пока прежний демон ещё может переподключиться.

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

Launcher для безопасного обновления

В 2.10 Docker, nginx, monitoring и Relay supervisor получили отдельный launcher. При работе под его управлением сохраняются предыдущий бинарник и журнал обновления на диске. Новая версия должна сообщить о локальной готовности и пройти 30-секундное окно стабильной работы до подтверждения обновления; неудачный запуск предусматривает откат. Менеджер служб наблюдает за launcher, а тот — за процессом демона.

Локальная готовность не доказывает соединение с Relay или исправность приложений. После обновления по-прежнему проверяйте версию, повторное подключение, возможности узла и реальную операцию. Если запуск launcher недоступен и демон работает напрямую, защита отката launcher отсутствует.

В 2.11 новая версия демона, объявляющая о готовности управляющего соединения, должна также получить от Opfield первую команду в течение 3 минут, иначе launcher откатывает обновление. Обновления демонов на нодах Docker, nginx и supervisor Relay заменяют и launcher; в 2.10 он оставался в той версии, с которой был установлен. Обновлённый демон готовит новый launcher, как только завершается уже идущая проверка launcher, launcher пробует новую версию при следующем старте и оставляет её, если проверка прошла стабильно, поэтому установленный launcher отстаёт от демона на одно обновление.

Продление сертификатов

Opfield продлевает свои внутренние сертификаты во время работы, без перезапуска, и записывает каждое продление в журнал аудита:

Сертификат	Срок действия	Продление
Сертификаты служб приёма соединений Opfield, а также сертификаты службы и клиента локального Relay	365 дней	Проверяются ежечасно и продлеваются за 30 дней до истечения срока; существующие соединения используют старый сертификат до повторного подключения. Пока есть неиспользованные токены регистрации, продление откладывается до последних 7 дней, потому что команды установщика закрепляют отпечаток сертификата Opfield; команды, созданные до продления, после него нужно сгенерировать заново
Сертификат, заданный через GRPC_TLS_CERT	Задаёте вы	Opfield его никогда не продлевает; ежедневно в журнал записывается предупреждение
Серверные сертификаты удалённых Relay	365 дней	Проверяются ежечасно, пока Relay supervisor подключён, и продлеваются за 60 дней до истечения срока, не чаще одного раза в сутки
Клиентские сертификаты демонов на каждой ноде	365 дней	Демон проверяет их ежечасно и продлевает, когда остаётся треть срока действия, примерно за 120 дней до истечения. Неудачная попытка повторяется через 5, 10, 20 и 40 минут, затем ежечасно. Чтобы предъявить новый сертификат, демон переподключается
Сертификат прокси реестра на нодах Docker	2 года	Проверяется при запуске демона и каждые 12 часов и перевыпускается тем же центром сертификации, когда остаётся треть срока действия или 30 дней; применяется без перезапуска
TLS-сертификаты управляемых хранилищ и управляемых баз данных	Задаёт Opfield	Проверяются ежечасно и загружаются на лету без перезапуска; см. управляемые хранилища и управляемые базы данных

Чтобы продлить сертификат, нода должна оставаться подключённой. Продление начинается за несколько месяцев до истечения срока, поэтому если у сертификата ноды осталось меньше 30 дней, значит продление не удаётся: Opfield поднимает предупреждение за 30 дней и критическое оповещение за 7 дней. Убедитесь, что нода может подключиться к Opfield и работает с актуальным демоном; после истечения срока сертификата ноду нужно зарегистрировать заново.

Системные центры сертификации, выпускающие эти сертификаты, действуют 10 лет, и в 2.11 у них нет автоматической смены. Выпущенные ими сертификаты заканчиваются вместе с ними, а Opfield поднимает оповещения за 730, 365, 180, 60, 30 и 7 дней до истечения срока системного центра сертификации. См. «Внутренняя PKI».

Токены регистрации

Токены регистрации одноразовые, их срок действия истекает через 7 дней. Для ноды, которая ещё ожидает регистрации, New enrollment token выдаёт команду установщика взамен прежней. Зарегистрированную ноду нельзя зарегистрировать повторно на месте: повторную регистрацию поддерживают только участники Relay. См. Relay и Relay Pool.

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

Обновите одну ноду кнопкой Update на её странице или сразу несколько — кнопкой Nodes > Update Nodes. Диалог показывает все ноды, демон которых старше последнего выпуска своего типа, и обновляет выбранные вместе. Ноды Relay в нём не показываются: они обновляются вместе с Relay Pool (Settings > General > Update Relay Pool), который выводит их из обслуживания по одной. Opfield отклоняет обновление демона для неподключённой ноды, для ноды Relay и для ноды, на которой уже работает этот выпуск или более новый.

• Состояние обновления. Нода сохраняет состояние обновления в списке и на своей странице, без значка доступного обновления и мерцания статуса «отключена» во время обновления. Неудачное, откатившееся или превысившее время ожидания обновление сохраняет причину на ноде, она показывается под Update Available, а нода, вернувшаяся на прежнюю версию, сразу отмечается как таковая.
• Участники аренды. Ноды, участвующие в одной политике Availability в режиме аренды, перезапускаются по очереди; ожидающее обновление показывается как Queued с тем, чего оно ждёт. См. Обновления и разные версии.
• Перезапуски Opfield. Если Opfield перезапустился во время обновления нод, выполняющиеся обновления ждут повторного подключения своих нод и завершаются или прерываются вовремя, а обновления из очереди продолжаются. Opfield проверяет наличие обновлений демонов при запуске и после собственного обновления.
• Разрыв соединения. Демон, подготовивший самообновление, перезапускается в новую версию, даже если соединение с Opfield оборвалось во время загрузки.
• Установщики. Команды установки нод и Relay берутся из выпуска работающего Opfield и проверяются по контрольным суммам этого выпуска, а установщики демонов закрепляют самый новый демон той же линии выпусков, поэтому Opfield никогда не выдаёт установщики из более новой ветки разработки.

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

1. Прочитайте примечания к выпуску компонента и минимальную совместимую версию.
2. Осознанно выберите канал обновлений: Stable для релизов рабочей среды или Preview для явно принятых предварительных версий.
3. Убедитесь, что нода подключена и не выполняет конфликтующую операцию жизненного цикла.
4. Зафиксируйте текущую версию, возможности, активные рабочие нагрузки и последние ошибки.
5. Для Relay Pool используйте обновление Relay Pool, которое выводит из обслуживания, обновляет и проверяет участников по одному.
6. Убедитесь, что оператор сможет войти на хост, если автоматическое восстановление завершится ошибкой.

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

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

После перезапуска демона проверьте не только версию:

• аутентифицированное повторное подключение и свежее время последнего сигнала (last-seen);
• полный отчёт о возможностях;
• обновление инвентаря и метрик;
• состояние профильных служб;
• согласование ожидающих Tasks;
• принадлежащие этой ноде Routes, сертификаты, рабочие нагрузки, Compose Project и привязки баз данных;
• ожидаемое появление или снятие оповещений.

Поведение при отключении по зонам ответственности

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

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

Перезапуски Docker-демона

Перезапуск или обновление Docker-демона не останавливает контейнеры и лишь ненадолго прерывает трафик к ним:

• Демон сначала подключается к Opfield и заново регистрирует свои адреса Relay — примерно за секунду, как только приходят свежие разрешения Opfield. Проверка Secure Runtime (gVisor) повторяется после этого в фоне. Пока она не завершилась, нода сообщает последний результат, проверенный для той же версии runsc, а при первом запуске новой версии — неизвестное состояние с причиной verification_pending, поэтому создание защищённых нагрузок не прерывается.
• О штатном перезапуске или обновлении демон предупреждает. Перед остановкой он сообщает Relay, что его адреса подключения перезапускаются, завершает текущие запросы Secure Links (не дольше 1 секунды) и закрывает соединения, простаивающие между запросами. Relay сохраняют его регистрации до 15 секунд, пока не зарегистрируется следующий процесс, а ноды Ingress удерживают новые соединения к нему до 8 секунд, а не завершают их ошибкой, поэтому перезапуск выглядит как задержка в несколько секунд, а не как ошибки. Реплика Availability, у которой есть другая обслуживающая реплика, не ждёт: её запросы сразу уходят на другую реплику. Для этого нужны Relay и nginx-демоны этого же релиза; со старыми Relay нода Ingress по-прежнему удерживает новые соединения до 3 секунд.
• Держатель аренды Availability продолжает обслуживать запросы при перезапуске в пределах той же загрузки: его аренда ещё действует, поэтому копия снова получает трафик, как только новый процесс зарегистрируется.
• Демон, который упал, или демон, чей хост стал недоступен, не удерживается: Relay разрывают его соединение примерно за 3,5 секунды, и запросы переходят на другие размещения, если они есть.
• После перезагрузки хоста каждая Secure Link восстанавливается отдельно: ссылка, цель которой не вернулась, остаётся непривязанной, пока цель не заработает, и не мешает остальным.
• Зависший Docker Engine (dockerd) не останавливает трафик к работающим контейнерам и Deployments: соединения Secure Links, управляемых баз данных и хранилищ ждут его не дольше 300 миллисекунд, а затем используют последний адрес, который он сообщил, ссылки остаются привязанными, если он не ответил при синхронизации, а маршрутизаторы Deployment не используют ни DNS Docker, ни журнал доступа. Приложение, которое пишет каждый запрос в вывод своего контейнера, всё же может остановиться, пока dockerd заморожен.
• Нода хранилища или баз данных запускается, даже если одного из её управляемых контейнеров нет; это хранилище или база показывается остановленной, а нода остаётся подключённой.
• Предупреждения всех компонентов демона, например об отклонённых соединениях привязок, попадают в журналы ноды в Opfield, а не только в системный журнал хоста.

Ноды, которые голосуют в аренде переключения на уровне данных или могут её держать, обновляются по одной на каждую политику Availability: обновление демона такой ноды может ждать её участников аренды, и всё это время нода показывается обновляющейся. См. Обновления и разные версии. На Docker-нодах, которые могут держать аренду, сторожевой процесс аренды работает отдельной службой gateway-lease-watchdog и обновляется сам.

Нода, откаченная на любой релиз демона начиная с 2.10.0, по-прежнему запускается: демоны хранят рядом со своими файлами состояния и файлы, которые читает старый релиз. Демоны заменяют файлы состояния надёжно (запись, сброс на диск, переименование), поэтому kill -9 или отключение питания никогда не оставляют недописанный файл.

Docker-демон 2.11.1 и общий коннектор

Docker-демон 2.11.1 обслуживает все привязки баз данных, привязки хранилища и связи контейнеров ноды через один общий коннектор защищённых связей, без отдельных контейнеров для каждой связи и без служб приёма соединений на хосте; см. Общий коннектор и сети связей.

• Привязки баз данных переходят на коннектор после обновления: Opfield один раз пересоздаёт каждую связанную рабочую нагрузку, по одной на каждой ноде: следующую — после того как предыдущая работает исправно. Deployment выкатывается по схеме blue/green без простоя; автономный Container или служба Compose один раз перезапускается.
• Привязки хранилища, созданные до 2.11.1, переходят на коннектор после обновления, и Opfield один раз пересоздаёт каждую связанную рабочую нагрузку сразу после перехода её привязки. Привязкам, созданным в 2.11.1, пересоздание не нужно.
• Откат Docker-демона до 2.11.0 автоматически возвращает связи обратно, тоже с одним пересозданием каждой рабочей нагрузки. На одной ноде одновременно пересоздаются не больше четырёх рабочих нагрузок — это предел одновременных команд демона, — поэтому на ноде с большим числом связанных Deployments последние переподключаются немного позже.
• Обновления коннектора сохраняют открытые соединения связей до 30 минут, после чего закрывают их один раз; клиенты переподключаются к новому коннектору.
• Связям контейнеров нужен Docker-демон 2.11.1 на обеих нодах; до этого они показывают update required.
• Диапазон сетей связей: новые сети связей получают по /26 из docker.secure_links.subnet_pool в /etc/docker-daemon/config.yaml, по умолчанию 10.213.x.x (/16). Демон пропускает подсети, уже занятые сетями Docker или маршрутами хоста; измените диапазон, если он пересекается с сетью, доступной с ноды через маршрут по умолчанию, и перезапустите демон.

Перезапуски nginx-демона

Перезапуск или обновление nginx-демона на ноде Ingress не закрывает её сокеты Secure Links. Launcher, который управляет демоном, хранит копию каждого слушающего сокета и передаёт их следующему процессу демона; с systemd он также хранит их в хранилище файловых дескрипторов юнита, поэтому они переживают systemctl restart. Пока ни один процесс демона не работает, новые соединения ждут в очереди сокета и обслуживаются следующим процессом. При остановке демон перестаёт принимать соединения, до 1,5 секунды завершает текущие запросы и закрывает соединения, простаивающие между запросами, чтобы nginx переподключился в очередь.

• Обновление с 2.10 заметно один раз. Старый демон при остановке ничего не передаёт, поэтому это единственное обновление примерно на секунду прерывает маршруты через Secure Links этой ноды. После этого перезапуски и обновления сохраняют сокеты, включая перезапуск, в котором launcher пробует новую версию: пока ещё работает старый launcher, который сокеты не хранит, демон сам помещает свои слушающие сокеты в хранилище файловых дескрипторов systemd.
• Запросы дольше 1,5-секундного завершения, а также долгие потоки, например WebSocket или server-sent events, при перезапуске обрываются.
• На нодах без systemd (OpenRC) launcher покрывает перезапуски при обновлении и после сбоя, но не перезапуск службы. Routes, конфигурация которых ещё использует loopback-порт TCP вместо сокета Secure Link, во время перезапуска, как и раньше, отказывают в соединении.

Сокеты Secure Links создаются под временным именем сразу с нужными владельцем и правами и затем переименовываются, поэтому nginx никогда не находит отсутствующий сокет или сокет, которым не может пользоваться; перед загрузкой конфигурации каждый сокет, на который она ссылается, уже принимает соединения.

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

Последовательность восстановления

1. Восстановите питание и сетевую доступность хоста.
2. Проверьте системное время, DNS и соединение с адресом Relay.
3. Проверьте юнит systemd демона и ограниченный фрагмент журналов.
4. Убедитесь, что сертификат демона и идентичность ноды не заменялись.
5. Дождитесь повторного подключения и свежего инвентаря.
6. До повтора проверьте неуспешные или прерванные операции.
7. Проверьте каждое семейство зависимых ресурсов, принадлежащих ноде.

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

Прерванные операции

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

Сопоставьте запись операции с фактическим ресурсом-владельцем. Container может работать, хотя последнее обновление прогресса в UI прервалось; Compose Project мог применить ревизию без итогового подтверждения; обновление могло перезапустить демон до возвращения управляющего сеанса. Используйте свежий снимок и профильное состояние как доказательство, затем запускайте только поддерживаемое продолжение или действие восстановления.

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

Замена или восстановление

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

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

Плановый тест отключения

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