AWSデプロイ　Health checks failed with these codes: [302]　を解消したい。

前提・実現したいこと

AWS targets statusのunhealthyを解消して、デプロイしたい。

もともと
docker→circleci→capistrano
でmasterブランチにいる際にプッシュすれば、デプロイが出来ていたのですが、

誤って、ローカルからbundle exec cap production deployコマンドを入力してしまいました。
その後、そのコマンドではエラーは出なかったのですが、
サイトにアクセスすると、このサイトにアクセスできませんのエラーとなりました。

AWSのターゲットを確認すると、unhealthyになってしまっていました。

その後、mastarブランチでpushを行い、circleciを確認すると、デプロイはsuccessとなるのですが、
サイトは変わらず表示されず
AWSもunhealthyのままです。

発生している問題・エラーメッセージ

AWS ターゲットグループ

Health checks failed with these codes: [302]

less log/unicorn.stderr.log

Can't connect to local MySQL server through socket '/var/l
ib/mysql/mysql.sock' (2) (Mysql2::Error::ConnectionError)

ローカルのエラー？関係なし？

該当のソースコード

yaml
1version: 2.1
2
3executors:
4  default:
5    docker:
6      - image: circleci/ruby:2.6.5-node-browsers
7        environment:
8          - BUNDLER_VERSION: 2.1.4
9          - RAILS_ENV: 'test'
10
11      - image: circleci/mysql:5.7
12        environment:
13          - MYSQL_ALLOW_EMPTY_PASSWORD: 'true'
14          - MYSQL_ROOT_HOST: '%'
15
16    working_directory: ~/CustomerCalender
17    
18commands:
19  setup:
20    steps:
21      - checkout
22
23      - restore_cache:
24          keys:
25          - v1-dependencies-{{ checksum "Gemfile.lock" }}
26          - v1-dependencies-
27
28      - run:
29          name: install dependencies
30          command: |
31            gem install bundler -v 2.1.4
32            bundle install --jobs=4 --retry=3 --path vendor/bundle
33      - save_cache:
34          paths:
35            - ./vendor/bundle
36          key: v1-dependencies-{{ checksum "Gemfile.lock" }}
37
38jobs:
39  test:
40    executor: default
41    environment:
42      RAILS_ENV: test
43    steps:
44      - setup
45      - run: mv config/database.yml.ci config/database.yml    
46      - run: bundle exec rake db:create
47      - run: bundle exec rake db:schema:load
48
49    # - run:
50    #     name: Rubocop
51    #     command: bundle exec rubocop
52
53      - run:
54          name: run tests
55          command: |
56            mkdir /tmp/test-results
57            TEST_FILES="$(circleci tests glob "spec/**/*_spec.rb" | \
58              circleci tests split --split-by=timings)"
59            bundle exec rspec \
60              --format progress \
61              --format RspecJunitFormatter \
62              --out /tmp/test-results/rspec.xml \
63              --format progress \
64              $TEST_FILES
65
66      - store_test_results:
67          path: /tmp/test-results
68      - store_artifacts:
69          path: /tmp/test-results
70          destination: test-results
71  deploy:
72    executor: default
73    steps:
74      - setup
75      - add_ssh_keys:
76          fingerprints:
77            - "e6:86:c2:2a:c4:91:de:e4:8f:7c:1a:08:aa:fc:2e:e3"
78      - deploy:
79            name: Capistrano deploy
80            command: bundle exec cap production deploy
81
82workflows:
83  test_and_deploy:
84    jobs:
85      - test
86      - deploy:
87          requires:
88            - test
89          filters:
90            branches:
91              only: master

database.yml

yaml
1省略
2default: &default
3  adapter: mysql2
4  encoding: utf8
5  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
6
7development:
8  <<: *default
9  database: CustomerCalender_development
10  host: db
11  username: root
12  password:
13  socket: /tmp/mysql.sock
14省略
15production:
16  <<: *default
17  database: <%= ENV['DB_DATABASE'] %>
18  adapter: mysql2
19  encoding: utf8mb4
20  charset: utf8mb4
21  collation: utf8mb4_general_ci
22  username: <%= ENV['DB_USERNAME'] %>
23  password: <%= ENV['DB_PASSWORD'] %>

Dockerfile
1FROM ruby:2.6.5
2
3RUN curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add - \
4    && echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources.list.d/yarn.list
5RUN apt-get update -qq && \
6    apt-get install -y build-essential \
7                       libpq-dev \
8                       nodejs \
9                       vim \
10                       yarn
11
12RUN mkdir /CustomerCalender
13
14WORKDIR /CustomerCalender
15
16COPY Gemfile /CustomerCalender/Gemfile
17COPY Gemfile.lock /CustomerCalender/Gemfile.lock
18
19ENV BUNDLER_VERSION 2.1.4
20RUN gem install bundler
21RUN bundle install
22RUN yarn install
23
24COPY . /CustomerCalender
25
26RUN mkdir -p tmp/sockets
27RUN mkdir -p tmp/pids

docker-compose.yml

yaml
1version: '3'
2
3services:
4  db:
5    image: mysql:5.7
6    volumes:
7      - mysql-data:/var/lib/mysql
8    ports:
9      - "4306:3306"
10
11  app:
12    build: .
13    command: bundle exec puma -C config/puma.rb
14    volumes:
15      - .:/CustomerCalender
16      - public-data:/CustomerCalender/public
17      - tmp-data:/CustomerCalender/tmp
18      - log-data:/CustomerCalender/log
19    tty: true
20    stdin_open: true
21    depends_on: 
22      - db
23    links: 
24      - db
25
26  web:
27    build:
28      context: containers/nginx
29    ports:
30      - 80:80
31    volumes:
32      - public-data:/CustomerCalender/public
33      - tmp-data:/CustomerCalender/tmp
34    tty: true
35    stdin_open: true
36    depends_on: 
37      - db
38    links: 
39      - db
40  
41
42
43volumes:
44  mysql-data:
45  public-data:
46  tmp-data:
47  log-data:

試したこと

本番環境にて
・mysql再起動　sudo systemctl restart mariadb
・unicorn ps→kill
・nginx再起動
・less log/unicorn.stderr.log

AWSにて
ロードバランサー削除→作成
ターゲットグループ削除→作成

補足情報（FW/ツールのバージョンなど）

ruby '2.6.5'
rails　'6.0.0'
unicorn, '5.4.1'
nginx
circleci
docker
capistrano

ローカルでbundle exec cap production deployを入力したのが原因だと思うのですが、
解決方法が分かりませんでしたので、質問させて頂きました。
宜しくお願い致します。

行動規範の内容に同意します

回答1件

ベストアンサー

302なので、ALBがヘルスチェックのためにEC2インスタンスに送ったリクエストがリダイレクトされているのではないでしょうか。

ヘルスチェックはALBがEC2インスタンスに対して指定したポート、パス、プロトコルでリクエストを送り、そのレスポンスが指定したレスポンスコードか否かによってOKかNGかを判定しています。
デフォルトだと200以外はNGなので302でもヘルスチェックに失敗します。

よくあるのはALB配下にあるにも関わらずhttp→httpsのリダイレクトをしてしまうことですが、その場合通常は３０１のリダイレクトを使用するので別のところでリダイレクトしてる可能性があります。
その他の原因はリクエストを送るパスに問題があるかですね。
どのようにリダイレクトされているかはログを見ないとわからないですが、ヘルスチェックの設定でパスを指定できるので、リダイレクトが発生しないようなパスがあればそこにリクエストを送ってもいいでしょう。

あまりお勧めしない方法としては、ヘルスチェックがOKとみなすレスポンスコードの対象に３０２を追加することですね。
これは200 OK でないレスポンスを許可してるというだけなので根本解決にはなりません。

投稿2021/01/18 16:44

yu_1985

総合スコア7588

a-ichi

2021/01/19 02:19 編集

yu-1985様いつも回答ありがとうございます。ヘルスチェックの設定を変更して、302を許可したのですが、仰る通り、根本的な解決にはなっていないようでした。 302に変更するとhelthyにはなりました。http://××.××.××.××/ではアクセス出来るようになりました。変更内容も反映されていました。 httpsのhttps://customer-calender.com/こちらでは表示されませんでした。この原因はdockerやcircleciが原因ではなく、 database.ymlかAWSが原因なのでしょうか？

a-ichi

2021/01/19 01:55 編集

unicornのlogがこちらです。最新が、1/4となっているので、関係無いですかね？ ArgumentError) from /home/ec2-user/.rbenv/versions/2.6.5/lib/ruby/gems/2.6.0/gems/unicorn-5.4.1/lib/unicorn/http_server.rb:137:in `start' from /home/ec2-user/.rbenv/versions/2.6.5/lib/ruby/gems/2.6.0/gems/unicorn-5.4.1/bin/unicorn_rails:209:in `<top (required)>' from /home/ec2-user/.rbenv/versions/2.6.5/bin/unicorn_rails:23:in `load' from /home/ec2-user/.rbenv/versions/2.6.5/bin/unicorn_rails:23:in `<main>' I, [2021-01-04T05:57:18.038358 #16916] INFO -- : reaped #<Process::Status: pid 16924 exit 0> worker=0 I, [2021-01-04T05:57:18.038500 #16916] INFO -- : master complete I, [2021-01-04T05:57:21.275149 #17106] INFO -- : Refreshing Gem list I, [2021-01-04T05:57:22.441693 #17106] INFO -- : listening on addr=0.0.0.0:3000 fd=9 I, [2021-01-04T05:57:22.446858 #17106] INFO -- : master process ready I, [2021-01-04T05:57:22.450431 #17114] INFO -- : worker=0 ready I, [2021-01-04T07:03:25.720807 #17106] INFO -- : reaped #<Process::Status: pid 17114 exit 0> worker=0 I, [2021-01-04T07:03:25.721372 #17106] INFO -- : master complete I, [2021-01-04T07:03:34.498219 #17953] INFO -- : Refreshing Gem list I, [2021-01-04T07:03:35.634133 #17953] INFO -- : listening on addr=/var/www/CustomerCalender/tmp/sockets/unicorn.sock fd=9 I, [2021-01-04T07:03:35.639628 #17953] INFO -- : master process ready I, [2021-01-04T07:03:35.643235 #17961] INFO -- : worker=0 ready I, [2021-01-04T07:53:11.814914 #17953] INFO -- : reaped #<Process::Status: pid 17961 exit 0> worker=0 I, [2021-01-04T07:53:11.815057 #17953] INFO -- : master complete (END)

a-ichi

2021/01/19 02:21

ヘルスチェックがunhealthyの状態でも、http://××.××.××.××/に接続出来る事が確認取れました。ということはhttps通信だけおかしいという事でしょうか？

yu_1985

2021/01/19 02:50

> ヘルスチェックがunhealthyの状態でも、http://××.××.××.××/に接続出来る事が確認取れましたリダイレクトはエラーではないのでアクセスは出来るでしょう。特に間違った挙動ではなくて、アクセスした上で何かしらリダイレクトの処理が走っています。それがnginxによるものなのかアプリによるものなのかこちらからは判断がつかないので、回答に書いたような複数の可能性を検証してほしいということです。少なくともcircleciは何の関係もありません。また、上記の通りリダイレクトはエラーではないのでエラーログに出るものではないでしょう。ヘルスチェックはデフォルトではトップにアクセスするので、トップへのアクセスで何らかのリダイレクトを行う処理をnginxなりRails（unicorn）なりで行っているのではないですか？ > ということはhttps通信だけおかしいという事でしょうか？ドメインを設定しているのがALBという前提で話しますが、クライアントからhttpで通信するかhttpsで通信するかについてはあくまでもALBに対する通信なので、ALBからEC2インスタンスに対する通信がどうかについては関係ありません。上記と違いhttp://××.××.××.××/　というのがEC2インスタンスのIPを指定しているのであれば、それはEC2インスタンスに直接接続しに行っているのだから接続できるのが正しい挙動でしょう。どうリダイレクトが発生しているのか自分でよくわからないのであれば、ブラウザの開発者ツール（F12）とかで挙動を確認するのもいいです。

a-ichi

2021/01/21 08:10 編集

yu_1985様コメントありがとうございます。 IPアドレスに繋がるのはおかしい事では無いのですね。他に原因がありそうですので、原因を探ってみます。ありがとうございました。

行動規範の内容に同意します