Implantando aplicativos CherryPy: Standalone, WSGI Server ou NGinx?

Question

Eu pretendo usar um único VPS para implantar vários aplicativos CherryPy de baixo tráfego como subdiretórios; Por exemplo: example.com/app1 , example.com/app2 , etc.

Depois de pesquisar sobre a implantação do WSGI, parece que o método preferido para implantar aplicativos é usar um servidor WSGI (Gunicorn, uWSGI, etc) e NGinx em uma configuração de proxy reverso. Parece um exagero usar dois servidores Web em conjunto - especialmente porque meu aplicativo CherryPy é um servidor da Web - mas não quero descartar a ideia como aparece em todos os lugares . Eu certamente não sou um especialista, então eu gostaria de discutir isso.

Eu vejo três opções:

• Implante o CherryPy sozinho.
• Implemente abaixo do Gunicorn ou de outro servidor WSGI.
• Implemente sob um servidor WSGI e faça um proxy reverso no NGinx, o que parece ser a solução de todos.

Minhas perguntas:

• Qual é a principal razão pela qual vejo esse padrão em todo lugar? O NGinx é apenas que é bom?
• Para aplicativos de baixo tráfego, o servidor CherryPy nativo é bom o suficiente, ou eu nem deveria tentar?

Qualquer e todo conselho é apreciado, obrigado.

    

Answer 1

A razão pela qual todo mundo coloca o nginx (ou outro servidor como o Apache) na frente de seus servidores de aplicativos é que todos têm conteúdo estático, como imagens, CSS e JavaScript, e requisitos estranhos que são exclusivos de seus aplicativos.

Seu servidor de aplicativos (CherryPy, gunicorn, whatever) é otimizado para executar seu aplicativo e veicular sua saída. Embora o servidor de aplicativos possa também veicule conteúdo estático, ele quase nunca é bem otimizado para essa tarefa, já que é secundário para o objetivo principal do servidor de aplicativos. (Alguns servidores de aplicativos também ajudam a reduzir e compactar seu CSS e JS, de modo que o servidor da Web na frente possa atender a esses recursos ainda mais rapidamente.)

Além disso, o servidor da Web real pode fazer muito mais do que a veiculação de conteúdo de alto desempenho. Coisas como armazenamento em cache, manipulação de cabeçalhos, reescrita de URL, geolocalização e muitos outros recursos que apenas inchariam o servidor de aplicativos sem um bom propósito.

Normalmente, você só executaria o servidor de aplicativos ao desenvolver o aplicativo, quando você é o único usuário, e o desempenho não é um problema. Mesmo que o seu site tenha pouco tráfego, você gostaria que ele fosse mais rápido, certo? Sites de baixo tráfego que são lentos geralmente não crescem em sites de alto tráfego ...

    

Answer 2

Por que as pessoas colocam o Nginx na frente?

1. O Nginx é um servidor da Web assíncrono. Isso significa que ele não dedica um thread ou um processo por conexão. Em vez disso, ele usa a biblioteca de sondagem de soquete preferida do SO e, portanto, é capaz de lidar com centenas de milhares de conexões. Por que você, como desenvolvedor de aplicativos, se importa? Porque o Nginx armazena em buffer as conexões e apenas passa a solicitação para sua instância do CherryPy upstream quando a solicitação é totalmente lida. O mesmo para respostas. Dessa forma, seu aplicativo CherryPy, que é um servidor encadeado, por trás do Nginx em muitos sentidos, torna-se assíncrono. Especificamente, você acenar com a mão para um problema de cliente lento e loris ataques loris DOS.
2. O Nginx tem limite de taxa de conexão fora da caixa. Digamos, eu não quero mais do que 8 conexões simultâneas do mesmo IP.
3. CherryPy tem problema SSL . O Nginx não.
4. O Python pode enviar bytes para a frente e para trás quase tão bem quanto C. O zlib do Python é apenas um wrapper em torno da biblioteca C. Mas, como o Nginx lida com a conexão de maneira eficaz, é uma boa ideia aliviar seus threads de trabalho do CherryPy de servir conteúdo estático na produção e dedicar-se apenas ao conteúdo dinâmico.
5. Multiplexando várias instâncias CherryPy na mesma porta, domínio, caminho, etc. Geralmente, flexibilidade adicional de outro nível de configuração.

É seguro usar CherryPy por conta própria?

De acordo com um dos autores originais, sim . A maioria das coisas relevantes para a web que você pode fazer com o CherryPy por conta própria.

CherryPy tem uma noção de aplicativo e você pode atender vários aplicativos com um CherryPy instância. CherryPy também pode servir outras aplicações WSGI .

Implantando o CherryPy

Em uma implantação tradicional em estilo * nix você escreve um script de inicialização, daemoniza seu processo, descarta seus privilégios, escreve seu PID, etc. Não é grande coisa quando você tem um par de instâncias CherryPy. Quando você tem dezenas, torna-se tedioso e faz sentido entregar o gerenciamento de processos para o Gunicorn ou o uWGSI e alternar suas instâncias do CherryPy de HTTP para WSGI.

Eu escrevi um esqueleto de tutorial / projeto, cherrypy-webapp-skeleton , cujo objetivo era preencher as lacunas para implantar (tradicional) um aplicativo CherryPy do mundo real no Debian para um desenvolvedor da Web.

Resumir

1. Baixo tráfego, sem requisitos especiais → CherryPy * 1 ⇐ HTTP ⇒ Client .
2. Requisitos especiais de alto tráfego → CherryPy * n ⇐ HTTP ⇒ Nginx ⇐ HTTP ⇒ Client .
3. Dezenas de instâncias CherryPy separadas no mesmo servidor, ávidas por um excesso de solução de todos → CherryPy * n ⇐ WSGI ⇒ Gunicorn ⇐ HTTP ⇒ Nginx ⇐ HTTP ⇒ Client .