web-dev-qa-db-ja.com

django wsgiで作成されていないgunicorn sockファイル

ローカルの仮想環境を備えたDigital Oceanサーバー（Ubuntu 16.04）に基本的なDjango RESTアプリケーションがあります。基本的なwsgi.pyは次のとおりです。

_import os

os.environ.setdefault("Django_SETTINGS_MODULE", "workout_rest.settings")

# This application object is used by any WSGI server configured to use this
# file. This includes Django's development server, if the WSGI_APPLICATION
# setting points here.
from Django.core.wsgi import get_wsgi_application
application = get_wsgi_application()

# Apply WSGI middleware here.
# from helloworld.wsgi import HelloWorldApplication
# application = HelloWorldApplication(application)
_

私はこのチュートリアルを順を追って実行しました： https://www.digitalocean.com/community/tutorials/how-to-set-up-Django-with-postgres-nginx-and-gunicorn-on-ubuntu -16-04

次のコマンドを使用して、プロジェクトにサービスを提供するGunicornの機能をテストすると、gunicorn --bind 0.0.0.0:8000 myproject.wsgi：applicationすべてが正常に機能します。

そこで、systemdサービスファイルを使用するようにGunicornをセットアップしようとしました。私の/etc/systemd/system/gunicorn.serviceファイルは：

_[Unit]
Description=gunicorn daemon
After=network.target

[Service]
User=ben
Group=www-data
WorkingDirectory=/home/ben/myproject
ExecStart=/home/ben/myproject/myprojectenv/bin/gunicorn --workers 3 --bind unix:/home/ben/myproject/myproject.sock myproject.wsgi:application

[Install]
WantedBy=multi-user.target
_

私のNginx設定は：

_server {
    listen 8000;
    server_name server_domain_or_IP;

    location = /favicon.ico { access_log off; log_not_found off; }
    location /static/ {
        root /home/ben/myproject;
    }

    location / {
        include proxy_params;
        proxy_pass http://unix:/home/ben/myproject/myproject.sock;
    }
}
_

80からerr_connection_refusedエラーが返されるため、リスンポートを80から8000に変更しました。このコマンドでサーバーを起動した後：

_Sudo systemctl restart nginx
_

Webサイトを実行しようとすると、502 Bad Gatewayエラーが発生します。私はこれらのコマンドを試しました（チュートリアルのコメントにあります）：

_Sudo systemctl daemon-reload
Sudo systemctl start gunicorn
Sudo systemctl enable gunicorn
Sudo systemctl restart nginx
_

しかし、何も変わりません。このコマンドでNginixログを見ると、次のようになります。

_Sudo tail -f /var/log/nginx/error.log
_

Sockファイルが存在しないことを読み取ることができます。

_2016/10/07 09:00:18 [crit] 24974#24974: *1 connect() to unix:/home/ben/myproject/myproject.sock failed (2: No such file or directory) while connecting to upstream, client: 86.197.20.27, server: 139.59.150.116, request: "GET / HTTP/1.1", upstream: "http://unix:/home/ben/myproject/myproject.sock:/", Host: "server_ip_adress:8000"
_

このsockファイルが作成されないのはなぜですか？ Django/gunicornを構成してこのファイルを作成するにはどうすればよいですか？ DjangoプロジェクトのINSTALLED_APPにgunicornを追加しましたが、何も変更されません。

編集：

Nginx設定ファイルを_nginx -t_でテストすると、エラーopen() "/run/nginx.pid" failed (13: Permission denied)が発生します。しかし、Sudo：_Sudo nginx -t_でコマンドを実行すると、テストは成功します。これは、「ben」ユーザーがNgnixを実行できるようにする必要があることを意味しますか？

Gunicornログファイルについて、それらを読み取る方法が見つかりません。どこに保管されていますか？

_ps aux | grep gunicorn_を使用して、gunicornが実行されているかどうかを確認すると、次のようになります。

_ben      26543  0.0  0.2  14512  1016 pts/0    S+   14:52   0:00 grep --color=auto gunicorn
_

Gunicornのsystemctl enableおよびstartコマンドを実行すると、次のようになります。

_Sudo systemctl enable gunicorn
Synchronizing state of gunicorn.service with SysV init with /lib/systemd/systemd-sysv-install...
Executing /lib/systemd/systemd-sysv-install enable gunicorn

Sudo systemctl start gunicorn
I get no output with this command

Sudo systemctl is-active gunicorn
active

Sudo systemctl status gunicorn
● gunicorn.service - gunicorn daemon
   Loaded: loaded (/etc/systemd/system/gunicorn.service; enabled; vendor preset: enabled)
   Active: active (exited) since Thu 2016-10-06 15:40:29 UTC; 23h ago

Oct 06 15:40:29 DevUsine systemd[1]: Started gunicorn.service.
Oct 06 18:52:56 DevUsine systemd[1]: Started gunicorn.service.
Oct 06 20:55:05 DevUsine systemd[1]: Started gunicorn daemon.
Oct 06 20:55:17 DevUsine systemd[1]: Started gunicorn daemon.
Oct 06 21:07:36 DevUsine systemd[1]: Started gunicorn daemon.
Oct 06 21:16:42 DevUsine systemd[1]: Started gunicorn daemon.
Oct 06 21:21:38 DevUsine systemd[1]: Started gunicorn daemon.
Oct 06 21:25:28 DevUsine systemd[1]: Started gunicorn daemon.
Oct 07 08:58:43 DevUsine systemd[1]: Started gunicorn daemon.
Oct 07 15:01:22 DevUsine systemd[1]: Started gunicorn daemon.
_
pythondjangonginxgunicorn
11
Ben

Sockフォルダーのアクセス許可を変更する必要がありました。

Sudo chown ben:www-data /home/ben/myproject/

もう1つは、sockファイルをDjangoプロジェクトに保持することは適切ではないことを多くの投稿で読んだ後、sockの場所を変更しました。新しい場所は次のとおりです。

/home/ben/run/

権限を変更することを忘れないでください：

Sudo chown ben:www-data /home/ben/run/

Gunicornが更新されたことを確認するには、次のコマンドを実行します。

pkill gunicorn
Sudo systemctl daemon-reload
Sudo systemctl start gunicorn

これにより、gunicornプロセスが強制終了され、新しいプロセスが開始されます。

次のコマンドを実行して、サーバーの起動時にプロセスを開始できます。

Sudo systemctl enable gunicorn

今はすべてうまくいきます。

22
Ben

受け入れられた回答は機能しますが、1つの（imoメジャー）問題があります。これは、gunicorn Webサーバーが（おそらく）rootとして実行されていることであり、推奨されません。ソケットをchownする必要があるのは、ソケットがroot:rootによって所有されているためです。これは、initジョブがデフォルトで想定するユーザー/グループだからです。仕事に別の役割を引き受ける方法はいくつかあります。この時点で（gunicorn 19.9.0を使用して）、私の意見では、これに対する最も簡単な解決策は、gunicornコマンドの一部として提供される--userおよび--groupフラグを使用することです。つまり、サーバーは指定したユーザー/グループで起動できます。あなたの場合：

exec gunicorn --user ben --group www-data --bind unix:/home/ben/myproject/myproject.sock -m 007 wsgi

ben:www-dataユーザーの下でgunicornを開始し、ben:www-dataが所有するソケットを770の権限で作成するか、ユーザーbenおよびグループのwww-dataに対する読み取り/書き込み/実行特権をソケットで作成します。 。

1
ThisGuyCantEven

プロジェクト外のsockファイルへのパスを指定しました。 .servicesファイルでそのパスについて述べたように、gunicornがそのディレクトリ内にファイルを作成できるように、ディレクトリを作成する必要がありました。基本的に、.servicesファイルのパスに従って、すべてのディレクトリが存在することを確認しました。権限や所有権を変更する必要はありません

0
Hashim