> 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.md). # Обновление продукта Подробная инструкция по обновлению iEXExchanger Эта инструкция описывает штатное обновление уже установленного iEXExchanger. Обновление можно выполнить двумя способами: * через административную панель; * через терминал сервера. Оба способа используют Updater — серверную программу, которая проверяет архивы, создаёт резервную копию, применяет изменения и проверяет результат. Административная панель передаёт задания через Update Agent — службу обновлений на сервере. В терминале технический специалист запускает Updater напрямую. Используйте эту инструкцию для обычной установки на сервере, выполненной через Installer iEXExchanger. Совместимость выбранной версии и возможность перехода система проверит перед запуском. {% hint style="danger" icon="triangle-exclamation" %} ## **Если iEXExchanger установлен через FASTPANEL** Новая система обновлений не предназначена для старых установок, развёрнутых через FASTPANEL. У старой установки другая организация файлов и серверных служб. Наличие работающего сайта само по себе не означает совместимость с новым механизмом обновлений. Не распаковывайте новые архивы поверх работающего проекта и не запускайте серверные команды обновления вручную. Рекомендуемый вариант — подготовить новый чистый сервер, выполнить [установку продукта](https://docs.iexexchanger.com/ustanovka-i-obnovlenie/ustanovka-produkta), проверить новую систему и отдельно перенести действующий проект. До завершения переноса сохраните старый сервер и его базы данных. {% endhint %} {% hint style="danger" icon="docker" %} ## **Если iEXExchanger установлен через Docker** Эта инструкция не применяется к Docker-установке. В Docker-режиме раздел системных обновлений и команда `iex-updater apply` не используются. Не запускайте повторную установку с архивами обновления и не удаляйте контейнеры или тома с данными. Для такого сервера используйте отдельную инструкцию обновления Docker-релиза. Если она ещё не предоставлена для нужного перехода, сохраните работающую версию и обратитесь в техническую поддержку. {% endhint %} ### Обозначения доменов В инструкции используются два адреса: ``` https://ваш_домен https://app.ваш_домен ``` `https://ваш_домен` — основной домен Frontend, на котором открывается клиентский сайт обменного пункта. `https://app.ваш_домен` — технический поддомен Backend. На нём находятся административная панель, API и другие серверные функции iEXExchanger. При проверке заменяйте эти обозначения фактическими адресами проекта. Для входа в административную панель используйте сохранённый адрес входа: он может отличаться от главной страницы технического поддомена. Обновление сохраняет настроенные домены. Повторно настраивать DNS или менять адреса в конфигурации для обычного обновления не требуется. *** ## Готовые промпты для ИИ-агента Выберите промпт для нужного способа обновления. Передайте агенту адреса проекта и доступ через защищённое подключение или уже авторизованную сессию. Не вставляйте в открытый чат пароли, приватные ключи, коды 2FA, содержимое `.env` или файлы лицензии. Откат, восстановление баз и удаление точки возврата требуют отдельного решения, если вы ещё не согласовали эти действия. {% content-ref url="/pages/U0YPvPyzY7nFVhyGTJFI" %} [Работа с AI](/nachalo-raboty/rabota-s-ai.md) {% endcontent-ref %} {% prompt description="Обновление через административную панель" icon="desktop" openInAIProviders="true" defaultExpanded="partial" %} ```markdown Обнови установленный iEXExchanger через административную панель штатным способом. Основной сайт: https://ваш_домен Backend: https://app.ваш_домен Адрес входа в административную панель: <сохранённый адрес проекта> Используй уже авторизованные сессии официального кабинета iEXExchanger и административной панели. Не выводи пароли, коды 2FA, содержимое .env, лицензии или другие секреты. Сначала проверь тип установки. Эта инструкция предназначена для обычной установки через Installer. Если используется FASTPANEL или Docker, Update Agent недоступен, текущий релиз не подтверждён системой, включён Maintenance либо уже выполняется другая операция, не начинай новое обновление. Сообщи состояние и требуемое действие. В официальном кабинете скачай Backend Update ZIP и Frontend Update ZIP одного целевого релиза. Не используй архивы полной установки, не переименовывай и не изменяй ZIP. Если вместе с релизом выдан новый ZIP лицензии, сохрани его отдельно. Если требуется его применение, до загрузки Backend и Frontend проверь, что технический специалист указал правильный источник лицензии в /etc/iexexchanger/updater/update.yaml. В форме панели нет поля лицензии: не загружай её вместо Backend или Frontend. Если система не может подтвердить сохранение действующей лицензии, сначала реши этот вопрос. В разделе «Обновления» проверь текущую версию, состояние «Готово», версию агента и отсутствие активной операции. Данные каталога показывают доступность релиза, но не подтверждают его установку. Нажми «Новое обновление», выбери Backend и Frontend, затем «Загрузить и проверить». Дождись серверной проверки и нажми «Сформировать план». Проверь исходную и целевую версии, поддерживаемый переход, обязательные резервную копию и Maintenance, изменения окружения и предупреждения. Не считай сформированный план подтверждением уже созданного backup или проверкой всех ресурсов. Запас диска система проверит перед резервным копированием. После проверки нажми «Подтвердить обновление» и «Запустить обновление» один раз. Не запускай параллельную команду через SSH. Дождись идентификатора операции и итогового статуса. При временной потере связи или ответе 503 сначала продолжай чтение состояния. Используй «Повторить отправку» только когда эту кнопку предлагает интерфейс. Для существующей прерванной операции используй «Продолжить», только если действие доступно и причина остановки устранена. Статус этапа «Проверено — изменений не требуется» означает успешную проверку. Он не равен ошибке и не требует принудительного повторения этапа. После состояния «Успешно» проверь новую текущую версию, выключенный Maintenance, основной сайт, вход в панель, переход между разделами, критичные функции проекта, «Установленные версии», «Историю операций» и «Журнал действий». Серверные проверки и резервную копию новой версии передай техническому специалисту, если у тебя нет разрешённого SSH-доступа. При ошибке не создавай новую операцию поверх незавершённой, не снимай Maintenance и не выполняй откат или восстановление баз без согласованного решения. Сохрани идентификатор, неуспешный этап и рекомендацию системы. В финальном отчёте укажи исходную и целевую версии, результат проверки архивов и backup, идентификатор и итог операции, состояние Maintenance, результаты проверок сайта и панели. Отдельно укажи, какие проверки не выполнены. Секреты не включай. ``` {% endprompt %} {% prompt description="Обновление через терминал" icon="terminal" openInAIProviders="true" defaultExpanded="partial" %} ```markdown Обнови установленный iEXExchanger через штатный Updater на сервере. Сервер: SSH-пользователь: <пользователь с root или sudo> Основной сайт: https://ваш_домен Backend: https://app.ваш_домен Каталог с официальными архивами: <абсолютный путь> Используй согласованный способ подключения. Не выводи пароли, ключи, содержимое .env и лицензий. Все команды обновления выполняй на целевом сервере. Сначала прочитай состояние: iex-updater version, iex-updater status, состояние iex-update-agent.service, iexctl services verify, iexctl backup status и нормализованную конфигурацию /etc/iexexchanger/updater/update.yaml через config show. Не начинай новое обновление на FASTPANEL- или Docker-установке, без подтверждённого текущего релиза, при активной операции или незавершённом Maintenance. Сначала установи причину и разрешённое следующее действие. Найди неизменённые Backend Update ZIP и Frontend Update ZIP одного официального релиза. Версию определяй по проверенным данным комплекта. Не переименовывай архивы, не используй full-install ZIP и не распаковывай файлы поверх проекта. Для новой операции при необходимости создай закрытый каталог /home/iex-updates/RELEASE и скопируй установленный update.yaml. Не перезаписывай конфигурацию уже начатой операции. В полной копии измени только необходимые пути к архивам. Каталог должен принадлежать root с правами 0700, конфигурация и ZIP — root с правами 0600. Текущая лицензия обычно сохраняется автоматически. Новый ZIP указывай в spec.input.loose.license.source, если он должен применяться с этим релизом или система требует его для проверки лицензии. Проверь, что в копии нет неподходящего пути к лицензии другой операции. Не отключай backupRequired, maintenanceRequired или automaticSelfUpdate. Задай IEX_UPDATE_CONFIG с абсолютным путём к выбранному полному файлу. Используй тот же путь и неизменные файлы во всех командах этой операции. Последовательно выполни config validate, checklist, plan и apply --dry-run. Проверь не только код завершения, но и содержание результатов. Неподдерживаемые режимы input.bundle, input.remote-api и plan.bundle не являются ошибкой для штатного обновления парой ZIP в режиме loose с планом builtin. Проверь правильность версий и перехода, обязательные backup и Maintenance, изменения окружения и запас диска. plan и apply --dry-run не обновляют установленные управляющие компоненты и не применяют изменения приложения. Их необходимое обновление выполняется при фактическом apply. Если проверки успешны, запусти apply один раз. Не запускай обновление параллельно из панели, не выполняй ручные миграции, Product Updates, Composer, npm, переключение current или отключение Maintenance. После успеха проверь status, reports list --kind update, reports show update, iexctl services verify, iexctl doctor, iexctl backup status, службу Update Agent и публичные домены. Используй сохранённый Installer и его фактический install.yaml для verify и verify --public-endpoints, если они доступны. Не создавай проверочный конфиг наугад. Проверь сайт, вход в панель и согласованные функции проекта, затем создай резервную копию новой версии. При потере SSH сначала установи, продолжает ли работать исходный процесс. apply --resume допустим для той же прерванной операции с исходными архивами и конфигурацией. Операции, созданные в панели, используют отдельные конфигурации и журналы: не пытайся продолжать их обычной CLI-командой с основным update.yaml. recover-failed, rollback и удаление точки возврата выполняй только по подтверждённому состоянию и согласованному решению с учётом данных. Сначала используй доступную предварительную проверку. После успешного recover-failed старое обновление не продолжай: для исправленного комплекта нужна новая операция. В финальном отчёте укажи исходную и целевую версии, путь конфигурации, результат предварительных проверок и backup, идентификатор запуска, итоговый статус, состояние Maintenance, серверные и публичные проверки, путь к отчёту и оставшиеся ограничения. Секреты не включай. ``` {% endprompt %} ## Какой способ выбрать {% tabs %} {% tab title="Административная панель" icon="desktop" %} Подходит владельцу проекта или ответственному администратору. Потребуются: * доступ к административной панели; * разрешение на запуск обновлений; * архивы Backend и Frontend на компьютере; * подготовленная лицензия, если для обновления требуется её замена. Файлы продукта загружаются через браузер. План, ход операции и результат отображаются в разделе «Обновления». Серверные команды при штатной работе панели выполняет агент. {% endtab %} {% tab title="Терминал" icon="terminal" %} Подходит техническому специалисту. Потребуются: * SSH-доступ к серверу; * права пользователя `root` или `sudo`; * архивы Backend и Frontend на сервере, а при необходимости — ZIP лицензии; * установленный `iex-updater`; * действующая конфигурация Updater. Команды выполняются непосредственно на сервере, а результат подтверждается серверным отчётом. {% endtab %} {% endtabs %} {% hint style="warning" icon="ban" %} Для одной операции выберите только один способ. Не запускайте одно обновление одновременно через административную панель и терминал. {% endhint %} ## Этап 1. Подготовка к обновлению ### Проверьте тип установки Штатное обновление доступно, если продукт установлен через Installer и управляется системными компонентами iEXExchanger. На сервере должны существовать: ``` /usr/local/sbin/iex-updater /usr/local/sbin/iexctl /etc/iexexchanger/installation.json /etc/iexexchanger/updater/update.yaml ``` В административной панели должен открываться раздел «Обновления», а блок «Состояние обновлений» должен показывать готовность сервера. Если Updater отсутствует, Update Agent недоступен или текущий релиз не подтверждён системой, сначала устраните это состояние. Для старого управляющего комплекта может потребоваться отдельная процедура обновления серверных инструментов. Выполняйте её по соответствующей инструкции или указанию технической поддержки. ### Выберите время и проверьте резервное копирование Запланируйте обновление на период низкой нагрузки и предупредите сотрудников о временном режиме обслуживания. Дождитесь завершения других работ на сервере. Управляемое резервное копирование должно быть настроено, а хранилище — доступно. Наличие вчерашней копии не заменяет обязательную копию, которую Updater создаёт для текущего обновления. Продолжительность зависит от объёма данных, скорости диска, хранилища резервных копий и состава изменений. Не прерывайте операцию только потому, что отдельный этап выполняется дольше ожидаемого: сначала проверьте журнал и состояние. ### Проверьте свободное место Во время обновления одновременно могут храниться: * полный backup; * точка возврата основной базы и базы Pulse; * текущий релиз; * новый релиз; * предыдущий релиз; * загруженные ZIP-файлы; * временные файлы проверки и распаковки. Перед резервным копированием и включением Maintenance система проверяет фактический запас диска и inode — доступных записей файловой системы для создания файлов и каталогов. При расчёте учитываются временные данные и дополнительный запас. Через терминал эту проверку можно выполнить заранее командой `apply --dry-run`, описанной ниже. Само формирование плана ещё не подтверждает достаточность свободного места на момент запуска. Если места недостаточно, проверка остановит обновление до резервного копирования и включения режима обслуживания. Устраните причину и повторите проверку; не отключайте защиту. {% hint style="warning" icon="hard-drive" %} Не удаляйте текущий или предыдущий релиз вручную ради освобождения места. Не удаляйте точки возврата и резервные копии, пока не завершены обновление и итоговая проверка. {% endhint %} ## Этап 2. Получение файлов обновления Скачивайте файлы только в персональном кабинете на официальном сайте iEXExchanger. {% content-ref url="/pages/hSsHgydQTzax5c06kVsd" %} [Файлы лицензии и релизы](/nachalo-raboty/faily-licenzii-i-relizy.md) {% endcontent-ref %} Для обновления нужны два отдельных файла одной версии: 1. ZIP обновления Backend. 2. ZIP обновления Frontend. Если для выбранного релиза выдан новый ZIP лицензии домена, скачайте и сохраните его отдельно. Порядок его применения описан ниже. Типовые имена файлов: ``` iexexchanger_backend_update.zip iexexchanger_frontend_update.zip iex-license-ваш_домен-версия.zip ``` Официальные имена Backend и Frontend могут дополнительно содержать версию, дату или уникальный идентификатор. Например: ``` update_backend_версия_дата_идентификатор.zip update_frontend_версия_дата_идентификатор.zip ``` Не переименовывайте скачанные файлы. Система определяет назначение и версию не только по имени, но и по внутренним метаданным, структуре пары и контрольным суммам. ### Требования к паре Backend и Frontend Оба архива должны: * относиться к одному официальному релизу; * оставаться без изменений после скачивания; * использоваться в соответствующем поле Backend или Frontend; * быть обычными ZIP-файлами, а не ссылками или специальными файлами. Ограничения сжатых архивов:
ФайлМаксимальный размер
Backend400 MiB
Frontend100 MiB
Вся пара500 MiB
Если интерфейс или сервер показывает меньший доступный лимит, используйте лимит конкретного сервера. Архивы обновления не должны содержать `.env`. Действующие настройки и секреты берутся из установленной системы. Если релиз требует изменения управляемого окружения, Updater выполняет предусмотренные изменения автоматически. Переносить настройки в ZIP вручную не нужно. ### Как используется файл лицензии При обычном обновлении Updater переносит действующие лицензионные файлы в новую версию. Отдельный ZIP нужен, когда требуется применить новую лицензию или система не может подтвердить состав уже установленной лицензии. {% tabs %} {% tab title="Обычное обновление" icon="floppy-disk" %} Если релиз не требует замены лицензии и система подтверждает возможность её сохранения, Updater использует действующие лицензионные файлы текущей установки. Если новый ZIP выдан в кабинете, сохраните его у владельца проекта. Само скачивание файла не означает, что его нужно вручную распаковать на сервере. {% endtab %} {% tab title="Требуется новая лицензия" icon="key" %} Если для релиза требуется новая лицензия, технический специалист заранее загружает ZIP на сервер и указывает его путь в конфигурации Updater. Это также требуется, если проверка не может подтвердить сохранение действующей лицензии. * При обновлении через терминал укажите файл в `spec.input.loose.license.source` используемого `update.yaml`. * При обновлении через административную панель укажите лицензию в основной конфигурации `/etc/iexexchanger/updater/update.yaml` **до загрузки Backend и Frontend**. Конфигурация и ZIP должны принадлежать `root` и быть закрыты от остальных пользователей. Пример раздела лицензии приведён в инструкции для терминала. После принятия файлов агент сохраняет отдельную конфигурацию этой операции. Последующая правка основного `update.yaml` не меняет уже подготовленную загрузку. Если обновление ещё не запускалось, после исправления лицензии подготовьте новую загрузку и новый план. Для начатой операции используйте порядок продолжения или восстановления. Updater проверит лицензию и применит её вместе с релизом. {% endtab %} {% endtabs %} {% hint style="danger" icon="upload" %} В форме административной панели есть только два поля: Backend и Frontend. Не загружайте ZIP лицензии ни в одно из этих полей. {% endhint %} ### Какие файлы нельзя использовать Не используйте вместо обновления: * архивы полной установки; * архив Linux Installer; * ZIP лицензии в поле Backend или Frontend; * Backend и Frontend от разных релизов; * изменённые или повреждённые ZIP-файлы; * файлы из сторонних источников; * один общий ZIP с несколькими вложенными архивами; * файлы, вручную переименованные в `backend.zip` или `frontend.zip`. {% hint style="info" icon="file-zipper" %} Устанавливать `zip` или `unzip` для обновления не требуется. Не распаковывайте архивы вручную: Updater самостоятельно проверяет и обрабатывает их. {% endhint %} ## Этап 3. Что система сделает автоматически Конкретный состав и количество этапов зависят от перехода между версиями. В обычном обновлении система выполняет следующие действия. {% stepper %} {% step %} ### Проверит систему и файлы Updater проверит текущую установленную версию, конфигурацию и совместимость перехода. Для архивов проверяются назначение, структура, размеры, контрольные суммы и принадлежность Backend и Frontend одному релизу. Одновременно выполняться может только одна изменяющая операция. {% endstep %} {% step %} ### Подготовит управляющие компоненты Если проверенный Backend содержит необходимое обновление Updater, Update Agent или `iexctl`, система применит его штатно при запуске обновления, до резервного копирования и изменения приложения. Формирование плана и предварительная проверка `apply --dry-run` эти программы не заменяют. {% endstep %} {% step %} ### Проверит место и создаст резервную копию До Maintenance система проверит запас диска и создаст полный управляемый backup: постоянные файлы, пользовательские данные, основную базу и базу Pulse. Будут проверены результат копирования и расписание следующих копий. Если обязательная копия не создана или не прошла проверку, обновление не перейдёт к изменению приложения. {% endstep %} {% step %} ### Подготовит новую версию Новый релиз будет подготовлен рядом с текущим. Действующая версия не перезаписывается распаковкой архива. Если для перехода нужны дополнительные пакеты окружения, система подготовит их по плану. {% endstep %} {% step %} ### Включит режим обслуживания Сайт перейдёт в Maintenance. Updater согласованно остановит очереди, планировщик фоновых задач и другие процессы, записывающие данные. {% endstep %} {% step %} ### Создаст точку возврата баз данных После остановки записи система сохранит согласованное состояние основной базы и базы Pulse. Эта точка используется для возврата к прежнему релизу и дополняет полный backup, созданный ранее. {% endstep %} {% step %} ### Применит изменения и переключит версию Updater выполнит предусмотренные изменения серверного окружения и Product Updates — штатную последовательность изменений приложения и его данных. Затем система закрепит версию приложения и сделает новый релиз текущим. Прежняя версия сохранится для возможного отката. {% endstep %} {% step %} ### Проверит результат Система запустит службы и проверит необходимые компоненты: веб-сервер, Backend, Frontend, API, WebSocket, базы данных, Redis и фоновые задачи. Maintenance будет снят после успешной проверки. Результаты этапов, сведения о резервной копии и точках возврата сохранятся в журнале и отчёте. {% endstep %} {% endstepper %} {% hint style="success" icon="shield" %} Обычное обновление не требует ручного запуска миграций, `php artisan`, Composer, npm или Product Updates. Необходимые версии серверных компонентов и их настройки определяются проверенным планом релиза. {% endhint %} ## Способ 1. Обновление через административную панель ### Необходимые разрешения Разрешение «Просмотр обновлений системы» предназначено для просмотра состояния и истории. Для запуска обновления или отката нужно разрешение «Запуск обновлений и откатов системы». Право запуска даёт возможность изменять работающую систему. Выдавайте его только ответственным администраторам. ### Выполните обновление {% stepper %} {% step %} #### Откройте раздел «Обновления» Проверьте: * текущую версию; * состояние «Готово»; * версию Update Agent; * отсутствие активной операции; * отсутствие Maintenance; * состояние официального каталога релизов. Блок «Актуальная версия iEXExchanger» показывает сведения официального каталога. Сообщение «Доступно обновление» не запускает скачивание или установку: архивы загружаются отдельно. Если показаны сохранённые данные или каталог временно недоступен, это относится к получению сведений о релизах. Фактическую установленную версию смотрите в блоке «Состояние обновлений». {% endstep %} {% step %} #### Нажмите «Новое обновление» Откроется форма с двумя отдельными полями: * Backend; * Frontend. ZIP лицензии в эту форму не загружается. {% endstep %} {% step %} #### Выберите файлы В поле Backend выберите официальный архив обновления Backend, а в поле Frontend — архив обновления Frontend того же релиза. Проверьте имена файлов до начала передачи. {% endstep %} {% step %} #### Нажмите «Загрузить и проверить» Дождитесь завершения передачи и серверной проверки. После принятия агент защищает файлы от дальнейшего изменения. Если браузер был перезагружен во время загрузки, повторно выберите ту же пару файлов. Если сессия загрузки ещё действительна, передача продолжится с подтверждённого сервером места. Не выбирайте другую пару для продолжения этой сессии. Если сессия истекла до запуска обновления, начните новую загрузку. {% endstep %} {% step %} #### Нажмите «Сформировать план» План не запускает обновление. Он должен показать: * переход с текущей версии на целевую; * обязательную резервную копию; * обязательный Maintenance; * возможные изменения серверного окружения; * последовательность этапов; * предупреждения и срок действия плана. Формирование плана ещё не создаёт резервную копию или новую точку возврата. Запас диска проверяется непосредственно перед резервным копированием при выполнении операции. Если срок плана истёк, сформируйте новый. Не запускайте устаревший план. {% endstep %} {% step %} #### Проверьте план Не продолжайте, если: * исходная версия не совпадает с установленной; * целевая версия не та, которую вы скачали; * Backend и Frontend не совпали; * резервное копирование или Maintenance отключены; * сервер сообщает о нехватке места; * маршрут обновления не поддерживается; * требуется ручное действие. {% endstep %} {% step %} #### Подтвердите запуск Нажмите «Подтвердить обновление», затем «Запустить обновление». Команда отправляется один раз. После подтверждения запуска появится идентификатор операции. Журнал будет пополняться по мере выполнения этапов. {% endstep %} {% step %} #### Дождитесь завершения Следите за журналом до итогового состояния. Если вкладка закрылась, снова откройте существующую операцию в истории. Во время Maintenance административное API может временно отвечать `503`. Это ожидаемо. Интерфейс читает состояние через монитор Update Agent, а при временной потере связи сохраняет подтверждённый прогресс и восстанавливает чтение журнала. Не обновляйте сервер вручную и не запускайте вторую операцию, даже если основной сайт временно недоступен. {% endstep %} {% step %} #### Подтвердите результат Нормальный итоговый статус — «Успешно». Затем проверьте вкладки: * «Установленные версии»; * «История операций»; * «Журнал действий». Новая версия должна иметь состояние «Текущая». Возможность возврата к прежней версии показывается отдельно: для этого должны сохраниться её файлы и согласованные точки обеих баз. {% endstep %} {% endstepper %} {% hint style="warning" icon="rotate" %} Если результат запуска не подтверждён, интерфейс сначала проверит, не была ли операция уже принята. Используйте «Повторить отправку» только тогда, когда эту кнопку показывает сам интерфейс. Она повторяет запрос с тем же ключом операции. {% endhint %} ## Способ 2. Обновление через терминал Этот способ предназначен для технического специалиста. Все команды этого раздела выполняются **на сервере проекта**, после подключения по SSH. Примеры рассчитаны на пользователя с правами `sudo`. Если вы вошли как `root`, выполняйте те же команды без префикса `sudo`. ### Проверьте управляющие компоненты {% content-ref url="/spaces/uyjsNtEAtO6Sby8CHWyD/pages/cCEoFDjTDIufy3NUEakd" %} [Подключение к серверу по SSH](/help-center/upravlenie-serverom/podklyuchenie-k-serveru-po-ssh.md) {% endcontent-ref %} ```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 sudo /usr/local/sbin/iexctl backup status ``` Ожидаемый результат: * `iex-updater` запускается без ошибки; * текущая версия определена и подтверждена системой; * `iex-update-agent.service` имеет состояние `active`; * проверка управляемых служб завершена успешно; * управляемое резервное копирование настроено, а его состояние не сообщает о проблеме, препятствующей обновлению. Если текущий релиз не подтверждён, Update Agent не работает или команда сообщает о незавершённой операции, сначала устраните это состояние. Не начинайте новую операцию поверх существующей. ### Найдите загруженные файлы Скопируйте официальные ZIP на сервер через SFTP или используемый файловый менеджер. Если вы подключаетесь не как `root`, сначала загрузите их в каталог, в который вашему SSH-пользователю разрешена запись. Дальнейшие команды выполняйте в SSH-сессии. Если файлы были загружены в `/home`, выведите их список: ```bash sudo find /home -maxdepth 3 -type f -name '*.zip' -print ``` Определите точные абсолютные пути к Backend и Frontend. Если применяется новая лицензия, отдельно определите путь к её ZIP. Рекомендуется хранить каждый релиз в отдельном закрытом каталоге: ``` /home/iex-updates/RELEASE/ ``` Замените `RELEASE` на обозначение скачанного релиза. Это значение используется только как имя каталога и не задаёт версию для Updater. Создать каталог можно командой: ```bash sudo install -d -o root -g root -m 0700 /home/iex-updates/RELEASE ``` Скопируйте архивы в подготовленный каталог с владельцем `root` и правами `0600`. В примере исходные файлы находятся непосредственно в `/home`; замените исходные пути, `RELEASE` и имена ZIP фактическими значениями: ```bash sudo install -o root -g root -m 0600 \ /home/BACKEND_FILE.zip \ /home/iex-updates/RELEASE/BACKEND_FILE.zip sudo install -o root -g root -m 0600 \ /home/FRONTEND_FILE.zip \ /home/iex-updates/RELEASE/FRONTEND_FILE.zip ``` Если архивы уже находятся в закрытом каталоге с указанными правами, повторно копировать их не нужно. Не заменяйте файлы существующей операции. Если применяется новый ZIP лицензии, скопируйте его аналогично: владелец `root:root`, права `0600`, фактическое имя файла без переименования. Не используйте символические и жёсткие ссылки. Не распаковывайте ZIP-файлы. ### Подготовьте конфигурацию этой операции Основная конфигурация установлена по адресу: ``` /etc/iexexchanger/updater/update.yaml ``` Сначала посмотрите нормализованные параметры: ```bash sudo /usr/local/sbin/iex-updater \ --config /etc/iexexchanger/updater/update.yaml \ config show ``` Если значения `spec.input.loose.backend.path` и `spec.input.loose.frontend.path` уже указывают на фактически загруженные файлы, используйте эту конфигурацию без изменений. Если пути отличаются, создайте конфигурацию новой операции на основе установленной. Не перезаписывайте конфигурацию уже начатого обновления: ```bash sudo install -o root -g root -m 0600 \ /etc/iexexchanger/updater/update.yaml \ /home/iex-updates/RELEASE/update.yaml sudo nano /home/iex-updates/RELEASE/update.yaml ``` Ниже показан **фрагмент существующей конфигурации**, а не полный `update.yaml`. В скопированном полном файле найдите `spec.input.loose` и измените пути Backend и Frontend. Не создавайте второй раздел `spec` и не удаляйте остальные настройки. Замените `BACKEND_FILE.zip` и `FRONTEND_FILE.zip` фактическими именами архивов. Отступы YAML сохраняйте пробелами: ```yaml spec: input: mode: loose loose: backend: type: local path: /home/iex-updates/RELEASE/BACKEND_FILE.zip frontend: type: local path: /home/iex-updates/RELEASE/FRONTEND_FILE.zip ``` Если для операции нужна новая лицензия, добавьте следующий фрагмент внутри `spec.input.loose`, на одном уровне с `backend` и `frontend`. Вместо `LICENSE_FILE.zip` укажите фактическое имя ZIP: ```yaml license: source: type: local path: /home/iex-updates/RELEASE/LICENSE_FILE.zip ``` Проверьте, не осталась ли в копии ссылка на лицензию от другой операции. Если новая лицензия не применяется, не добавляйте этот раздел. Если источник уже настроен, проверьте его совместимость и доступность до запуска. Указанные в нём контрольная сумма и размер, если они заданы, должны соответствовать выбранному ZIP. Сохраните остальные параметры полного файла: ограничения, политики безопасности и настройки входящих файлов. Не меняйте: ``` installationState backupRequired maintenanceRequired automaticSelfUpdate ``` После редактирования сохраните файл в `nano` сочетанием `Ctrl + O`, подтвердите имя клавишей `Enter` и выйдите через `Ctrl + X`. Далее задайте переменную с абсолютным путём к выбранной конфигурации. Она используется только для сокращения команд в текущей SSH-сессии и не изменяет файл: ```bash IEX_UPDATE_CONFIG='/home/iex-updates/RELEASE/update.yaml' ``` Если вы используете основную конфигурацию без копии, задайте: ```bash IEX_UPDATE_CONFIG='/etc/iexexchanger/updater/update.yaml' ``` Выберите один подходящий вариант. После повторного подключения по SSH задайте эту переменную заново с тем же путём. ### Проверьте конфигурацию и сформируйте план Выполните команды по порядку: ```bash 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.bundle`, `input.remote-api` или `plan.bundle` не мешает штатному обновлению парой ZIP с `input.mode: loose` и `plan.mode: builtin`. Ошибки текущей установки, выбранного режима или обязательных проверок нужно устранить. В плане проверьте: * текущую и целевую версии; * совпадение Backend и Frontend; * поддерживаемый маршрут обновления; * обязательную резервную копию; * обязательный Maintenance; * изменения серверного окружения, если они нужны релизу; * итоговый список этапов. {% hint style="info" icon="gears" %} Команда `plan` не переключает приложение, не включает Maintenance и не изменяет базы данных. Команды `plan` и `apply --dry-run` не заменяют установленные управляющие программы. Их необходимое обновление происходит при фактическом запуске `apply`. Проверка ZIP может сохранять служебные файлы в закрытом кеше. {% endhint %} ### Проверьте условия выполнения Выполните предварительную проверку без применения обновления: ```bash sudo /usr/local/sbin/iex-updater \ --config "$IEX_UPDATE_CONFIG" \ apply --dry-run ``` Она проверяет доступные состояния этапов, включая фактический запас диска и inode. Команда не создаёт обязательную резервную копию и не заменяет приложение. Отметка, что этап ещё не выполнен, сама по себе ожидаема: новый релиз и его backup пока не созданы. Ошибки проверки ресурсов или окружения нужно устранить до `apply`. При реальном запуске система повторно проверит необходимые условия. Предварительная проверка не резервирует свободное место на диске. ### Запустите обновление После успешных предварительных проверок выполните: ```bash sudo /usr/local/sbin/iex-updater \ --config "$IEX_UPDATE_CONFIG" \ apply ``` Запустите `apply` один раз и дождитесь итогового результата. Не запускайте одновременно обновление из административной панели. Не перезагружайте сервер и не завершайте процесс без необходимости. ### Посмотрите результат и отчёт ```bash sudo /usr/local/sbin/iex-updater \ --config "$IEX_UPDATE_CONFIG" \ status sudo /usr/local/sbin/iex-updater reports list --kind update sudo /usr/local/sbin/iex-updater reports show update ``` Сохраните: * идентификатор запуска; * исходную версию; * целевую версию; * итоговый статус; * путь к отчёту. {% hint style="info" icon="file-lines" %} Операции, запущенные из терминала, сохраняются в серверных отчётах. Основным подтверждением их результата является отчёт Updater. История административной панели в первую очередь показывает операции, созданные через её интерфейс и сверенные с Update Agent. {% endhint %} ## Статусы и ход операции Общий статус относится ко всему обновлению, а отметка рядом с этапом — только к отдельной проверке или действию.
СтатусЧто означает
«План готов»План сформирован; обновление ещё не выполнено.
«В очереди»Операция принята и ожидает выполнения.
«Выполняется»Сервер выполняет этапы операции.
«Maintenance»Приложение находится в режиме обслуживания.
«Успешно»Операция завершена; переходите к проверке результата.
«Ошибка»Операция остановилась; изучите неуспешный этап и рекомендацию.
«Нужно ручное действие»Автоматическое продолжение невозможно без указанного вмешательства.
{% hint style="info" icon="circle-check" %} **«Проверено — изменений не требуется» — успешный результат этапа.** Например, места уже достаточно, расписание резервных копий настроено или конфигурация Nginx соответствует плану. Система проверила состояние, поэтому повторно менять его не требуется. В старом интерфейсе такой результат мог называться «Пропущено». Оценивайте описание этапа и общий итог операции; эта отметка не равна статусу «Ошибка». {% endhint %} Количество этапов может различаться между обновлениями. Ориентируйтесь на план текущего перехода, а не на количество шагов в предыдущей операции. ## Этап 4. Проверка после обновления После статуса «Успешно» или успешного завершения `apply` проверьте сервер и работу продукта. Если вы обновляли через панель и не имеете SSH-доступа, серверную часть проверки выполняет технический специалист. ### Проверьте сервер Выполните на сервере: ```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 ``` Убедитесь, что: * текущая версия соответствует выбранному релизу; * Maintenance выключен; * управляемые службы работают; * последнее резервное копирование видно в состоянии системы; * список `systemctl --failed` не содержит связанных с iEXExchanger ошибок. Для Update Agent ожидаются `enabled` и `active`. Временное переподключение во время обновления самой службы возможно, но повторяющиеся перезапуски, состояние «Нестабильно» или недоступность после завершения требуют диагностики. Если сохранены 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 ``` Первая команда проверяет установленную систему, вторая — доступность через публичные адреса. Если Installer или его исходный `install.yaml` отсутствует, не создавайте новый конфиг наугад. Выполните остальные проверки и запросите способ восстановления проверочной конфигурации. ### Проверьте продукт в браузере Откройте основной сайт: ``` https://ваш_домен ``` Затем перейдите по сохранённому адресу входа в административную панель на Backend: ``` https://app.ваш_домен ``` Проверьте: * доступность обоих доменов по HTTPS; * загрузку клиентского сайта; * вход в административную панель; * переход между разделами панели; * отображение новой текущей версии; * отсутствие Maintenance; * работу функций, критичных для вашего проекта. Перезагрузите страницу панели после обновления и перейдите в другой раздел, чтобы проверить загрузку новых ресурсов. Страницы не должны возвращать ошибку `500` или оставаться в состоянии бесконечной загрузки. API, WebSocket и связанные с ними функции должны работать штатно. Если проверяете создание заявки, используйте согласованный тестовый сценарий. Даже неоплаченная заявка может запускать уведомления и интеграции. {% hint style="success" icon="circle-check" %} Результат обновления подтверждается успешным статусом операции, проверкой серверных служб, публичных доменов и основных функций продукта. {% endhint %} ### Создайте резервную копию новой версии Копия, созданная перед обновлением, относится к прежнему состоянию. После успешной проверки продукта сохраните отдельную копию новой версии: ```bash sudo /usr/local/sbin/iexctl backup run sudo /usr/local/sbin/iexctl backup status ``` Проверьте успешное завершение и время последней копии. Копию до обновления и точку возврата сохраняйте на период проверки новой версии. Если новая копия завершилась ошибкой, устраните проблему резервного копирования. Повторно запускать уже успешное обновление для этого не нужно. {% content-ref url="/pages/LBKgvBucM15o8QrI5D99" %} [Создание резервной копии](/server-i-dannye/sozdanie-rezervnoi-kopii.md) {% endcontent-ref %} ## Если обновление было прервано ### Через административную панель Откройте существующую операцию в разделе «Обновления». Если причина остановки устранена и интерфейс предлагает «Продолжить», используйте эту кнопку. Она продолжает ту же операцию по сохранённому плану. Не создавайте новую загрузку, если сервер уже вошёл в Maintenance или начал применять изменения. Не снимайте Maintenance вручную. ### Через терминал Потеря SSH-соединения не доказывает, что обновление остановилось. Сначала проверьте `status` и отчёт. Пока исходный процесс работает, не запускайте вторую команду. Если операция, начатая через терминал, действительно прервана и её можно продолжить, устраните причину и используйте исходные ZIP и ту же конфигурацию: ```bash sudo /usr/local/sbin/iex-updater \ --config "$IEX_UPDATE_CONFIG" \ apply --resume ``` Updater проверит сохранённые результаты и продолжит ту же операцию. При необходимости этап может быть выполнен повторно, если требуемое состояние больше не подтверждается. {% hint style="danger" icon="fingerprint" %} Во время `resume` нельзя заменять архивы, редактировать `update.yaml`, менять путь конфигурации или вручную переключать релиз. Продолжение привязано к точному сохранённому переходу. Операции, запущенные из панели, имеют отдельные конфигурацию и журнал. Не пытайтесь продолжать их обычной CLI-командой с основным `update.yaml`: используйте «Продолжить» в панели или помощь специалиста, который определит параметры именно этой операции. {% endhint %} ## Если обновление завершилось ошибкой Сначала сохраните: * идентификатор операции; * итоговый статус; * название неуспешного этапа; * текст рекомендации Updater; * отчёт и относящиеся к операции события. Не удаляйте новую и предыдущую версии, точки возврата, принятые агентом архивы, журналы и резервные копии вручную. {% tabs %} {% tab title="Ошибка до Maintenance" icon="shield" %} Если ошибка возникла при предварительной проверке, устраните указанную причину: например, загрузите подходящую пару архивов или освободите место безопасным способом. Само отсутствие Maintenance не означает, что сервер совсем не менялся: управляющие программы и часть окружения могут подготавливаться раньше. Дальнейшее действие выбирайте по сохранённому состоянию и отчёту. Новый запуск допустим только после того, как предыдущая операция имеет подтверждённое конечное состояние и система разрешает новую операцию. {% endtab %} {% tab title="Ошибка после начала изменений" icon="triangle-exclamation" %} Если сервер вошёл в Maintenance или начал изменять приложение, используйте только действие, разрешённое состоянием существующей операции. Обычные варианты: * продолжить ту же операцию кнопкой «Продолжить» в панели или через `apply --resume`, если она запускалась из терминала; * выполнить управляемое восстановление неуспешного обновления; * обратиться в техническую поддержку с идентификатором и отчётом. Не создавайте новый план поверх такого состояния. {% endtab %} {% endtabs %} ### Управляемое восстановление после ошибки `recover-failed` возвращает подтверждённый рабочий релиз после неуспешного обновления, если сохранены необходимые данные и точки обеих баз. Это не универсальная команда для любой ошибки. Команды ниже относятся к обновлению, начатому через терминал с обычными каталогами Updater. Для операции из панели технический специалист должен определить её собственную конфигурацию и журнал. Использовать основной `update.yaml` вместо них нельзя. {% hint style="danger" icon="database" %} Восстановление возвращает базы к сохранённой точке. Более поздние изменения данных могут быть потеряны. Перед запуском согласуйте действие с ответственным за проект и проверьте, какую именно операцию предлагает восстановить система. {% endhint %} Сначала выполните предварительную проверку восстановления: ```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 ``` После успешного восстановления повторите проверки сервера и продукта. Старое обновление через `apply --resume` больше не продолжайте: для исправленных архивов нужна новая операция. Если само восстановление было прервано: ```bash sudo /usr/local/sbin/iex-updater \ --config "$IEX_UPDATE_CONFIG" \ recover-failed --resume ``` `recover-failed` не используется для продолжения обычного отката. Для прерванного отката применяется `rollback --resume`. ## Если новые обновления приостановлены Сообщение «Новые обновления приостановлены» означает запрет на запуск новых обновлений. Приостановка может быть включена вручную или автоматически после ошибок. Сначала изучите историю и устраните причину. После проверки ответственный администратор может нажать «Возобновить» в блоке состояния. Не путайте действия: * **«Повторить отправку»** — повторяет неподтверждённый запрос запуска с тем же ключом операции. * **«Продолжить»** — продолжает существующую прерванную операцию. * **«Возобновить»** — снова разрешает запуск новых обновлений. Разрешение новых обновлений не исправляет неуспешную операцию и не снимает Maintenance автоматически. ## Откат после успешного обновления Откат — отдельная операция, а не обязательный шаг каждого обновления. Выполняйте его при подтверждённой проблеме новой версии и после решения ответственного лица. {% hint style="danger" icon="database" %} Согласованный откат возвращает код и обе PostgreSQL-базы к сохранённой точке. Данные, созданные или изменённые после этой точки, могут быть потеряны. Перед запуском оцените последствия и остановите новые операции пользователей. {% endhint %} ### Откат через административную панель 1. Откройте раздел «Обновления» и вкладку «Установленные версии». 2. Найдите версию со статусом «Доступна для отката». 3. Нажмите «Откатиться до …». 4. Нажмите «Проверить возможность отката». 5. Проверьте исходную и целевую версии, точки возврата обеих баз и предупреждение о данных. 6. Нажмите «Подтвердить откат», затем «Запустить откат». 7. Дождитесь состояния «Откат выполнен». 8. Повторите проверки сервера и продукта из раздела «Проверка после обновления». После отката сохранённая новая версия может получить статус «Готова к возврату» и действие «Вернуться на …». Для возврата сформируйте и проверьте новый план, затем используйте «Подтвердить возврат» и «Вернуться на актуальную версию». Это отдельная операция с резервным копированием и восстановлением соответствующего состояния баз. Она не объединяет данные, накопившиеся при работе на разных версиях. ### Откат через терминал Команда `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 status sudo /usr/local/sbin/iex-updater reports show rollback sudo /usr/local/sbin/iexctl services verify ``` Затем повторите публичные проверки и проверку продукта в браузере. Если откат был прерван: ```bash sudo /usr/local/sbin/iex-updater \ --config "$IEX_UPDATE_CONFIG" \ rollback --resume ``` Не переключайте ссылку `current` вручную и не восстанавливайте только одну базу данных. Код, основная база и база Pulse должны возвращаться согласованно. После успешного отката ранее активная версия становится предыдущей. Если она сохранена и система подтверждает возможность возврата, новая команда `rollback --dry-run` покажет переход к ней. Возврат выполняется новой операцией `rollback`, а `rollback --resume` предназначен только для продолжения уже прерванного отката. ## Хранение файлов и удаление старых версий ### После успешной проверки Сохраните вне обновляемого сервера: * оригинальные Backend и Frontend текущего релиза; * ZIP лицензии, применяемой для этой версии; * контрольные суммы, если они опубликованы в кабинете; * идентификатор и отчёт операции; * дату обновления; * имя ответственного специалиста. Загруженные копии ZIP можно удалить с сервера после успешной проверки продукта, подтверждения наличия внешней копии и завершения операций, которым эти файлы ещё нужны. Не удаляйте используемые файлы, если требуется продолжение, восстановление или откат. ### Удаление сохранённого релиза Сохранённые версии удаляйте штатным действием в административной панели. Не удаляйте их каталоги вручную. Откройте раздел «Обновления», перейдите во вкладку «Установленные версии» и выберите действие «Удалить» у нужной версии. Перед подтверждением система покажет: * выбранную версию; * общий размер файлов и фактически занятое место на диске; * связь с текущим или предыдущим релизом; * доступность отката; * причины запрета удаления; * сведения о сохранении отдельной резервной копии. Текущую активную версию удалить нельзя. Удаление также блокируется, когда состояние сервера или выполняемая операция не позволяют сделать это безопасно. Для обычного удаления используется кнопка «Удалить версию». Если предварительный расчёт устарел, нажмите «Пересчитать состав» и проверьте его заново. {% hint style="warning" icon="trash" %} Предыдущую версию система может разрешить удалить с предупреждением «Будет удалена текущая точка отката». В этом случае кнопка называется «Удалить и отказаться от отката». Продолжайте только после согласованного решения: быстрый возврат к этой версии станет недоступен. {% endhint %} Отдельная резервная копия не удаляется этой кнопкой и хранится по своей политике. Её сохранение не означает, что удалённый релиз останется доступен для быстрого отката. ## Диагностика и обращение в поддержку Для разбора проблемы подготовьте идентификатор операции, исходную и целевую версии, название неуспешного этапа, текст ошибки и рекомендацию системы. Укажите, как запускалось обновление: через панель или терминал. В панели откройте отчёт нужной операции в «Истории операций». Для запуска из терминала используйте серверные отчёты: ```bash sudo /usr/local/sbin/iex-updater reports list --kind update sudo /usr/local/sbin/iex-updater reports show update ``` Сверьте время и идентификатор: последний отчёт должен относиться именно к рассматриваемой операции. Если требуется дополнительная диагностика, технический специалист может подготовить комплект: ```bash sudo /usr/local/sbin/iexctl --format json support bundle ``` Команда покажет путь к результату. Передавайте диагностические материалы через защищённый канал. Не прикладывайте отдельно пароли, приватные ключи, `.env`, коды лицензии, cookie или дампы баз данных. ## Действия, которые нарушают штатное обновление Во время обновления, продолжения, восстановления и отката не выполняйте самостоятельно: * распаковку ZIP поверх активного проекта; * замену файлов в текущем релизе; * `php artisan migrate` или ручной запуск Product Updates; * Composer или npm в активном релизе; * ручную замену Updater, Update Agent или `iexctl`; * изменение ссылок `current` и `previous`; * отключение Maintenance после ошибки; * перезапуск серверных служб без указания процедуры восстановления; * замену ZIP или конфигурации во время `resume`; * запуск второй операции из другого интерфейса; * удаление точек возврата, журналов, принятых архивов или резервных копий до завершения восстановления. Необходимые изменения выполняет Updater. Если система требует ручного действия, выполняйте именно указанную процедуру для существующей операции. ## Когда обновление завершено Обновление считается полностью завершённым, когда одновременно выполнены все условия: * операция имеет подтверждённый статус «Успешно»; * новая версия отмечена как текущая; * Maintenance выключен; * управляемые серверные службы прошли проверку; * Update Agent доступен и работает штатно; * основной и административный домены доступны по HTTPS; * вход в административную панель работает; * API, WebSocket и основные функции продукта доступны; * резервная копия до обновления и точки обеих баз подтверждены в отчёте операции; * после проверки создана резервная копия новой версии; * отчёт операции сохранён; * прежний релиз и точки возврата сохранены на период проверки; * оригинальные архивы и используемая лицензия сохранены владельцем проекта вне обновляемого сервера. {% hint style="success" icon="check" %} После выполнения этих проверок продукт обновлён штатно. Перезагрузка сервера только ради применения обновления не требуется. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.iexexchanger.com/ustanovka-i-obnovlenie/obnovlenie-produkta.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.