ブログ | NGINX

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

アマンダ・ボッコーベン

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 プロジェクトの作成

Django プロジェクトを作成するディレクトリに移動します。
```
$ cd /var/www/
```
新しいプロジェクトを初期化するには、 django-admin startprojectコマンドを使用します。私たちはそれをdjappと呼んでいます。
```
$ sudo django-admin startproject djapp
```
プロジェクトディレクトリに変更します。
```
$ cd djapp
```
新しく作成されたプロジェクトに必要なプロジェクトのデータベースを移行するには、 manage.pyスクリプトを使用します。 Django はデフォルトで SQLite を使用します。デモではデフォルトを受け入れていますが、プロジェクトのニーズを満たす任意のデータベースを使用できます。

manage.pyスクリプトは、手順 2 で実行したdjango-adminコマンドによってインストールされます。このスクリプトはdjango-adminと同じコマンドを実行し、同じ引数を受け入れますが、プロジェクト固有の設定を自動的に導出して使用するので便利です。詳細については、 Django のドキュメントを参照してください。
```
$ sudo python3 manage.py migrate
```
このようなサンプルプロジェクトでは厳密には必要ありませんが、DjangoスーパーユーザーID を作成することをお勧めします。
```
$ sudo python3 manage.py createsuperuser
```
手順 2 でdjango-admin startprojectコマンドによって作成されたsettings.pyファイルを含むサブディレクトリに移動します。
```
$ cd /var/www/djapp/djapp
```
好みのテキストエディターを使用して、 settings.pyを開きます。ここではnano を使用しています:
```
$ sudo nano settings.py
```
ALLOWED_HOSTS行を見つけて、アプリケーションのドメイン名、ホスト名、または IP アドレスを追加します。
```
ALLOWED_HOSTS = ['domain-name']
```
また、ファイルの最後に次の行を追加して、アプリケーションによって提供されるすべての静的コンテンツを保存するディレクトリに名前を付けます (手順 9 を参照)。
```
STATIC_ROOT = '/var/www/djapp/djapp/static'
```
メインプロジェクトディレクトリ ( manage.py が存在する場所) に戻ります。
```
$ cd ..
```
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 を使用することもできます。

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

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

$ sudo nano django.conf

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

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

status_zoneディレクティブによってこの仮想サーバーに対して有効にされた拡張メトリック収集。 NGINX Plus API は構成内の他の場所で有効になっていると想定しています。
health_checkディレクティブによって有効になるアクティブなヘルスチェック。

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

# Upstream group for the backend (NGINX Unit running the Python application)
upstream django_unit {
    zone django_unit 64k;
    server 127.0.0.1:8000;
}
 
server {
    listen 8080;
    # Uncomment to collect metrics if using NGINX Plus and the NGINX Plus API
    #status_zone django;
      	
    # enable caching
    proxy_cache django_cache;
    proxy_cache_valid 200 60m;
 
    # root directory for static files
    root /var/www/djapp/djapp;
 
    # proxy to the NGINX Unit backend
    location / {
        proxy_pass http://django_unit;

        # Second argument must match your production hostname and the value of 
        # ALLOWED_HOSTS in settings.py
        proxy_set_header Host $host; 
 
        # Uncomment to enable active health checks if using NGINX Plus
        #health_check;
    }

    # Location for the static files collected from Django and served by 
    # NGINX Plus; can be empty (as here), because it inherits the value of the 
    # 'root' directive from its parent block
    location /static {
    }
}

構成の構文の妥当性を確認します。
```
$ sudo nginx –t
```
エラーを修正したら、構成を再ロードします。
```
$ sudo nginx -s reload
```

NGINXユニットの設定

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

このcurlコマンドを実行すると、PHP 上で実行されている WordPress の現在の NGINX Unit 構成が表示されます。ここでは出力を示しませんが、WordPress の設定は、これから追加する Python アプリケーションの設定とともに、以下の手順 6 に表示されます。
curlコマンドにはsudo を使用していることに注意してください。ほとんどのcurlコマンドではこれを行う必要はありません。ここでこれが必要になるのは、UNIX ソケットにアクセスするには、 rootが持つ読み取り/書き込み権限が必要だからです。
```
$ sudo curl --unix-socket /run/control.unit.sock http://localhost/config/
```
NGINX Unit 構成ファイルのディレクトリに変更します。

これらのファイルはオプションであり、NGINX Unit API 呼び出しの引数としてすべてのデータを入力せずに構成のコレクションをロードするための便利な方法にすぎないことに注意してください。ファイルの内容は API を介してアップロードされるため (すべての構成データと同様に)、NGINX Unit はファイルの場所を認識せず、起動時にファイルを自動的に読み取ることができません (NGINX Open Source や NGINX Plus とは異なります)。代わりに、NGINX Unit はランタイム状態を別のディレクトリに保存します。
```
$ cd /etc/unit
```
django.configというファイルを作成します (ここでもnano を使用します)。
```
$ sudo nano django.config
```
Python アプリケーションを表す次の JSON を追加します。
```
{
      "type": "python",
      "processes": 5,
      "module": "djapp.wsgi",
      "path": "/var/www/djapp"
}
```
この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 は新しいアプリケーションオブジェクトの名前です。
アプリケーションのリスナーオブジェクトを定義します。手順 4 のように構成データのファイルをロードするのではなく、 curlコマンドラインで直接データを定義し、 djappアプリケーションがポート 8000 でリッスンするように指定します。
```
$ sudo curl -X PUT --data-binary '{"application":"djapp"}' --unix-socket /run/control.unit.sock 'http://localhost/config/listeners/*:8000'
```

手順 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,
                        "spare": 5
                   },
 
                  "user": "www-data",
                  "group": "www-data",
                  "root": "/var/www/wordpress",
                  "script": "index.php"
            },
 
            "direct_php": {
                  "type": "php",
                  "processes": {
                        "max": 5,
                        "spare": 0
                  },
 
                  "user": "www-data",
                  "group": "www-data",
                  "root": "/var/www/wordpress",
                  "index": "index.php"
                  },
 
            "djapp": {
                  "type": "python",
                  "processes": 5,
                  "module": "djapp.wsgi",
                  "path": "/var/www/djapp"
            }
      }
}

まとめ

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

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

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

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

検索結果の提案

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

前提条件

NGINXの設定

NGINXユニットの設定

まとめ

あらゆるアプリを安全に配信しましょう

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

前提条件

NGINXの設定

NGINXユニットの設定

まとめ

あらゆるアプリを安全に配信しましょう

F5の情報を入手