> For the complete documentation index, see [llms.txt](https://docs.iexexchanger.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.iexexchanger.com/ustanovka-i-obnovlenie/obnovlenie-produkta/obnovlenie-cherez-terminal.md). # Обновление через терминал Архивы и конфигурация Updater, установка, проверка, продолжение и восстановление через команды Используйте Updater на сервере для установки проверенной пары ZIP. Файлы могут находиться в локальном каталоге или поступать по прямым HTTPS-адресам. Для каждой операции сохраняйте отдельную полную конфигурацию, исходные архивы и отчёт. ## Готовый промпт для обновления через терминал Укажите фактический сервер, пути к двум ZIP или их HTTPS-адреса и путь к полной конфигурации операции. Секретные данные передавайте отдельно через предусмотренный защищённый способ. {% prompt description="Обновление через терминал сервера" icon="terminal" openInAIProviders="true" defaultExpanded="partial" %} ```markdown Помоги обновить управляемую установку iEXExchanger через /usr/local/sbin/iex-updater. Сайт обменника: https://ваш_домен. Серверная часть: https://app.ваш_домен. Пути к Backend, Frontend и полному конфигу операции предоставлю отдельно. Новый ZIP лицензии применяется только при подтверждённой необходимости. Сначала проверь version, status, services verify, backup status и отсутствие другой активной операции. Скопируй действующий полный update.yaml в отдельный каталог операции, сохрани остальные параметры, настрой loose input и builtin plan. Для локальных архивов обеспечь владельца root:root, права 0600 и защищённый каталог. Выполни config validate, checklist, plan и apply --dry-run. Покажи исходную и целевую версии, обязательную копию, обслуживание, изменения окружения, предупреждения и результат проверок. Дождись моего подтверждения перед apply. Запусти apply один раз. Не запускай параллельное обновление через панель. При потере SSH сначала проверь существующий процесс. Для продолжения используй apply --resume с теми же ZIP, конфигом и абсолютным путём. При ошибке покажи сохранённый отчёт и предложенное системой действие. Recover-failed и rollback сначала проверяй через --dry-run; восстановление данных и откат согласуй отдельно. После успеха проверь текущую версию, обслуживание, службы, Update Agent, публичные домены и основные функции обменника. Создай копию проверенной новой версии. Сохрани идентификатор и отчёт; не называй установку проверенной только по завершению команды. Не распаковывай архивы поверх current, не запускай миграции отдельно, не заменяй файлы или конфиг во время resume и не отключай обслуживание вручную после ошибки. ``` {% endprompt %} ## Подготовка сервера Для подключения используйте своего SSH-пользователя и адрес сервера: {% content-ref url="/spaces/uyjsNtEAtO6Sby8CHWyD/pages/cCEoFDjTDIufy3NUEakd" %} [Подключение к серверу по SSH](/help-center/upravlenie-serverom/podklyuchenie-k-serveru-po-ssh.md) {% endcontent-ref %} ```bash ssh SSH_USER@SERVER_IP ``` Замените `SSH_USER` и `SERVER_IP` фактическими значениями. После подключения выполните: ```bash sudo /usr/local/sbin/iex-updater version sudo /usr/local/sbin/iex-updater status sudo /usr/local/sbin/iexctl services verify sudo /usr/local/sbin/iexctl backup status ``` Сверьте текущую версию, состояние обслуживания, служб и предыдущих операций. Если сервер ожидает восстановления, сначала завершите его. ### Проверьте резервное копирование Updater проверяет службу резервного копирования и создаёт полную копию до изменения работающей версии. После включения режима обслуживания и остановки служб, изменяющих данные, он сохраняет согласованную точку восстановления основной базы и базы Pulse. Полная копия и точка восстановления баз решают разные задачи. Наличие скачанных ZIP или готового плана не означает, что эти копии уже созданы: резервное копирование выполняется при установке. Технический специалист может проверить состояние резервного копирования командой: ```bash sudo /usr/local/sbin/iexctl backup status ``` Если резервное копирование недоступно или завершалось ошибкой, устраните причину до установки. Оставьте обязательные проверки резервного копирования и режима обслуживания включёнными. Подробное управление копиями описано в статье [«Создание резервной копии»](https://docs.iexexchanger.com/server-i-dannye/sozdanie-rezervnoi-kopii). ### Проверьте службу обновлений Панель передаёт операции серверному агенту Update Agent. Через него выполняются проверка архивов, установка, продолжение, откат и удаление сохранённых версий. Если раздел показывает **«Обновления временно недоступны»**, прочитайте указанную причину. Технический специалист проверяет сервер: ```bash sudo /usr/local/sbin/iex-updater version sudo /usr/local/sbin/iex-updater status sudo systemctl is-active iex-update-agent.service sudo /usr/local/sbin/iexctl services verify ``` Недоступность агента, несовместимая версия службы и незавершённая операция требуют разных действий. Не заменяйте их повторной загрузкой архивов. Для фоновой подготовки также должен работать планировщик приложения. Если задача сохраняется в разделе, но подготовка не продвигается, проверьте планировщик и службы системы. ## Установка обновления {% stepper %} {% step %} ### Подготовьте архивы и полную конфигурацию Для каждой операции используйте отдельный каталог. В примере это `/home/iex-updates/RELEASE_ID`; замените `RELEASE_ID` уникальным обозначением операции и используйте этот же путь во всех последующих фрагментах. ```bash IEX_UPDATE_DIR='/home/iex-updates/RELEASE_ID' sudo install -d -o root -g root -m 0700 "$IEX_UPDATE_DIR" sudo install -o root -g root -m 0600 \ /etc/iexexchanger/update.yaml \ "$IEX_UPDATE_DIR/update.yaml" IEX_UPDATE_CONFIG="$IEX_UPDATE_DIR/update.yaml" ``` Используйте новый каталог, в котором ещё нет файлов другой операции. Не перезаписывайте комплект и конфигурацию незавершённого запуска. `/etc/iexexchanger/update.yaml` — стандартный базовый конфиг. Если он размещён иначе, скопируйте действующий полный файл по фактическому пути. Сохраняйте остальные параметры установки. Откройте копию конфигурации в текстовом редакторе: ```bash sudoedit "$IEX_UPDATE_CONFIG" ``` Выберите один источник комплекта: {% tabs %} {% tab title="Локальные ZIP" %} Загрузите пару ZIP через SFTP или SCP. В командах замените `/home/SSH_USER/iex-upload` фактическим абсолютным путём к каталогу передачи. Для локального варианта скопируйте два переданных файла в этот каталог: ```bash sudo install -o root -g root -m 0600 \ /home/SSH_USER/iex-upload/iexexchanger_backend_update.zip \ "$IEX_UPDATE_DIR/iexexchanger_backend_update.zip" sudo install -o root -g root -m 0600 \ /home/SSH_USER/iex-upload/iexexchanger_frontend_update.zip \ "$IEX_UPDATE_DIR/iexexchanger_frontend_update.zip" ``` В существующей структуре `spec` задайте источник двух файлов и встроенный план. Следующий блок — фрагмент полного файла, а не замена всей конфигурации: ```yaml spec: input: mode: loose loose: backend: type: local path: /home/iex-updates/RELEASE_ID/iexexchanger_backend_update.zip frontend: type: local path: /home/iex-updates/RELEASE_ID/iexexchanger_frontend_update.zip plan: mode: builtin ``` Не создавайте второй раздел `spec` или второй блок `input`: измените соответствующие значения в скопированном полном файле. Оставьте действующими параметры состояния установки, резервного копирования, обслуживания, каталогов и канала. {% endtab %} {% tab title="HTTPS" %} Для прямых доверенных HTTPS-адресов задайте источники файлов в копии полной конфигурации: ```yaml spec: input: mode: loose loose: backend: type: https url: https://files.example.com/iexexchanger_backend_update.zip frontend: type: https url: https://files.example.com/iexexchanger_frontend_update.zip plan: mode: builtin ``` `files.example.com` — пример: замените его предоставленными адресами файлов одного релиза. Updater получает архивы на сервер, затем выполняет те же проверки комплекта и плана. Адрес должен отдавать ZIP, а не страницу входа или карточку релиза. Временные ссылки должны действовать на время получения файлов. Не отключайте проверку HTTPS или сетевые ограничения для обхода ошибки загрузки. Подтверждённое подключение **«Обновления с сервера»** обслуживается агентом и панелью. В обычном CLI используйте поддерживаемый режим `loose` с локальными или HTTPS-файлами. Отдельной команды `iex-updater download` для этого подключения нет. {% endtab %} {% endtabs %} #### Если применяется новый ZIP лицензии Поместите его в каталог операции с владельцем `root:root` и правами `0600`. Внутри `spec.input.loose`, рядом с `backend` и `frontend`, добавьте: ```yaml license: source: type: local path: /home/iex-updates/RELEASE_ID/ФАКТИЧЕСКОЕ_ИМЯ_ЛИЦЕНЗИИ.zip ``` Укажите фактическое имя официального ZIP для этого домена. Если у источника уже заданы `sha256` и `sizeBytes`, они должны соответствовать выбранному файлу. Если новая лицензия не применяется, дополнительный источник не нужен. При уже существующем источнике проверьте, что он соответствует этой операции и доступен Updater. {% endstep %} {% step %} ### Проверьте конфигурацию и план В той же SSH-сессии выполните по очереди: ```bash sudo /usr/local/sbin/iex-updater \ --config "$IEX_UPDATE_CONFIG" \ config validate ``` ```bash sudo /usr/local/sbin/iex-updater \ --config "$IEX_UPDATE_CONFIG" \ checklist ``` ```bash sudo /usr/local/sbin/iex-updater \ --config "$IEX_UPDATE_CONFIG" \ plan ``` Переходите к следующей команде после устранения ошибок предыдущей. Проверьте исходную и целевую версии, маршрут, контрольные суммы, обязательное копирование, обслуживание и изменения окружения. В `checklist` могут быть перечислены возможности, не используемые выбранным режимом. Например, отметка о неподключённом `input.remote-api` сама по себе не запрещает поддерживаемую установку через `loose` и `builtin`. Оценивайте ошибки готовности выбранного способа. Затем выполните предварительную проверку этапов: ```bash sudo /usr/local/sbin/iex-updater \ --config "$IEX_UPDATE_CONFIG" \ apply --dry-run ``` `plan` и `apply --dry-run` не выполняют установку. Они не заменяют создание копии при реальном запуске и не резервируют место на диске. Если предварительная проверка завершилась ошибкой, устраните её до `apply`. {% endstep %} {% step %} ### Запустите установку После проверки плана и согласования времени выполните: ```bash sudo /usr/local/sbin/iex-updater \ --config "$IEX_UPDATE_CONFIG" \ apply ``` Запустите команду один раз и дождитесь результата. Сохраняйте эту SSH-сессию на время выполнения. При потере соединения сначала выясните, продолжает ли работать существующий процесс. Параллельный запуск из панели, перезапись конфигурации или замена ZIP во время операции недопустимы. {% endstep %} {% step %} ### Проверьте отчёт операции ```bash sudo /usr/local/sbin/iex-updater status sudo /usr/local/sbin/iex-updater reports list --kind update sudo /usr/local/sbin/iex-updater reports show update ``` Сверьте время и идентификатор запуска: последний отчёт должен относиться к выполненной операции. Для конкретного запуска используйте: ```bash sudo /usr/local/sbin/iex-updater reports show update RUN_ID ``` Замените `RUN_ID` идентификатором из списка отчётов. Сохраните исходную и целевую версии, статус, идентификатор и путь к отчёту. После успешного результата выполните проверки из раздела **«Проверка после обновления» этой инструкции**. {% endstep %} {% endstepper %} ## Проверка после обновления {% stepper %} {% step %} ### Проверьте сервер После подтверждённого успешного обновления, отката или возврата выполните: ```bash sudo /usr/local/sbin/iex-updater status sudo /usr/local/sbin/iexctl services verify sudo /usr/local/sbin/iexctl doctor sudo /usr/local/sbin/iexctl backup status sudo systemctl --failed --no-pager sudo systemctl is-enabled iex-update-agent.service sudo systemctl is-active iex-update-agent.service ``` Текущая версия должна совпадать с результатом операции, обслуживание — быть выключено, управляемые службы — работать. Для агента ожидаются `enabled` и `active`. Ошибки относящихся к обменнику служб требуют диагностики. Если сохранились Installer и исходный файл установки, дополнительно используйте проверки по их фактическим путям. В следующем примере предполагается, что файлы находятся в `/home/installer`; замените пути своим расположением: ```bash sudo /home/installer/iex-installer \ --config /home/installer/install.yaml \ verify sudo /home/installer/iex-installer \ --config /home/installer/install.yaml \ verify --public-endpoints ``` При отсутствии сохранённой конфигурации не создавайте её наугад для проверки. Используйте остальные команды и восстановите проверочную конфигурацию с техническим специалистом. {% endstep %} {% step %} ### Проверьте сайт и панель Откройте клиентский сайт `https://ваш_домен` и сохранённый адрес входа в панель на серверной части `https://app.ваш_домен`. Проверьте: * Оба домена доступны по HTTPS. * Сайт загружается и показывает ожидаемые страницы, направления и курсы. * Вход в административную панель работает. * Разделы панели открываются после перезагрузки страницы. * В обновлениях отображается правильная текущая версия. * Режим обслуживания завершён. * API, WebSocket и используемые интеграции работают. * Основные функции, затронутые релизом, проходят согласованный тестовый сценарий. Ошибки `500`, бесконечная загрузка и недоступность ключевых функций требуют проверки даже при успешном серверном отчёте. Для проверки создания заявок используйте согласованный сценарий: такие действия могут отправлять уведомления и обращаться к интеграциям. {% endstep %} {% step %} ### Сохраните резервную копию и результат После проверки создайте отдельную резервную копию новой версии: ```bash sudo /usr/local/sbin/iexctl backup run sudo /usr/local/sbin/iexctl backup status ``` Убедитесь, что копия завершилась успешно и время последнего копирования обновилось. Ошибка новой копии требует исправления резервного копирования; повторно устанавливать уже принятую версию для этого не нужно. Сохраните отчёт операции, исходную и целевую версии, дату и ответственного специалиста. В отчёте должны быть подтверждены резервное копирование и точки обеих баз. Прежний релиз и точки возврата оставьте на период проверки; оригинальные файлы храните вне обновляемого сервера. Обновление завершено после подтверждения серверного результата, работы публичных доменов и основных функций, завершения обслуживания и сохранения проверенной резервной копии новой версии. {% endstep %} {% endstepper %} ## Продолжение и восстановление ### Если прервалась SSH-сессия Для операции, первоначально запущенной из терминала, используйте прежний полный конфиг по прежнему абсолютному пути: ```bash IEX_UPDATE_CONFIG='/home/iex-updates/RELEASE_ID/update.yaml' sudo /usr/local/sbin/iex-updater \ --config "$IEX_UPDATE_CONFIG" \ apply --resume ``` Сначала убедитесь, что прежний процесс завершился и на сервере не выполняется другая операция. Для `--resume` сохраняйте исходные ZIP, их содержимое, полный конфиг и путь к нему. Новая SSH-сессия не сохраняет переменную `IEX_UPDATE_CONFIG`: задайте её заново тем же значением. Операция панели использует собственную сохранённую конфигурацию агента. Подмена её обычным `/etc/iexexchanger/update.yaml` не продолжает ту же попытку. Для такой операции используйте интерфейс либо восстановление специалистом по её отчёту и фактическому пути конфигурации. ### Восстановление неуспешной установки Команда `recover-failed` возвращает рабочую принятую версию после определённого типа сбоя: обновление уже сохранило точку обеих баз, но новая версия ещё не принята и её успешное состояние не зафиксировано. Это отдельная операция восстановления. Для успешно принятой новой версии применяется штатный откат. Возможность восстановления проверяется по защищённому журналу и сохранённым точкам. Технический специалист выбирает фактический полный конфиг проблемной операции и сначала проверяет восстановление: ```bash sudo /usr/local/sbin/iex-updater \ --config "$IEX_UPDATE_CONFIG" \ recover-failed --dry-run ``` Если проверка подтверждает нужную рабочую версию и сохранённые данные, выполняет: ```bash sudo /usr/local/sbin/iex-updater \ --config "$IEX_UPDATE_CONFIG" \ recover-failed ``` Для продолжения уже начатого и прерванного восстановления: ```bash sudo /usr/local/sbin/iex-updater \ --config "$IEX_UPDATE_CONFIG" \ recover-failed --resume ``` После результата проверьте состояние и отчёт: ```bash sudo /usr/local/sbin/iex-updater status sudo /usr/local/sbin/iex-updater reports show recovery sudo /usr/local/sbin/iexctl services verify ``` После успешного восстановления прежняя попытка обновления закрывается. Для исправленных архивов создайте новую подготовку; продолжать старый `apply --resume` после восстановления нельзя. {% hint style="danger" %} Восстановление баз возвращает данные к сохранённой точке. Не отключайте обслуживание вручную и не восстанавливайте одну базу отдельно: код, основная база и Pulse должны соответствовать друг другу. {% endhint %} ### Диагностика для поддержки Подготовьте способ запуска, время, идентификатор операции, исходную и целевую версии, название остановившегося этапа, код ошибки и рекомендацию системы. Для серверной диагностики технический специалист может выполнить: ```bash sudo /usr/local/sbin/iex-updater reports list --kind update sudo /usr/local/sbin/iex-updater reports show update sudo systemctl status iex-update-agent.service --no-pager sudo journalctl -u iex-update-agent.service -n 100 --no-pager sudo /usr/local/sbin/iexctl --format json support bundle ``` Для отката используйте `reports show rollback`, для восстановления — `reports show recovery`. Команда `support bundle` показывает путь к диагностическому комплекту. Передавайте материалы через защищённый канал. Не добавляйте отдельно `.env`, пароли, приватные ключи, cookie, коды подтверждения, ZIP лицензии и дампы баз. ## Откат и возврат через терминал Откат нужен при подтверждённой проблеме уже установленной новой версии. Он является отдельной операцией с планом, проверками и резервным копированием. {% hint style="danger" %} Откат возвращает код и обе базы данных к сохранённому состоянию выбранной версии. Данные, созданные или изменённые после этой точки, будут потеряны. Перед подтверждением оцените последствия для заявок, платежей, пользователей и других данных. {% endhint %} Для быстрого отката должны сохраниться файлы версии и подтверждённые данные восстановления. Наличие записи о старой версии само по себе не гарантирует возможность отката. `rollback` выбирает сохранённый предыдущий релиз. Произвольную старую версию нельзя выбрать только по номеру. Используйте действующую полную конфигурацию и задайте её фактический путь в `IEX_UPDATE_CONFIG`. Сначала проверьте план: ```bash sudo /usr/local/sbin/iex-updater \ --config "$IEX_UPDATE_CONFIG" \ rollback --dry-run ``` После проверки версии назначения и точек обеих баз запустите: ```bash sudo /usr/local/sbin/iex-updater \ --config "$IEX_UPDATE_CONFIG" \ rollback ``` Для продолжения этого же прерванного отката: ```bash sudo /usr/local/sbin/iex-updater \ --config "$IEX_UPDATE_CONFIG" \ rollback --resume ``` После завершения: ```bash sudo /usr/local/sbin/iex-updater status sudo /usr/local/sbin/iex-updater reports show rollback sudo /usr/local/sbin/iexctl services verify ``` При успешном откате ранее активная версия становится предыдущей. Если она сохранена и возврат допустим, новая команда `rollback --dry-run` покажет переход к ней. Возврат выполняется новой операцией `rollback`; `rollback --resume` продолжает уже начатый откат. После отката или возврата повторите проверки сервера, сайта и обеих баз. Данные версий не объединяются: каждое восстановление возвращает выбранное сохранённое состояние. ## Хранение файлов операции Сохраните вне обновляемого сервера оригинальные ZIP установленного релиза, применяемые лицензионные файлы, опубликованные контрольные суммы, отчёт и идентификатор операции. На период проверки новой версии сохраняйте прежний релиз и точки возврата. Если требуется продолжение или восстановление, оставьте также входные архивы и конфигурацию этой операции. Копии входных ZIP можно удалить после успешной проверки продукта и завершения всех операций, которым они нужны. Для комплектов, принятых агентом, используйте доступное штатное действие удаления. Удаление сохранённых релизов и проверка точки отката выполняются через административную панель. Порядок описан в [инструкция по обновлению с сервера](/ustanovka-i-obnovlenie/obnovlenie-produkta/obnovlenie-s-servera.md).