ブログ | NGINX

NGINXカンファレンス2018: 本番アプリケーション用の NGINX ユニットの構成 - Django プロジェクトの提供

NGINX-F5 水平黒タイプ RGB の一部
アマンダ・ボッコーベン サムネイル
アマンダ・ボッコーベン
2018年11月28日公開

NGINX Unit は、複数の言語と各言語の複数のバージョンを提供できる完全に動的なアプリケーション サーバーです。 これは、サービスの中断や構成の再読み込みなしに、RESTful JSON API を使用してメモリ内の構成を変更するという意味で動的です。

10 月に開催されたNGINX Conf 2018でのプレゼンテーションでは、既存の本番環境で新しいアプリケーションを構成する方法を紹介しました。 具体的には、PHP 上で実行される WordPress に、Django フレームワークを使用する Python アプリケーションをデプロイしました。 また、ファイルから構成をロードする方法と、API 呼び出しの引数で指定された構成をロードする方法も示しました。

このブログには、デモで使用したすべてのコマンドと構成コードが含まれているため、独自の展開に簡単に適応できます。

前提条件

NGINX Conf のデモでは、次のソフトウェアをインストールしました。

  • Ubuntu 16.04
  • NGINX Plusですが、特に記載がない限りNGINX Open Sourceも使用できます。
  • すべての言語モジュールがインストールされたNGINXユニット
  • Python 3 の場合
  • Django (未設定 – デモとこのブログの内容はこれです)
  • ルート権限、またはsudoによる同等のアクセス（必要に応じて使用）

既存のアプリケーションとして PHP と WordPress もインストールしました。

Django プロジェクトの作成

  1. Django プロジェクトを作成するディレクトリに移動します。

    $ cd /var/www/

  2. 新しいプロジェクトを初期化するには、 django-admin startprojectコマンドを使用します。 私たちはそれをdjappと呼んでいます。

    $ sudo django-admin startproject djapp

  3. プロジェクト ディレクトリに変更します。

    $ cd djapp

  4. 新しく作成されたプロジェクトに必要なプロジェクトのデータベースを移行するには、 manage.pyスクリプトを使用します。 Django はデフォルトで SQLite を使用します。デモではデフォルトを受け入れていますが、プロジェクトのニーズを満たす任意のデータベースを使用できます。

    manage.pyスクリプトは、手順 2 で実行したdjango-adminコマンドによってインストールされます。このスクリプトはdjango-adminと同じコマンドを実行し、同じ引数を受け入れますが、プロジェクト固有の設定を自動的に導出して使用するので便利です。 詳細については、 Django のドキュメントを参照してください。 

    $ sudo python3 manage.py 移行

  5. このようなサンプル プロジェクトでは厳密には必要ありませんが、DjangoスーパーユーザーID を作成することをお勧めします。

    $ sudo python3 manage.py スーパーユーザーを作成します

  6. 手順 2 でdjango-admin startprojectコマンドによって作成されたsettings.pyファイルを含むサブディレクトリに移動します。

    $ cd /var/www/djapp/djapp

  7. 好みのテキスト エディターを使用して、 settings.pyを開きます。 ここではnano を使用しています:

    $ sudo ナノ設定.py

    ALLOWED_HOSTS行を見つけて、アプリケーションのドメイン名、ホスト名、または IP アドレスを追加します。

    ALLOWED_HOSTS = ['ドメイン名']

    また、ファイルの最後に次の行を追加して、アプリケーションによって提供されるすべての静的コンテンツを保存するディレクトリに名前を付けます (手順 9 を参照)。

    STATIC_ROOT = '/var/www/djapp/djapp/static'

  8. メイン プロジェクト ディレクトリ ( manage.py が存在する場所) に戻ります。

    $ cd ..

  9. manage.py collectstaticコマンドを実行して、Django プロジェクトにあるすべての静的ファイルを収集し、手順 7 で定義したSTATIC_ROOTの場所に配置します。

    $ sudo python3 manage.py collectstatic

NGINXの設定

デフォルトでは、Django 自体がプロジェクトの静的コンテンツを提供しますが、NGINX Open Source と NGINX Plus は優れたパフォーマンスを提供します。 ここでは NGINX Plus を設定しますが、以下に示す 1 つの機能を除いて NGINX Open Source を使用することもできます。

  1. 機能固有（またはこの場合はアプリケーション固有）の HTTP 構成ファイルの通常の場所である/etc/nginx/conf.dにディレクトリを変更します。

    $ cd /etc/nginx/conf.d

  2. django.confというファイルを作成します (ここでもnano を使用します)。

    $ sudo ナノ django.conf

    キャッシュを有効にする次の構成を挿入します。

    この構成には、NGINX Plus 専用の 2 つの機能も含まれています。 NGINX Plus を使用しており、その機能を活用したい場合は、関連するディレクティブのコメントを解除します。

    注目すべき点の 1 つは、NGINX Conf のデモでは、 proxy_set_headerディレクティブの 2 番目の引数としてローカル マシンの IP アドレスを指定したことです。 実稼働環境では、以下に示すように$host変数を使用する方が合理的です。

    # バックエンドのアップストリーム グループ (Python アプリケーションを実行する NGINX Unit)
upstream django_unit {
zone django_unit 64k;
server 127.0.0.1:8000;
}

server {
listen 8080;
# NGINX Plus と NGINX Plus API を使用している場合は、コメントを解除してメトリックを収集します
#status_zone django;

# キャッシュを有効にします
proxy_cache django_cache;
proxy_cache_valid 200 60m;

# 静的ファイルのルート ディレクトリ
root /var/www/djapp/djapp;

# NGINX Unit バックエンドへのプロキシ
location / {
proxy_pass http://django_unit;

# 2 番目の引数は、本番環境のホスト名と、settings.py の ALLOWED_HOSTS の値と一致する必要があります
proxy_set_header Host $host;

# NGINX Plus を使用している場合は、コメントを解除してアクティブ ヘルス チェックを有効にします
#health_check;
}

# Django から収集され、 
# NGINX Plus によって提供される静的ファイルの場所。親ブロックから 
# 'root' ディレクティブの値を継承するため、空にすることができます (ここのように)
location /static {
}
}

  3. 構成の構文の妥当性を確認します。

    $ sudo nginx –t

  4. エラーを修正したら、構成を再ロードします。

    $ sudo nginx -s リロード

NGINXユニットの設定

最後に、アプリケーションへのリクエストを処理するように NGINX Unit を構成する必要があります。

  1. このcurlコマンドを実行すると、PHP 上で実行されている WordPress の現在の NGINX Unit 構成が表示されます。 ここでは出力を示しませんが、WordPress の設定は、これから追加する Python アプリケーションの設定とともに、以下の手順 6 に表示されます。

    curlコマンドにはsudo を使用していることに注意してください。ほとんどのcurlコマンドではこれを行う必要はありません。 ここでこれが必要になるのは、UNIX ソケットにアクセスするには、 rootが持つ読み取り/書き込み権限が必要だからです。

    $ sudo curl --unix-socket /run/control.unit.sock http://localhost/config/

  2. NGINX Unit 構成ファイルのディレクトリに変更します。

    これらのファイルはオプションであり、NGINX Unit API 呼び出しの引数としてすべてのデータを入力せずに構成のコレクションをロードするための便利な方法にすぎないことに注意してください。ファイルの内容は API を介してアップロードされるため (すべての構成データと同様に)、NGINX Unit はファイルの場所を認識せず、起動時にファイルを自動的に読み取ることができません (NGINX Open Source や NGINX Plus とは異なります)。 代わりに、NGINX Unit はランタイム状態を別のディレクトリに保存します。

    $ cd /etc/ユニット

  3. django.configというファイルを作成します (ここでもnano を使用します)。

    $ sudo ナノ django.config

    Python アプリケーションを表す次の JSON を追加します。

    {
"type": "python",
"processes": 5、「モジュール」：「djapp.wsgi」、「パス」：「/var/www/djapp」 }

  4. このcurlコマンドを実行して、 django.configに含まれる JSON を、NGINX Unit によって管理されるdjappという新しいアプリケーション オブジェクトとして読み込みます。

    $ sudo curl -X PUT --data-binary @/etc/unit/django.config --unix-socket /run/control.unit.sock http://localhost/config/applications/djapp

    このコマンドでは、

    • HTTP PUTメソッドは、最後の引数 (URL) で指定された場所に新しい NGINX Unit 構成オブジェクトを作成します。 下の最後の箇条書きを参照してください。
    • --data-binary引数は、curl に、提供されたとおりにdjango.configの内容をロードし、改行と復帰を保持し、いかなる種類の処理も実行しないように指示します。
    • --unix-socket引数は、NGINX Unit API がリッスンする場所を定義します。 (ソケットのデフォルトの所有者であるroot を使用しているため、 sudoコマンドを使用します。)
    • 最後の引数は、 django.config内の JSON 形式の構成データを入力する新しいアプリケーション オブジェクトを検索して名前を付けます。configは最上位の NGINX Unit 構成オブジェクト、 applications はアプリケーション オブジェクトの親、 djapp は新しいアプリケーション オブジェクトの名前です。

  5. アプリケーションのリスナー オブジェクトを定義します。 手順 4 のように構成データのファイルをロードするのではなく、 curlコマンド ラインで直接データを定義し、 djappアプリケーションがポート 8000 でリッスンするように指定します。

    $ sudo curl -X PUT --data-binary '{"application":"djapp"}' --unix-socket /run/control.unit.sock 'http://localhost/config/listeners/*:8000'

  6. 手順 1 のcurlコマンドを繰り返して NGINX ユニット構成を表示します。これには、オレンジ色で強調表示された Python アプリケーションdjapp が含まれています。

    $ sudo curl --unix-socket /run/control.unit.sock http://localhost/config/ { "listeners": { "127.0.0.1:8090": { "application": "script_index_php" }, "127.0.0.1:8091": { "application": "direct_php" }, "*:8000": { "application": "djapp" } }, "applications": { "script_index_php": { "type": "php", "processes": { "max": 20、「スペア」： 5 }, "user": "www-data", "group": "www-data", "root": "/var/www/wordpress", "script": "index.php" }, "direct_php": { "type": "php", "processes": { "max": 5、「スペア」： 0 }, "ユーザー": "www-data", "グループ": "www-data", "ルート": "/var/www/wordpress", "インデックス": "index.php" }, "djapp": { "タイプ": "python", "プロセス": 5、「モジュール」：「djapp.wsgi」、「パス」：「/var/www/djapp」 } } }

まとめ

この投稿では、本番環境で WordPress 用の PHP アプリケーションを実行する NGINX Unit から始めて、Python アプリケーションを追加しました。 デモでは、NGINX Plus ダッシュボードを使用して、新しいアプリケーションが追加されても既存のアプリケーションに中断がないことを示していますが、この目的にはpsコマンドなどの任意のシステム監視ツールを使用することもできます。 NGINX ユニット構成の動的な性質により、実行中のアプリケーションのリソースが節約され、新しいデプロイメントでのダウンタイムがゼロになり、アプリケーション バージョン間のスムーズな移行が保証されます。

詳細については、 unit.nginx.org をご覧ください。

F5 NGINX に関するブログ投稿をもっと読む ›

「このブログ投稿には、入手できなくなった製品やサポートされなくなった製品が参照されている場合があります。 利用可能な F5 NGINX 製品およびソリューションに関する最新情報については、 NGINX 製品ファミリーをご覧ください。 NGINX は現在 F5 の一部です。 以前の NGINX.com リンクはすべて、F5.com の同様の NGINX コンテンツにリダイレクトされます。"