CherryPyアプリのデプロイ：スタンドアロン、WSGIサーバー、NGinx？

Question

1つのVPSを使用して、トラフィックの少ない複数のCherryPyアプリをサブディレクトリとして展開するつもりです。例：example.com/app1、example.com/app2など.

WSGIデプロイメントについて調査したところ、アプリのデプロイに推奨される方法は、WSGIサーバー（Gunicorn、uWSGIなど）とNGinxをリバースプロキシ設定で使用することです。特に私のCherryPyアプリ自体がWebサーバーであるため、2つのWebサーバーをタンデムで使用するのはやり過ぎのように見えますが、表示されているようにeverywhereのように考えを却下したくありません。私は確かに専門家ではないので、話し合いたいと思います。

3つのオプションが表示されます。

• CherryPyを単独でデプロイします。
• Gunicornまたは別のWSGIサーバーの下にデプロイします。
• WSGIサーバーの下にデプロイし、NGinxにリバースプロキシします。これは、みんなのソリューションのようです。

私の質問：

• どこにでもこのパターンが見られる主な理由は何ですか？ NGinxはただあの良いですか？
• トラフィックの少ないアプリの場合、ネイティブのCherryPyサーバーで十分ですか、それとも試してはいけませんか？

どんなアドバイスでもよろしくお願いします。

Answer 1

誰もがnginx（またはApacheなどの別のサーバー）をアプリサーバーの前に配置する理由は、画像、CSS、JavaScriptなどの静的コンテンツ、およびアプリケーション固有の奇妙な要件があるためです。

アプリサーバー（CherryPy、gunicornなど）は、アプリを実行してその出力を提供するように最適化されています。アプリサーバーcanも静的コンテンツを提供しますが、アプリサーバーの主な目的の副次的なものであるため、このタスクに最適化されることはほとんどありません。 （一部のアプリサーバーは、CSSとJSを縮小して圧縮することでも役立つため、前面のWebサーバーがこれらのリソースをさらに高速に提供できます。）

さらに、実際のWebサーバーは、高パフォーマンスのコンテンツサービスよりもはるかに多くのことができます。キャッシング、ヘッダー操作、URLの書き換え、地理位置情報など、アプリサーバーを肥大化させるだけの目的ではない多くの機能。

通常、アプリケーションサーバーを単独で実行するのは、アプリケーションを開発するときだけで、自分が唯一のユーザーであり、パフォーマンスは問題ではありません。サイトのトラフィックが少ない場合でも、より高速にしたいですか？低速なトラフィックの少ないサイトは、一般的にトラフィックの多いサイトに成長しません...

Answer 2

なぜ人々はNginxを前に置くのですか？

1. Nginxは非同期のWebサーバーです。これは、接続ごとにスレッドまたはプロセスを専用にしないことを意味します。代わりに、OSの優先ソケットポーリングライブラリを使用するため、数十万の接続を処理できます。アプリケーション開発者として、なぜ気にする必要があるのですか？ Nginxは接続をバッ​​ファリングし、リクエストが完全に読み取られたときにのみCherryPyアップストリームインスタンスにリクエストを渡すためです。応答についても同じです。このようにして、さまざまな意味でNginxの背後にあるスレッドサーバーであるCherryPyアプリケーションが非同期になります。具体的には、遅いクライアントの問題と遅いロリスDOS攻撃に手を振ります。
2. Nginxには、すぐに使用できる接続レート制限があります。たとえば、同じIPから8つを超える同時接続が必要ではありません。
3. CherryPyには SSLの問題 があります。 Nginxはサポートしていません。
4. PythonはCとほぼ同じようにバイトを送受信できます。PythonのzlibはCライブラリのラッパーにすぎません。しかし、Nginxは接続を効率的に処理するため、CherryPyワーカースレッドが本番環境で静的コンテンツを提供しないようにし、動的コンテンツのみに専念することをお勧めします。
5. 同じポート、ドメイン、パスなどで複数のCherryPyインスタンスを多重化します。一般に、別の構成レベルの追加の柔軟性。

CherryPyを単独で使用しても安全ですか？

原作者の一人によると、 はい 。 CherryPyだけでできるWeb関連のほとんどのこと。

CherryPyにはアプリケーションの概念があり、1つのCherryPyインスタンスで 複数のアプリケーションにサービスを提供する を使用できます。 CherryPyは他の WSGIアプリケーション にも対応できます。

CherryPyのデプロイ

従来の* nixスタイルのデプロイメントでは、initスクリプトの作成、処理のデーモン化、その特権の削除、PIDの書き込みなどを行います。CherryPyインスタンスが2つある場合は、それほど大きな問題ではありません。何十もあると、退屈になり、プロセス管理をGunicornまたはuWGSIに引き渡して、CherryPyインスタンスをHTTPからWSGIに切り替えることは理にかなっています。

私はチュートリアル/プロジェクトのスケルトン cherrypy-webapp-skeleton を書きました。この目標は、Web開発者向けに、Debianに実際のCherryPyアプリケーションを（従来の）デプロイするためのギャップを埋めることでした。

要約

1. 低トラフィック、特別な要件なし→CherryPy * 1 ⇐ HTTP ⇒ Client。
2. 高トラフィック、特別な要件→CherryPy * n ⇐ HTTP ⇒ Nginx ⇐ HTTP ⇒ Client。
3. 同じサーバー上の数十の個別のCherryPyインスタンス、のやりすぎに熱心ですみんなのソリューション→CherryPy * n ⇐ WSGI ⇒ Gunicorn ⇐ HTTP ⇒ Nginx ⇐ HTTP ⇒ Client。