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

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 находятся на разных машинах. Отдельные машины могут быть отдельными физическими блоками или виртуальными машинами в одном и том же физическом блоке, в зависимости от бюджета / потребностей.