Обновление и откат

Это руководство показывает, как перевести установку Mockarty на новый релиз без
остановки и как вернуться назад, если новый релиз ведёт себя неправильно.

Что происходит при обновлении

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

Большинство изменений базы только добавляют что-то — новую таблицу, новый
столбец со значением по умолчанию. Предыдущий релиз продолжает работать с такой
базой, поэтому во время плавного обновления он работает рядом с новым и может
снова принять нагрузку после отката. Немногие изменения удаляют или
перестраивают то, чем предыдущий релиз ещё пользуется. После такого изменения
предыдущий релиз отказывается запускаться на этой базе и объясняет причину —
вместо того чтобы запуститься и упасть на первом же запросе.

Состояние базы можно посмотреть в любой момент:

mockarty --migrate version

В Kubernetes выполните команду внутри пода администрирования — в нём уже есть
настройки подключения к базе:

kubectl exec deploy/mockarty -- /app/mockarty --migrate version

Вывод выглядит так:

Current version: 438 (dirty: false)
Binary schema version: 438
Oldest binary schema version this database accepts: 435

• Current version — изменения базы, применённые к этому моменту.
• Binary schema version — самое новое изменение, которое знает этот бинарник
  Mockarty. Выполните команду бинарником каждого релиза, чтобы узнать его номер.
• Oldest binary schema version this database accepts — на базе может работать
  релиз, у которого номер схемы бинарника не меньше этого числа.

Перед обновлением

1. Сделайте резервную копию базы данных и файлового хранилища. См.
   Резервное копирование и восстановление.
2. Прочитайте примечания ко всем релизам между вашим и целевым.
3. Запишите номер схемы бинарника текущего релиза — он понадобится при откате.

Обновление в Kubernetes (Helm)

Чарт заменяет поды администрирования по одному: новый под запускается,
становится готовым, и только после этого останавливается старый. Указывайте
точную версию, чтобы обновление можно было повторить:

helm upgrade mockarty ./mockarty -f my-values.yaml \
  --set admin.image.tag=1.5.0 \
  --set resolver.image.tag=1.5.0 \
  --set runner.image.tag=1.5.0
kubectl rollout status deployment/mockarty

Сначала обновите узлы администрирования, затем резолверы и раннеры — раннеры,
отстающие на один релиз, тем временем продолжают работать; см.
Эксплуатация парка раннеров.

Обновление в Docker Compose или единого бинарника

Единственный узел перезапускается, поэтому пользователи увидят короткий перерыв:

docker compose pull
docker compose up -d

При установке из бинарника замените бинарник и перезапустите сервис. Новый
бинарник применит изменения базы при запуске.

Откат

Сначала выясните, может ли предыдущий релиз работать на базе в её текущем
состоянии. Выполните mockarty --migrate version и сравните Oldest binary
schema version this database accepts с номером схемы бинарника, который вы
записали перед обновлением.

Предыдущий релиз подходит (его номер равен или больше): откатите
развёртывание. Действий с базой не нужно.

helm rollback mockarty

Предыдущий релиз не подходит (его номер меньше): новый релиз изменил базу
так, что предыдущий не может с ней работать. Отмените эти изменения бинарником
нового релиза, затем откатите развёртывание:

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

2. Один раз запустите бинарник нового релиза против базы, указав номер схемы
   бинарника предыдущего релиза:

   mockarty --migrate down-to 435
   

   В Kubernetes запустите его разовым подом с новым образом и теми же
   настройками базы, что у подов администрирования.

3. Откатите развёртывание (helm rollback mockarty) и снова пустите трафик.

down-to отказывается опускаться ниже самой старой версии, к которой эта
установка может вернуться на месте. Если команда отказала, восстановите
резервную копию, сделанную перед обновлением.

Режим усиленной защиты PostgreSQL

Когда узлы администрирования работают с ограниченной ролью базы
(DB_RUNTIME_ROLE), они сами никогда не меняют базу. Применяйте изменения
нового релиза отдельным шагом обслуживания с учётной записью владельца схемы до
выкатки нового образа, а при откате так же выполняйте down-to. Этот режим
описан в Руководстве администратора.