Q&A
なぜwebサーバーをPrivateにしてるのですか？ まずはそこから。
AWSのALBを使用してプライベートインスタンスに接続を行おうとすると404エラーが発生してしまう。
404エラー画面
※写真の補足
- Load balancerは指定してあります。
- Targetにはプライベートインスタンスを設定しております。
- 現状、デプロイ中の為、インスタンスは一つのみとなっております。
- 後述しておりますが、EC2事態にアクセスを行おうと試みてはいるようです。
ヘルスチェック
簡単にやっていることの説明
フロントエンドにAngular
バックエンドにLaravel sanctumを使った
アプリケーションをデプロイしようと試みている
実現したいこと
- Target画面に表示されている404エラーを解消したい。
- インスタンス内にある、Laravel sanctumに接続したい。
自分が思うエラーの原因
Laravelのindex.phpをALB側で確認できていないために404エラーになっていると思われる。
環境
nginx: 1.22.1
PHP: 8.1.14
Composer: 2.5.2
Laravel: 9.31.0
確認が取れているもの
- sudo systemctl status nginx.service実行結果
nginx.serviceのステータス
1● nginx.service - The nginx HTTP and reverse proxy server 2 Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled) 3 Drop-In: /usr/lib/systemd/system/nginx.service.d 4 mqphp-fpm.conf 5 Active: active (running) since Tue 2023-02-21 12:21:01 UTC; 2h 57min ago 6
- sudo systemctl status php-fpm実行結果
php
1● php-fpm.service - The PHP FastCGI Process Manager 2 Loaded: loaded (/usr/lib/systemd/system/php-fpm.service; enabled; vendor preset: disabled) 3 Active: active (running) since Tue 2023-02-21 12:20:59 UTC; 2h 59min ago 4 Main PID: 2951 (php-fpm) 5 Status: "Processes active: 0, idle: 5, Requests: 0, slow: 0, Traffic: 0req/sec" 6 CGroup: /system.slice/php-fpm.service 7 tq2951 php-fpm: master process (/etc/php-fpm.conf) 8
設定周りのファイル一覧
ディレクトリ
/etc/nginx/nginx.conf
nginx.conf
1# For more information /var/www/src/publicon configuration, see: 2# * Official English Documentation: http://nginx.org/en/docs/ 3# * Official Russian Documentation: http://nginx.org/ru/docs/ 4 5user nginx; 6worker_processes auto; 7error_log /var/log/nginx/error.log; 8pid /run/nginx.pid; 9 10# Load dynamic modules. See /usr/share/doc/nginx/README.dynamic. 11include /usr/share/nginx/modules/*.conf; 12 13events { 14 worker_connections 1024; 15} 16 17http { 18 log_format main '$remote_addr - $remote_user [$time_local] "$request" ' 19 '$status $body_bytes_sent "$http_referer" ' 20 '"$http_user_agent" "$http_x_forwarded_for"'; 21 22 access_log /var/log/nginx/access.log main; 23 24 sendfile on; 25 tcp_nopush on; 26 tcp_nodelay on; 27 keepalive_timeout 65; 28 types_hash_max_size 4096; 29 30 include /etc/nginx/mime.types; 31 default_type application/octet-stream; 32 33 # Load modular configuration files from the /etc/nginx/conf.d directory. 34 # See http://nginx.org/en/docs/ngx_core_module.html#include 35 # for more information. 36 include /etc/nginx/conf.d/*.conf; 37 38 server { 39 listen 80; 40 listen [::]:80; 41 server_name _; 42 root /var/www/src/public; 43 44 add_header X-Frame-Options "SAMEORIGIN"; 45 add_header X-XSS-Protection "1; mode=block"; 46 add_header X-Content-Type-Options "nosniff"; 47 48 index index.php; 49 50 charset utf-8; 51 52 location / { 53 try_files $uri $uri/ /index.php?$query_string; 54 } 55 56 location ~ \.php$ { 57 fastcgi_pass unix:/run/php-fpm/www.sock; 58 fastcgi_index index.php; 59 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; 60 include fastcgi_params; 61 } 62 # Load configuration files for the default server block. 63 include /etc/nginx/default.d/*.conf; 64 } 65 66}
index.phpディレクトリ
1var 2└── www 3 └── src 4 └── public 5 └── index.php 6
発生している問題・エラーメッセージ
/var/log/nginx/access.logにあるaccess.logを確認するとELBからtargetに対して、アクセスを行おうとしていることは確認ができます。
Nginxのアクセスログ
access.log
1172.16.24.58 - - [21/Feb/2023:14:14:21 +0000] "GET / HTTP/1.1" 404 153 "-" "ELB-HealthChecker/2.0" "-" 2172.16.23.109 - - [21/Feb/2023:14:14:21 +0000] "GET / HTTP/1.1" 404 153 "-" "ELB-HealthChecker/2.0" "-" 3172.16.24.58 - - [21/Feb/2023:14:14:51 +0000] "GET / HTTP/1.1" 404 153 "-" "ELB-HealthChecker/2.0" "-" 4172.16.23.109 - - [21/Feb/2023:14:14:51 +0000] "GET / HTTP/1.1" 404 153 "-" "ELB-HealthChecker/2.0" "-"
※アクセスログをみて、アクセスが飛んできていることは確認できているのですが、
/var/log/nginx/error.log にはエラーが一切記載されておりません。
試したこと
nginx.confを書き換え以下のように書換え→404エラーのまま
nginx.conf
1root /var/www/src/public; //変更前 2root /var/www/src/public/; //変更後
理由 index.phpをALBが認識できていないために、実行できていないと思った為、上記のように修正
nginx.confを書き換え以下のように書換え→404エラーのまま
nginx.conf
1 location / { 2 try_files $uri $uri/ /index.php?$query_string;//変更前 3 } 4 5 location / { 6 root /var/www/src/public; //追加 7 try_files $uri $uri/ /index.php?$query_string;//変更後 8 }
理由 index.phpをALBが認識できていないために、実行できていないと思った為、上記のように修正
下記URLを参照した際、記述ミスなのではないかと思った為。
https://cloudsmith.co.jp/blog/2022/02/2030266.html
AbeTakashi様のご回答のもとをにして、修正した結果。
修正方法
・nginx.confを※1のURLを参考にして修正
・healthのcheck pathを/nginxに修正
・nginxをsudo nginx -s reloadで再起動
※1のURLを参考にnginx.confを修正させていただきました。
※1https://qiita.com/oogaki_newmedia/items/749c855ad985c8258e66
そしてhealth PathのURLを
/nginxに変更しました。
しかし404が解消されていないようです。
index.htmlは/usr/share/nginx/html/index.htmlに配置しております。
修正後のaccess.log
172.16.23.100 - - [22/Feb/2023:16:57:12 +0000] "GET /nginx HTTP/1.1" 404 153 "-" "ELB-HealthChecker/2.0" "-" 172.16.24.168 - - [22/Feb/2023:16:57:42 +0000] "GET /nginx HTTP/1.1" 404 153 "-" "ELB-HealthChecker/2.0" "-" 172.16.23.100 - - [22/Feb/2023:16:57:42 +0000] "GET /nginx HTTP/1.1" 404 153 "-" "ELB-HealthChecker/2.0" "-"
修正後のnginx.conf
1 # For more information /var/www/src/publicon configuration, see: 2 # * Official English Documentation: http://nginx.org/en/docs/ 3 # * Official Russian Documentation: http://nginx.org/ru/docs/ 4 5 user nginx; 6 worker_processes auto; 7 error_log /var/log/nginx/error.log; 8 pid /run/nginx.pid; 9 10 # Load dynamic modules. See /usr/share/doc/nginx/README.dynamic. 11 include /usr/share/nginx/modules/*.conf; 12 13 events { 14 worker_connections 1024; 15 } 16 17 http { 18 log_format main '$remote_addr - $remote_user [$time_local] "$request" ' 19 '$status $body_bytes_sent "$http_referer" ' 20 '"$http_user_agent" "$http_x_forwarded_for"'; 21 22 access_log /var/log/nginx/access.log main; 23 24 sendfile on; 25 tcp_nopush on; 26 tcp_nodelay on; 27 keepalive_timeout 65; 28 types_hash_max_size 4096; 29 30 include /etc/nginx/mime.types; 31 default_type application/octet-stream; 32 33 # Load modular configuration files from the /etc/nginx/conf.d directory. 34 # See http://nginx.org/en/docs/ngx_core_module.html#include 35 # for more information. 36 include /etc/nginx/conf.d/*.conf; 37 38 server { 39 listen 80; 40 listen [::]:80; 41 server_name _; 42 root /var/www/src/public/; 43 44 add_header X-Frame-Options "SAMEORIGIN"; 45 add_header X-XSS-Protection "1; mode=block"; 46 add_header X-Content-Type-Options "nosniff"; 47 48 index index.php index.html; 49 50 charset utf-8; 51 52 location / { 53 root /var/www/src/public/; 54 try_files $uri $uri/ /index.php?$query_string; 55 } 56 57 location /nginx { 58 root /usr/share/; 59 try_files $uri $uri/ /nginx/html/index.html; 60 } 61 62 location ~ \.php$ { 63 fastcgi_pass unix:/run/php-fpm/www.sock; 64 fastcgi_index index.php; 65 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; 66 include fastcgi_params; 67 } 68 # Load configuration files for the default server block. 69 include /etc/nginx/default.d/*.conf; 70 } 71 72 }
また、Laravelのエラーログは表示されていませんでした。
一番最新のログです。
[2023-02-10 23:56:10] production.ERROR: Call to undefined function Termwind\ValueObjects\mb_strimwidth() {"exception":"[object] (Error(code: 0): Call to undefined function Termwind\\ValueObjects\\mb_strimwidth() at /var/www/src/vendor/nunomaduro/termwind/src/ValueObjects/Styles.php:1043)
最後に
足りていない情報などがありましたら、コメントしていただければ、早めに添付させていただきたいと思います。
また、言葉として足りない箇所やわかりにくい箇所がありましたら、コメントいただければ、修正したいと思います。
何か、ヒントや参考になりますURLなどがありましたら、教えていただけれると幸いです。
よろしくお願いいたします。
コメントいただき、ありがとうございます。
WebサーバーをPrivateにてしている理由は2つあります。
１基本的にアプリケーションのユーザーはAngularから通信を行う。
→Laravel自体が直接インターネットと通信を行わない為、プライベートインスタンスで管理を
したほうがセキュリティを高めると考えた為。
2LaravelはAngularとRDS,S3以外と通信をしない仕様になっている。
→基本的に通信先が決まっているので、パブリックインスタンスではなく、
プライベートインスタンスにしてセキュリティを高める為
以上となります。
よろしくお願いします。
Publicにしないと動かないと思います。
> mike2mike4さん
ALBを経由するのでEC2インスタンスがPublic Subnetにあるかどうかは直接関係はありません。
リバースプロキシを経由させてWEBサーバーをPrivate Subnetに配置するのはよくある構成で特にそこは問題ありません。
そもそも今回の問題はヘルスチェックがうまく行かないことなので関係がありません。
> yamatoさん
Laravelのログにはなにか出てないでしょうか。
また、このアプリケーションはALBを経由しない状態で動くことは確認できていますか？
ALB自体がリバースプロキシのような役割をします。
EC2インスタンスにはALBを経由してアクセスするのでインターネットから直接アクセスできる必要はありませんし、むしろできないほうがいいです。
あえてリバースプロキシと書いたのは、これがALB特有の話ではないからです。
ALB（ELB）配下のインスタンスやECSのコンテナなどをプライベートサブネット内に配置すること自体は、AWSにおける構築の典型的なパターンです。
https://aws.amazon.com/jp/premiumsupport/knowledge-center/public-load-balancer-private-ec2/
>yu_1985さん
ご連絡遅くなってしまい、もうしわけございません。
まずはコメントへのご返答ありがとうございます。
Q.Laravelのログにはなにか出てないでしょうか。
A.Laravelのログに関しては確認を取ることができませんでした。
/storage/logs/laravel.logを確認しても、ALBの動作を確認した日付のログは出力されていませんでした。
「最後に」のすぐ上に確認できた最新のlogだけ出力させていただきました。
Q.また、このアプリケーションはALBを経由しない状態で動くことは確認できていますか？
A.現状確認が取れていることは以下の通りです。
・ローカル環境での挙動
・LaravelとRDSの導通
よろしくお願いいたします。
念の為ですが、設定変更したら一旦インスタンスをターゲットグループから外して、その後再度ターゲットグループ内に入れる操作をしないと一度Unhealthyになったインスタンスに対してリクエストは送られないのでご注意ください。
ALBを経由しない状態で動くことが確認できているのなら、ヘルスチェックのリクエストと通常のリクエストの差異を見るといいでしょう。
実際のリクエストと同様のものを送ったヘルスチェックでなくて構わないのであれば、回答にすでに書いてある（そして既に記載されている）ように、ヘルスチェックのリクエストだけ200を返すようにすればよいです。それを許容するかはサービス側の判断ですが。
ちなみに、そのようなときに便利なnginxの機能としてempty_gifを返す設定があります。
https://qiita.com/yumiyon/items/5cd2c6b4c696355926dc
>yu_1985様
>mike2mike4様
コメントを頂き、ありがとうございました。
解決方法に記載させていただいた方法で解決いたしました。
よろしくお願いいたします。
回答2件
0
ぱっと見る限りだとロードバランサーからアクセスすると$query_stringに値がなにも入らないので、Laravel側で404を返していて、それでNginxのエラーログに残ってないのでは？という気がします。Laravelのログを見てみたら何か出てませんか？
もしこの説が合っていてそれを簡単に解決するなら、ロードバランサーからのアクセスだけnginx.confの設定に任せて（完全に別のディレクトリにヘルスチェック用のindex.htmlを置いて、それが参照されるようにする）、Laravel側へのアクセスは別にnginxでバーチャルホストの設定を切って分けるなどすれば、ヘルスチェックの設定はわりと簡単にできます。
投稿2023/02/22 01:39
編集2023/02/22 01:43
総合スコア4539
ご回答いただき、ありがとございます。
出先のため確認ができない状況にあります。
家に帰宅次第、確認させていただきます。
確認させていただきました。
読みにくくなってしまったので、実行結果は本文に追加させていただきます。
location /nginx で設定されてるのはわかりますが、それがなぜ404になるのかは第三者の私には分からないです。nginx側で404返してるのならnginxのエラーログに「どういうファイルがあることを期待してるか」のログがあると思いますがどうでしょうか（以前の設定だとおそらくLaravelで404を返していたのでエラーログがなかったことは頷けるのですが。逆にnginxにエラーログが出ないなら、その404はLaravelで返してる可能性があるので、nginxの設定が正しく効いてない可能性もあると思います）。
まずはヘルスチェックを通過させること（200を返せるようになること）を第一にして検証を進められるとどうでしょう。まずは単純にデフォルトのドキュメントルートにindex.htmlを置いて、ロードバランサーのPath URLもindex.htmlだけにしてみるとか。とにかくヘルスチェックを通過できないと他のことは何もできませんので。ヘルスチェックのアクセスをレスポンスコードで200を返せることが分かったら、そこから細かい調整をしていった方がいいと思います（nginxのlocationは優先順位やらで色々とややこしいため）。
あと、回答にも書きましたがnginxのバーチャルホストを利用して、ヘルスチェックとLaravel側の設定と完全に切り分けることで、nginx.confの設定をかなり単純化できますので、そちらも検討されるといいかと思います。
ご連絡遅くなってしまい、もうしわけございません。
まずはALBからindex.htmlを取得できるように本日実践したいと思います。
>AbeTakashi様
アンサーを頂き、ありがとうございました。
解決方法に記載させていただいた方法で解決いたしました。
よろしくお願いいたします。
0
自己解決
まず始めに
コメントをしてくださった方、質問をくださった方皆様。
ありがとうございました。
コメントをしてくださった方の助言などを行わせていただいたのですが、
404エラーが解消されませんでした。
そこで、参考URLを元に修正してみたところ、うまく修正できましたので
まとめさせていただきます。
解決方法
nginx.confのserver_nameの箇所をプライベートサブネットのプライベート IPv4 アドレスに変更することでhealthチェックが通るようになりました。
参考にしたURLは以下こちらになります。
参考URL
# For more information /var/www/src/publicon configuration, see: # * Official English Documentation: http://nginx.org/en/docs/ # * Official Russian Documentation: http://nginx.org/ru/docs/ 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; listen [::]:80; server_name プライベート IPv4 アドレス; ＃変更箇所 add_header X-Frame-Options "SAMEORIGIN"; add_header X-XSS-Protection "1; mode=block"; add_header X-Content-Type-Options "nosniff"; charset utf-8; location / { root /var/www/src/public/; index index.php; try_files $uri $uri/ /index.php?$query_string; } location /index.html { root /usr/share/nginx/html; index index.html; } location ~ \.php$ { fastcgi_pass unix:/run/php-fpm/www.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } # Load configuration files for the default server block. include /etc/nginx/default.d/*.conf; } }
投稿2023/02/24 16:24
編集2023/02/24 16:26総合スコア2
確かにこれで直近の問題解決はしますが、インスタンスを入れ替えてIPが変わった瞬間に機能しなくなります。
ServerNameの設定は、リクエストのホスト名がServerNameの値と一致したときにそのブロックの設定を適用するように記述するのですが、そもそもALBしかリクエストを送らない前提ならいっそのことServerNameを設定せずデフォルトでその部分の記述が適用されるのもアリです。
>yu_1985
確かにそうですね。
現在、プライベートインスタンスはセキュリティグループで
ALBからのみ実行できるようにしています。
ですので、server_nameを設定をしないで、ALBからのみリクエストを行えるように
セキュリティグループで制御したいと思います。
ドメインを当てているなら、該当のドメインを使っての接続でのみ機能するようにするといいです。
nginx側で設定してもいいですが、ALBのリスナールールで制御するとサーバー上の状態が減るのでおすすめです。
ご連絡遅くなってしまい、申し訳ございません。
アドバイスありがとうございます。
試してみたいと思います。
あなたの回答
tips
プレビュー
