Pull to refresh

Comments 17

Вспомнил я свой деплой джанги на IIS несколько лет назад, это было ужасно. Да, там в итоге работало как-то, но потом всё время что-то вылезало, блочилось, текло, глючило понемногу. Но делал вроде не так, через какие-то полу-родные тулзы. Не знаю может сейчас лучше с этим. В итоге сейчас там на апаче+mod_wsgi всё это стоит, даже это лучше оказалось.
Два вопроса которые выползли из головы от начала статьи:
Все показы сайта проходили на моём ноутбуке, не давая возможности заказчику сесть вечером с кружкой кофе, расслабиться и насладиться тем, что мы уже для него сделали.

Почему не использовали heroku.com — dynos? Ведь для тестов и прототипов за глаза хватает бесплатного аккаунта. Ну или аналоги.

Радость моя была не долгой. Сайт на Django, а сервер на Windows Server 2012.

Почему не обговорили с клиентом тип сервера(особенно после выбора языка и фреймворка), а пустили всё на самотёк? Ведь клиент мог с тем же успехом и шаред хостинг взять за 30р в месяц, с поддержкой только статики.
Начну со второго. Всё было обговорено, кроме ОС. Я даже и не подумал, что может быть что-то кроме UNIX (я был в курсе о существовании Windows Server). К тому же, заказчик уверял, что через неделю — две он оформит нам сервер. И каждую неделю сроки отодвигались.
Теперь первый. Сайт был развёрнут на тестовом сервере другого проекта и приходилось его (сайт) частенько останавливать. А обещание вот-вот получить собственный сервер — вселяло надежду))
python manage.py runserver 80

Открываю сайт в браузер на сервере — всё работает. Отлично. Открываю сайт на домашней машине и вижу, что сайт не доступен. Грусть.

Порою ошибки позволяют развить вполне себе интересные направления, как, например, Ваша статья.
python manage.py runserver 0.0.0.0:8000

Так было бы проще, но тогда Вы не освоили бы реализацию IIS+Django.
Спасибо, буду знать. Я перепробовал все комбинации, но не подумал о порте 8000.

Дело же не в порте, а в хосте.

Пробовал оба варианта:
python manage.py runserver 80
python manage.py runserver 0.0.0.0:80

И оба раза провалился.
А по поводу 8000 — предположил, вдруг магия в нём))

Чтобы поднять сервак на порту с номером меньшим чем 1024, нужны права администратора. Плюс, если установлен апач/нжинкс, они могут использовать этот порт и подниматься при старте системы. Может дело было в этом.

И этот вариант был проверен. Третьим и четвёртым соответственно (первый и второй — запуски в обычной консоли).
А по поводу Apache/nginx — было желание воспользоваться ими, но желание «победить» IIS пересилило)))
А еще, внезапно, скайп юзает 80 порт.
ну у вас же 80-й порт был IIS-ом занят
Встроенный сервер только для разработки, использовать его в бою — очень плохая идея.
Попробую пока так, ибо нагрузка планируется не сильно высокой, но если что-то пойдёт не так — буду думать в сторону Apache/nginx
Сам не пробовал, но насколько мне известно, Apache + mod_wsgi нормально работают на Windows, а Django нормально работает под WSGI.
Спаибо за статью, интересный опыт!

Вариант с размещением виртуальной машины (и, например, бриджом интерфейсов) не рассматривался? Более гибкая и привычная архитектура, удобство миграций и бекапов в подарок :)
На третий час борьбы(а это было где-то в 00:00), я уже был готов на всё что угодно, но интерес взял своё.
Sign up to leave a comment.

Articles