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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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