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.

Após 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 da web em conjunto - especialmente porque meu aplicativo CherryPy é um servidor da web - mas não quero descartar a ideia, pois ela aparece em todos os lugares . Eu certamente não sou um especialista, então gostaria de discutir isso.

Eu vejo três opções:

• Implante o CherryPy por si só.
• Implante no Gunicorn ou em outro servidor WSGI.
• Implante em um servidor WSGI e faça proxy reverso no NGinx, que parece ser a solução de todos.

Minhas perguntas:

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

Todo e qualquer conselho é apreciado, obrigado.

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

Seu servidor de aplicativos (CherryPy, gunicorn, qualquer que seja) é otimizado para executar seu aplicativo e servir sua saída. Embora o servidor de aplicativos também possa servir conteúdo estático, eles quase nunca são otimizados para esta tarefa, pois é secundário ao principal objetivo do servidor de aplicativos. (Alguns servidores de aplicativos também ajudarão a reduzir e compactar seu CSS e JS, para que o servidor da Web na frente possa servir esses recursos ainda mais rapidamente.)

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

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

Por que as pessoas colocam o Nginx na frente?

1. Nginx é um servidor da web assíncrono. Isso significa que não dedica um thread ou um processo por conexão. Em vez disso, usa a biblioteca de pesquisa 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? Como o Nginx armazena em buffer as conexões e passa apenas a solicitação para sua instância upstream CherryPy 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, se torna assíncrono. Especificamente, você acena uma mão para um problema lento do cliente e para ataques loris do DOS lentos.
2. O Nginx tem uma taxa de conexão limitada imediatamente. Digamos, não quero mais que 8 conexões simultâneas do mesmo IP.
3. CherryPy tem um problema de SSL . Nginx não.
4. O Python pode enviar bytes de um lado para o outro quase tão bom quanto o C. O Python zlibé apenas um invólucro em torno da biblioteca C. Porém, como o Nginx lida com a conexão de maneira eficaz, é uma boa idéia aliviar os threads de trabalho do CherryPy de veicular conteúdo estático na produção e dedicar 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 o CherryPy por conta própria?

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

CherryPy tem noção de um aplicativo e você pode atender a vários aplicativos com uma instância CherryPy. O CherryPy também pode atender a outros aplicativos WSGI .

Implantando o CherryPy

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

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

Embrulhar

1. Tráfego baixo, sem requisitos especiais → CherryPy * 1 ⇐ HTTP ⇒ Client.
2. → Tráfego intenso, requisitos especiais → CherryPy * n ⇐ HTTP ⇒ Nginx ⇐ HTTP ⇒ Client.
3. Dezenas de instâncias separadas do CherryPy no mesmo servidor, ansiosas por exagerar na solução de todos → CherryPy * n ⇐ WSGI ⇒ Gunicorn ⇐ HTTP ⇒ Nginx ⇐ HTTP ⇒ Client.