Обновление платформы

Введение.

Обновление платформы может быть простым и быстрым на одном проекте и крайне сложным и трудоемким на другом проекте. Зависит это от следующих факторов:

• Насколько старую версию нужно обновлять. Нельзя обновить 2.15 сразу на 2.22, например. Придется обновляться постепенно 2.15 => 2.16 => 2.17…=> 2.22 и так далее до нужной версии. А это уже прилично времени на скачивания docker образов и операции обновления на сервере с платформой. К тому же после каждого обновления (на каждой промежуточной версии) нужно проверять работоспособность основного функционала, например, дашборды, работа в Дизайнере, темы, кастомные виджеты, авторизация, отправка отчетов и пр.

• Есть ли в дистрибутиве текущей версии платформы на сервере правки в YML или SH файлах. Все эти правки необходимо переносить в файлы дистрибутива новой версии платформы и потом проверять их работоспособность. Кастомные правки не тестируются при выпуске версий. Пример правок: записи extra-hosts, монтирование измененного конфига в контейнер.

• Кастомные docker образы компонентов платформы. Определить с нуля это уже на работающем сервере не всегда просто, лучше все сразу документировать. Пару признаков, что работают кастомные образы: последняя введенная команда запуска run.sh содержит ключи с кастомными образами, в docker image ls видны образы платформы с необычными тегами (обычный тег это latest и версия платформы). Обновление платформы с кастомной версии обычно не тестируется, и нужно быть готовым к неожиданностям или писать предварительно в техподдержку.

• Особенности обновления, присущие конкретной версии платформы. Обычно описаны в статьях, например, для 2.22: https://visiology-doc.atlassian.net/wiki/spaces/v22/pages/8756604. Соответственно трудоемкость может возрасти, если был серьезно переработан какой-то механизм, который активно используется на проекте.

• Использование сторонних скриптов, работающих с API компонентов платформы. При изменениях в API скрипты придется корректировать.

• Использование неофициального API, например, для 2.22 это API рассылки отчетов, создание пользователей. Работа этого функционала не гарантируется после обновления.

• Кастомизация JS на дашбордах. Здесь могут быть как простые закономерности (обновилась библиотека Highcharts и логика немного поменялась), так и более сложные (использование неофиц API или незадокументированных приемов в коде).

• Отличный от Ubuntu Server дистрибутив Linux. Тестирование происходит только на рекомендованном дистрибутиве Ubuntu Server, указанном в системных требованиях.

Шаг 1. Работоспособность текущей версии.

После понимания необходимости обновления первое, что нужно сделать, это проверить, что текущая версия платформы исправно работает. Обновление системы с неполадками ни к чем хорошему не приведет. Можно выделить следующие пункты:

• Все Docker контейнеры исправно работают и их uptime не вызывает вопросов.

• Все компоненты платформы доступны. Основную информацию можно подчерпнуть из этих статей для версии 2.22: https://visiology-doc.atlassian.net/wiki/spaces/v22/pages/8756970 и https://visiology-doc.atlassian.net/wiki/spaces/v22/pages/8753910.

• Дашборды на портале.

• Загрузчики в викуб админке.

• ETL процессы и сторонние скрипты, работающие с платформой по API.

• Генерация отчетов и их рассылка.

• Перенос из системы сбора.

• Целостность снапшота Викуба. Его можно проверить, только перезапустив викуб, чтобы он его загрузил заново. Поэтому полезно иметь бэкапы более старых снапшотов на случай проблем с актуальным сейчас. Перед перезапуском Викуба нужно не забыть создать снапшот вручную в веб интерфейсе администрирования и желательно сделать экспорт данных Викуба, без таблиц. Экспорт находится на вкладке Основные в веб администрировании: нам интересны загрузчики, измерения и группы показателей. Они должны быть очень легковесны, а тяжелые таблицы при необходимости можно наполнить, запустив загрузчики или внешние скрипты вручную.

Шаг 2. Ресурсы.

Во-первых, система должна удовлетворять системными требованиям, для версии 2.22 тут:

Во-вторых, не стоит обновляться, если нет никакого запаса для жестком диске. Как минимум, для новых Docker образов может потребоваться временно дополнительное дисковое пространство. К примеру образы версии 2.22 занимают около 20 Гб и в будущих версиях это должно только расти. С учетом других возможных операций копирования, распаковки и пр. целесообразно иметь хотя бы 50 Гб. Если места впритык, то нужно мониторить, не переполнялся ли накопитель во время обновления.

В-третьих, не лишним будет убедиться в исправности железа сервера.

В-четвертых, важно проверить соответствие версии Docker. Для версии 2.22 тут:

Шаг 3. Подушка.

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

Если простые низкоуровневые варианты создания бэкапа недоступны, то необходимо делать резервную копию самих докер томов компонентов платформы. Для версии 2.22 это описано тут: . Скопированные данные желательно сохранить на всякий случай куда-то вне сервера.

Шаг 4. Обновление.

Внимательно изучаем статьи (пример для 2.22): . Для каждой версии платформы это своя статья в отдельном пространстве Confluence. И идем по шагам, обычно это вариант с компонентами на одном сервере (пример для 2.22): .

Шаг 5. Проверка работы новой версии.

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