Apache:使用mod_wsgi时自动reload代码

最新推荐文章于 2025-02-08 12:07:47 发布

qingjinlyc

最新推荐文章于 2025-02-08 12:07:47 发布

阅读量3.6k

点赞数

分类专栏： Thrill for Tech 文章标签： http服务器 web开发 apache python django

本文链接：https://blog.youkuaiyun.com/qingjinlyc/article/details/51946035

版权

Thrill for Tech 专栏收录该内容

5 篇文章

订阅专栏

本文介绍如何使用Apache的mod_wsgi模块在代码更新时自动重载Python Web应用，通过设置WSGIDaemonProcess及WSGIScriptReloading参数实现守护进程模式，并举例说明如何配置。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

我们用python的web框架（DJango或Flask）部署在apache上。当项目代码有更新时，我们希望Apache能够自动地reload代码。

将python web项目部署在apache上需要借助mod_wsgi。mod_wsgi具有两种工作模式，分别是Embedded process和Daemon process。

前者的wsgi程序是apache进程直接管理和调用的，因此当项目代码更改时，必须restart或者reload apache才能达到代码更新的目的。而后者，是apache

为wsgi程序启动了一个守护进程，即独立于apache进程的进程。其效果是，当web项目中的wsgi脚本有变化时，该守护进程就会被重启，重启过程中，自然项目代码

也就被reload进入内存了。

具体的一个配置的例子是：

ServerName webmaster@localhost

ErrorLog /home/***/yaojia/errlog

Alias /video/ /home/***/xxx/yyy/proj/uploads/video/

WSGIDaemonProcess xxx threads=100 display-name=xxx

WSGIScriptReloading On

WSGIScriptAlias / /home/***/xxx/yyy/proj/test.wsgi

DocumentRoot /home/***/xxx/YYY/proj/

WSGIProcessGroup mtl_performance

Require all granted

</Directory>

</VirtualHost>

当代码更新时，touch test.wsgi即可。

附上mod_wsgi相关原文：

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>
    Order allow,deny
    Allow from all
    </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>
    Order allow,deny
    Allow from all
    </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.