AWSでデプロイしたアプリが突如繋がらなくなった件

##概要
EC２でデプロイしたrailsアプリが数日触ってない間にアクセス不可になってしまい、復旧に苦戦した中で学んだことを備忘録として記述。

##エラー内容

![スクリーンショット 2020-12-10 13.02.34.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/864534/53e72c97-50ff-3016-7120-b87e564b03e7.png)


```
sudo less /var/log/nginx/error.log
ActionController::RoutingError (No route matches [POST] "/Autodiscover/Autodiscover.xml"):
ActionController::RoutingError (No route matches [GET] "/wp-content/plugins/wp-file-manager/readme.txt"):
ActionController::RoutingError (No route matches [GET] "/console"):
ActionController::RoutingError (No route matches [GET] "/index.php"):
ActionController::RoutingError (No route matches [POST] "/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php"):
ActionController::RoutingError (No route matches [GET] "/solr/admin/info/system"):
ActionController::RoutingError (No route matches [GET] "/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php"):
```
自身のPCのネットワークの問題？と思いましたが、知人のPCでもアクセスができませんでした。

##試したこと
・EC２の再起動（ステータス→実行中、ステータスチェック→問題なし）
・unicorn、nginxの再起動

```
ps aux | grep unicorn
ec2-user 10276  0.0  0.0 119436   964 pts/0    S+   04:21   0:00 grep --color=auto unicorn
```
不要なunicornのセッションをkillして再起動しようとしたが、そもそもkillできるセッションが無い状態。

##原因推定
・unicornが起動していない？


```log/unicorn.stderr.log
http_server.rb:205:in `pid=': Already running on PID:13932 (or pid=/var/www/text-31024/tmp/pids/unicorn.pid is stale) (ArgumentError)
```
PID:13932がすでに稼働している？しかし、killでは削除できない。

``sudo rm -f /var/www/text-31024/tmp/pids/unicorn.pid``
で強制的に削除しようとしたがそれも不可。

・nginxの問題？

```
systemctl status nginx
Loaded: loaded (/usr/lib/systemd/system/nginx.service; disabled; vendor preset: disabled)
Active: active (running) since 木 2020-12-10 05:29:38 UTC; 1 day 19h ago
systemd[1]: Failed to read PID from file /run/nginx.pid: Invalid argument
```
何やらエラーっぽいのが出ているが、調べた所、こちらは直接的な原因では無いっぽい。

##解決
・ポート：３０００がlisten状態になっていなかった。

``netstat -atn|grep LISTEN``
コマンドでサーバ上で開放されているそれぞれのポートの状態を確認することができます。

```
[ec2-user@ip-172-31-43-44 text-31024]$ netstat -atn|grep LISTEN
tcp        0      0 0.0.0.0:3306            0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN     
tcp6       0      0 :::111                  :::*                    LISTEN     
tcp6       0      0 :::80                   :::*                    LISTEN     
tcp6       0      0 :::22                   :::*                    LISTEN     
```

ん？ポート:3000が無くね？

https://chopesu.com/aws/nginx-change-port/
こちらのサイトを参考に、unicornの設定ファイルを確認。

```unicorn.rb
#ポート番号を指定
listen "#{app_path}/tmp/sockets/unicorn.sock"
```
nginxの設定に合わせる為に、この記述をしておりましたが、なんらかの理由で
このパスでは接続できなくなってしまった。

```unicorn.rb
#ポート番号を指定
listen 3000
```

に変更。


```
[ec2-user@ip-172-31-43-44 text-31024]$ netstat -atn|grep LISTEN
tcp        0      0 0.0.0.0:3306            0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:3000            0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN     
tcp6       0      0 :::111                  :::*                    LISTEN     
tcp6       0      0 :::80                   :::*                    LISTEN     
tcp6       0      0 :::22                   :::*                    LISTEN     
```

ポート:3000がlisten状態に！！そして、111、80、22にもとりあえず影響はなさそう！！
ということで、EC2上で再起動したらサイトにアクセスできるようになりました。

https://itengine.seesaa.net/article/442155338.html
ポート番号関連のコマンドはこちらのサイトも参考になります。

アクセスはできるようになったものの、果たしてこのままで今後の開発に支障が無いのか？
そもそも数日全く触っていなかったにも関わらず何故このようなエラーが起きたのかがまだ不明です。ネットワークの基礎の部分から勉強しないといけないな、と感じました。

また、セキュリティの虚弱性からアタックを受けてサーバがダウンしてしまうこともあるようなので、Basic認証、IP制限等のセキュリテイ対策の重要性も再認識した出来事となりました。