A resposta para as perguntas acima, resumidas como:
- é possível compartilhar daemons wsgi entre vhosts?
- é possível manter cada aplicativo em cada vhost separado (enquanto compartilha daemons) para que as configurações locais estejam em vigor?
- se 1. e 2. forem possíveis, pode um dos daemons de reinicialização / desligamento para economizar memória?
A resposta para todos os itens acima é Sim .
Aqui está uma configuração de exemplo, usando a configuração do apache2 do Debian como exemplo:
...
# Include definition of wsgi_daemons above the vhost configs
Include /etc/apache2/wsgi_daemons/
# Include the virtual host configurations:
Include /etc/apache2/sites-enabled/
...
Defina alguns daemons wsgi, por exemplo:
WSGIDaemonProcess wsgi_support threads=5 \
display-name=wsgi_support inactivity-timeout=600
Na sua configuração vhost, defina um bloco ao longo das seguintes linhas:
<Location /support/console>
WSGIProcessGroup wsgi_support
WSGIApplicationGroup <this_vhost>_support
# WSGIApplicationGroup %{GLOBAL} does not work!!!
</Location>
WSGIScriptAlias /support/ /var/www/<this_vhost>/support/site.wsgi
O que isso faz:
- Um daemon com o nome "wsgi_support" será iniciado quando o Apache for iniciado / reiniciado
- Quando o aplicativo de suporte
<this_vhost>
for acessado, ele será anexado ao processo daemon wsgi_support, conforme definido pela diretiva WSGIProcessGroup - Para garantir que a cópia do aplicativo
<this_vhosts>
esteja sendo executada em seu próprio namespace (o que é vital se você estiver executando aplicativos Django, por exemplo, porque as configurações são avaliadas apenas na inicialização), o vhost receberá seu próprio WSGIApplicationGroup. Isso faz com que o daemon mestre crie um subinterpretador para o aplicativo<this_vhost>
. - Por fim, a diretiva de tempo limite faz com que o daemon reinicie após o período declarado de inatividade, liberando memória usada pelos subinterpretadores. Isso é perfeito para aplicativos pouco usados, como consoles de suporte.
Leia os excelentes documentos no link .
Duas coisas me atrapalharam inicialmente: não definir as wsgi_daemons no lugar certo (o que era muito estúpido) e não perceber que as diretivas do WSGIProcessGroup apontam para as definições WSGIDaemonProcess.