まずは構成図
AWSにmattermostを、terraformで構築した時の話です。
まずは構築した構成図です。
- ec2インスタンスはauto scaling groupにて最小1の構成で1a, 1cに構築されます
- ALBを踏み台にしてtarget groupに構築したec2を指定して8065ポートでアクセスします(mattermostはデフォルトで8065をリッスンします)
- ALBは↑のtarget groupをForwardでHTTPS(443)でルーティングします
- route53でドメインを取ってCertificate Managerでssl認証させています
- ec2はamazon linux2のt2.micro です
- 他はよくある構成と同じです(割愛します)
502エラーとの出会い
terraform applyでウッキウキで完了を待ち、ドメインを見に行くと、そこに現れたのは502 bad gatewayでした。
しかし焦る事勿れ。awsのec2を状態を見に行きましょう。
今回、ec2でのmattermostをインストールしデーモン化する所もスクリプトで書いているため、terraformでapply complite!と言われても内部ではまだ処理を受け付けてくれていない可能性があります。
しばらく待ちましょう。
!!!502 bad gateway!!!
探したこと
まずはaws環境を見に行き、何かぱっと見で稼働していない部分などがないかを探しました。
するとtarget groupがunhealthyでした。
しかしec2はactiveですし他におかしな部分は見当たらない。
ググってみたところ、以下がよく解決策として挙げられました。
- サーバのKeepAliveTimeoutがtarget groupのIdle Timeout 値よりも長くする
- ALB, target groupのポート設定を正しいものにする(nginxなら80)
- ヘルスチェックのディレクトリパスが正しくない
などなど。。。
特にnginxで80をリッスンしているのにターゲットグループのポートを443にしているケースが多くみられました。
しかしmattermostのポートは8065...ここのあたりはミスはなさそう。
ALBアクセスログも見に行きましたが、ここでも何かおかしな点はありませんでした。
ALBアクセスログの保存設定の仕方は以下の記事がわかりやすかったです
https://dev.classmethod.jp/articles/alb-log-to-s3/
結論: まさかのスクリプト落ち
沼っているところec2にアクセスしてディレクトリを見に行ったところ、、、スクリプトに書いたディレクトリが作成されてなかったりしました。なんじゃこりゃ。
もしやと思いサーバ内を色々探ってみた結果...スクリプトで書いたダウンロード系統が見つからなかったらしく、処理がスキップされていました。
お前！「terraform complite!」ゆうたやんけ！！！
たとえスクリプトファイルでダウンロードが正常にできなくてもterraformは構築は完了したのでcompleteを返します。
というわけで原因は自分が書いたスクリプトの問題でサーバ内部の問題でした。
完全に灯台下暗し。
まずはありがちな部分から探そう
今回ハンズオン学習を除くとterraformで初めてaws基盤を構築しました。
初めて使ってエラーが出ると、未熟さを理解しているが故にまずはその新技術に対応する部分が問題になっているを思い込んでしまいました。
その結果terraformのコードを何度も読み返したりすることになり大変時間を浪費してしまいました。
新技術でも、エラーが出た際にはまずありがちな部分から攻めるべきということを身をもって実感しました。
今回で言うと
- ec2インスタンスはactiveか
- インスタンス内部は問題ないか
- target groupやALBの設定は適切か
- その他基盤設定は問題ないか
と言った順序で攻めるべきでした。
target groupのunhealtyが第一発見だった事...見事に沼りました。