Тип статьи | Инструкция и рекомендации. | ||||||
|---|---|---|---|---|---|---|---|
Компетенции | Статья полезна всем работающим в платформе, но в первую очередь инженеру, который ее обновляет. | ||||||
Необходимые права | Как минимум SSH c root и учетная запись администратора в платформе. | ||||||
Версия платформы | 2.22, но по сути неважна для данной статьи. | ||||||
Статус |
| ||||||
Сложность | средне | ||||||
Полезные ссылки | |||||||
Дополнительные сведения | Ubuntu Server 18.04 |
...
Насколько старую версию нужно обновлять. Нельзя обновить 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: Особенности обновления на версию 2.22. Соответственно трудоемкость может возрасти, если был серьезно переработан какой-то механизм, который активно используется на проекте.
Использование сторонних скриптов, работающих с API компонентов платформы. При изменениях в API скрипты придется корректировать.
Использование неофициального API, например, для 2.22 это API рассылки отчетов, создание пользователей. Работа этого функционала не гарантируется после обновления.
Кастомизация JS на дашбордах. Здесь могут быть как простые закономерности (обновилась библиотека Highcharts и логика немного поменялась), так и более сложные (использование неофиц API или незадокументированных приемов в коде).
Отличный от Ubuntu Server дистрибутив Linux. Тестирование происходит только на рекомендованном дистрибутиве Ubuntu Server, указанном в системных требованиях.
...
| Примечание |
|---|
Если обновление прошло неуспешно и принято решение откатываться, то откат без контрольных точек виртуальной машины, а только со скопированными данными платформы потребует дополнительных шагов. Это тема отдельной статьи, но суть состоит в ручной замене всех docker образов новой версии старыми, возвращении сохраненной папки /docker-volume и прохождении развертывания данных (статья для 2.22): Развертывание данных. Поэтому быстрее и проще вариант с контрольной точкой ВМ. |
| Подсказка |
|---|
С версии 2.24 добавили скрипты для автоматического бэкапа и развертывания платформы. Можно и нужно использовать их вместо ручного копирования докер томов и остановки компонентов. Копирование и восстановление данных с помощью скриптов |
Шаг 4. Обновление.
...
Внимательно изучаем статьи (пример для 2.22): Обновление компонентов платформы. Для каждой версии платформы это своя статья в отдельном пространстве Confluence. И идем по шагам, обычно это вариант с компонентами на одном сервере (пример для 2.22): Обновление компонентов, установленных на одном сервере.
| Примечание |
|---|
Лучше сразу сохранять историю команд и выводов в терминале для будущей диагностики проблем. Не забывайте про проверку функционала на каждой промежуточной версии. Не стоит обновляться дальше, если у вас уже что-то перестало работать – дальше это может усугубится. |
| Предупреждение |
|---|
Нельзя пропускать версии при обновлении. С 2.15 на 2.25, например, придется проводить десять итераций и аналогично для других версий. |
Шаг 5. Проверка работы новой версии.
...