Pull to refresh

Comments 25

Надеюсь мне простится мой комментарий.

Мы используем nginx / uWSGI / Django / VirtualEnv. Таким образом мы избавляемся от громоздкого Apache, и получаем свободу для нескольких проектов в рамках одной системы.

Спасибо за топик, Вы подали идею рассказать о нашей реализации хостинга Python/Django-проектов.
Да, я в курсе, что Ваше сочетание удобнее предложенного. Скажу даже больше — Ваш подход практичнее для создания высоко нагруженных проектов (если еще добавить memcached). Но в данном случае я описал конфигурацию с Apache. Возможно, тем, кто пользуется этим web-сервером приведенная информация будет полезна. Знания лишними не бывают. :)

И кстати, с удовольствием прочитал бы про Вашу реализацию! Буду ждать топика!
с вас значит тоже топик :-)
О! напиши, плиз. я наверное тоже напишу про эту связку.
будет шанс сравнить и взять лучшее
Для этого и планирую написать :)
Убивать за упоминание mod_python, он уже давным давно не развивается, труп и deprecated.
А так, очередная статья как поднять простое
про mod_python — согласен.
А вот про «поднять простое» — нет.
когда только начинаешь — очень не хватает толковой статьи как это _правильно_ сделать. И ответов на вопрос «а как это вообще бывает» тоже.
Благодарю за поддержку! :)
То есть мне писать не стоит?
пиши, пиши…
обмен опытом всегда полезен. Часто бывает ценна даже не сама статья, а те идеи, которые там проскакивают намеком.
Писать стоит! В официальной документации слишком сухой язык. Не хватает реальных примеров.
да ладно, даже в оф доке есть инструкци

да, есть.
Но врагу не пожелал бы следовать им.
как и держать в штатном месте (/var/www и аналогичном) что либо отличное от тестового сайта на локалхосте. С чьими правами оно там будет исполняться?
По поводу mod_python я в статье предупредил сразу, что он устарел. Поэтому не нахожу смысла в цитировании меня же в комментариях к моей статье. Но дело, конечно, Ваше!
Так зачем же было про него вообще писать, раз он устаревший и вы всё равно пишете про нормальный вариант? )
Ну, я привел два варианта просто для сравнения, захватив при этом кусочек истории (в виде mod_python). Так как FastCGI меня не прельщает, а uWSGI я еще не успел опробовать, поэтому описал приведенные модули. Может кому и пригодится — у людей разные капризы бывают. А как сказал Доктор Шелдон Купер: «Ну, жизнь без капризов — это не жизнь!» )
Ваше решение имеет очень серьезные недостатки.

По моему, так те, кто серверную папку ставят в /home, недалеко ушли от тех, кто в Windows все валят в корень c:. А как это папку потом вынести на сетевое хранилище? Как обеспечить доступ других пользователей?

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

Плюс, в вашей схеме надо руками создавать конфиг для каждого сайта. Не надоест? А если все 100 конфигов надо будет обновить? Вот, в нгинксе, например можно как-то регуляркой все эти хосты описать. (в апаче тоже есть nameVirtualHost, но он 100% неюзабелен).

Плюс, в вашей схеме надо руками создавать конфиг для каждого сайта.

Нет, если конфиг создается через вэб-морду при регистрации проекта на профиль.
Тогда надо дать серверу права на запись в /etc, что небезопасно. Проблема массового обновления конфигов тоже остается.
По моему, так те, кто серверную папку ставят в /home, недалеко ушли от тех, кто в Windows все валят в корень c:
Апач под FreeBSD по умолчанию держит сайты в /usr/local/www, чем автору не понравился этот путь — непонятно. Мы (занимаясь хостингом) оставляем сайты именно там — просто домашние каталоги пользователей, размещающих у нас сайты, находятся, например, в /usr/local/www/data/SiteName. Плюс к этому, /usr/local/www, как правило — или отдельная файловая система, или вообще отдельный физический диск.
Я в статье забыл озвучить, что данный вариант приведен для тестового локального хоста (извиняюсь перед всеми). Поэтому о хостнге на настоящей рабочей станции здесь и не может идти речи.
Раздел /home у меня физически на отдельном жестком диске, потому и складываю туда все наработки. Я не думаю, что это критично, ведь я в любой момент могу все перенести в тот же /usr/local/www, а все конфиги проекта поправить чем-то вроде:
grep home/valera ./* | sed -i -e 's/home\/valera/usr\/local\/www/g' *
Или я не прав?
Перезапускаем сервер:
/usr/local/etc/rc.d/apache22 restart
А зачем так? Есть же apachectl — он есть и для 1.3, и для 2.2, сидит в /usr/local/sbin, то есть по пути, упоминающемуся в $PATH у рута. Я для перезапуска апача просто пишу apachectl restart — этого вполне достаточно.
Не буду умничать, а приведу цитату из книги Майкла Лукаса, отмеченной у меня в списке литературы: «Хотя утилита apachectl(8) работает очень неплохо, рекомендую применять сценарий запуска, интегрированный в операционную систему FreeBSD. Этот сценарий запускает apachectl(8) с особыми настройками, необходимыми именно в вашем случае, и гарантирует, что при следующей загрузке системы сервер Apache будет работать точно так же, как до ее останова».
Ну, а на самом деле, я просто привык так поступать. Хотя, когда сильно тороплюсь, делаю как Вы.
Sign up to leave a comment.

Articles