Как перезапустить приложение Django через API после внесения изменений settings.py?

Я работаю над проектом на Django, в котором я динамически добавляю новые языки через API. Рабочий процесс выглядит следующим образом:

  • Добавьте новый язык через API (http://localhost:8000/core/swagger/).
  • Через API /generate/ Сгенерируйте файлы .mo и .po после добавления языка.
  • Новый язык добавляется в файл languages.json, который загружается в settings.py при запуске.
  • Чтобы применить новый язык, Django необходимо перезапустить.

Я перепробовал несколько подходов к автоматическому перезапуску Django через API:

  • ✅ Очистка кэша Django перед перезапуском.
  • ✅ Использование скрипта .sh для завершения процесса и перезапуска Django.
  • ✅ Ручная остановка и перезапуск Django (это прекрасно работает вручную, но не с помощью скрипта).

Проблема: При вызове restart API Django успешно останавливается, но не перезапускается. Перезапуск работает только тогда, когда я вручную останавливаю сервер и перезапускаю его из терминала. Скрипт удаляет PID, но не перезапускает Django должным образом. В чем мне нужна помощь: Каков наилучший способ перезапустить Django из вызова API? Есть ли более надежный способ перезапустить Django также внутри Docker? Почему ручная остановка Django и последующий перезапуск работают, а скриптовый подход - нет?

Соответствующий репозиторий с объяснением того, как загрузить docker + другие шаги: https://github.com/Yemeni/ai_blog_system/

Я проверил другие подходы, которые являются динамической перезагрузкой settings.py но это не рекомендуется в соответствии с документами django

Каков наилучший способ перезапустить Django из вызова API? Есть ли более надежный способ перезапустить Django также и внутри Docker?

Лучший способ - не перезапускать. Если данные динамические, это означает, что вы обычно сохраняете и извлекаете их из базы данных.

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

Это также может привести к другим уязвимостям: если пользователю каким-то образом удается изменить файл, перезагрузка означает, что пользователь может запустить произвольный код, что является серьезной проблемой. Обычно идея заключается в том, чтобы клонировать файлы из хранилища, которое вы проверяете, и немедленно запустить сервер с этими файлами, и, таким образом, не перезагружать при изменении файла.

Поэтому, я думаю, вам следует перенести проблему с .po файлов, которые используются для статических переводов, на такие инструменты, как django-parler или django-translated-fields. Они переносят проблему в базу данных: например, сохраните поле, которое нуждается в переводе, оно создает name, name_en, name_fr, name_ar, и так далее, и выберите правильное поле в зависимости от языка запроса.

Вернуться на верх