42

WSGIアプリケーションのデプロイ。この猫の皮を剥ぐ方法はたくさんあります。現在、mod-wsgiでapache2を使用していますが、これにはいくつかの潜在的な問題があります。

では、どうすればそれを行うことができますか？

  1. Apache Mod-wsgi（他のmod-wsgiは価値がないようです）
  2. 純粋なPythonWebサーバー（例：paste、cherrypy、Spawning、Twisted.web）
  3. 2と同じですが、nginx、apache2などからのリバースプロキシを使用し、静的ファイルを適切に処理します
  4. ブリッジ（Flupなど）を使用し、従来のWebサーバーで実行されているFCGIなどの他のプロトコルへの変換。

もっと？

私はあなたがそれをどのように行うのか、そしてなぜそれがそれを行うための最良の方法であるのか知りたいです。何が、なぜ、アプリケーション固有のものなどについての詳細で私を退屈させてくれることを絶対に望んでいます。私は、非常識でない答えを支持します。

4

9 に答える 9

26

いつものように: 場合によります ;-)

Apache 機能が必要ないときは、paste などの純粋な python Web サーバーを使用します。どれが正確にアプリケーションに依存するかは、いくつかのベンチマークを実行することで決定できます。私はいつも何かをしたいと思っていましたが、それには至りませんでした。スポーンには、すぐに使用できるノンブロッキング IO を使用する利点があると思いますが、パッチが適用されているために問題が発生することがありました。

もちろん、いつでも自由にワニスを前に置くことができます。

Apache が必要な場合は、通常、プロセスを分離できるようにソリューション 3 を使用します。また、プロセスを他のサーバーなどに簡単に移動することもできます。

私が現在使用している静的ファイルの場合、静的イメージ/css/jsのみを提供するプロジェクト用に別のサーバーを使用しています。私は、優れたパフォーマンスを持つ Web サーバーとして lighttpd を使用しています (この場合、前面にワニスがありません)。

もう 1 つの便利なツールは、これらのサービスを制御および監視するためのSupervisordです。

さらに、展開と開発サンドボックスを管理するためにbuildoutを使用しています ( virtualenvと共に)。

于 2009-02-22T01:39:56.040 に答える
13

何が、なぜ、アプリケーション固有のものなどについての詳細で私を退屈させてくれることを絶対に望んでいます

ホー。さてあなたはそれを求めました！

ダニエルのように、私は個人的にmod_wsgiでApacheを使用しています。まだ十分に新しいので、一部の環境でのデプロイは苦労する可能性がありますが、とにかくすべてを自分でコンパイルする場合は、非常に簡単です。初期のバージョンでさえ、非常に信頼できることがわかりました。グラハム・ダンプルトンを自分でコントロールし続けるための小道具。

ただし、私にとっては、WSGIアプリケーションがすべての可能なサーバーで機能することが不可欠です。現在、この領域には少し穴があります。WSGI呼び出し可能オブジェクト（アプリケーション）が何をするかを示すWSGI標準がありますが、デプロイメントの標準化はありません。アプリケーションの場所をWebサーバーに伝える単一の方法はありません。また、更新時にサーバーにアプリケーションを再ロードさせる標準化された方法もありません。

私が採用したアプローチは次のとおりです。

  • モジュール/パッケージ内のすべてのアプリケーションロジック、できればクラス内

  • メインアプリケーションをサブクラス化し、メンバーをオーバーライドすることによって行われるすべてのWebサイト固有のカスタマイズ

  • クラス__init__（）パラメーターとしてのすべてのサーバー固有のデプロイメント設定（データベース接続ファクトリー、メールリレー設定など）

  • 現在のサーバーの正しいデプロイメント設定でApplicationクラスを初期化し、CGIスクリプト、mod_wsgi WSGIScriptAlias（またはPassenger、これは明らかに同じように機能します）、またはコマンドラインから対話できます

  • 上記のデプロイメントの問題を処理し、アプリケーションが変更に依存しているモジュールのときにアプリケーションをリロードできるようにするヘルパーモジュール

したがって、application.pyが最終的にどのように見えるかは次のようになります。

#!/usr/bin/env python

import os.path
basedir= os.path.dirname(__file__)

import MySQLdb
def dbfactory():
    return MySQLdb.connect(db= 'myappdb', unix_socket= '/var/mysql/socket', user= 'u', passwd= 'p')

def appfactory():
    import myapplication
    return myapplication.Application(basedir, dbfactory, debug= False)

import wsgiwrap
ismain= __name__=='__main__'
libdir= os.path.join(basedir, 'system', 'lib')
application= wsgiwrap.Wrapper(appfactory, libdir, 10, ismain)

wsgiwrap.Wrapperは、libdir内のアプリケーションモジュールのいずれかが更新されているかどうかを10秒ごとにチェックし、更新されている場合は、すべてを確実にアンロードするための厄介なsys.modulesマジックを実行します。次に、appfactory（）が再度呼び出され、更新されたアプリケーションの新しいインスタンスが取得されます。

（次のようなコマンドラインツールを使用することもできます

./application.py setup
./application.py daemon

呼び出し可能なアプリケーションによって提供されるセットアップフックとバックグラウンドタスクフックを実行します—distutilsの動作に少し似ています。また、initスクリプトのように開始/停止/再起動に応答します。）

私が使用するもう1つのトリックは、複数のサーバー（開発/テスト/本番）のデプロイメント設定を同じapplication.pyスクリプトに入れ、「socket.gethostname（）」をスニッフィングして、使用するサーバー固有の設定を決定することです。

ある時点で、wsgiwrapをパッケージ化して、適切にリリースする可能性があります（おそらく別の名前で）。それまでの間、興味がある場合は、 http：//www.doxdesk.com/file/software/py/v/wsgiwrap-0.5.pyでdogfood-developmentバージョンを確認できます。

于 2009-03-07T22:15:27.943 に答える
13

最も簡単にデプロイできるのは CherryPy です。Web アプリケーションは、スタンドアロンの Web サーバーになることもできます。CherryPy は、純粋な Python で記述されていることを考えると、かなり高速なサーバーでもあります。そうは言っても、それはApacheではありません。したがって、CherryPy はボリュームの少ない Web アプリケーションに適していることがわかりました。

それ以外には、この質問に正解も不正解もないと思います。あなたが話している技術に基づいて、大量のウェブサイトが数多く構築されています。私は、あなたがそれらの方法のどれをとっても間違っているとは思いません (とはいえ、mod-wsgi がすべての技術に対応しているわけではないことに同意します)。非 Apache サーバー)。

また、isapi_wsgiを使用して、IIS に Python アプリをデプロイしています。これは理想的な設定とは言えませんが、うまく機能し、Windows 中心の世界に住んでいると、常に別の方法を選択できるとは限りません。

于 2009-02-22T20:36:33.920 に答える
6

Nginx リバース プロキシと静的ファイル共有 + XSendfile + uploadprogress_module。目的のためにそれに勝るものはありません。

WSGI 側では、Apache + mod_wsgi または cherrypy サーバーのいずれか。メモリとリクエストが少ないサーバー上のアプリケーションには、cherrypy wsgi サーバーを使用するのが好きです。

理由:

さまざまな一般的なソリューションに対してさまざまなツールを使用してベンチマークを行いました。

私は、Web 開発よりも低レベルの TCP/IP、特に http 実装の経験が豊富です。私は、優れた Web フレームワークを認識できるよりも、優れた http サーバーを認識できることに自信を持っています。

私は Django や Pylons よりも Twisted のことをよく知っています。Twisted の http スタックはまだこれに達していませんが、そこにはあります。

于 2009-03-11T18:06:50.380 に答える
4

TurboGears（2.0）

TurboGears 2.0は来月中にベータ版をリリースします（かなり長い間ベータ版に含まれています）。2.0は1.0シリーズを改良し、最高のWSGIスタックを提供しようとします。そのため、煩わしさを最小限に抑えたい場合は、デフォルトでいくつかの選択肢があります。

tg*1.xシリーズでテストおよび展開するためのツールがありますがpaster、2.0シリーズで同等のものに変換されました。これは、に慣れている場合はおなじみのようですpylons。

tg-adminクイックスタート—>パスタークイックスタート
tg-admin info —> paster tginfo
tg-adminツールボックス–>パスターツールボックス
tg-adminシェル–>パスターシェル
tg-admin sql create –> paster setup-app development.ini

パイロン

WSGIスタック（ORMの選択、テンプレートの選択、フォームの選択）でより柔軟になりたい場合は、Pylonsが統合された選択肢になりつつあります。これは、優れたドキュメントを提供し、さまざまなコンポーネントを試すことができるため、私の推奨する選択です。

結果として作業することは喜ばしいことであり、Apache（実稼働展開）またはスタンドアロン（テストおよび実験段階に役立ちます）で動作します。

したがって、Pylonsで両方を行うことができます。

  • テスト段階の2つのオプション（pythonスタンドアロン）

  • スケーラブルな本番環境の場合は4（FastCGI、選択したデータベースが維持できると仮定）

Pylons管理インターフェースはTurboGearsと非常によく似ています。おもちゃのスタンドアロンの例を次に示します。

$ paster create -t​​ pylons helloworld
$ cd helloworld
$パスターサーブ--reloaddevelopment.ini

本番クラスのデプロイメントについては、Apache + FastCGI + mod_rewriteこちらのセットアップガイドを参照してください。これはほとんどのニーズに合わせてスケールアップします。

于 2009-03-10T07:08:23.823 に答える
4

開発中のアプリケーションに Google App Engine を使用しています。WSGI アプリケーションを実行します。 ここにいくつかの情報があります。

これは私が実際に取り組んだ最初の Web アプリなので、比較の根拠はありませんが、Google ファンなら調べてみてください。学習のフレームワークとして使用するのはとても楽しかったです。

于 2009-02-24T12:47:38.523 に答える
3

web.py（wsgiアプリケーション）を使用したApache httpd+mod_fcgid。

チャームのように機能します。

于 2009-03-04T21:53:23.327 に答える
1

一部のWebサービスには純粋なPasteを使用しています。デプロイは簡単で（内部デプロイメントメカニズムを使用します。PasteDeployなどは使用していません）、本番システムと開発者のワークステーションで実行されているシステムとの違いを最小限に抑えることができます。警告：リクエストは非常に重いため、Paste自体のレイテンシが低くなることは期待できません。いくつかの大まかなベンチマークでは、素晴らしい結果が得られませんでした。私たちの典型的なリクエストハンドラーの費用のために、それは結局議論の余地がありました。これまでのところ、正常に機能しています。

静的データは、S3、Akamai、Apache、IISの使用など、さまざまな方法で完全に分離された（そしてある程度「有機的に」成長した）スタックによって処理されてきました。

于 2009-03-04T21:48:27.207 に答える
1

アパッチ+mod_wsgi、

シンプル、クリーン。(Web サーバー構成の 4 行のみ)、他のシステム管理者が理解するのは簡単です。

于 2009-03-05T21:34:32.553 に答える