この記事は主に Django の nginx+uwsgi のデプロイに関する問題点をすべて紹介しています (概要) ので、それを共有して参考にさせていただきます。見に来てください
最近、夏休みに書いた小さなプロジェクトが完成したので、ポートを開いてpython3マネージャーrunserver 0.0を実行する必要があると考えました。 0.0:80 で完了することがわかりました。これは Django の開発モードにのみ適用され、この場合はデプロイメントに Web サーバーが必要です。 nginxを使用しました
nginx?
なぜ nginx なのか?
まず第一に、nginx は小さく、非常に軽量で、使いやすく、Apache ほど複雑ではないと思います。また、インターネット上で Django をデプロイするには nginx が推奨されています。
インストール
コマンドのインストールは nginx の Taobao の二次開発である可能性があるため、Linux ユーザーはソース コードのインストールを推奨します。個人的には、依然としてオリジナル バージョンを使用することをお勧めします。
uwsgi
なぜこれがまだ必要なのですか
簡単に言うと、nginxはリバースプロキシサーバーで何ができるのですか? 80 などのポートをリッスンするには、8000 などのリバース プロキシ ポートを構成できます。この方法では、すべての外部ユーザーのポート 80 へのアクセスは、実際にはポート 8000 からのデータを要求しますが、ユーザーは実際にはポート 8000 と通信していません。ポート 8000 ですが、このブリッジは 80 を通過しました。現時点では、これで私の本当のポートを隠すことができるとしか考えていません。何か提案があれば、メッセージを残してください。
この場合、実際には 1 人のユーザーのみがアクセスできるため、複数のユーザーが同時にアクセスできるツールが必要です。その場合、それが uwsgi です。
インストール方法?
pip install uwsgi
設定ファイル
まず、プロジェクトのファイルステータスを示します:
FlyCold ├── FlyCold │ ├── settings.py │ ├── urls.py │ └── wsgi.py ├── manage.py ├── SchoolBuy │ ├── admin.py │ ├── forms.py │ ├── __init__.py │ ├── models.py │ ├── urls.py │ └── views.py └── templates
以下の説明、これは合理化されたディレクトリツリー、作成されたプロジェクト名ですFlyCold の場合、生成された FlyCold サブディレクトリと SchoolBuy サブディレクトリが生成されます。私のメイン コードは SchoolBuy にあり、setting.py は Flycold サブディレクトリにあり、manager.py は FlyCold ルート ディレクトリにあります。
インストール後、次の内容の設定ファイルを作成します
# myweb_uwsgi.ini file [uwsgi] # Django-related settings socket = :8080 #真实服务的端口 # Django项目根目录 (绝对路径) chdir = /home/lyt/FlyCold # wsgi.py文件在项目中的位置 module = FlyCold.wsgi # process-related settings # master master = true # 运行的进程数 processes = 4 # ... with appropriate permissions - may be needed # chmod-socket = 664 # clear environment on exit vacuum = true
この .ini ファイルは、起動時にどこにでも配置できます。uwsgi --ini ***.ini
nginx を設定します。 nginx.conf を見つけて次の内容を書き込みます
server { #这里是访问时用到的端口 listen 80; server_name localhost; charset UTF-8; #这块存让日志文件 access_log /var/log/nginx/SchoolBuy_access.log; error_log /var/log/nginx/SchoolBuy_error.log; client_max_body_size 75M; location / { include uwsgi_params; #同uwsgi内容 uwsgi_pass 127.0.0.1:8001; #链接超时时间 uwsgi_read_timeout 30; } }
このようにして、nginx を再起動し、ポート 80 にアクセスすると、効果が表示されます。
まだご質問がありますか? Web ページ上の静的リソースにアクセスできないことに気付いたかもしれません。 !たとえば、管理ページは非常にシンプルになります。これは、nginx+uwsgi+Django を使用する場合、nginx を Django の静的リソースの処理のプロキシとして使用できないためです (おそらく)。つまり、nginx のほうが静的リソースを処理できるため、Django にこのようなことを許可すべきではありません。静的リソースについては nginx に処理させます。
一般的に、/media/ で始まるリンクと /static/ で始まるリンクの 2 種類の静的リソースがあります。静的は、一部の Web サイトの元の画像、ビデオ、js、および css ファイルを処理するために使用されます。Django 自体はこの種のリンクをサポートしています。では、/static/ で始まるファイルを処理するために Django をオフにする方法は非常に簡単です。現時点では、Django は /static/ ファイルを処理しません。
/media/ についてはどうですか?一般的には、ユーザーがアップロードした写真を保存し、Web ページに表示するときに /media/ を使用し、setting.py で
MEDIA_URL = '/media/' #访问的前缀链接 MEDIA_ROOT = os.path.join(BASE_DIR, '../media') #存放文件的具体位置
を設定し、url.py に
from django.conf import settings from django.conf.urls.static import static if settings.DEBUG: urlpatterns += static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)
を追加します
これが意味するのは、DEBUG=True の場合、/media/ ファイルが解析され、ファイルが保存される場所が 2 番目のパラメータになるということです。
このように、運用環境にデプロイする場合は、DEBUG を False に変更するだけでよく、Django は静的およびメディアを処理しません。
静的ファイルを収集するDjango には、nginx 分析を容易にするためにアプリケーションで使用されるすべての静的ファイルを収集できるツールがあります。具体的には:
set STATIC_ROOT = os.path.join(BASE_DIR, '../collectedstatic') in settings.py
この方法で収集された静的ファイルは、上記のディレクトリに配置されます。このツールを実行するにはどうすればよいですか? python3 manager.pycollectstatic
静的ファイルを解析するようにnginxを設定します同様に、nginx.conf
まず、ファイルの先頭にユーザーroot
ステートメントを追加して、rootユーザーがnginxを実行できるようにします。そうしないと、静的ファイルにアクセスするときにプロンプトが表示される可能性があります。許可はありません
次に、構成ファイルの場所 / 前述の場所の前に次の内容を追加します
location /static/ { autoindex on; alias /root/SchoolBuyWeb/collectedstatic/; } location /media/ { autoindex on; alias /root/SchoolBuyWeb/media/; }
エイリアスに注意して、設定したディレクトリと一致させてください。
nginxを再起動してください、もう大丈夫です~~
以上がnginx+uwsgi を使用して Django をデプロイする際のすべての問題を解決する (概要)_nginxの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。