Обновление через терминал

Архивы и конфигурация Updater, установка, проверка, продолжение и восстановление через команды

Используйте Updater на сервере для установки проверенной пары ZIP. Файлы могут находиться в локальном каталоге или поступать по прямым HTTPS-адресам. Для каждой операции сохраняйте отдельную полную конфигурацию, исходные архивы и отчёт.

Готовый промпт для обновления через терминал

Укажите фактический сервер, пути к двум ZIP или их HTTPS-адреса и путь к полной конфигурации операции. Секретные данные передавайте отдельно через предусмотренный защищённый способ.

Обновление через терминал сервера

Помоги обновить управляемую установку 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 и не отключай обслуживание вручную после ошибки.

Подготовка сервера

Для подключения используйте своего SSH-пользователя и адрес сервера:

Подключение к серверу по SSH

ssh SSH_USER@SERVER_IP

Замените SSH_USER и SERVER_IP фактическими значениями. После подключения выполните:

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 или готового плана не означает, что эти копии уже созданы: резервное копирование выполняется при установке.

Технический специалист может проверить состояние резервного копирования командой:

sudo /usr/local/sbin/iexctl backup status

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

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

Проверьте службу обновлений

Панель передаёт операции серверному агенту Update Agent. Через него выполняются проверка архивов, установка, продолжение, откат и удаление сохранённых версий.

Если раздел показывает «Обновления временно недоступны», прочитайте указанную причину. Технический специалист проверяет сервер:

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

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

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

Установка обновления

1

Подготовьте архивы и полную конфигурацию

Для каждой операции используйте отдельный каталог. В примере это /home/iex-updates/RELEASE_ID; замените RELEASE_ID уникальным обозначением операции и используйте этот же путь во всех последующих фрагментах.

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 — стандартный базовый конфиг. Если он размещён иначе, скопируйте действующий полный файл по фактическому пути. Сохраняйте остальные параметры установки.

Откройте копию конфигурации в текстовом редакторе:

sudoedit "$IEX_UPDATE_CONFIG"

Выберите один источник комплекта:

Локальные ZIP

Загрузите пару ZIP через SFTP или SCP. В командах замените /home/SSH_USER/iex-upload фактическим абсолютным путём к каталогу передачи.

Для локального варианта скопируйте два переданных файла в этот каталог:

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 задайте источник двух файлов и встроенный план. Следующий блок — фрагмент полного файла, а не замена всей конфигурации:

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: измените соответствующие значения в скопированном полном файле. Оставьте действующими параметры состояния установки, резервного копирования, обслуживания, каталогов и канала.

HTTPS

Для прямых доверенных HTTPS-адресов задайте источники файлов в копии полной конфигурации:

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 для этого подключения нет.

Если применяется новый ZIP лицензии

Поместите его в каталог операции с владельцем root:root и правами 0600. Внутри spec.input.loose, рядом с backend и frontend, добавьте:

license:
  source:
    type: local
    path: /home/iex-updates/RELEASE_ID/ФАКТИЧЕСКОЕ_ИМЯ_ЛИЦЕНЗИИ.zip

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

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

2

Проверьте конфигурацию и план

В той же SSH-сессии выполните по очереди:

sudo /usr/local/sbin/iex-updater \
  --config "$IEX_UPDATE_CONFIG" \
  config validate

sudo /usr/local/sbin/iex-updater \
  --config "$IEX_UPDATE_CONFIG" \
  checklist

sudo /usr/local/sbin/iex-updater \
  --config "$IEX_UPDATE_CONFIG" \
  plan

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

В checklist могут быть перечислены возможности, не используемые выбранным режимом. Например, отметка о неподключённом input.remote-api сама по себе не запрещает поддерживаемую установку через loose и builtin. Оценивайте ошибки готовности выбранного способа.

Затем выполните предварительную проверку этапов:

sudo /usr/local/sbin/iex-updater \
  --config "$IEX_UPDATE_CONFIG" \
  apply --dry-run

plan и apply --dry-run не выполняют установку. Они не заменяют создание копии при реальном запуске и не резервируют место на диске. Если предварительная проверка завершилась ошибкой, устраните её до apply.

3

Запустите установку

После проверки плана и согласования времени выполните:

sudo /usr/local/sbin/iex-updater \
  --config "$IEX_UPDATE_CONFIG" \
  apply

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

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

4

Проверьте отчёт операции

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

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

sudo /usr/local/sbin/iex-updater reports show update RUN_ID

Замените RUN_ID идентификатором из списка отчётов. Сохраните исходную и целевую версии, статус, идентификатор и путь к отчёту.

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

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

1

Проверьте сервер

После подтверждённого успешного обновления, отката или возврата выполните:

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; замените пути своим расположением:

sudo /home/installer/iex-installer \
  --config /home/installer/install.yaml \
  verify

sudo /home/installer/iex-installer \
  --config /home/installer/install.yaml \
  verify --public-endpoints

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

2

Проверьте сайт и панель

Откройте клиентский сайт https://ваш_домен и сохранённый адрес входа в панель на серверной части https://app.ваш_домен.

Проверьте:

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

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

3

Сохраните резервную копию и результат

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

sudo /usr/local/sbin/iexctl backup run
sudo /usr/local/sbin/iexctl backup status

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

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

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

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

Если прервалась SSH-сессия

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

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 возвращает рабочую принятую версию после определённого типа сбоя: обновление уже сохранило точку обеих баз, но новая версия ещё не принята и её успешное состояние не зафиксировано.

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

Технический специалист выбирает фактический полный конфиг проблемной операции и сначала проверяет восстановление:

sudo /usr/local/sbin/iex-updater \
  --config "$IEX_UPDATE_CONFIG" \
  recover-failed --dry-run

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

sudo /usr/local/sbin/iex-updater \
  --config "$IEX_UPDATE_CONFIG" \
  recover-failed

Для продолжения уже начатого и прерванного восстановления:

sudo /usr/local/sbin/iex-updater \
  --config "$IEX_UPDATE_CONFIG" \
  recover-failed --resume

После результата проверьте состояние и отчёт:

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 после восстановления нельзя.

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

Диагностика для поддержки

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

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

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 лицензии и дампы баз.

Откат и возврат через терминал

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

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

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

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

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

sudo /usr/local/sbin/iex-updater \
  --config "$IEX_UPDATE_CONFIG" \
  rollback --dry-run

После проверки версии назначения и точек обеих баз запустите:

sudo /usr/local/sbin/iex-updater \
  --config "$IEX_UPDATE_CONFIG" \
  rollback

Для продолжения этого же прерванного отката:

sudo /usr/local/sbin/iex-updater \
  --config "$IEX_UPDATE_CONFIG" \
  rollback --resume

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

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 можно удалить после успешной проверки продукта и завершения всех операций, которым они нужны. Для комплектов, принятых агентом, используйте доступное штатное действие удаления.

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