Теплое обновление библиотек из приложения или через API

Используемый чаще всего способ обновления на новую минорную версию.

Производится внутри контейнера путем подмены всех библиотек и ассетов на версии из архива с обновлением. Docker-контейнер при этом не пересоздается, а остается прежний. Поэтому версия контейнера также остается прежней и может быть не согласована с исполняемой внутри версией платформы. Это однако не создает никаких рисков.

Файл обновления имеет имя формата 'era_<VERSION>_debian_amd64.zip' и содержит библиотеки и ассеты в целевом дереве каталогов. Такой архив обновления может быть применен к произвольной установленной версии, за исключением нескольких случаев, описанных ниже в разделе "Ограничения".

Заливка происходит на веб-сервер через API или администраторcкое приложение "Настройки" с авторизацией под учетной записью администратора мастер-домена.

Подготовка обновления заключается в копировании архива на все доступные серверы кластера и его распаковке. Архивы размещаются в рабочих каталогах нод с активными экземплярами микросервисов mic и ic. Путь внутри контейнера: "/var/lib/era/_workdir/<NODE>/autoupdate"). Распакованные каталоги размещаются в каталоге "/usr/lib/era_platform/<VERSION_DIRECTORY>". Все время, пока идет подготовка, система активна и доступна. Копирование обновления намеренно замедляется, чтобы не влиять значительно на пропускную способность сети.

Обновление применяется путем изменения сим-линка /usr/lib/era/ на каталог с обновленной версией на всех доступных серверах кластера. Затем корневое приложение выгружается, инициируя перезапуск docker-контейнера. Подготовленное ранее обновление можно применить в любое время, если со времени подготовки не производились другие операции (отмена текущего обновления или заливка другого файла обновления).

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

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

С точки зрения всех целевых процессов системы обновление протекает с момента применения обновления до момента завершения перезагрузки нод

Проверка состояния производится опроса /system/state и мониторинга нод и их аптайма.

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

Это обновление может быть проведено через приложение администратора мастер-домена, через API или вручную внутри контейнера.

Шаг 1. Авторизоваться в мастер-домен под учетной записью с ролью "admin". Открыть приложение "Настройки":

Шаг 2. Выбрать раздел "Система/Обновление":

Шаг 3. Выбрать архив обновления:

Шаг 4. Загрузить выбранный архив на сервер, нажав кнопку "Загрузить", и дождаться окончания загрузки:

Шаг 5. Инициировать подготовку к обновлению, нажав кнопку "Подготовить":

Шаг 6. Подготовка - длительная процедура, в зависимости от количества серверов она может занять 5-10 минут. Приложение делает регулярный опрос состояния процесса обновления и отображает его выдачу в левом списке. В отображаемом списке перечисляются узлы кластера, ответственные за обновление. Каждый из них проходит состояния: idle .. prepare .. ready. О завершении процедуры подготовки будет понятно по состоянию "ready" у всех элементов в левом списке:

Шаг 7. По достижении этого состояния (все ready) можно продолжить обновление, инициировать перезапуск системы на новой версии, либо дождаться более подходящего момента. Например, ожидание спада нагрузки или наступления времени технологического перерыва.

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

Так окно подтверждения выглядит в нормальном режиме:

Шаг 8. После подтверждения начала обновления система начнет перезапускаться. Временно пропадет и веб-сервер, и доступ к API. В приложения это выглядит так:

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

Шаг 9. В разделе "Cистема/Ноды" можно наблюдать за ходом их перезапуска нод и сбросом аптайма. Отсортировав по аптайму можно мониторить ход загрузки. Сразу после перезапуска и первые 10 минут состояние нод отображается красной пиктограммой. Первый час - желтой пиктограммой, а после - зеленой пиктограммой.

Шаг 10. Переключившись в раздел "Система/Состояние", можно получить информацию о /system/state. Пустой список - критерий корректности проведенного обновления:

Шаг 11. В разделе "Главная" после нажатия F5 в браузере будет отображаться информация о новой версии:

Шаг 12. Спустя 10 минут ни одной красной пиктограммы в мониторинге нод не должно остаться:

Процесс обновления управляется через API мастер-домена, доступное учетным записям с ролью "admin".

Подробное описание Update-API.

Команды:

Отдельно API для мониторинга:

Описываемый способ обновления не может применяться в следующих случаях:

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

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