mod_wsgi: compartilha processos de daemon entre vhosts

Question

Eu tenho muitos sites usando os mesmos 5 aplicativos Django (com configurações locais), hospedados no Apache. Atualmente, cada aplicativo de site tem sua própria configuração da seguinte forma:

WSGIDaemonProcess api_example threads=15 maximum-requests=2000
WSGIProcessGroup api_example
WSGIScriptAlias /api /var/www/sites/example/api/site.wsgi

É possível compartilhar daemons entre vhosts, mas manter as configurações locais ativas? Meu objetivo é economizar memória e reduzir o número de processos do Apache lançados para solicitações de serviço (vários desses aplicativos são consoles de gerenciamento / suporte que são usados apenas ocasionalmente).

- editar -

Como Graham Dumpleton estabelece aqui: mod_wsgi daemon mode - WSGIDaemonProcess por configuração de host virtual? , deve ser possível "chegar até a definição do processo de daemon no host virtual anterior por tanto tempo [pois ele tem o mesmo nome de servidor." Note que, como Graham aponta, a diretiva WSGIApplicationGroup terá que ser ajustada do padrão, provavelmente para% {GLOBAL} ou% {ENV: variable}.

Não sei como "usar" declarações em nível de servidor em um vhost. É possível usar um daemon no nível do servidor com configurações locais?

    

Answer 1

A resposta para as perguntas acima, resumidas como:

1. é possível compartilhar daemons wsgi entre vhosts?
2. é possível manter cada aplicativo em cada vhost separado (enquanto compartilha daemons) para que as configurações locais estejam em vigor?
3. 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.