[解決済み] gunicornとnginxを使ったDjangoのデプロイメント

質問

これは広範な質問ですが、私は正規の答えを得たいと思います。私は、あるサイトを gunicorn と nginx で Django . 大量のチュートリアルを読んだ後、私は成功しましたが、私が従った手順が問題なくサイトを運営するのに十分であるかどうか、あるいはもっと良い方法があるのかどうか、確信が持てません。その不確実性が厄介です。

だから、初心者のためにとても詳しくてよく説明された答えを探しているんです。これは回答を少し歪める可能性があり、他の人があなたの回答からあまり恩恵を受けないかもしれないので、私が知っていることと知らないことをあまり説明したくありません。しかし、言及してほしいことがいくつかあります。

• どのようなセットアップが最も効果的だと思われますか？私が使用したのは virtualenv を使用し、私の Django プロジェクトをこの環境内に移動しました。しかし、仮想環境用のフォルダとプロジェクト用のフォルダが存在する別のセットアップを見たことがあります。

• 複数のサイトを 1 つのサーバーでホストできるようにするには、どのようにセットアップすればよいでしょうか。

• なぜ一部の人々は gunicorn_django -b 0.0.0.0:8000 を使うことを提案する人がいて、他の人は gunicorn_django -b 127.0.0.1:8000 ? Amazon EC2インスタンスでテストしてみましたが、前者は問題なく動いたのに対し、後者は動きませんでした。

• nginx の設定ファイルの背後にある論理は何ですか？多くのチュートリアルが全く異なる設定ファイルを使用しているので、どれが良いのか混乱しています。例えば、ある人は alias /path/to/static/folder を使う人もいれば root /path/to/static/folder . もしかしたら、あなたの好みの設定ファイルを共有できるかもしれません。

• の間にシンボリックリンクを作成するのはなぜですか？ site-available と sites-enabled で /etc/nginx ?

• いくつかのベストプラクティスはいつでも歓迎します :-)

ありがとうございます。

どのように解決するのですか？

どのようなセットアップが一番効果的でしたか？私はvirtualenvを使用し、私の しかし、私は別のセットアップを見たことがあります。 しかし、仮想環境用のフォルダとプロジェクト用のフォルダがある別のセットアップを見たことがあります。 プロジェクト用のフォルダがあります。

virtualenv は Python 環境を分離するための方法です。 デプロイメント - しかし 開発 と テスト は、強く推奨されないまでも、必要条件です。

virtualenvから得られる価値は、アプリケーションのために正しいバージョンのライブラリがインストールされていることを確認できることです。 そのため、仮想環境そのものをどこに置くかは問題ではありません。ただ、ソースコードのバージョン管理システムの一部としてそれを含めないことを確認してください。

ファイルシステムのレイアウトは重要ではありません。ディレクトリ レイアウトや、出発点としてクローンできるスケルトン プロジェクトの美徳を賞賛する多くの記事を目にすることでしょう。 私は、これは必須の要件というよりも、個人的な好みであると感じています。もちろん、あるに越したことはないのですが の理由を知っていなければなりません。 の理由を知らない限り、デプロイメント プロセスに何の価値も与えません。したがって、あなたのシナリオにとって意味がない限り、あるブログが推奨しているからといってそれを実行しないでください。たとえば setup.py ファイルを作成する必要はありません。

複数のサイトを1つのサーバでホストできるようにするには、どのように設定すればよいですか？ を1つのサーバでホストできるようにするにはどうすればよいですか？

複数のサイトのセットアップを行うには、2つのことが必要です。

1. 公開 IP でポート 80 および/または SSL を使用している場合はポート 443 をリッスンしているサーバー。
2. 実際の django ソースコードを実行している、たくさんの "processes" です。

nginx は非常に高速なプロキシであり、Apache のような包括的なサーバのオーバーヘッドを伴わないので、人々は #1 に nginx を使用しています。 Apache のような包括的なサーバのオーバーヘッドがないためです。そのポートでリッスンしていて、実際の django コードを実行しているプロセスへリダイレクト (プロキシ) する方法を知っているサービスが必要なだけです。

2については、これらのプロセスを開始する方法がいくつかあります。gevent/uwsgiが最も有名なものです。ここで覚えておくべき唯一のことは 実稼働環境ではランサーバーを使用しないこと .

これらは絶対的な最低要件です。一般的に、人々は実行中のすべての "django servers" (#2) を制御するために、ある種のプロセスマネージャを追加します。ここで、あなたは upstart と supervisor が挙げられます。私は、（upstart とは異なり）システム全体を引き継ぐ必要がない supervisor を好みます。しかしながら、繰り返しになりますが、これは ハード要件 . あなたは完全に、たくさんの screen セッションを実行し、それらをデタッチすることができます。欠点は、サーバーが再起動した場合、スクリーン セッションを再起動する必要があることです。

個人的には、私は

1. 1位はNginx
2. uwsgiとgunicornのどちらかを選びます。
3. 管理者 バックエンドプロセスを管理するためのものです。
4. ホストしている各アプリケーションのための個別のシステムアカウント（ユーザー）。

4を推奨する理由は、パーミッションを分離するためです。繰り返しますが、必須条件ではありません。

なぜ、ある人は gunicorn_django -b 0.0.0.0:8000 を使い、他の人は gunicorn_django -b 127.0.0.1:8000 を使うことを勧めるのですか？ gunicorn_django -b 127.0.0.1:8000を提案する人がいるのはなぜですか？私は後者をテストしました Amazon EC2インスタンスでテストしましたが、前者は問題なく動作しましたが、後者は動作しませんでした。 問題なく動作しました。

0.0.0.0 はすべてのIPアドレスを意味し、メタアドレス（つまりプレースホルダアドレス）です。 127.0.0.1 は予約されたアドレスで、常にローカルマシンを指しています。そのため、"localhost" と呼ばれています。これは、同じシステム上で実行されているプロセスに対してのみ到達可能です。

通常、フロントエンドサーバー (上記のリストの 1 番目) はパブリック IP アドレスをリッスンしています。あなたは にサーバを明示的にバインドする必要があります。 1 IP アドレス .

しかし、何らかの理由で DHCP を使用している場合や、IP アドレスがわからない場合（例えば、新しくプロビジョニングされたシステム）、nginx/apache/その他のプロセスに、バインド先を 0.0.0.0 . であるべきです。 一時的な応急処置 .

本番サーバーの場合は、静的 IP を持つことになります。動的IP(DHCP)を使用している場合は、そのまま 0.0.0.0 . しかし、実稼働マシンにDHCPがあることは非常に稀です。

gunicorn/uwsgi をこのアドレスにバインドするのは 推奨されません。 です。もしバックエンドプロセス (gunicorn/uwsgi) を 0.0.0.0 にバインドすると、フロントエンドプロキシ (nginx/apache/etc) をバイパスして "direct" にアクセスできるようになるかもしれません。 http://your.public.ip.address:9000/ をリクエストし、あなたのアプリケーションに直接アクセスすることができます。 特にフロントエンドサーバ (nginx) とバックエンドプロセス (django/uwsgi/gevent) が同じマシンで動作している場合 .

フロントエンドのプロキシサーバを運用する手間を省きたいのであれば、自由にやればいいのですが。

nginx の設定ファイルはどのような理屈で作られているのですか？非常に多くの チュートリアルがあり、どれが良いのか迷っています。 どれが良いのか迷っています。例えば、ある人は "alias;を使っています。 /path/to/static/folder" を使っている人もいれば、 "root /path/to/static/folder" を使っている人もいるようです。 もしかしたら、あなたの好みの設定ファイルを共有できるかもしれません。

nginxについて最初に知っておくべきことは、nginxは ウェブサーバではない Apache や IIS のようなウェブサーバではないということです。プロキシなのです。そのため、「アップストリーム」「ダウンストリーム」といった異なる用語や、複数の「サーバ」などが定義されているのがわかると思います。まずはnginxのマニュアルをじっくり読んでみてください。

nginx のセットアップには様々な方法がありますが、ここでは質問に対する一つの答えを示します。 alias との比較です。 root . root は、nginx のドキュメントルート（"ホームディレクトリ"）をバインドする明示的なディレクティブです。のようなパスがないリクエストを送ったときに、このディレクトリが参照されます。 http://www.example.com/

alias は、"名前をディレクトリにマップする"を意味します。エイリアスディレクトリ は をドキュメントルートのサブディレクトリにすることはできません。

なぜ、site-availableとsites-enabledの間にシンボリックリンクを /の間にシンボリック リンクを作成するのはなぜですか?

これは debian (および ubuntu のような debian に似たシステム) に特有のものです。 sites-available は、システム上の全てのバーチャルホスト/サイトの設定ファイルをリストアップします。からのシンボリックリンクは sites-enabled から sites-available はそのサイトやバーチャルホストを有効化します。これは、設定ファイルを分離し、簡単にホストを有効化/無効化する方法です。