On 20 January 2011 16:59, Aljoša Mohorović <[email protected]> wrote:
> first off, i apologize if my explanations/questions are not clear.
> please ask for detailed explanations where necessary.
>
> topic: targeting easier wsgi application releases/versioning with
> advanced monitoring and runtime reconfiguration
>
> knowing that it's possible to configure apache/mod_wsgi to support
> serving different wsgi application release/version (easiest way being
> through wsgi script) mentioned in this and similar threads:
> http://groups.google.com/group/modwsgi/browse_thread/thread/3a0e23444992f35f/bf39048caa8b9658
> there are still some issues that are now quite clear.
>
> assuming structure in /var/www/wsgi/example.com/ similar to:
> ------------------------------------------------------
> |- media/
> |- releases/
> |- r1/
> |- project.wsgi # wsgi script
> |- env # virtualenv
> |- static # static files
> |- r2/
> |- project.wsgi # wsgi script
> |- env # virtualenv
> |- static # static files
>
> apache/mod_wsgi is somehow configured to handle example.com domain,
> example.com and www.example.com pointing to release somehow marked as
> "stable" while r<n>.example.com pointing to related release/version.
>
> if i define WSGIDaemonProcess with threads=5 (and other similar
> settings) it will be applied for all but what if i want different
> settings when accessing release not marked as "stable".
> can i have 5 threads for release marked as "stable" (not shared with
> other releases) and only 1 thread when accessing r10.example.com and
> other r<n>.example.com releases not marked as "stable".
> now that i have different settings for each release it should also be
> possible to restrict access by ip or similar apache options.
> since every release has static files, it should point to r10/static/
> when accessing r10.example.com/static/.
> also, separate logs for each release as addition to standard logs for domain.
>
> arguably, this can be achieved with current mod_wsgi implementation.
> although, not in an easy way.
> note that i would personally like to achieve this in apache/mod_wsgi
> configuration and not in wsgi scripts.
Currently this is possible using special WSGI script file which
selects actual application WSGI script file to use, plus use of
.htaccess inside of each release directory to control aspects such as
what daemon process group is used. For static files you would have to
use mod_rewrite to be able to dynamically select which part of file
system is used based on hostname being accessed. That or possibly use
VirtualDocumentRoot in conjunction with .htaccess files to control
which daemon process group selected.
The ability to have dynamic daemon process groups possibly makes this
a bit more workable because you aren't constrained to a fixed number
of daemon processes. The remainder of the configuration likely
wouldn't be much different.
Overall, aspects of what you are needing are always going to be better
off handled by other Apache modules, eg. mod_alias, mod_rewrite, and
doesn't make sense with the way mod_wsgi is now to try and expand
capabilities of mod_wsgi to do it. At least I haven't wanted to go
down that path of having mod_wsgi do such stuff as usually you then
need other hacky directives to then tell mod_wsgi not to override
certain sub URLs so Apache can actually be used for other things. I
have thus tried always to be a well behaved Apache citizen and not
just override everything else as some other Apache modules do. From
memory Passenger is like that and overrides things and sharing
VirtualHost with other stuff becomes hard. Ie., it assumes it is only
thing running in VirtualHost and even directives like Alias don't
override it.
As a side note, I have had discussions with people in the past about a
virtualenv directory becoming the defacto container for a WSGI
application, including subdirectories for static files, WSGI script
files etc and that is even what I have been using myself of late for
some testing am doing. Eg.
Grumpys-MacBook-Pro:Sites graham$ ls -lLas django-2/
total 3152
0 drwxr-xr-x 12 graham admin 408 28 Dec 11:08 .
0 drwxr-xr-x 6 graham admin 204 6 Jan 16:09 ..
3152 -rwxr-xr-x 1 root wheel 4093808 25 Jun 2010 .Python
0 drwxr-xr-x 23 graham admin 782 27 Dec 14:23 bin
0 drwxr-xr-x 3 graham admin 102 13 Jan 22:00 db
0 drwxr-xr-x 2 graham admin 68 27 Dec 13:11 eggs
0 drwxr-xr-x 5 graham admin 170 27 Dec 14:56 htdocs
0 drwxr-xr-x 3 graham admin 102 27 Dec 13:11 include
0 drwxr-xr-x 3 graham admin 102 27 Dec 13:11 lib
0 drwxr-xr-x 4 graham admin 136 27 Dec 15:22 logs
0 drwxr-xr-x 5 graham admin 170 27 Dec 13:45 projects
0 drwxr-xr-x 3 graham admin 102 27 Dec 13:12 src
The boilerplate for the VirtualHost is then something like:
<VirtualHost *:80>
ServerName django-1.example.com
CustomLog /Library/WebServer/Sites/django-1/logs/access_log common
ErrorLog /Library/WebServer/Sites/django-1/logs/error_log
LogLevel info
DocumentRoot /Library/WebServer/Sites/django-1/htdocs
<Directory /Library/WebServer/Sites/django-1/htdocs>
Options ExecCGI FollowSymLinks
Order allow,deny
Allow from all
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
#RewriteRule ^(.*)$ /environ.wsgi/$1 [QSA,PT,L]
RewriteRule ^(.*)$ /project.wsgi/$1 [QSA,PT,L]
</Directory>
WSGIDaemonProcess django-1 display-name=%{GROUP} user=graham group=staff
WSGIProcessGroup django-1
WSGIApplicationGroup %{RESOURCE}
<Files project.wsgi>
WSGIApplicationGroup %{GLOBAL}
</Files>
</VirtualHost>
Note that there is no WSGIScriptAlias. Instead everything dumped in
htdocs. If URL maps to resource, eg., static file, that is served, or
if to actual WSGI file then that. If a 404, would be rerouted into
project.wsgi as fall back. That way can dynamically add additional
WSGI applications at sub URLs without needing to change main Apache
configuration.
Some boiler plate is needed in project.wsgi to fixup and hide
project.wsgi in SCRIPT_NAME so doesn't leak out in URL reconstruction,
but even ways to hide that through other mod_wsgi features so user
doesn't have to add it themselves. I haven't said much about those
features of mod_wsgi though as wasn't 100 percent happy with it in
mod_wsgi 3.X and going to change it slightly in 4.0.
All up, right now for what you are talking about just needs to be
documented how to do it in most clean way. Problem is that yours isn't
the standard setup and so question of priorities of what is more
important to document.
Beyond that, if a standardised container for WSGI projects based
around a virtualenv which included a place for static files got worked
out then mod_wsgi could possibly be extended to support that. Maybe a
WSGIProjectAlias directive which implicitly then does all what the
current stuff in VirtualHost does for mapping resources. So, handling
of static files, plus ability to mount multiple WSGI applications
within the project URL mount point. Daemon process groups would still
be defined separately as would log files for VirtualHost. Some more
thought is needed on that one though.
Graham
--
You received this message because you are subscribed to the Google Groups
"modwsgi" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/modwsgi?hl=en.
