Тип статьи | Инструкция и рекомендации. | ||||||
|---|---|---|---|---|---|---|---|
Компетенции | Статья полезна всем работающим в платформе, но в первую очередь инженеру, который ее обновляет. | ||||||
Необходимые права | Как минимум 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, указанном в системных требованиях.
...
| Примечание |
|---|
Лучше сразу сохранять историю команд и выводов в терминале для будущей диагностики проблем. Не забывайте про проверку функционала на каждой промежуточной версии. Не стоит обновляться дальше, если у вас уже что-то перестало работать – дальше это может усугубится. |
Шаг 5. Проверка работы новой версии.
...