Обновление

Резервная копия базы

В базе платформы хранятся пользователи, роли и правки проектов, которые ещё не отправили в git кнопкой «Push». Git их не заменяет, поэтому перед обновлением снимите копию базы.

1. Попросите пользователей отправить изменения в git и не запускать сборки до конца обновления.

2. Снимите копию из пода PostgreSQL:

   kubectl -n <namespace> exec postgres-0 -- \
     pg_dump -U karavan -d karavan --format=custom > neomsa-esb-before-upgrade.dump
   

3. Храните файл в защищённом месте: в нём все проекты и хэши паролей пользователей.

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

1. Загрузите новый образ платформы и, если он изменился, новый образ сборщика в реестр.
2. Укажите новые теги в values.yaml: image.tag и NEOMSA_ESB_DEVMODE_IMAGE.

3. Примените чарт:

   helm upgrade neomsa-esb ./neomsa-esb -n <namespace>
   

При запуске платформа сама обновляет схему базы (Flyway), в логе это строки Migrating schema. База лежит на постоянном томе и при обновлении чарта сохраняется.

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

kubectl -n <namespace> rollout restart deploy/neomsa-esb

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

Если обновление не удалось

1. Остановите сборки и сохраните лог платформы: kubectl -n <namespace> logs deploy/neomsa-esb > upgrade.log.

2. Если в логе нет строк Migrating schema, схема базы не менялась. Верните прежний релиз:

   helm rollback neomsa-esb -n <namespace>
   

3. Если новая версия уже обновила схему, одного отката чарта мало: прежняя версия может не запуститься на новой схеме. Остановите платформу, восстановите базу из копии и верните прежний релиз:

   kubectl -n <namespace> scale deploy/neomsa-esb --replicas=0
   kubectl -n <namespace> exec -i postgres-0 -- \
     pg_restore -U karavan -d karavan --clean --if-exists < neomsa-esb-before-upgrade.dump
   helm rollback neomsa-esb -n <namespace>
   

4. Проверьте вход, пользователей, проекты и контрольную сборку.

База из копии возвращает состояние на момент её создания. Правки, сделанные позже, придётся перенести вручную.

Переход с 4.18.1 на 4.22.2

Версия 4.22.2 требует изменений не только в платформе, но и в интеграциях.

В чарте:

• Service платформы должен называться neomsa-esb. Сборщик 4.22 обращается к платформе по адресу http://neomsa-esb.<namespace>. В чарте 4.22 имя уже зафиксировано.
• В roleRules нужны права на pods/log (get), events из групп "" и events.k8s.io (get, list, watch) и serviceaccounts (get, list). В чарте 4.22 они есть.
• Нужен образ сборщика 4.22.2. Библиотеки в образе сборщика подобраны под версию Camel, поэтому версия сборщика должна совпадать с версией платформы.

В интеграциях:

• Добавьте в application.properties параметр camel.management.enabled=true. Без него в 4.22 не отвечают /observe/health и /observe/metrics, пробы Kubernetes не проходят, и под перезапускается.
• Добавьте camel.management.port=9876. В deployment.jkube.yaml объявите порт контейнера observability (9876) и направьте на него пробы и аннотацию prometheus.io/port. Пример есть в шаблоне проекта из комплекта поставки. Без этого порта в логе платформы появляются сообщения Connection refused с адресом пода и портом 9876, а состояние маршрутов в интерфейсе не обновляется.
• Обновите библиотеки OpenTelemetry в camel.jbang.dependencies до версии 1.64.0.
• В Kafka-маршрутах замените заголовок kafka.KEY на CamelKafkaKey. В Camel 4.21 строковые имена заголовков Kafka изменились на CamelKafka..., поэтому проверьте и другие заголовки kafka.*. Константы KafkaConstants в Java-коде менять не нужно.
• Пересоберите все интеграции новым сборщиком, чтобы они перешли на Camel 4.22.2.

Ветку интеграций для 4.22 удобно завести отдельно и указать её в ключе git-branch секрета. Так интеграции версии 4.18 продолжат работать до полного перехода.