mod_wsgi と関連するVirtual Hostに関するいろいろメモ

これはmod_wsgiとVirtualHostの基本を理解する為の単なるメモです。　

1. mod_wsgi

1) Daemon Mode と Embeded Mode.
Defaultはエンベデッド・モード

wsgiファイルとして、以下の内容をブラウザでアクセスすると、どちらのモードか分かる。

myapp.wsgi

def application(environ, start_response):
    status = '200 OK'
    if not environ['mod_wsgi.process_group']:
      output = u'EMBEDDED MODE'
    else:
      output = u'DAEMON MODE'
    response_headers = [('Content-Type', 'text/plain'),
                        ('Content-Length', str(len(output)))]
    start_response(status, response_headers)
    return [output.encode('UTF-8')]

2. Apache Virtual Host:
 https://httpd.apache.org/docs/2.4/

1) <Directory> Directive
<Directory> and </Directory> are used to enclose a group of directives that will apply only to the named directory, sub-directories of that directory, and the files within the respective directories. Any directive that is allowed in a directory context may be used. Directory-path is either the full path to a directory, or a wild-card string using Unix shell-style matching.

2)DocumentRoot Directive
This directive sets the directory from which httpd will serve files. Unless matched by a directive like Alias, the server appends the path from the requested URL to the document root to make the path to the document.

 Example:

DocumentRoot "/usr/web"

then an access to http://my.example.com/index.html refers to /usr/web/index.html

だよねー。このドキュメント・ルートと、後で出てくるwsgiアプリのマウント・ポイントの書き方が大切。


3)  WSGIScriptAlias

基本的な設定の書き方は、URLのマウント・ポイントとWSGIアプリを明示的にマップさせる。
この場合、マッピングは固定されて、Confファイルの記述を変更し、httpdを再起動しない限り、変更は反映されない。

The main approach entails explicitly declaring in the main Apache configuration file the URL mount point and a reference to the WSGI application script file. In this case the mapping is fixed, with changes only being able to be made by modifying the main Apache configuration and restarting Apache.　

このディレクティブは、'WSGIScriptAlias'と呼ばれる。
For mod_wsgi, the directive is instead called WSGIScriptAlias:

WSGIScriptAlias /myapp /usr/local/www/wsgi-scripts/myapp.wsgi
　　　　　　　　　　　　①　　　　　　　　　　　　　②

This directive can only appear in the main Apache configuration files. The directive can be used at server scope but would normally be placed within the VirtualHost container for a particular site.

It cannot be used within either of the Location, Directory or Files container directives, nor can it be used within a “.htaccess” file.

① The first argument to the WSGIScriptAlias directive should be the URL mount point for the WSGI application. For this case the URL should not contain a trailing slash. The only exception to this is if the WSGI application is to be mounted at the root of the web server, in which case ‘/’ would be used.

② The second argument to the WSGIScriptAlias directive should be an absolute pathname to the WSGI application script file. (絶対パスで記述する。) It is into this file that the sample WSGI application code should be placed.

Note that an absolute pathname must be used for the WSGI application script file supplied as the second argument. It is not possible to specify an application by Python module name alone. A full path is used for a number of reasons, the main one being so that all the Apache access controls can still be applied to indicate who can actually access the WSGI application.
Because the Apache access controls will apply, if the WSGI application is located outside of any directories already configured to be accessible to Apache, it will be necessary to tell Apache that files within that directory can be used. To do this the Directory directive must be used:

<Directory /usr/local/www/wsgi-scripts>
    Require all granted
</Directory>

Note that it is highly recommended that the WSGI application script file in this case NOT be placed within the existing DocumentRoot for your main Apache installation, or the particular site you are setting it up for. This is because if that directory is otherwise being used as a source of static files, the source code for your application might be able to be downloaded.
You also should not use the home directory of a user account, as to do that would mean allowing Apache to serve up any files in that account. In this case any misconfiguration of Apache could end up exposing your whole account for downloading.
It is thus recommended that a special directory be setup distinct from other directories and that the only thing in that directory be the WSGI application script file, and if necessary any support files it requires.
A complete virtual host configuration for this type of setup would therefore be something like:

<VirtualHost *:80>
    ServerName www.example.com
    ServerAlias example.com
    ServerAdmin webmaster@example.com
    DocumentRoot /usr/local/www/documents
    <Directory /usr/local/www/documents>
    <IfVersion < 2.4>
        Order allow,deny
        Allow from all
    </IfVersion>
    <IfVersion >= 2.4>
        Require all granted
    </IfVersion>
    </Directory>
    WSGIScriptAlias /myapp /usr/local/www/wsgi-scripts/myapp.wsgi
    <Directory /usr/local/www/wsgi-scripts>
    <IfVersion < 2.4>
        Order allow,deny
        Allow from all
    </IfVersion>
    <IfVersion >= 2.4>
        Require all granted
    </IfVersion>
    </Directory>
</VirtualHost>

After appropriate changes have been made Apache will need to be restarted. For this example, the URL ‘http://www.example.com/myapp’ would then be used to access the the WSGI application.
Note that you obviously should substitute the paths and hostname with values appropriate for your system.

Mounting At Root Of Site
If instead you want to mount a WSGI application at the root of a site, simply list ‘/’ as the mount point when configuring the WSGIScriptAlias directive:

WSGIScriptAlias / /usr/local/www/wsgi-scripts/myapp.wsgi

Do note however that doing so will mean that any static files contained in the DocumentRoot will be hidden and requests against URLs pertaining to the static files will instead be processed by the WSGI application.
In this situation it becomes necessary to remap using the Alias directive, any URLs for static files to the directory containing them:

Alias /robots.txt /usr/local/www/documents/robots.txt
Alias /favicon.ico /usr/local/www/documents/favicon.ico
Alias /media/ /usr/local/www/documents/media/

A complete virtual host configuration for this type of setup would therefore be something like:

<VirtualHost *:80>
    ServerName www.example.com
    ServerAlias example.com
    ServerAdmin webmaster@example.com
    DocumentRoot /usr/local/www/documents
    Alias /robots.txt /usr/local/www/documents/robots.txt
    Alias /favicon.ico /usr/local/www/documents/favicon.ico
    Alias /media/ /usr/local/www/documents/media/
    <Directory /usr/local/www/documents>
    <IfVersion < 2.4>
        Order allow,deny
        Allow from all
    </IfVersion>
    <IfVersion >= 2.4>
        Require all granted
    </IfVersion>
    </Directory>
    WSGIScriptAlias / /usr/local/www/wsgi-scripts/myapp.wsgi
    <Directory /usr/local/www/wsgi-scripts>
    <IfVersion < 2.4>
        Order allow,deny
        Allow from all
    </IfVersion>
    <IfVersion >= 2.4>
        Require all granted
    </IfVersion>
    </Directory>
</VirtualHost>

After appropriate changes have been made Apache will need to be restarted. For this example, the URL ‘http://www.example.com/’ would then be used to access the the WSGI application.
Note that you obviously should substitute the paths and hostname with values appropriate for your system.

Delegation To Daemon Process
By default any WSGI application will run in what is called embedded mode. That is, the application will be hosted within the Apache worker processes used to handle normal static file requests.
When embedded mode is used, whenever you make changes to your WSGI application code you would generally have to restart the whole Apache web server in order for changes to be picked up. This can be inconvenient, especially if the web server is a shared resource hosting other web applications at the same time, or you don’t have root access to be able to restart the server and rely on someone else to restart it.
On UNIX systems when running Apache 2.X, an option which exists with mod_wsgi and that avoids the need to restart the whole Apache web server when code changes are made, is to use what is called daemon mode.
In daemon mode a set of processes is created for hosting a WSGI application, with any requests for that WSGI application automatically being routed to those processes for handling.
When code changes are made and it is desired that the daemon processes for the WSGI application be restarted, all that is required is to mark the WSGI application script file as modified by using the ‘touch’ command.
To make use of daemon mode for WSGI applications hosted within a specific site, the WSGIDaemonProcess and WSGIProcessGroup directives would need to be defined. For example, to setup a daemon process group containing two multithreaded process one could use:

WSGIDaemonProcess example.com processes=2 threads=15
WSGIProcessGroup example.com

A complete virtual host configuration for this type of setup would therefore be something like:

<VirtualHost *:80>
    ServerName www.example.com
    ServerAlias example.com
    ServerAdmin webmaster@example.com
    DocumentRoot /usr/local/www/documents
    Alias /robots.txt /usr/local/www/documents/robots.txt
    Alias /favicon.ico /usr/local/www/documents/favicon.ico
    Alias /media/ /usr/local/www/documents/media/
    <Directory /usr/local/www/documents>
    <IfVersion < 2.4>
        Order allow,deny
        Allow from all
    </IfVersion>
    <IfVersion >= 2.4>
        Require all granted
    </IfVersion>
    </Directory>
    WSGIDaemonProcess example.com processes=2 threads=15 display-name=%{GROUP}
    WSGIProcessGroup example.com
    WSGIScriptAlias / /usr/local/www/wsgi-scripts/myapp.wsgi
    <Directory /usr/local/www/wsgi-scripts>
    <IfVersion < 2.4>
        Order allow,deny
        Allow from all
    </IfVersion>
    <IfVersion >= 2.4>
        Require all granted
    </IfVersion>
    </Directory>
</VirtualHost>

After appropriate changes have been made Apache will need to be restarted. For this example, the URL ‘http://www.example.com/’ would then be used to access the the WSGI application.
Note that you obviously should substitute the paths and hostname with values appropriate for your system.
As mentioned previously, the daemon processes will be shutdown and restarted automatically if the WSGI application script file is modified.
For the sample application presented in this document the whole application is in that file. For more complicated applications the WSGI application script file will be merely an entry point to an application being imported from other Python modules or packages. In this later case, although no change may be required to the WSGI application script file itself, it can still be touched to trigger restarting of the daemon processes in the event that any code in the separate modules or packages is changed.
Note that only requests for the WSGI application are handled within the context of the daemon processes. Any requests for static files are still handled within the Apache worker processes.