Насколько близки веб-серверы разработки к производственным веб-серверам?

Question

Большинство фреймворков python будут иметь какой-либо веб-сервер разработки, который будет иметь предупреждение о том, что он не предназначен для использования в качестве производственных серверов.Насколько сильно они, как правило, отличаются от своих производственных аналогов?

Я еще не совсем решил, с каким фреймворком работать, не говоря уже о том, какой производственный сервер использовать, поэтому мне довольно сложно свести это к "сравнению сервера разработки x с производственным сервером y". Итак, учитывая сказанное, позвольте мне сформулировать вопрос немного точнее:Исходя из вашего прошлого опыта работы с фреймворком Python, сколько времени вам пришлось потратить на запуск вашего приложения в производственной системе после того, как оно было разработано на сервере разработки?Или вы пропустили сервер разработки и разработали свое приложение на сервере, который больше похож на тот, который вы будете использовать в производстве?

Answer 1

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

Вот некоторые переменные, которые следует иметь в виду::

• часто в производстве задействовано несколько машин (сервер приложений, сервер баз данных, веб-сервер, балансировщики нагрузки, брандмауэры и т.д.).Имейте все это в виду.

• Операционные системы

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

• балансировка нагрузки.Во много раз более низкие среды не сбалансированы по нагрузке.Если вы реплицируете сеансы (например) на нескольких серверах производственных приложений, вам следует попытаться сделать то же самое в среде с более низким уровнем производительности

• Версии программного обеспечения / библиотек

Answer 2

Я развиваюсь с Джанго. Производственный сервер у нас удаленный, поэтому его сложно использовать для разработки. Таким образом, сначала я создал vm и постарался максимально приблизиться к среде сервера prod. В какой-то момент, что vm шланг (из-за несвязанного инцидента). В то время я подвел итоги ситуации и понял, что на самом деле нет веских причин использовать настроенный виртуальный компьютер для разработки. Так как ресурсы, доступные приложению, не были такими же, как у сервера prod, в любом случае это было бесполезно для синхронизации запросов (в абсолютном смысле).

Тем не менее, теперь я использую встроенный в django сервер dev с sqlite для разработки и apache / wsgi и postgresql для производства. Пока зависимости python встречаются с обеих сторон, он на 100% совместим. Единственной потенциальной проблемой было бы написание raw sql вместо использования orm.

Answer 3

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

Answer 4

В идеале логическая конфигурация сервера разработки, тестирования и производства должна быть одинаковой. Они должны иметь ту же версию ОС, веб-сервер и все другие программные ресурсы, которые используются для запуска приложения. Однако, в зависимости от того, насколько сильны будут ваши окружения, скопируйте изображения / сценарии и т. Д. На машину разработчика, которая не прошла тестирование и / или производство.

чтобы минимизировать это, вам, вероятно, нужен какой-то сценарий push, который может переместить вас с одного этапа на другой, то есть PushVersionDev, PushVesionTest, PushVersionProd. в идеале это должен быть тот же сценарий с параметрами для целевого сервера (серверов), представляющими все, что вам нужно для перемещения приложения на различных этапах.

Я бы порекомендовал прочитать книгу Тео Шлосснагла Масштабируемый Интернет Архитектура для большего количества идей по этому вопросу.

Чтобы ответить на ваш вопрос напрямую .... после того, как вы протестировали и внедрили свое приложение, время перехода на productoin невелико - разверните ОС, веб-сервер, поддерживающие фреймворки, если им нужна установка, приложение, и вы хорошо идти. Из чистого металла я видел, как Linux-серверы выходили в сеть через 1 час, а окна - около 90 минут. если у вас ОС и веб-сервер работают еще меньше .. минут.

Answer 5

Ваша промежуточная среда должна имитировать вашу производственную среду. Разработка больше похожа на игровую площадку, и контроль над средой разработки не должен быть таким строгим. Однако среду разработки следует периодически обновлять из производственной среды (например, данные prod, скопированные в dev db, закрыть порты dev, закрытые на prod и т. Д.).

В идеале, dev, stage и prod находятся на разных машинах. Отдельные машины могут быть отдельными физическими блоками или виртуальными машинами в одном и том же физическом блоке, в зависимости от бюджета / потребностей.