Встроенный веб-сервер Django: проблемы использования и надежности

Question

Краткий вопрос 1
Что составляет производственную среду, определенную в Документация Джанго примерно на половине пути?

Краткий вопрос 2
Есть ли документированные случаи, когда интерфейс администратора портил базу данных, если несколько человек одновременно обращались к БД?

Фон
У меня естьиспользовал Django в качестве ORM для сервера PostgreSQL.Поскольку основное использование приложения - ORM, оно запускается на клиентском компьютере для связи с удаленным сервером.До сих пор для доступа к веб-интерфейсу администратора я запускаю python manage.py runserver, на котором размещен небольшой веб-сервер на локальном хосте (127.0.0.1:8000) для доступа к нему.

Этот подход работал, за исключением того, что в любое время, когда мне нужно исправить ввод данных или что-то посмотреть, я должен быть на машине, на которой установлено / работает приложение.Мое исправление для этого состояло в том, чтобы запустить интерфейс администратора приложения с сервера Ubuntu и дать ему реальный IP-адрес.Обратите внимание, что настоящий IP-адрес находится в нашей локальной сети и находится за брандмауэром.Я протестировал одновременный доступ с двумя людьми без проблем, не видя ошибок, я добавил этот процесс Python как системный процесс через Ubuntu Upstart.

Долгосрочная цель - установить Apache и Mod_WSGI для размещения приложения.Однако с такой маленькой командой (3 человека в любой момент времени), нужно ли даже преодолевать трудности?Обратите внимание, что если мы когда-нибудь откроем это для внешнего мира, вопрос станет спорным, и Apache является обязательным.

Answer 1

Если вы не используете сервер разработки для разработки проекта django, для меня это звучит как производство. Стоит ли развертывать ваше приложение с Apache и модом WSGI? Это зависит от вас, но совет разработчиков Django довольно однозначен.

НЕ ИСПОЛЬЗУЙТЕ ЭТОТ СЕРВЕР В НАСТРОЙКЕ ПРОИЗВОДСТВА. Он не прошел аудит безопасности или тесты производительности. (И так оно и останется. Мы занимаемся созданием веб-фреймворков, а не веб-серверов, поэтому улучшение этого сервера для обработки производственной среды выходит за рамки Django.)

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

Рассмотрим двух пользователей, редактирующих один и тот же Person. Первый пользователь меняет первое имя, затем второй пользователь меняет второе имя. Поскольку второй пользователь загрузил страницу изменений перед сохранением первого пользователя, имя снова меняется на Joe.

| Description   | First Name | Second Name  |
=============================================
| initial value | Joe        | Smith        |
| first user    | Joseph     | Smith        |
| second user   | Joe        | Bloggs       |
=============================================

Answer 2

Вы говорите о коррупции, происходящей в результате двух отдельных случаев запуска django в одной базе данных? Если это так, я определенно вижу возможность повреждения данных, поскольку ORM API и Forms API Django не предназначены для такого распространения.

Что касается определения «производственного» сервера. Насколько я понимаю, сервер разработки не был рассчитан на надежность, доступность, безопасность или качество в целом. Например, он может обслуживать только один запрос за раз. Сказав это, каждый вариант использования определяет свой собственный набор требований, которые определяют производственную среду. То, что я считаю «производством» для своих нужд, не удовлетворит определение производства Amazon:)