Обновление продукта

Эта инструкция описывает штатное обновление уже установленного iEXExchanger.

Обновление можно выполнить двумя способами:

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

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

В инструкции используются два адреса:

https://ваш_домен — основной домен Frontend, на котором открывается клиентский сайт обменного пункта.

https://app.ваш_домен — технический поддомен Backend. На нём находятся административная панель, API и другие серверные функции iEXExchanger.

При проверке заменяйте эти обозначения фактическими адресами проекта.

Для входа в административную панель используйте сохранённый адрес входа: он может отличаться от главной страницы технического поддомена.

Обновление сохраняет настроенные домены. Повторно настраивать DNS или менять адреса в конфигурации для обычного обновления не требуется.

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

Не вставляйте в открытый чат пароли, приватные ключи, коды 2FA, содержимое .env или файлы лицензии.

Откат, восстановление баз и удаление точки возврата требуют отдельного решения, если вы ещё не согласовали эти действия.

Штатное обновление доступно, если продукт установлен через Installer и управляется системными компонентами iEXExchanger.

На сервере должны существовать:

В административной панели должен открываться раздел «Обновления», а блок «Состояние обновлений» должен показывать готовность сервера.

Если Updater отсутствует, Update Agent недоступен или текущий релиз не подтверждён системой, сначала устраните это состояние.

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

Запланируйте обновление на период низкой нагрузки и предупредите сотрудников о временном режиме обслуживания. Дождитесь завершения других работ на сервере.

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

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

Во время обновления одновременно могут храниться:

Перед резервным копированием и включением Maintenance система проверяет фактический запас диска и inode — доступных записей файловой системы для создания файлов и каталогов. При расчёте учитываются временные данные и дополнительный запас.

Через терминал эту проверку можно выполнить заранее командой apply --dry-run, описанной ниже. Само формирование плана ещё не подтверждает достаточность свободного места на момент запуска.

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

Скачивайте файлы только в персональном кабинете на официальном сайте iEXExchanger.

Для обновления нужны два отдельных файла одной версии:

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

Типовые имена файлов:

Официальные имена Backend и Frontend могут дополнительно содержать версию, дату или уникальный идентификатор. Например:

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

Оба архива должны:

Ограничения сжатых архивов:

Если интерфейс или сервер показывает меньший доступный лимит, используйте лимит конкретного сервера.

Архивы обновления не должны содержать .env. Действующие настройки и секреты берутся из установленной системы.

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

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

Не используйте вместо обновления:

Конкретный состав и количество этапов зависят от перехода между версиями. В обычном обновлении система выполняет следующие действия.

Разрешение «Просмотр обновлений системы» предназначено для просмотра состояния и истории.

Для запуска обновления или отката нужно разрешение «Запуск обновлений и откатов системы».

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

Этот способ предназначен для технического специалиста. Все команды этого раздела выполняются на сервере проекта, после подключения по SSH.

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

Ожидаемый результат:

Если текущий релиз не подтверждён, Update Agent не работает или команда сообщает о незавершённой операции, сначала устраните это состояние.

Не начинайте новую операцию поверх существующей.

Скопируйте официальные ZIP на сервер через SFTP или используемый файловый менеджер.

Если вы подключаетесь не как root, сначала загрузите их в каталог, в который вашему SSH-пользователю разрешена запись. Дальнейшие команды выполняйте в SSH-сессии.

Если файлы были загружены в /home, выведите их список:

Определите точные абсолютные пути к Backend и Frontend. Если применяется новая лицензия, отдельно определите путь к её ZIP.

Рекомендуется хранить каждый релиз в отдельном закрытом каталоге:

Замените RELEASE на обозначение скачанного релиза. Это значение используется только как имя каталога и не задаёт версию для Updater.

Создать каталог можно командой:

Скопируйте архивы в подготовленный каталог с владельцем root и правами 0600.

В примере исходные файлы находятся непосредственно в /home; замените исходные пути, RELEASE и имена ZIP фактическими значениями:

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

Если применяется новый ZIP лицензии, скопируйте его аналогично: владелец root:root, права 0600, фактическое имя файла без переименования.

Не используйте символические и жёсткие ссылки. Не распаковывайте ZIP-файлы.

Основная конфигурация установлена по адресу:

Сначала посмотрите нормализованные параметры:

Если значения spec.input.loose.backend.path и spec.input.loose.frontend.path уже указывают на фактически загруженные файлы, используйте эту конфигурацию без изменений.

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

Ниже показан фрагмент существующей конфигурации, а не полный update.yaml.

В скопированном полном файле найдите spec.input.loose и измените пути Backend и Frontend. Не создавайте второй раздел spec и не удаляйте остальные настройки.

Замените BACKEND_FILE.zip и FRONTEND_FILE.zip фактическими именами архивов. Отступы YAML сохраняйте пробелами:

Если для операции нужна новая лицензия, добавьте следующий фрагмент внутри spec.input.loose, на одном уровне с backend и frontend.

Вместо LICENSE_FILE.zip укажите фактическое имя ZIP:

Проверьте, не осталась ли в копии ссылка на лицензию от другой операции.

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

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

Не меняйте:

После редактирования сохраните файл в nano сочетанием Ctrl + O, подтвердите имя клавишей Enter и выйдите через Ctrl + X.

Далее задайте переменную с абсолютным путём к выбранной конфигурации. Она используется только для сокращения команд в текущей SSH-сессии и не изменяет файл:

Если вы используете основную конфигурацию без копии, задайте:

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

Выполните команды по порядку:

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

checklist перечисляет в том числе режимы, которые не используются в этом сценарии. Отметка [НЕТ] у input.bundle, input.remote-api или plan.bundle не мешает штатному обновлению парой ZIP с input.mode: loose и plan.mode: builtin.

Ошибки текущей установки, выбранного режима или обязательных проверок нужно устранить.

В плане проверьте:

Выполните предварительную проверку без применения обновления:

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

Отметка, что этап ещё не выполнен, сама по себе ожидаема: новый релиз и его backup пока не созданы. Ошибки проверки ресурсов или окружения нужно устранить до apply.

При реальном запуске система повторно проверит необходимые условия. Предварительная проверка не резервирует свободное место на диске.

После успешных предварительных проверок выполните:

Запустите apply один раз и дождитесь итогового результата.

Не запускайте одновременно обновление из административной панели. Не перезагружайте сервер и не завершайте процесс без необходимости.

Сохраните:

Общий статус относится ко всему обновлению, а отметка рядом с этапом — только к отдельной проверке или действию.

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

После статуса «Успешно» или успешного завершения apply проверьте сервер и работу продукта.

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

Выполните на сервере:

Убедитесь, что:

Для Update Agent ожидаются enabled и active.

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

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

Первая команда проверяет установленную систему, вторая — доступность через публичные адреса.

Если Installer или его исходный install.yaml отсутствует, не создавайте новый конфиг наугад. Выполните остальные проверки и запросите способ восстановления проверочной конфигурации.

Откройте основной сайт:

Затем перейдите по сохранённому адресу входа в административную панель на Backend:

Проверьте:

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

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

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

Копия, созданная перед обновлением, относится к прежнему состоянию. После успешной проверки продукта сохраните отдельную копию новой версии:

Проверьте успешное завершение и время последней копии. Копию до обновления и точку возврата сохраняйте на период проверки новой версии.

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

Откройте существующую операцию в разделе «Обновления».

Если причина остановки устранена и интерфейс предлагает «Продолжить», используйте эту кнопку. Она продолжает ту же операцию по сохранённому плану.

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

Не снимайте Maintenance вручную.

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

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

Updater проверит сохранённые результаты и продолжит ту же операцию. При необходимости этап может быть выполнен повторно, если требуемое состояние больше не подтверждается.

Сначала сохраните:

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

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

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

Для операции из панели технический специалист должен определить её собственную конфигурацию и журнал. Использовать основной update.yaml вместо них нельзя.

Сначала выполните предварительную проверку восстановления:

Запускайте восстановление только если проверка подтверждает нужное неуспешное обновление и возможность возврата:

После успешного восстановления повторите проверки сервера и продукта.

Старое обновление через apply --resume больше не продолжайте: для исправленных архивов нужна новая операция.

Если само восстановление было прервано:

recover-failed не используется для продолжения обычного отката. Для прерванного отката применяется rollback --resume.

Сообщение «Новые обновления приостановлены» означает запрет на запуск новых обновлений. Приостановка может быть включена вручную или автоматически после ошибок.

Сначала изучите историю и устраните причину. После проверки ответственный администратор может нажать «Возобновить» в блоке состояния.

Не путайте действия:

Разрешение новых обновлений не исправляет неуспешную операцию и не снимает Maintenance автоматически.

Откат — отдельная операция, а не обязательный шаг каждого обновления.

Выполняйте его при подтверждённой проблеме новой версии и после решения ответственного лица.

После отката сохранённая новая версия может получить статус «Готова к возврату» и действие «Вернуться на …».

Для возврата сформируйте и проверьте новый план, затем используйте «Подтвердить возврат» и «Вернуться на актуальную версию».

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

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

Используйте действующую полную конфигурацию, путь к которой задан в IEX_UPDATE_CONFIG.

Сначала проверьте план:

Если план подтверждает правильную предыдущую версию и точки возврата обеих баз, выполните:

После завершения:

Затем повторите публичные проверки и проверку продукта в браузере.

Если откат был прерван:

Не переключайте ссылку current вручную и не восстанавливайте только одну базу данных. Код, основная база и база Pulse должны возвращаться согласованно.

После успешного отката ранее активная версия становится предыдущей.

Если она сохранена и система подтверждает возможность возврата, новая команда rollback --dry-run покажет переход к ней. Возврат выполняется новой операцией rollback, а rollback --resume предназначен только для продолжения уже прерванного отката.

Сохраните вне обновляемого сервера:

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

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

Сохранённые версии удаляйте штатным действием в административной панели. Не удаляйте их каталоги вручную.

Откройте раздел «Обновления», перейдите во вкладку «Установленные версии» и выберите действие «Удалить» у нужной версии.

Перед подтверждением система покажет:

Текущую активную версию удалить нельзя. Удаление также блокируется, когда состояние сервера или выполняемая операция не позволяют сделать это безопасно.

Для обычного удаления используется кнопка «Удалить версию». Если предварительный расчёт устарел, нажмите «Пересчитать состав» и проверьте его заново.

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

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

Укажите, как запускалось обновление: через панель или терминал.

В панели откройте отчёт нужной операции в «Истории операций». Для запуска из терминала используйте серверные отчёты:

Сверьте время и идентификатор: последний отчёт должен относиться именно к рассматриваемой операции.

Если требуется дополнительная диагностика, технический специалист может подготовить комплект:

Команда покажет путь к результату.