15

Web上のほぼすべてのdjango+nginxチュートリアルを試しましたが、画面に表示する画像ファイルを取得できません。それは常に古い話です-404ページが見つかりません。Webページは正常に読み込まれますが、 /static/フォルダーのdjango.pngは読み込まれません。それがsettings.pyに問題があるのか​​、nginxに問題があるのか​​わからない。

私はそれにとても不満を感じているので、別の「nginx/djangoチュートリアルの入手方法」を見るのを拒否します。近い将来、Webサイトをデプロイする場合、GunicornはDjangoサイトを実行し、Apacheまたはnginxを使用せずに静的ファイルを同時に提供するのに十分ですか？そもそもリバースプロキシを使用することに大きなメリットはありますか？

4

5 に答える 5

15

はい。Gunicornはあなたのスタティックにもサービスを提供できます。

他のすべてが失敗した場合は、djangoに任せてください（ただし、これはフラストレーションの前の最後の手段として実行してください）。これを行うには、次のように別のURLパターンを追加する必要があります。

urlpatterns = patterns('',
    # ... the rest of your URLconf goes here ...
) + static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)

静的に提供するdjangoは、まったく提供しないよりも優れていますが、nginxのように同じように最適化されたサーバーに委任する価値があります。

最初に別のポートでnginxを実行し、django STATIC_URL設定を変更してポートを含めることをお勧めします（ポートが静的に機能することを確認した後）。-これを行うのは、nginxフォルダーからMEDIA_ROOTへのsimlinkを行うのと同じくらい簡単です。

とにかくnginxを使用している場合は、nginxを使用してすべてのリクエストをプロキシし、djangoリクエストのみをgunicornに渡すこともお勧めします。これに必要なのは、confそれに応じてnginxに通知するファイルを追加することだけです。

すべて（プロキシリクエスト、静的サービス、nginxの構成）を一度に開始して実行しようとしている人にとって、それがどのように混乱する可能性があるかがわかります。一つずつ試してみてください。gunicornからメディアを入手してください。次に、nginxからサービスを提供し、最終的にはnginxプロキシも使用します。ただし、アプリを本番環境に移行する前に、これをすべて実行してください。このアプローチは、理解を深め、欲求不満を減らすのを見てきました。

于 2012-06-02T19:25:40.797 に答える
13

Gunicornのドキュメントには、低速のクライアントをバッファリングするプロキシがないと、デフォルトのワーカーがサービス拒否攻撃を受けやすいと記載されています：http: //gunicorn.org/deploy.html

利用可能なHTTPプロキシは多数ありますが、Nginxを使用することを強くお勧めします。別のプロキシサーバーを選択する場合は、デフォルトのGunicornワーカーを使用するときに、低速のクライアントを確実にバッファリングする必要があります。このバッファリングがないと、Gunicornはサービス拒否攻撃を受けやすくなります。slowlorisを使用して、プロキシが適切に動作しているかどうかを確認できます。

これは、geventやtornadoなどの非同期ワーカーの1つを使用している場合には当てはまらない可能性があります。

于 2012-06-02T13:53:31.820 に答える
7

すでにアマゾンウェブサービスを使用している場合は、s3バケットを使用して静的コンテンツをホストし、gunicorn（または必要なもの）を使用してアプリをec2にデプロイできます。そうすれば、独自の静的ファイルサーバーを設定することをまったく心配する必要がありません。

于 2012-06-02T13:46:17.450 に答える
5

いくつかの理由から、前にNginxを使用することをお勧めします。

  • gunicornがダウンしている場合、メンテナンスまたは内部サーバーのエラーページを簡単に実装できます。つまり、アプリケーションサーバーが実行されていない場合は、常に応答するものがあります。
  • Gunicornのドキュメントが示唆しているように、DOSなどのhttp攻撃は検出されません。
  • 後で独自の負荷分散戦略を実装することをお勧めします。これは、プロジェクトの規模が大きくなるにつれて、リリースエンジニアリングにとってより重要になります。個人的には、AWS ELBの信頼性が少し低いと感じており、それについて考えています。

更新：

また、Gunicornの開発者によるよく書かれた回答をご覧ください。

なぜNginxとGunicornのようなものが必要なのですか？

于 2013-07-20T17:01:54.593 に答える
2

Werkzeugミドルウェアを使用して作成しました。nginxサーバーを使用するほど美しくもパフォーマンスも良くありませんが、次のような役割を果たします。

settings.pyでSTATIC_ROOTを設定します

# project/settings.py
import os
BASE_DIR = os.path.dirname(os.path.dirname(__file__)))
STATIC_ROOT = BASE_DIR+'/static-collected'

このフォルダからファイルを提供するようにWerkzeugに指示するより

# project/wsgi.py
import os
BASE_DIR = os.path.dirname(os.path.dirname(__file__))

(...)
from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()
(...)

import os
from werkzeug.wsgi import SharedDataMiddleware
print 'Installing WSGI static files server middleware'
application = SharedDataMiddleware(application, {
    '/static': os.path.join(BASE_DIR, 'static-collected'),
})

DEBUG = Trueの場合、Djangoはファイルを提供します。DEBUG = Falseの場合、Werkzeugは静的に収集されたフォルダーからファイルを提供します。これを機能させるには、DEBUG=Falseを使用するサーバーでcollectstaticを実行する必要があります。

Obs：何らかの理由で、Werkzeugは見つからないファイルに対して404ではなく500を提供します。奇妙ですが、それでも機能します。理由がわかっている場合は、コメントしてください。

于 2013-06-11T20:14:03.180 に答える