Комментарии 25
Надеюсь мне простится мой комментарий.
Мы используем nginx / uWSGI / Django / VirtualEnv. Таким образом мы избавляемся от громоздкого Apache, и получаем свободу для нескольких проектов в рамках одной системы.
Спасибо за топик, Вы подали идею рассказать о нашей реализации хостинга Python/Django-проектов.
Мы используем nginx / uWSGI / Django / VirtualEnv. Таким образом мы избавляемся от громоздкого Apache, и получаем свободу для нескольких проектов в рамках одной системы.
Спасибо за топик, Вы подали идею рассказать о нашей реализации хостинга Python/Django-проектов.
+12
Да, я в курсе, что Ваше сочетание удобнее предложенного. Скажу даже больше — Ваш подход практичнее для создания высоко нагруженных проектов (если еще добавить memcached). Но в данном случае я описал конфигурацию с Apache. Возможно, тем, кто пользуется этим web-сервером приведенная информация будет полезна. Знания лишними не бывают. :)
И кстати, с удовольствием прочитал бы про Вашу реализацию! Буду ждать топика!
И кстати, с удовольствием прочитал бы про Вашу реализацию! Буду ждать топика!
+6
У нас аналогично.
0
О! напиши, плиз. я наверное тоже напишу про эту связку.
будет шанс сравнить и взять лучшее
будет шанс сравнить и взять лучшее
0
Для этого и планирую написать :)
0
ага, давай делиться:
habrahabr.ru/blogs/django/139270/
habrahabr.ru/blogs/django/139270/
0
Убивать за упоминание mod_python, он уже давным давно не развивается, труп и deprecated.
А так, очередная статья как поднять простое
А так, очередная статья как поднять простое
+5
про mod_python — согласен.
А вот про «поднять простое» — нет.
когда только начинаешь — очень не хватает толковой статьи как это _правильно_ сделать. И ответов на вопрос «а как это вообще бывает» тоже.
А вот про «поднять простое» — нет.
когда только начинаешь — очень не хватает толковой статьи как это _правильно_ сделать. И ответов на вопрос «а как это вообще бывает» тоже.
-1
Благодарю за поддержку! :)
0
да ладно, даже в оф доке есть инструкци docs.djangoproject.com/en/1.3/howto/deployment/modwsgi/
А сколько их в рунете ууу
А сколько их в рунете ууу
0
По поводу mod_python я в статье предупредил сразу, что он устарел. Поэтому не нахожу смысла в цитировании меня же в комментариях к моей статье. Но дело, конечно, Ваше!
+1
Так зачем же было про него вообще писать, раз он устаревший и вы всё равно пишете про нормальный вариант? )
+1
Ну, я привел два варианта просто для сравнения, захватив при этом кусочек истории (в виде mod_python). Так как FastCGI меня не прельщает, а uWSGI я еще не успел опробовать, поэтому описал приведенные модули. Может кому и пригодится — у людей разные капризы бывают. А как сказал Доктор Шелдон Купер: «Ну, жизнь без капризов — это не жизнь!» )
0
Ваше решение имеет очень серьезные недостатки.
По моему, так те, кто серверную папку ставят в /home, недалеко ушли от тех, кто в Windows все валят в корень c:. А как это папку потом вынести на сетевое хранилище? Как обеспечить доступ других пользователей?
Все сайты работают из-под одного пользователя. У вас может это не критично, а на хостинге, взломав один, можно получить доступ ко всем остальным. Если вы хотите сделать защищенный хостинг, нужна настоящая виртуализация сервисов и пользователя для каждого сайта.
Плюс, в вашей схеме надо руками создавать конфиг для каждого сайта. Не надоест? А если все 100 конфигов надо будет обновить? Вот, в нгинксе, например можно как-то регуляркой все эти хосты описать. (в апаче тоже есть nameVirtualHost, но он 100% неюзабелен).
По моему, так те, кто серверную папку ставят в /home, недалеко ушли от тех, кто в Windows все валят в корень c:. А как это папку потом вынести на сетевое хранилище? Как обеспечить доступ других пользователей?
Все сайты работают из-под одного пользователя. У вас может это не критично, а на хостинге, взломав один, можно получить доступ ко всем остальным. Если вы хотите сделать защищенный хостинг, нужна настоящая виртуализация сервисов и пользователя для каждого сайта.
Плюс, в вашей схеме надо руками создавать конфиг для каждого сайта. Не надоест? А если все 100 конфигов надо будет обновить? Вот, в нгинксе, например можно как-то регуляркой все эти хосты описать. (в апаче тоже есть nameVirtualHost, но он 100% неюзабелен).
0
Плюс, в вашей схеме надо руками создавать конфиг для каждого сайта.
Нет, если конфиг создается через вэб-морду при регистрации проекта на профиль.
0
По моему, так те, кто серверную папку ставят в /home, недалеко ушли от тех, кто в Windows все валят в корень c:Апач под FreeBSD по умолчанию держит сайты в /usr/local/www, чем автору не понравился этот путь — непонятно. Мы (занимаясь хостингом) оставляем сайты именно там — просто домашние каталоги пользователей, размещающих у нас сайты, находятся, например, в /usr/local/www/data/SiteName. Плюс к этому, /usr/local/www, как правило — или отдельная файловая система, или вообще отдельный физический диск.
0
Я в статье забыл озвучить, что данный вариант приведен для тестового локального хоста (извиняюсь перед всеми). Поэтому о хостнге на настоящей рабочей станции здесь и не может идти речи.
Раздел /home у меня физически на отдельном жестком диске, потому и складываю туда все наработки. Я не думаю, что это критично, ведь я в любой момент могу все перенести в тот же /usr/local/www, а все конфиги проекта поправить чем-то вроде:
Или я не прав?
Раздел /home у меня физически на отдельном жестком диске, потому и складываю туда все наработки. Я не думаю, что это критично, ведь я в любой момент могу все перенести в тот же /usr/local/www, а все конфиги проекта поправить чем-то вроде:
grep home/valera ./* | sed -i -e 's/home\/valera/usr\/local\/www/g' *
Или я не прав?
0
Перезапускаем сервер:А зачем так? Есть же apachectl — он есть и для 1.3, и для 2.2, сидит в /usr/local/sbin, то есть по пути, упоминающемуся в $PATH у рута. Я для перезапуска апача просто пишу
/usr/local/etc/rc.d/apache22 restart
apachectl restart
— этого вполне достаточно.0
Не буду умничать, а приведу цитату из книги Майкла Лукаса, отмеченной у меня в списке литературы: «Хотя утилита apachectl(8) работает очень неплохо, рекомендую применять сценарий запуска, интегрированный в операционную систему FreeBSD. Этот сценарий запускает apachectl(8) с особыми настройками, необходимыми именно в вашем случае, и гарантирует, что при следующей загрузке системы сервер Apache будет работать точно так же, как до ее останова».
Ну, а на самом деле, я просто привык так поступать. Хотя, когда сильно тороплюсь, делаю как Вы.
Ну, а на самом деле, я просто привык так поступать. Хотя, когда сильно тороплюсь, делаю как Вы.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Виртуальный хостинг для Django (FreeBSD + Apache + mod_python / mod_wsgi)