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

Обзор

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

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

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

Алгоритм обновления

  1. Залить файл обновления в систему.

  2. Инициировать процесс подготовки обновления и дождаться его завершения.

  3. Инициировать применение обновления и дождаться его завершения.

  4. Проверить состояние системы и дождаться его нормализации.

Принцип обновления

Заливка происходит на веб-сервер через 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". Открыть приложение "Настройки":

root

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

up 01 region

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

up 02 select

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

up 03 upload

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

up 05 wait prepare

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

up 07 prepare finished

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

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

up 06 false start

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

up 08 confirm

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

up 09 apply

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

up 10 after

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

up 11 nodes

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

up 12 status

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

up 13 general

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

up 14 nodes yellow

API

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

Команды:

  • POST /api/admin/v1/update/upload - заливка файла обновления (zip-архив).

  • POST /api/admin/v1/update/prepare - инициация подготовки обновления, требует указать параметром имя архива с обновлением.

  • GET /api/admin/v1/update/get_upstate - чтение текущего состояния процесса обновления (подготовки).

  • POST /api/admin/v1/update/apply - инициация применения подготовленного обновления.

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

Ограничения

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

  • При мажорном обновлении (меняется первый индекс версии)

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

  • Версия обновления ниже или совпадает с уже установленной.

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

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