django AWS 本番運用環境への移行 nginx error

Question

webアプリの公開で躓いています。

ローカル開発環境で作ったwebサイトをAWSのEC2でElastic IPを取得して実際にhttp://<ElasticIP>として検索したところ、画像のようなエラーが出てしまいます。

ローカル開発環境ではうまく表示され、参考書通りに本番運用環境に対応した設定の変更なども行いました。
公開の際にnginxとgunicornを使いました。

本番運用環境への移行作業は初めてで、参考書を読みながらて手探りで進めています。
どこの情報が重要なのかもわかっていないので、質問内容でわからない所があれば聞いてください。
よろしくお願いします。

Answer 1

出ているエラーメッセージそのままです。

You may need to add '（IPアドレス）' to ALLOWED_HOSTS.

Django 1.5以降ではALLOWED_HOSTSの設定が必要
参考サイトではドメイン名と書かれていますが、ALLOWED_HOSTSに記載すべきはアクセスする時に指定されるホストなので、ここではElasticIPの値を指定すればいいでしょう。
ワイルドカードも可能ですが
最近のフレームワークではこのような設定が必要なものが多い印象です。

こういったことはエラーメッセージで調べればすぐ出てきますので、ぜひ調べる癖をつけてください。

Comments

[taisei_02]

ご回答ありがとうございます！
ALLOWED_HOSTsの記載は　ALLOWED_HOSTS = [os.environ.get('ALLOWED_HOSTS')]
でも大丈夫でしょうか。参考書にある通りにこのようにしています。
bitbucketリモートリポジトリのsettings.pyにもこのように書いていますが、検索した時に反映されていないのが原因でしょうか？
gitに使い方も慣れていないのですが、リモートリポジトリにおいたデータがそのまま紐付けたIPで検索した結果に反映される訳ではないのでしょうか。

[yu_1985]

環境変数にALLOWED_HOSTSを設定しているのならそれでもいいでしょうけど、環境変数は設定してますか？

> リモートリポジトリにおいたデータがそのまま紐付けたIPで検索した結果に反映される訳ではない

ごめんなさい、ちょっとよくわからないです。
「検索」という言葉をここで使うのが恐らく適切ではないです。

[taisei_02]

すみません。少し勘違いしていました。
EC2インスタンスにSSH接続した後、djangoのプロジェクトディレクトリに移動し、git pullコマンドでbitbucketリモートリポジトリの内容を本番運用環境に反映させる、という流れで公開するので合っていますか？
これを行っても、ALLOWED_HOSTSのエラーが出てしまいます。settings.pyの変更内容が反映されていないようです。。

[yu_1985]

> [os.environ.get('ALLOWED_HOSTS')]

これは環境変数を読み込んでいるので、環境変数が設定されてなかったり誤っていたりしたらうまくいきません。
再度聞きますが環境変数は設定していますか？

[taisei_02]

環境変数とは、SSH接続したホームディレクトリのbash_profileで合っていますかね？
ここで、export ALLOWED_HOSTS=<ElasticIP>としています！

すみません。検索という言葉を、urlをhttp://<ElasticIP>とした、という意味で使っています。

[taisei_02]

エラー情報の画面では、ローカル開発の時に設定していた
ALLOWED_HOSTS []
のままになっています。git pullで反映できていないということなのでしょうか。。

[yu_1985]

.bash_profileはログイン時に実行されるのでdjangoをどのユーザがどのように起動したかによってはそこで設定した値は反映されないケースがあります。
OS側の環境変数を読み込むより.envを使うべきかと。（.envはgit管理してはいけません）
https://qiita.com/moonwalkerpoday/items/9da47dda80d3ddac9a62

個人的にはALLOWED_HOSTSを環境変数で設定するメリットを特に感じないので普通に直書きでいいと思うのですが…。

[taisei_02]

リモートリポジトリ において、ALLOWED_HOSTS=["<ElasticIP>"]としてgit pullしてみましたが、
やはりエラーになってしまいます。
DEBUG=Trueになっているのもおかしいと思うのですが、git pullで本番運用環境にリモートリポジトリの中身を移動するだけでは不十分なのでしょうか。。

[yu_1985]

一応聞きますが、ちゃんとdjangoを立ち上げ直しましたか？

[taisei_02]

すみません、djangoを立ち上げ直すとはどうゆうことでしょうか。。

[yu_1985]

ALLOWED_HOSTSの設定があるので勝手にdjangoだと思っていましたが、flaskとか別のフレームワークかもしれなかったですね。
ただ、エラーの内容がdjangoのエラーメッセージと思ったのでそう判断しています。（別のフレームワークだったらすいません）
いずれにしても、ソースの情報がないのでわからないところですが、フレームワークを使っているのだとしたらただPullするだけではダメで立ち上げ直す必要があります。

ローカル開発環境ではアクセスできたとのことですが、何のソースをどのようにしたらアクセスできたのでしょうか。

[yu_1985]

と、タイトルにdjangoって書いてありましたね。

どういうことも何も、既に立ち上げたdjangoのプロセスを落として再度起動しないと設定が読み込まれないのでそうしてください、ということです。

[taisei_02]

はい、djangoを使っています。
ローカルの時はPyCharmでAdd configurationsからmanage.pyのrunserverを登録して、これを起動させてチェックしていました。
本番の時も、同じようにこれを動かすのでしょうか。今runserverをしてみましたが、settingsを本番用に変えたせいか、赤文字でエラーが出ています。

[yu_1985]

djangoをそもそも立ち上げてないならエラーが出る以前の問題です。
別のエラーが出てるのならそれは別の問題なので長くなりそうなら先にそちらを対処してください。

nginxとgunicornを使っているのならローカルと設定が同じであることは考えにくいので、ちゃんとそれらを組み合わせた上で動くのか確認する必要があります。
ただdjangoを立ち上げた時点でエラーになるのであればdjangoの設定に問題があります。

本番環境にソースを載せてからどのようなコマンドを打ちどのような操作をしたのかを詳細に書いたほうが良さそうです。

[taisei_02]

ただいま、本番用がrunserverで立ち上がるように検討しています。
本番用のdjangoが立ち上がらなくても、nginxやgunicornは正常に動いているようですが、こうゆうものなのでしょうか。
settings_commonを共用として、ローカル用にsettings_dev、本番用にsettingsを使うようにしています。また、EC2インスタンスにおける環境変数のDJANGO_SETTINGS_MODULEをsettingsに設定しているのですが、ElasticIPにアクセスしても変わらず同じエラーが出てしまいます。settingsの中身は別の質問に貼ったのでよかったら、見てほしいです。

[yu_1985]

ああ、ここは少し誤解してましたかね。gunicorn上でdjangoを動かすということなので、まずはそちらが問題なく動くかですね。
nginxとgunicornを再起動したらどうなりますか？

[taisei_02]

どちらも停止した後、nginx,gunicornを起動すると、
nginx error!
The page you are looking for is temporarily unavailable. Please try again later.
Website Administrator
Something has triggered an error on your website. This is the default error page for nginx that is distributed with Amazon Linux 2. It is located /usr/share/nginx/html/50x.html

You should customize this error page for your own site or edit the error_page directive in the nginx configuration file /etc/nginx/nginx.conf.

このようなページに移るようになりました。

[yu_1985]

nginxの設定はどうなってますか？
またgunicornの起動時にエラー等は出てませんか？

[taisei_02]

user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;

# Load dynamic modules. See /usr/share/doc/nginx/README.dynamic.
include /usr/share/nginx/modules/*.conf;

events {
worker_connections 1024;
}

http {
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';

access_log /var/log/nginx/access.log main;

sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 4096;
include /etc/nginx/mime.types;
default_type application/octet-stream;

# Load modular configuration files from the /etc/nginx/conf.d directory.
# See http://nginx.org/en/docs/ngx_core_module.html#include
# for more information.
include /etc/nginx/conf.d/*.conf;

server {
listen 80;
server_name <ElasticIP>;
root /usr/share/nginx/html;

# Load configuration files for the default server block.
include /etc/nginx/default.d/*.conf;

location /static{
alias /usr/share/nginx/html/static;
}
location /media{
alias /usr/share/nginx/html/media;
}
location /.well-known/acme-challenge{
root /usr/share/nginx/html;
}
location /{
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

proxy_pass http://127.0.0.1:8000;
}

error_page 404 /404.html;
location = /40x.html {
}

error_page 500 502 503 504 /50x.html;
location = /50x.html {
}
}

少し長くなりましたが、nginx.confの中身は上の通りです。

● nginx.service - The nginx HTTP and reverse proxy server
Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)
Active: active (running) since 木 2020-10-22 20:59:55 JST; 11s ago
Process: 17249 ExecStart=/usr/sbin/nginx (code=exited, status=0/SUCCESS)
Process: 17246 ExecStartPre=/usr/sbin/nginx -t (code=exited, status=0/SUCCESS)
Process: 17245 ExecStartPre=/usr/bin/rm -f /run/nginx.pid (code=exited, status=0/SUCCESS)
Main PID: 17252 (nginx)
CGroup: /system.slice/nginx.service
├─17252 nginx: master process /usr/sbin/nginx
└─17254 nginx: worker process
こちらが、nginxを起動して、systemctl status nginx.serviceとして確認した状態です。

続いて、python仮想環境に入りgunicorn --bind 127.0.0.1:8000 job_offer.wsgi -Dでgunicornを起動しても何もエラー等は出ませんでした。
ps ax | grep gunicornとすると、
17294 pts/0 S+ 0:00 grep --color=auto gunicorn
と出ます。
ページは変わらず、nginx errorのままです。

[yu_1985]

gunicornのプロセスが見つからないということはgunicornが起動してないのでは…。
ログファイルにはなにか出てませんか？

[taisei_02]

nginxのlogファイルは次のように残っていません、と出ました。
tail -f /var/log/nginx/error.log
tail: `/var/log/nginx/error.log' を 読み込み用に開くことが出来ません: Permission denied
tail: ファイルが全く残っていません

gunicornのlogの場所はどうやって調べるのでしょうか？

[taisei_02]

ハンドラの設定から見れますかね。
BASE_DIR, 'logs/django.log'
とあったのでここを見てみましたけど、logsの中は空でした。
DJANGO_SETTINGS_MODULEをsettinds_dev(ローカル用)に設定してgunicornを動かすとプロセスがちゃんと表示されました。ページはALLOWED_HOSTSが空なのでエラーになりますけど、、

[yu_1985]

nginxのログはアクセスログなのでアクセスしてなければ当然ないのですが、それは権限のエラーなのでまた別です。ただアクセスログは今回関係ないです。

gunicornの起動コマンドを書いてないですが、--log-level debugを指定して起動するとなにか出ないですか？

また、ローカル用と本番用の設定にどのような差分がありますか？

[taisei_02]

from .settings_common import *

# SECURITY WARNING: don't run with debug turned on in production!
DEBUG = True

ALLOWED_HOSTS = []

# ロギング設定
LOGGING = {
'version': 1, # 1固定
'disable_existing_loggers': False,

# ロガーの設定
'loggers': {
# Djangoが利用するロガー
'django': {
'handlers': ['console'],
'level': 'INFO',
},
# diaryアプリケーションが利用するロガー
'diary': {
'handlers': ['console'],
'level': 'DEBUG',
},
},

# ハンドラの設定
'handlers': {
'console': {
'level': 'DEBUG',
'class': 'logging.StreamHandler',
'formatter': 'dev'
},
},

# フォーマッタの設定
'formatters': {
'dev': {
'format': '\t'.join([
'%(asctime)s',
'[%(levelname)s]',
'%(pathname)s(Line:%(lineno)d)',
'%(message)s'
])
},
}
}

EMAIL_BACKEND = 'django.core.mail.backends.console.EmailBackend'

MEDIA_ROOT = os.path.join(BASE_DIR, 'media')

こちらが、ローカル用のsettings_devで

from .settings_common import *

# デバッグモードを有効にするかどうか(本番運用では必ずFalseにする)
DEBUG = False

# 許可するホスト名のリスト
ALLOWED_HOSTS = ['ElasticIP']

# 静的ファイルを配置する場所
STATIC_ROOT = '/usr/share/nginx/html/static'
MEDIA_ROOT = '/usr/share/nginx/html/media'

# Amazon SES関連設定
# セキュリティ関連設定

こちらが本番用のsettingsです。
こちらはrunserverをするとロギング設定のところで、エラーが出て原因がわからなかったのでロギングの設定をすべて消してしまっています。

--log-level debugを指定というのがわからないです。
起動コマンドは、gunicorn --bind 127.0.0.1:8000 job_offer.wsgi -Dです。

[yu_1985]

> こちらはrunserverをするとロギング設定のところで、エラーが出て原因がわからなかったのでロギングの設定をすべて消してしまっています。

本末転倒では…。ログの出力は必ず行ってください。

> --log-level debugを指定というのがわからないです。
そのまんまなのですが…。
オプションに--log-level debugを追加してください。
上記のログ出力設定がなければ出ない可能性もあるのでそこも正しく行ってください。ログがないと原因を辿れないので。

[taisei_02]

なぜかアクセスはできるようになったみたいです。
ps ax | grep gunicorn　とすると
22632 ? S 0:00 /home/app_admin/venv_private_diary/bin/python3 /home/app_admin/venv_private_diary/bin/gunicorn --bind 127.0.0.1:8000 job_offer.wsgi -D --log-level debug
22635 ? S 0:00 /home/app_admin/venv_private_diary/bin/python3 /home/app_admin/venv_private_diary/bin/gunicorn --bind 127.0.0.1:8000 job_offer.wsgi -D --log-level debug
22637 pts/2 S+ 0:00 grep --color=auto gunicorn
と出て、gunicornも立ち上がっているようです。
ただ、https設定はしていないのにhttpsのページにリダイレクトされて、「このサイトにアクセスできません<ElasticIP> で接続が拒否されました。」
と出るようになりました。。
--log-level debugをつけて起動してもdjango.logには何も書かれていませんでした。

[yu_1985]

gunicornを立ち上げたからアクセスできるようになったのではないでしょうか…。

> ただ、https設定はしていないのにhttpsのページにリダイレクトされて、「このサイトにアクセスできません<ElasticIP> で接続が拒否されました。」

nginxにそのようなことをしているところがない以上アプリ側のどこかでリダイレクトしていると思われるので修正指定ください。

[taisei_02]

どうやらgunicornを停止しても同じ「このサイトにアクセスできません<ElasticIP> で接続が拒否されました。」が出ているようです。
settings.pyのSECURE_SSL_REDIRECTがTrueになっていたので、この設定をFalseのしてもhttpsにリダイレクトされるのは変わりませんでした。
そして変わらずdjango.logは空のままです。。

[yu_1985]

> どうやらgunicornを停止しても同じ「このサイトにアクセスできません<ElasticIP> で接続が拒否されました。」

URLを明示的にhttp://〜に指定しましたか？httpsのままになっている可能性があります。

[taisei_02]

ちゃんとhttp://に変えましたけど、httpsにリダイレクトされてしまいます。。

[yu_1985]

gunicornを立ち上げ直してもそうなりますか？
すべて本番用の設定であることを前提にしてますが、そこは間違いないでしょうか。

[taisei_02]

はい、何度立ち上げ直してもこうなります。
本番用の設定ではありますが、pycharmでrunserverをするとロギングでエラーが出てしまいます。
ロギングの設定を削除してみると,ローカルのサーバーが立ち上がりますが、bad request(400)と出てしまいます。

後、ローカル用の設定をrunserverで起動した時、昨日までchromeでちゃんとページがみれたのですが、今日はhttpsにリダイレクトされて「このサイトに安全に接続できません」と出るようになってしまいました。設定を変えていないはずなので原因は謎なのですが、同じhttp://127.0.0.1:8000のローカルのアドレスをsafaliやfirefoxでアクセスしようとするとリダイレクトされずちゃんとページが表示されます。
ブラウザによって勝手にリダイレクトされたりするのでしょうか。

[yu_1985]

一度リダイレクトさせるとブラウザにそれがキャッシュとして残る可能性があるので一度確実に消してからやったほうがいいです。
それかゲストでブラウザをたちあげるか。
https://gotohayato.com/content/100/

[taisei_02]

ありがとうございます。
ブラウザのキャッシュが残っていたことがhttpsへのリダイレクトの原因だったようです。本番のページも正常に開くことができました！！
無知なもので、初歩的なところがわかっていない部分が多かったにも関わらず、丁寧に質問に答えてくださりありがとうございました。本当に助かりました！！