Миграция сервера OpenShip v0.4.7: чек-лист

Последнее обновление: 3 августа 2026 года. Данные сверены с официальным журналом изменений OpenShip, текущим репозиторием OpenShip и документацией по Docker-механике.

Целевые контейнеры уже запущены, но база данных, фоновые задачи или возврат на старый узел не проверены → миграция сервера OpenShip v0.4.7 ещё не принята. Самый быстрый безопасный вариант → до переключения трафика отдельно подтвердить контейнеры, данные, секреты, домен, задания и рабочий откат.

OpenShip v0.4.7 был опубликован 28 июля 2026 года; официальный журнал изменений указывает на улучшения надёжности удалённой миграции Docker. Это подтверждает изменение цепочки миграции, но не доказывает, что именно ваша рабочая система готова к переключению. (github.com)

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

Что именно считается успешной миграцией OpenShip

В официальной документации OpenShip описаны варианты запуска на локальной машине, собственном сервере и в облачной среде, а также работа через графическую панель, веб-интерфейс и командную строку. Это удобная модель управления, но она не заменяет проверку фактического состояния контейнеров и хранилищ после переноса. (github.com)

Для приёмки разделите результат на три уровня:

1. Технический запуск — нужные контейнеры созданы, образы доступны, порты связаны корректно.
2. Сохранность состояния — база данных, объекты, файлы загрузок и данные томов доступны после перезапуска.
3. Рабочий продакшен — домен, TLS, авторизация, фоновые процессы, очереди и возврат на старый сервер проверены.

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

Сценарий из эксплуатации

Представьте AI SaaS с веб-контейнером, API, реляционной базой, хранилищем файлов и отдельным потребителем очереди. После Docker миграции все контейнеры на новом сервере имеют статус running. Главная страница открывается, поэтому команда переключает DNS.

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

Именно поэтому «контейнеры запущены» — только предварительный сигнал, а не итог миграции сервера OpenShip v0.4.7.

Первый этап: зафиксируйте исходное и целевое состояние

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

Сохраните:

• фактическую версию OpenShip и идентификатор используемого релиза;
• адрес исходного сервера и нового узла;
• список проектов и всех сервисов, включая вспомогательные контейнеры;
• используемые образы и их точные теги или хэши;
• файл Compose, переменные окружения и список подключённых секретов;
• имена данных томов, каталоги bind mount и внешние хранилища;
• домены, прокси-маршруты, сертификаты и параметры проверки здоровья;
• команды запуска, остановки, резервного копирования и возврата.

Затем сравните два списка:

• что описано в репозитории или Compose;
• что реально запущено командой Docker;
• что требуется бизнес-процессу, даже если контейнер сейчас остановлен.

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

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

Второй этап: проверьте образы, контейнеры и повторное развёртывание

После переноса не ограничивайтесь проверкой списка контейнеров. Для каждого сервиса зафиксируйте четыре объекта:

1. имя сервиса в конфигурации;
2. фактическое имя контейнера;
3. используемый образ;
4. состояние сети, портов, томов и зависимостей.

У сервиса со сборкой должен быть проверен повторный build. У сервиса с готовым образом — повторная загрузка образа из указанного источника. Это позволяет обнаружить ситуацию, когда на новом узле приложение работает только потому, что случайный локальный слой уже присутствовал в кэше.

Проведите контролируемое повторное развёртывание:

docker compose config
docker compose ps
docker compose images
docker compose up -d --force-recreate
docker compose ps

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

Проверка считается пройденной, если:

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

Если старый контейнер отображается как остановленный, но сервис снаружи работает, не запускайте его повторно вслепую.

Почему старый контейнер может быть остановлен, хотя сервис работает? Чаще всего трафик уже обслуживает новый контейнер, а панель показывает исторический объект; либо имя сервиса изменилось, но прокси направляет запросы на другой экземпляр. Сначала сопоставьте домен, маршрут, контейнер и журнал запросов. Если новый экземпляр действительно принимает трафик, старый объект можно оставить остановленным. Если же прокси указывает на старый адрес или очередь всё ещё обслуживается старым контейнером, миграция не принята — остановите переключение и восстановите однозначную схему.

Какие проверки отделяют «запущено» от «готово к трафику»

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

Такой подход полезнее статуса «успешно» в панели, потому что каждый пункт имеет объект, доказательство, порог и действие при ошибке.

Третий этап: проверьте базу данных и данные томов

Главный риск при миграции Docker-сервера — перепутать контейнер с состоянием приложения. Контейнер можно удалить и создать заново, а данные тома должны пережить эту операцию. Для каждого тома выясните:

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

Не проверяйте только наличие файлов. Выполните сценарий:

1. прочитайте несколько существующих записей или объектов;
2. создайте контрольную запись через приложение;
3. прочитайте её через пользовательский интерфейс и API;
4. перезапустите связанный контейнер;
5. повторите чтение;
6. удалите контрольный объект только после фиксации результата.

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

Может ли OpenShip при миграции Docker-сервера привести к потере данных? Само завершение миграционного процесса не доказывает ни потерю, ни сохранность. Потеря возникает, когда копируется только слой контейнера, подключается новый пустой том, резервная копия считается успешной без восстановления или приложение продолжает писать в старую базу во время копирования. Поэтому граница записи должна быть определена заранее: остановка приложения, режим только для чтения или согласованная репликация.

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

Четвёртый этап: подтвердите переменные, секреты и права доступа

Перенос окружения часто ломается из-за значения, которое не отображается в интерфейсе. Сравните старое и новое окружение по категориям:

• адрес базы данных;
• имя базы и схема;
• ключи подписи сессий;
• ключи внешних API;
• учётные данные реестра образов;
• настройки очереди и планировщика;
• публичный URL приложения;
• разрешённые домены и обратные адреса авторизации.

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

Проверьте и сетевую поверхность:

• служебные порты не должны быть доступны из интернета без причины;
• администрирование должно проходить через разрешённый канал;
• база и очередь должны принимать соединения только от нужных сервисов;
• тестовый внешний доступ не должен превращать внутреннюю панель в публичную.

Если для восстановления нужен доступ администратора, используйте временную учётную запись, ограничьте срок действия и удалите её после проверки.

Пятый этап: переключите домен и сертификат без догадок

Домен нельзя считать перенесённым только потому, что главная страница открывается. До изменения DNS проверьте новый узел через тестовый домен или локальное разрешение имени.

Минимальный набор сценариев:

• HTTP перенаправляется на HTTPS по ожидаемому правилу;
• основной домен отдаёт новый сервис;
• API сохраняет правильный путь и заголовки;
• WebSocket или другой долгоживущий канал устанавливается и не закрывается сразу;
• проверка здоровья видит именно новый контейнер;
• прокси передаёт исходный протокол, адрес и имя хоста;
• сертификат выдан на нужное имя и может быть автоматически продлён.

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

Как переносить домен и сертификат при смене сервера OpenShip? Сначала подготовьте сертификат и маршруты на новом узле, затем проверьте их по тестовому имени. После этого уменьшите неопределённость DNS-переключения настолько, насколько позволяет ваша инфраструктура, зафиксируйте точное время изменения и оставьте старый сервер обслуживать прежний маршрут до завершения проверки. Не удаляйте старую конфигурацию сразу после появления нового HTTPS-ответа.

В журнале переключения запишите:

• время изменения DNS;
• время первого корректного ответа нового узла;
• срок, в течение которого старый узел остаётся доступным;
• ответственного за решение об окончательном отключении;
• условие немедленного возврата.

Шестой этап: остановите двойную обработку фоновых задач

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

Перед переключением трафика:

1. определите все планировщики, обработчики очередей и периодические контейнеры;
2. остановите или заморозьте старого потребителя;
3. зафиксируйте идентификатор последнего обработанного задания;
4. запустите новый потребитель;
5. отправьте одну контрольную задачу;
6. проверьте единственную обработку, результат и запись в журнале;
7. включите регулярное расписание только после подтверждения границы.

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

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

Когда старый сервер можно отключать

Старый узел можно выводить из эксплуатации только после выполнения всех условий:

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

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

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

Что делать, если проверка не пройдена

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

Контейнеры не запускаются. Сравните образ, переменные, подключённые тома, сеть и зависимости. Не восстанавливайте базу заново, пока не доказано, что проблема действительно в данных.

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

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

HTTPS работает, но WebSocket или API ломается. Проверьте прокси-заголовки, маршрут, тайм-ауты и соответствие публичного URL. Проверка только главной страницы здесь бесполезна.

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

Для самой процедуры миграции полезно сверять ожидания с официальной документацией OpenShip по способам запуска и архитектуре, а поведение контейнеров — с официальной справкой по жизненному циклу Compose-сервисов. Эти материалы описывают возможности и команды, но итоговый статус продакшена всё равно определяется вашими журналами, тестовыми записями и доказательством отката.

Итоговая приёмка перед переключением

Перед изменением DNS ответьте «да» на все вопросы:

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

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

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