LINUX.ORG.RU

Как обслуживать endpoint'ы?

 , ,


1

2

Есть djangorest endpoint. Допустим, работает себе endpoint. К нему прилетают запросы. Происходит изменение БД. Как мне его безопасно отключить, чтобы обновить или изменить схему бд или сделать еще что-то? Нужно сделать так, чтобы endpoint перешел в режим maintenance. Но не просто выключился. А перестал принимать новые запросы апи, но завершил старые и отдал ответы от запросов, которые прилетели раньше того момента, как я перевел endpoint в режим maintenance. Как это решается?

Есть django-maintenancemode. Он делает именно так, как я описал выше или нет? Если нет, то что взять, чтобы было так, как описано ранее?

★★★

Последнее исправление: serg002 (всего исправлений: 1)

Ужас какой, почему отключать? Никто так не делает, кроме очень очень серьезной необходимости (смена роутера там, например), ибо по шапке получит. Это изменения в ДБ должны быть обратно совместимы. Если понадобится - несколько изменении. Пользователь - превыше всего, ему должно быть плевать, что там админы себе сегодня надумали.

anonymous
()
Ответ на: комментарий от anonymous

Я про механизм, который будет позволять выключать на обслуживание endpoint’a. А необходимость бывает. И бывает очень разной

serg002 ★★★
() автор топика
Ответ на: комментарий от serg002

Ты закрываешь апи за nginx, меняешь location на /api/maintenance возвращающий нужный тебе ответ говорящий что API на техобслуживании, и всё.

Nxing должен дать закончить работу старых воркеров работающих до релоада, т.ч. условие о «вернуть старые ответы» сохраняется.

Потом, возвращаешь location на стандартный.

Можно конечно учить такому сервер, но легче и универсальнее это делается на роутере стоящем перед бекендом

anonymous
()
Ответ на: комментарий от serg002

Этот механизм называется версионированием. Как только появляется необходимость внести несовместимые изменения в эндпоинт, создаётся новый с номером версии на 1 больше, а старый объявляется устаревшим и, когда все потребители перейдут на новый, отключается

grazor ★★
()
Последнее исправление: grazor (всего исправлений: 1)
Ответ на: комментарий от serg002

Нет, хост и гит тут не причём

Допустим, у тебя был метод /api/v1/register, ты хочешь сделать в нём обязательным поле phone, но тогда перестанет работать регистрация на старых версиях приложения, которые ничего об этом не знают, и не передают. Ты создаёшь новый метод /api/v2/register, который требует это поле, при этом оригинальный метод не трогаешь, и какое-то время поддерживаешь оба. Как только пользователи обновят приложения, можешь отключать первый эндпоинт, и накатывать миграции на базу

grazor ★★
()

отдал ответы от запросов, которые прилетели раньше того момента

Без двух баз + репликации удачи с этим. Не, ну ты можешь сделать миграцию схемы в транзакции и не делать COMMIT пока все старые запросы не завершатся, но это не сильно тривиально сделать и я сомневаюсь, что готовые библиотеки есть.

django-maintenancemode

Нет, оно просит тебя переключить флаг в settings.py. Естественно, это увидят только новые воркеры. Тебе нужно будет костылить механизм вокруг всего этого чтобы не запускать новых воркеров пока обновление не завершилось + не принимать запросы старыми.

x3al ★★★★★
()
Ответ на: комментарий от x3al

Так ему уже предлагали простой способ - через nginx делать (если он его использует), просто изменив на это время конфиг, чтобы на все 503 отдавать и сделать reload.

gruy ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.