82

これは幅広い質問ですが、標準的な回答を得たいと思います。Djangoでgunicornとnginxを使用してサイトをデプロイしようとしています。たくさんのチュートリアルを読んだ後、私は成功しましたが、従った手順がサイトを問題なく実行するのに十分であるか、それを行うためのより良い方法があるかどうかはわかりません. その不確実性は厄介です。

そのため、初心者向けの非常に詳細でよく説明された回答を探しています。私が知っていることと私が知らないことをあまり説明したくありません. ただし、私が言及したいいくつかのことは次のとおりです。

  • どの「セットアップ」が最も効果的でしたか? virtualenvを使用し、 Djangoプロジェクトをこの環境内に移動しましたが、仮想環境用のフォルダーとプロジェクト用のフォルダーがある別のセットアップを見てきました。

  • 単一のサーバーで複数のサイトをホストできるように設定するにはどうすればよいですか?

  • なぜ一部の人は使用を提案し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ですか?

  • いくつかのベスト プラクティスは常に歓迎されます :-)

ありがとう

4

4 に答える 4

106

どの「セットアップ」が最も効果的でしたか? 私はvirtualenvを使用し、djangoプロジェクトをこの環境内に移動しましたが、仮想環境用のフォルダーとプロジェクト用のフォルダーがある別のセットアップを見てきました。

virtualenv は Python 環境を分離する方法です。そのため、展開時に大きな役割を果たすことはありませんが、開発およびテスト中は必須ですが、強くお勧めしません。

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

ファイル システムのレイアウトは重要ではありません。ディレクトリ レイアウトの利点を称賛する記事や、出発点として複製できるスケルトン プロジェクトを称賛する記事がたくさんあります。これは厳密な要件というよりも個人的な好みだと思います。確かに持っているのはいいことです。ただし、理由がわからない限り、展開プロセスに価値はありません。シナリオにとって意味がない限り、一部のブログで推奨されているため、実行しないでください。たとえばsetup.py、展開ワークフローの一部であるプライベート PyPi サーバーがない場合、ファイルを作成する必要はありません。

単一のサーバーで複数のサイトをホストできるように設定するにはどうすればよいですか?

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

  1. SSL を使用している場合は、ポート 80 および/またはポート 443 でパブリック IP をリッスンしているサーバー。
  2. 実際の django ソース コードを実行している一連の「プロセス」。

人々は #1 に nginx を使用します。これは、非常に高速なプロキシであり、Apache のような包括的なサーバーのオーバーヘッドが発生しないためです。Apache に慣れている場合は、自由に使用できます。「複数のサイトの場合、nginx を使用する」という要件はありません。そのポートでリッスンし、実際のdjangoコードを実行しているプロセスにリダイレクト（プロキシ）する方法を知っているサービスが必要なだけです。

#2 については、これらのプロセスを開始する方法がいくつかあります。gevent/uwsgi が最も人気のあるものです。ここで覚えておくべき唯一のことは、本番環境では runserver を使用しないことです。

これらは絶対的な最小要件です。通常、実行中のすべての「djangoサーバー」（＃2）を制御するために、ある種のプロセスマネージャーを追加します。ここでは、参照upstartしてsupervisor言及します。システム全体を引き継ぐ必要がないため、スーパーバイザーを好みます（新興企業とは異なります）。ただし、繰り返しますが、これは難しい要件ではありません。screen一連のセッションを完全に実行して、それらを切り離すことができます。欠点は、サーバーが再起動した場合に、画面セッションを再起動する必要があることです。

個人的に私はお勧めします：

  1. ＃1のNginx
  2. uwsgi と gunicorn のどちらかを選択してください。私は uwsgi を使用しています。
  3. バックエンド プロセスを管理するスーパーバイザー。
  4. ホスティングしている各アプリケーションの個々のシステム アカウント (ユーザー)。

#4 をお勧めする理由は、権限を分離するためです。繰り返しますが、要件ではありません。

gunicorn_django -b 0.0.0.0:8000 の使用を提案する人もいれば、gunicorn_django -b 127.0.0.1:8000 の使用を提案する人がいるのはなぜですか? Amazon EC2 インスタンスで後者をテストしましたが、前者は問題なく動作しましたが、動作しませんでした。

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

通常、パブリック IP アドレスでリッスンするフロント エンド サーバー (上記のリストの 1 番目) があります。サーバーを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) をバイパスして「直接」アクセスできるようになります。特にフロントエンド サーバー (nginx) とバックエンド プロセス (django/uwsgi/gevent) が同じマシンで実行されている場合、誰かがアプリケーションを直接要求http://your.public.ip.address:9000/してアクセスする可能性があります。

ただし、フロントエンド プロキシ サーバーを実行する手間をかけたくない場合は、自由に実行できます。

nginx の構成ファイルの背後にあるロジックは何ですか? 大幅に異なる構成ファイルを使用するチュートリアルが非常に多くあるため、どちらが優れているかについて混乱しています。たとえば、「エイリアス /path/to/static/folder」を使用する人もいれば、「root /path/to/static/folder」を使用する人もいます。おそらく、好みの構成ファイルを共有できます。

nginx について最初に知っておくべきことは、これがApache や IIS のようなWeb サーバーではないということです。プロキシです。したがって、「上流」/「下流」や複数の「サーバー」などのさまざまな用語が定義されていることがわかります。時間をかけて、最初に nginx のマニュアルを読んでください。

nginx をセットアップするにはさまざまな方法があります。aliasしかし、これはvs.に関するあなたの質問に対する 1 つの答えrootです。rootnginx のドキュメント ルート (「ホーム ディレクトリ」) をバインドする明示的なディレクティブです。これは、次のようなパスなしでリクエストを送信したときに参照するディレクトリですhttp://www.example.com/

alias「名前をディレクトリにマップする」ことを意味します。エイリアス ディレクトリは、ドキュメント ルートのサブ ディレクトリではない場合があります。

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

これは、debian (および ubuntu のような debian に似たシステム) に固有のものです。 sites-availableシステム上のすべての仮想ホスト/サイトの構成ファイルを一覧表示します。sites-enabledからへのシンボリック リンクは、sites-availableそのサイトまたは仮想ホストを「アクティブ化」します。これは、構成ファイルを分離し、ホストを簡単に有効/無効にする方法です。

于 2012-10-22T04:25:46.783 に答える
11

私はデプロイメントの第一人者ではありませんが、gevent を使用して Django をデプロイするための私のプラクティスのいくつかを共有します (gunicorn に似ているはずです)。

virtualenv私が立ち入らない理由で素晴らしいです。ただし、virtualenv-wrapper（docs）は非常に便利であることがわかりました。特に、さまざまな仮想環境を簡単に切り替えることができるため、多くのプロジェクトに取り組んでいる場合はそうです。これは実際にはデプロイメント環境には当てはまりませんが、SSH を使用してサーバーでトラブルシューティングを行う必要がある場合、これは非常に便利であることがわかりました。これを使用するもう 1 つの利点は、virtualenv ディレクトリを管理するため、手作業が少なくなることです。Virtualenv は使い捨てであるため、バージョンの問題やその他のインストールの問題が発生した場合は、env をダンプして新しいものを作成できます。そのため、virtualenv 内にプロジェクト コードを含めないことがベスト プラクティスです。別々に保管する必要があります。

複数のサイトのセットアップに関してvirtualenvは、ほぼ答えです。プロジェクトごとに個別の virutalenv が必要です。それだけで多くの問題を解決できます。その後、デプロイすると、別の Python プロセスが別のサイトを実行し、デプロイ間の競合を回避します。同じサーバーで複数のサイトを管理するのに特に便利なツールの 1 つにsupervisor( docs）。さまざまな Django インスタンスを開始、停止、および再起動するための簡単なインターフェイスを提供します。また、プロセスが失敗したときやコンピューターの起動時にプロセスを自動再起動することもできます。たとえば、何らかの例外が発生し、それをキャッチするものがない場合、Web サイト全体がダウンする可能性があります。スーパーバイザーはそれをキャッチし、Django インスタンスを自動的に再起動します。以下は、スーパーバイザー プログラム (単一プロセス) 構成のサンプルです。

[program:foo]
command=/path/toviertualenv/bin/python deploy.py
directory=/path/where/deploy.py/is/located/
autostart=true
autorestart=true
redirect_stderr=True
user=www

Nginx の場合、最初は圧倒される可能性があることはわかっています。Nginxの本はとても役に立ちました。すべての主要な nginx ディレクティブについて説明します。

私の nginx インストールでは、ベスト プラクティスは、ファイル内のコア構成のみをセットアップすることであることがわかりました。次に、ホストするサイトごとに nginx 構成を保持nginx.confする別のフォルダーを作成します。sites次に、そのフォルダーのすべてのファイルをコア構成ファイルに含めます。ディレクティブを使用しinclude sites/+*.conf;ます。このようにして、フォルダー+内のシンボルで始まるファイルのみが含まれます。sitesそうすれば、ファイル名だけで、どの構成ファイルをロードするかを制御できます。したがって、特定のサイトを無効にしたい場合は、構成ファイルの名前を変更して nginx を再起動するだけです。includeこれらはApacheの名前付きフォルダーであるため、質問の「/ etc/nginxで利用可能なサイトと有効なサイトの間のシンボリックリンク」が何を意味するのかよくわかりませんが、ディレクティブと同様のタスクを実行します。

rootおよびディレクティブに関してaliasは、ルートが計算される場所を除いて、それらはほとんど同じです。では、でドロップさaliasれたものは何でも、ルートではそうではありません。location次の nginx 構成があることをイメージします。

location /static {
    alias /some/path/;
}
location /static2 {
    root /some/other/path/;
}

ユーザーがこれらの URL にアクセスすると、nginx はシステム上の次の場所でファイルを検索しようとします。

/static/hello/world.pdf => /some/path/hello/world.pdf
/static2/hello/world.pdf => /some/other/path/static2/hello/world.pdf

これは、nginx サイトの単純な構成です。

server {
    server_name .foodomain.com;
    listen 80;

    access_log logs/foodomain.log;

    gzip                on;
    gzip_http_version   1.0;
    gzip_comp_level     2;
    gzip_proxied        any;
    gzip_min_length     1100;
    gzip_buffers        16 8k;
    gzip_types          text/plain text/html text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript;

    # Some version of IE 6 don't handle compression well on some mime-types, so just disable for them
    gzip_disable "MSIE [1-6].(?!.*SV1)";

    # Set a vary header so downstream proxies don't send cached gzipped content to IE6
    gzip_vary on;

    location / {
        proxy_read_timeout      30s;
        proxy_pass              http://localhost:8000;
        proxy_set_header        Host                 $host;
        proxy_set_header        User-Agent           $http_user_agent;
        proxy_set_header        X-Real-IP            $remote_addr;
    }

    location /media {
        alias   /path/to/media/;
        expires 1y;
    }

    location /static {
        autoindex on;
        expires   1y;
        alias     /path/to/static/;
    }

     location /favicon.ico {
        alias /path/to/favicon.ico;
    }
}

うまくいけば、これはあなたを少し助けます。

于 2012-10-22T03:53:31.997 に答える
2

ええと、あなたが質問で尋ねたベストプラクティスに関する限り、文字通り、私にとって驚異的に機能するツールを共有せずにはいられません! 私自身、いくつかのサイトの gunicorn、nginx、supervisorD のいくつかの構成ファイルで混乱していました。しかし、どうにかしてプロセス全体を自動化し、アプリやサイトに変更を加えてすぐに展開できるようにしたいと考えていました。その名はジャンゴ・ファグンギス。Django デプロイメントの自動化に関する私の経験の詳細については、こちらを参照してください。fabfile.py ONCEを構成しました（django-fagungisはファブリックを使用してプロセス全体を自動化し、リモートサーバーに非常に便利なvirtualenvを作成します単一のサーバーでホストされている複数のサイトの依存関係を管理します。nginx、gunicorn、および SupervisorD を使用して Django プロジェクト/サイトの展開を処理し、django-fagungis は最新のプロジェクトを bitbucket (サブバージョン管理に使用) から複製し、リモート サーバーに展開します。シェルで 3 つのコマンドを入力するだけです。私のローカルマシンのそれとそれ!! 私にとって、これは Django の展開に最適で手間のかからない方法であることが判明しました。

于 2013-02-08T15:21:04.477 に答える
2

Django プロジェクトに必要な最小限の gunicorn および nginx 構成については、これを確認してください。 http://agiliq.com/blog/2013/08/minimal-nginx-and-gunicorn-configuration-for-djang/

于 2013-12-16T20:47:03.857 に答える