Ubuntu22.04でPostgres、Nginx、Gunicornを使用してDjangoをセットアップする方法
序章
Djangoは、PythonアプリケーションまたはWebサイトを立ち上げるのに役立つ強力なWebフレームワークです。 Djangoには、コードをローカルでテストするための簡略化された開発サーバーが含まれていますが、本番環境に少しでも関連する場合は、より安全で強力なWebサーバーが必要です。
このガイドでは、Djangoアプリケーションをサポートおよび提供するために、Ubuntu22.04にいくつかのコンポーネントをインストールして構成します。 デフォルトのSQLiteデータベースを使用する代わりに、PostgreSQLデータベースをセットアップします。 アプリケーションとインターフェイスするようにGunicornアプリケーションサーバーを構成します。 次に、GunicornにリバースプロキシするようにNginxを設定し、アプリを提供するためのセキュリティ機能とパフォーマンス機能にアクセスできるようにします。
前提条件と目標
このガイドを完了するには、基本的なファイアウォールを備えた新しいUbuntu 22.04サーバーインスタンスと、sudo
権限が構成された非rootユーザーが必要です。 初期サーバーセットアップガイドを実行すると、これをセットアップする方法を学ぶことができます。
仮想環境内にDjangoをインストールします。 プロジェクトに固有の環境にDjangoをインストールすると、プロジェクトとその要件を個別に処理できるようになります。
データベースとアプリケーションを起動して実行したら、Gunicornアプリケーションサーバーをインストールして構成します。 これは、アプリケーションへのインターフェースとして機能し、クライアント要求をHTTPからアプリケーションが処理できるPython呼び出しに変換します。 次に、Gunicornの前にNginxをセットアップして、その高性能接続処理メカニズムと実装が容易なセキュリティ機能を利用します。
始めましょう。
Ubuntuリポジトリからのパッケージのインストール
プロセスを開始するには、Ubuntuリポジトリから必要なすべてのアイテムをダウンロードしてインストールします。 後で、Pythonパッケージマネージャーpip
を使用して追加のコンポーネントをインストールします。
まず、ローカルのapt
パッケージインデックスを更新してから、パッケージをダウンロードしてインストールする必要があります。 インストールするパッケージは、プロジェクトで使用するPythonのバージョンによって異なります。
Python 3 でDjangoを使用している場合は、次のように入力します。
sudo apt update sudo apt install python3-venv python3-dev libpq-dev postgresql postgresql-contrib nginx curl
このコマンドは、Pythonプロジェクト、後でGunicornを構築するために必要なPython開発ファイル、Postgresデータベースシステムとそれと対話するために必要なライブラリ、およびNginxWebサーバー用の仮想環境を作成するためのツールをインストールします。
PostgreSQLデータベースとユーザーの作成
これで、すぐにジャンプして、Djangoアプリケーションのデータベースとデータベースユーザーを作成できます。
デフォルトでは、Postgresはローカル接続に「ピア認証」と呼ばれる認証スキームを使用します。 基本的に、これは、ユーザーのオペレーティングシステムのユーザー名が有効なPostgresユーザー名と一致する場合、そのユーザーはそれ以上の認証なしでログインできることを意味します。
Postgresのインストール中に、postgres
という名前のオペレーティングシステムユーザーが、postgres
PostgreSQL管理ユーザーに対応するように作成されました。 管理タスクを実行するには、このユーザーを使用する必要があります。 -u
オプションを使用すると、sudoを使用してユーザー名を渡すことができます。
次のように入力して、インタラクティブなPostgresセッションにログインします。
sudo -u postgres psql
要件を設定できるPostgreSQLプロンプトが表示されます。
まず、プロジェクトのデータベースを作成します。
CREATE DATABASE myproject;
注:すべてのPostgresステートメントはセミコロンで終了する必要があるため、問題が発生している場合は、コマンドがセミコロンで終了していることを確認してください。
次に、プロジェクトのデータベースユーザーを作成します。 安全なパスワードを選択してください。
CREATE USER myprojectuser WITH PASSWORD 'password';
その後、作成したばかりのユーザーの接続パラメーターのいくつかを変更します。 これにより、データベース操作が高速化されるため、接続が確立されるたびに正しい値を照会して設定する必要がなくなります。
デフォルトの文字エンコードをUTF-8
に設定します。これは、Djangoが期待するものです。 また、デフォルトのトランザクション分離スキームを「読み取りコミット」に設定しています。これは、コミットされていないトランザクションからの読み取りをブロックします。 最後に、タイムゾーンを設定します。 デフォルトでは、DjangoプロジェクトはUTC
を使用するように設定されます。 これらはすべて、Djangoプロジェクト自体からの推奨事項です。
ALTER ROLE myprojectuser SET client_encoding TO 'utf8'; ALTER ROLE myprojectuser SET default_transaction_isolation TO 'read committed'; ALTER ROLE myprojectuser SET timezone TO 'UTC';
これで、新しいユーザーに新しいデータベースを管理するためのアクセス権を与えることができます。
GRANT ALL PRIVILEGES ON DATABASE myproject TO myprojectuser;
終了したら、次のように入力してPostgreSQLプロンプトを終了します。
\q
これで、Djangoがデータベース情報に接続して管理できるようにPostgresが設定されました。
プロジェクト用のPython仮想環境の作成
データベースの準備ができたので、残りのプロジェクト要件の取得を開始できます。 管理を容易にするために、仮想環境内にPython要件をインストールします。
まず、プロジェクトファイルを保存できるディレクトリを作成して変更します。
mkdir ~/myprojectdir cd ~/myprojectdir
プロジェクトディレクトリ内で、次のように入力してPython仮想環境を作成します。
python3 -m venv myprojectenv
これにより、myprojectdir
ディレクトリ内にmyprojectenv
というディレクトリが作成されます。 内部には、Pythonのローカルバージョンとpip
のローカルバージョンをインストールしてパッケージを管理します。 この仮想環境構造を使用して、作成するプロジェクト用に分離されたPython環境をインストールおよび構成できます。
プロジェクトのPython要件をインストールする前に、仮想環境をアクティブ化する必要があります。 次のように入力すると、次のように入力できます。
source myprojectenv/bin/activate
プロンプトが変化して、Python仮想環境内で操作していることを示します。 (myprojectenv)user@host:~/myprojectdir$
のようになります。
仮想環境をアクティブにして、Django、Gunicorn、およびpsycopg2
PostgreSQLアダプターをpip
のローカルインスタンスとともにインストールします。
注:仮想環境がアクティブ化されている場合(プロンプトの前に(myprojectenv)
がある場合)、使用している場合でも、pip3
の代わりにpip
を使用してくださいPython3。 仮想環境のツールのコピーには、Pythonのバージョンに関係なく、常にpip
という名前が付けられます。
pip install django gunicorn psycopg2-binary
これで、Djangoプロジェクトを開始するために必要なすべてのソフトウェアが揃いました。
新しいDjangoプロジェクトの作成と構成
Pythonコンポーネントをインストールすると、実際のDjangoプロジェクトファイルを作成できるようになります。
Djangoプロジェクトの作成
すでにプロジェクトディレクトリがあるので、ここにファイルをインストールするようにDjangoに指示します。 通常の実際のコードを使用して第2レベルのディレクトリを作成し、このディレクトリに管理スクリプトを配置します。 これの鍵は、Djangoが現在のディレクトリに関連する決定を行うことを許可するのではなく、ディレクトリを明示的に定義していることです。
django-admin startproject myproject ~/myprojectdir
この時点で、プロジェクトディレクトリ(この例では~/myprojectdir
)には次のコンテンツが含まれているはずです。
~/myprojectdir/manage.py
:Djangoプロジェクト管理スクリプト。~/myprojectdir/myproject/
:Djangoプロジェクトパッケージ。 これには、__init__.py
、settings.py
、urls.py
、asgi.py
、およびwsgi.py
ファイルが含まれている必要があります。~/myprojectdir/myprojectenv/
:前に作成した仮想環境ディレクトリ。
プロジェクト設定の調整
新しく作成したプロジェクトファイルで最初に行うべきことは、設定を調整することです。 テキストエディタで設定ファイルを開きます。
nano ~/myprojectdir/myproject/settings.py
ALLOWED_HOSTS
ディレクティブを見つけることから始めます。 これは、サーバーのアドレスまたはドメイン名のリストを定義し、Djangoインスタンスへの接続に使用できます。 このリストにないHostヘッダーを持つ着信要求は、例外を発生させます。 Djangoでは、特定のクラスのセキュリティの脆弱性を防ぐためにこれを設定する必要があります。
角かっこ内に、Djangoサーバーに関連付けられているIPアドレスまたはドメイン名をリストします。 各項目は、エントリをコンマで区切って引用符で囲む必要があります。 ドメイン全体とサブドメインのリクエストを希望する場合は、エントリの先頭にピリオドを追加します。 以下のスニペットには、デモンストレーションに使用されるコメントアウトされた例がいくつかあります。
注:ローカルのNginxインスタンスを介して接続をプロキシするため、オプションの1つとしてlocalhost
を必ず含めてください。
〜/ myprojectdir / myproject / settings.py
. . . # The simplest case: just add the domain name(s) and IP addresses of your Django server # ALLOWED_HOSTS = [ 'example.com', '203.0.113.5'] # To respond to 'example.com' and any subdomains, start the domain with a dot # ALLOWED_HOSTS = ['.example.com', '203.0.113.5'] ALLOWED_HOSTS = ['your_server_domain_or_IP', 'second_domain_or_IP', . . ., 'localhost']
次に、データベースアクセスを構成するセクションを見つけます。 DATABASES
で始まります。 ファイル内の構成はSQLiteデータベース用です。 プロジェクト用にPostgreSQLデータベースをすでに作成しているので、設定を調整する必要があります。
PostgreSQLデータベース情報で設定を変更します。 pip
でインストールしたpsycopg2
アダプターを使用するようにDjangoに指示します。 データベース名、データベースユーザー名、データベースユーザーのパスワードを指定してから、データベースがローカルコンピューター上にあることを指定する必要があります。 PORT
設定は空の文字列のままにしておくことができます。
〜/ myprojectdir / myproject / settings.py
. . . DATABASES = { 'default': { 'ENGINE': 'django.db.backends.postgresql_psycopg2', 'NAME': 'myproject', 'USER': 'myprojectuser', 'PASSWORD': 'password', 'HOST': 'localhost', 'PORT': '', } } . . .
次に、ファイルの一番下に移動し、静的ファイルを配置する場所を示す設定を追加します。 これは、Nginxがこれらのアイテムのリクエストを処理できるようにするために必要です。 次の行は、ベースプロジェクトディレクトリのstatic
というディレクトリにそれらを配置するようにDjangoに指示しています。
〜/ myprojectdir / myproject / settings.py
. . . STATIC_URL = 'static/' # Default primary key field type # https://docs.djangoproject.com/en/4.0/ref/settings/#default-auto-field DEFAULT_AUTO_FIELD = 'django.db.models.BigAutoField' import os STATIC_ROOT = os.path.join(BASE_DIR, 'static/')
終了したら、ファイルを保存して閉じます。
プロジェクトの初期設定の完了
これで、管理スクリプトを使用して、初期データベーススキーマをPostgreSQLデータベースに移行できます。
~/myprojectdir/manage.py makemigrations ~/myprojectdir/manage.py migrate
次のように入力して、プロジェクトの管理ユーザーを作成します。
~/myprojectdir/manage.py createsuperuser
ユーザー名を選択し、メールアドレスを入力し、パスワードを選択して確認する必要があります。
次のように入力して、構成したディレクトリの場所にすべての静的コンテンツを収集できます。
~/myprojectdir/manage.py collectstatic
操作を確認する必要があります。 静的ファイルは、プロジェクトディレクトリ内のstatic
というディレクトリに配置されます。
サーバーの初期設定ガイドに従った場合は、サーバーを保護するUFWファイアウォールが必要です。 開発サーバーをテストするには、使用するポートへのアクセスを許可する必要があります。
次のように入力して、ポート8000の例外を作成します。
sudo ufw allow 8000
最後に、次のコマンドを使用してDjango開発サーバーを起動することにより、プロジェクトをテストできます。
~/myprojectdir/manage.py runserver 0.0.0.0:8000
Webブラウザーで、サーバーのドメイン名またはIPアドレスにアクセスし、その後に:8000
を続けます。
http://server_domain_or_IP:8000
デフォルトのDjangoインデックスページが表示されます。
アドレスバーのURLの末尾に/admin
を追加すると、createsuperuser
コマンドで作成した管理用ユーザー名とパスワードの入力を求められます。
認証後、デフォルトのDjango管理インターフェースにアクセスできます。
探索が終了したら、ターミナルウィンドウで CTRL-C を押して、開発サーバーをシャットダウンします。
プロジェクトにサービスを提供するGunicornの能力をテストする
仮想環境を離れる前に最後に行う必要があるのは、Gunicornをテストして、アプリケーションにサービスを提供できることを確認することです。 これを行うには、プロジェクトディレクトリに入り、gunicorn
を使用してプロジェクトのWSGIモジュールをロードします。
cd ~/myprojectdir gunicorn --bind 0.0.0.0:8000 myproject.wsgi
これにより、Django開発サーバーが実行されていたのと同じインターフェースでGunicornが起動します。 戻って、ブラウザでアプリを再度テストできます。
注: Gunicornはこれに関与する静的CSSコンテンツを見つける方法を知らないため、管理インターフェースにはスタイルが適用されません。
Pythonのモジュール構文を使用して、アプリケーションへのエントリポイントであるDjangoのwsgi.py
ファイルへの相対ディレクトリパスを指定することにより、Gunicornにモジュールを渡しました。 このファイルの中には、application
という関数が定義されており、アプリケーションとの通信に使用されます。 WSGI仕様の詳細については、ここをクリックをクリックしてください。
テストが終了したら、ターミナルウィンドウでCTRL-Cを押してGunicornを停止します。
これで、Djangoアプリケーションの構成が完了しました。 次のように入力すると、仮想環境から戻ることができます。
deactivate
プロンプトの仮想環境インジケーターが削除されます。
Gunicorn用のsystemdソケットおよびサービスファイルの作成
GunicornがDjangoアプリケーションと対話できることをテストしましたが、アプリケーションサーバーを起動および停止するためのより堅牢な方法を実装する必要があります。 これを実現するには、systemdサービスとソケットファイルを作成します。
Gunicornソケットは起動時に作成され、接続をリッスンします。 接続が発生すると、systemdは接続を処理するためにGunicornプロセスを自動的に開始します。
sudo
権限を持つGunicornのsystemdソケットファイルを作成して開くことから始めます。
sudo nano /etc/systemd/system/gunicorn.socket
内部では、ソケットを説明する[Unit]
セクション、ソケットの場所を定義する[Socket]
セクション、およびソケットが確実に作成されるようにする[Install]
セクションを作成します。適切なタイミング:
/etc/systemd/system/gunicorn.socket
[Unit] Description=gunicorn socket [Socket] ListenStream=/run/gunicorn.sock [Install] WantedBy=sockets.target
終了したら、ファイルを保存して閉じます。
次に、テキストエディタでsudo
権限を持つGunicornのsystemdサービスファイルを作成して開きます。 サービスファイル名は、拡張子を除いてソケットファイル名と一致する必要があります。
sudo nano /etc/systemd/system/gunicorn.service
[Unit]
セクションから始めます。このセクションは、メタデータと依存関係を指定するために使用されます。 ここにサービスの説明を入力し、ネットワークターゲットに到達した後にのみこれを開始するようにinitシステムに指示します。 サービスはソケットファイルのソケットに依存しているため、その関係を示すためにRequires
ディレクティブを含める必要があります。
/etc/systemd/system/gunicorn.service
[Unit] Description=gunicorn daemon Requires=gunicorn.socket After=network.target
次に、[Service]
セクションを開きます。 実行する処理を行うユーザーとグループを指定します。 プロセスは関連するすべてのファイルを所有しているため、通常のユーザーアカウントにプロセスの所有権を付与します。 NginxがGunicornと簡単に通信できるように、www-data
グループにグループの所有権を付与します。
次に、作業ディレクトリをマップし、サービスの開始に使用するコマンドを指定します。 この場合、仮想環境内にインストールされているGunicorn実行可能ファイルへのフルパスを指定する必要があります。 次に、プロセスを/run
ディレクトリ内に作成したUnixソケットにバインドして、プロセスがNginxと通信できるようにします。 journald
プロセスがGunicornログを収集できるように、すべてのデータを標準出力に記録します。 ここで、オプションのGunicornの微調整を指定することもできます。 たとえば、この場合、3つのワーカープロセスを指定しました。
/etc/systemd/system/gunicorn.service
[Unit] Description=gunicorn daemon Requires=gunicorn.socket After=network.target [Service] User=sammy Group=www-data WorkingDirectory=/home/sammy/myprojectdir ExecStart=/home/sammy/myprojectdir/myprojectenv/bin/gunicorn \ --access-logfile - \ --workers 3 \ --bind unix:/run/gunicorn.sock \ myproject.wsgi:application
最後に、[Install]
セクションを追加します。 これにより、起動時にサービスを開始できるようにした場合に、このサービスを何にリンクするかがsystemdに通知されます。 通常のマルチユーザーシステムが稼働しているときにこのサービスを開始する必要があります。
/etc/systemd/system/gunicorn.service
[Unit] Description=gunicorn daemon Requires=gunicorn.socket After=network.target [Service] User=sammy Group=www-data WorkingDirectory=/home/sammy/myprojectdir ExecStart=/home/sammy/myprojectdir/myprojectenv/bin/gunicorn \ --access-logfile - \ --workers 3 \ --bind unix:/run/gunicorn.sock \ myproject.wsgi:application [Install] WantedBy=multi-user.target
これで、systemdサービスファイルが完成しました。 今すぐ保存して閉じます。
これで、Gunicornソケットを起動して有効にできます。 これにより、/run/gunicorn.sock
で起動時にソケットファイルが作成されます。 そのソケットに接続が確立されると、systemdは自動的にgunicorn.service
を起動してそれを処理します。
sudo systemctl start gunicorn.socket sudo systemctl enable gunicorn.socket
ソケットファイルを確認することで、操作が成功したことを確認できます。
Gunicornソケットファイルの確認
プロセスのステータスをチェックして、プロセスを開始できたかどうかを確認します。
sudo systemctl status gunicorn.socket
次のような出力が表示されます。
Output● gunicorn.socket - gunicorn socket Loaded: loaded (/etc/systemd/system/gunicorn.socket; enabled; vendor preset: enabled) Active: active (listening) since Mon 2022-04-18 17:53:25 UTC; 5s ago Triggers: ● gunicorn.service Listen: /run/gunicorn.sock (Stream) CGroup: /system.slice/gunicorn.socket Apr 18 17:53:25 django systemd[1]: Listening on gunicorn socket.
次に、/run
ディレクトリ内にgunicorn.sock
ファイルが存在するかどうかを確認します。
file /run/gunicorn.sock
Output/run/gunicorn.sock: socket
systemctl status
コマンドでエラーが発生したことが示された場合、またはディレクトリにgunicorn.sock
ファイルが見つからない場合は、Gunicornソケットを正しく作成できなかったことを示しています。 次のように入力して、Gunicornソケットのログを確認します。
sudo journalctl -u gunicorn.socket
続行する前に、/etc/systemd/system/gunicorn.socket
ファイルをもう一度確認して、問題を修正してください。
ソケットアクティベーションのテスト
現在、gunicorn.socket
ユニットのみを起動した場合、ソケットはまだ接続を受信していないため、gunicorn.service
はまだアクティブになりません。 次のように入力して、これを確認できます。
sudo systemctl status gunicorn
Output○ gunicorn.service - gunicorn daemon Loaded: loaded (/etc/systemd/system/gunicorn.service; disabled; vendor preset: enabled) Active: inactive (dead) TriggeredBy: ● gunicorn.socket
ソケットアクティベーションメカニズムをテストするには、次のように入力して、curl
を介してソケットに接続を送信できます。
curl --unix-socket /run/gunicorn.sock localhost
ターミナルでアプリケーションからHTML出力を受け取る必要があります。 これは、Gunicornが起動され、Djangoアプリケーションを提供できたことを示しています。 次のように入力して、Gunicornサービスが実行されていることを確認できます。
sudo systemctl status gunicorn
Output● gunicorn.service - gunicorn daemon Loaded: loaded (/etc/systemd/system/gunicorn.service; disabled; vendor preset: enabled) Active: active (running) since Mon 2022-04-18 17:54:49 UTC; 5s ago TriggeredBy: ● gunicorn.socket Main PID: 102674 (gunicorn) Tasks: 4 (limit: 4665) Memory: 94.2M CPU: 885ms CGroup: /system.slice/gunicorn.service ├─102674 /home/sammy/myprojectdir/myprojectenv/bin/python3 /home/sammy/myprojectdir/myprojectenv/bin/gunicorn --access-logfile - --workers 3 --bind unix:/run/gunicorn.sock myproject.wsgi:application ├─102675 /home/sammy/myprojectdir/myprojectenv/bin/python3 /home/sammy/myprojectdir/myprojectenv/bin/gunicorn --access-logfile - --workers 3 --bind unix:/run/gunicorn.sock myproject.wsgi:application ├─102676 /home/sammy/myprojectdir/myprojectenv/bin/python3 /home/sammy/myprojectdir/myprojectenv/bin/gunicorn --access-logfile - --workers 3 --bind unix:/run/gunicorn.sock myproject.wsgi:application └─102677 /home/sammy/myprojectdir/myprojectenv/bin/python3 /home/sammy/myprojectdir/myprojectenv/bin/gunicorn --access-logfile - --workers 3 --bind unix:/run/gunicorn.sock myproject.wsgi:application Apr 18 17:54:49 django systemd[1]: Started gunicorn daemon. Apr 18 17:54:49 django gunicorn[102674]: [2022-04-18 17:54:49 +0000] [102674] [INFO] Starting gunicorn 20.1.0 Apr 18 17:54:49 django gunicorn[102674]: [2022-04-18 17:54:49 +0000] [102674] [INFO] Listening at: unix:/run/gunicorn.sock (102674) Apr 18 17:54:49 django gunicorn[102674]: [2022-04-18 17:54:49 +0000] [102674] [INFO] Using worker: sync Apr 18 17:54:49 django gunicorn[102675]: [2022-04-18 17:54:49 +0000] [102675] [INFO] Booting worker with pid: 102675 Apr 18 17:54:49 django gunicorn[102676]: [2022-04-18 17:54:49 +0000] [102676] [INFO] Booting worker with pid: 102676 Apr 18 17:54:50 django gunicorn[102677]: [2022-04-18 17:54:50 +0000] [102677] [INFO] Booting worker with pid: 102677 Apr 18 17:54:50 django gunicorn[102675]: - - [18/Apr/2022:17:54:50 +0000] "GET / HTTP/1.1" 200 10697 "-" "curl/7.81.0"
curl
からの出力またはsystemctl status
の出力が問題が発生したことを示している場合は、ログで詳細を確認してください。
sudo journalctl -u gunicorn
/etc/systemd/system/gunicorn.service
ファイルに問題がないか確認してください。 /etc/systemd/system/gunicorn.service
ファイルに変更を加えた場合は、デーモンをリロードしてサービス定義を再読み取りし、次のように入力してGunicornプロセスを再起動します。
sudo systemctl daemon-reload sudo systemctl restart gunicorn
続行する前に、必ず上記の問題のトラブルシューティングを行ってください。
NginxをGunicornへのプロキシパスに設定する
Gunicornがセットアップされたので、トラフィックをプロセスに渡すようにNginxを構成する必要があります。
Nginxのsites-available
ディレクトリに新しいサーバーブロックを作成して開くことから始めます。
sudo nano /etc/nginx/sites-available/myproject
内部で、新しいサーバーブロックを開きます。 まず、このブロックが通常のポート80でリッスンし、サーバーのドメイン名またはIPアドレスに応答するように指定します。
/ etc / nginx / sites-available / myproject
server { listen 80; server_name server_domain_or_IP; }
次に、ファビコンの検索に関する問題を無視するようにNginxに指示します。 また、~/myprojectdir/static
ディレクトリで収集した静的アセットの場所も通知します。 これらのファイルはすべて「/static」の標準URIプレフィックスを持っているため、これらのリクエストに一致するロケーションブロックを作成できます。
/ etc / nginx / sites-available / myproject
server { listen 80; server_name server_domain_or_IP; location = /favicon.ico { access_log off; log_not_found off; } location /static/ { root /home/sammy/myprojectdir; } }
最後に、location / {}
ブロックを作成して、他のすべてのリクエストに一致させます。 この場所の中に、Nginxインストールに含まれている標準のproxy_params
ファイルを含めてから、トラフィックをGunicornソケットに直接渡します。
/ etc / nginx / sites-available / myproject
server { listen 80; server_name server_domain_or_IP; location = /favicon.ico { access_log off; log_not_found off; } location /static/ { root /home/sammy/myprojectdir; } location / { include proxy_params; proxy_pass http://unix:/run/gunicorn.sock; } }
終了したら、ファイルを保存して閉じます。 これで、ファイルをsites-enabled
ディレクトリにリンクして有効にできます。
sudo ln -s /etc/nginx/sites-available/myproject /etc/nginx/sites-enabled
次のように入力して、構文エラーについてNginx構成をテストします。
sudo nginx -t
エラーが報告されていない場合は、次のように入力してNginxを再起動してください。
sudo systemctl restart nginx
最後に、ファイアウォールをポート80の通常のトラフィックに開放する必要があります。 開発サーバーにアクセスする必要がなくなったため、ルールを削除してポート8000を開くこともできます。
sudo ufw delete allow 8000 sudo ufw allow 'Nginx Full'
これで、サーバーのドメインまたはIPアドレスに移動してアプリケーションを表示できるようになります。
注: Nginxを構成したら、次のステップはSSL/TLSを使用してサーバーへのトラフィックを保護する必要があります。 これがないと、パスワードを含むすべての情報がプレーンテキストでネットワーク経由で送信されるため、これは重要です。
ドメイン名をお持ちの場合、トラフィックを保護するためにSSL証明書を取得する最も簡単な方法は、Let'sEncryptを使用することです。 このガイドに従って、Ubuntu22.04でLet'sEncryptwithNginxを設定します。 このガイドで作成したNginxサーバーブロックを使用した手順に従います。
NginxとGunicornのトラブルシューティング
この最後の手順でアプリケーションが表示されない場合は、インストールのトラブルシューティングを行う必要があります。
NginxはDjangoアプリケーションの代わりにデフォルトページを表示しています
Nginxがアプリケーションにプロキシする代わりにデフォルトのページを表示する場合は、通常、サーバーのIPアドレスまたはドメイン名を指すように/etc/nginx/sites-available/myproject
ファイル内のserver_name
を調整する必要があることを意味します。
Nginxはserver_name
を使用して、リクエストへの応答に使用するサーバーブロックを決定します。 デフォルトのNginxページを受け取った場合、それはNginxがリクエストをサーバーブロックに明示的に一致させることができなかったことを示しているため、/etc/nginx/sites-available/default
で定義されたデフォルトブロックにフォールバックしています。
プロジェクトのサーバーブロックのserver_name
よりも具体的である必要があります。
NginxはDjangoアプリケーションの代わりに502BadGatewayエラーを表示しています
502エラーは、Nginxがリクエストを正常にプロキシできないことを示します。 さまざまな構成の問題が502エラーで表されるため、適切にトラブルシューティングするには、より多くの情報が必要です。
詳細情報を探す主な場所は、Nginxのエラーログです。 一般に、これにより、プロキシイベント中に問題が発生した条件がわかります。 次のように入力して、Nginxエラーログを追跡します。
sudo tail -F /var/log/nginx/error.log
次に、ブラウザで別のリクエストを実行して、新しいエラーを生成します(ページを更新してみてください)。 ログに書き込まれた新しいエラーメッセージを受け取るはずです。 メッセージを見ると、問題を絞り込むのに役立つはずです。
次のメッセージが表示される場合があります。
connect()からunix:/run/gunicorn.sockに失敗しました(2:そのようなファイルまたはディレクトリはありません)
これは、Nginxが指定された場所でgunicorn.sock
ファイルを見つけることができなかったことを示しています。 /etc/nginx/sites-available/myproject
ファイル内で定義されたproxy_pass
の場所を、gunicorn.socket
systemdユニットによって生成されたgunicorn.sock
ファイルの実際の場所と比較する必要があります。
/run
ディレクトリ内にgunicorn.sock
ファイルが見つからない場合は、通常、systemdソケットファイルでファイルを作成できなかったことを意味します。 Gunicornソケットファイルの確認に関するセクションに戻り、Gunicornのトラブルシューティング手順を実行します。
connect()からunix:/run/gunicorn.sockに失敗しました(13:アクセスが拒否されました)
これは、権限の問題のためにNginxがGunicornソケットに接続できなかったことを示しています。 これは、sudo
ユーザーの代わりにrootユーザーを使用して手順に従った場合に発生する可能性があります。 systemdはGunicornソケットファイルを作成できますが、Nginxはそれにアクセスできません。
これは、ルートディレクトリ(/
)、gunicorn.sock
ファイルの間のいずれかの時点でアクセス許可が制限されている場合に発生する可能性があります。 namei
コマンドにソケットファイルへの絶対パスを渡すことにより、ソケットファイルとその各親ディレクトリのアクセス許可と所有権の値を確認できます。
namei -l /run/gunicorn.sock
Outputf: /run/gunicorn.sock drwxr-xr-x root root / drwxr-xr-x root root run srw-rw-rw- root root gunicorn.sock
出力には、各ディレクトリコンポーネントの権限が表示されます。 アクセス許可(最初の列)、所有者(2番目の列)、およびグループ所有者(3番目の列)を確認することで、ソケットファイルに許可されているアクセスの種類を把握できます。
上記の例では、ソケットファイルとソケットファイルにつながる各ディレクトリに、ワールド読み取りおよび実行権限があります(ディレクトリの権限列は、---
ではなくr-x
で終わります)。 Nginxプロセスはソケットに正常にアクセスできるはずです。
ソケットにつながるディレクトリのいずれかにワールド読み取りおよび実行権限がない場合、Nginxは、ワールド読み取りおよび実行権限を許可するか、Nginxが含まれるグループにグループ所有権が付与されていることを確認しない限り、ソケットにアクセスできません。の。
Djangoが表示されています:「サーバーに接続できませんでした:接続が拒否されました」
Webブラウザでアプリケーションの一部にアクセスしようとしたときにDjangoから受け取る可能性のあるメッセージの1つは次のとおりです。
OperationalError at /admin/login/ could not connect to server: Connection refused Is the server running on host "localhost" (127.0.0.1) and accepting TCP/IP connections on port 5432?
これは、DjangoがPostgresデータベースに接続できないことを示しています。 次のように入力して、Postgresインスタンスが実行されていることを確認します。
sudo systemctl status postgresql
そうでない場合は、次のように入力して、起動し、起動時に自動的に起動できるようにすることができます(まだ設定されていない場合)。
sudo systemctl start postgresql sudo systemctl enable postgresql
それでも問題が解決しない場合は、~/myprojectdir/myproject/settings.py
ファイルで定義されているデータベース設定が正しいことを確認してください。
さらなるトラブルシューティング
追加のトラブルシューティングについては、ログが根本原因の絞り込みに役立ちます。 それぞれを順番にチェックし、問題のある領域を示すメッセージを探します。
次のログが役立つ場合があります。
sudo journalctl -u nginx
と入力して、Nginxプロセスログを確認します。sudo less /var/log/nginx/access.log
と入力して、Nginxアクセスログを確認します。sudo less /var/log/nginx/error.log
と入力して、Nginxエラーログを確認します。sudo journalctl -u gunicorn
と入力して、Gunicornのアプリケーションログを確認します。sudo journalctl -u gunicorn.socket
と入力して、Gunicornソケットログを確認します。
構成またはアプリケーションを更新するときに、変更に適応するためにプロセスを再起動する必要がある場合があります。
Djangoアプリケーションを更新する場合は、Gunicornプロセスを再起動して、次のように入力することで変更を取得できます。
sudo systemctl restart gunicorn
Gunicornのソケットまたはサービスファイルを変更した場合は、デーモンをリロードし、次のように入力してプロセスを再開します。
sudo systemctl daemon-reload sudo systemctl restart gunicorn.socket gunicorn.service
Nginxサーバーブロックの構成を変更する場合は、次のように入力して構成をテストしてからNginxをテストします。
sudo nginx -t && sudo systemctl restart nginx
これらのコマンドは、構成を調整するときに変更を取得するのに役立ちます。
結論
このガイドでは、独自の仮想環境でDjangoプロジェクトをセットアップします。 Djangoがクライアントリクエストを処理できるように、クライアントリクエストを変換するようにGunicornを設定しました。 その後、クライアント接続を処理し、クライアントの要求に応じて正しいプロジェクトを提供するリバースプロキシとして機能するようにNginxを設定します。
Djangoは、多くの一般的な要素を提供することでプロジェクトとアプリケーションの作成を簡単にし、独自の要素に集中できるようにします。 この記事で説明する一般的なツールチェーンを活用することで、単一のサーバーから作成したアプリケーションを簡単に提供できます。