ECS on FargateでLaravelを動かすときにはまったこと

ソフトウェアエンジニアの小野寺です。先日、自社サービスのリニューアルで新たにコンテナ環境でサービスを稼働するタスクを担当させていただきました。その際につまづいたこと、ハマったことを書こうと思います。インフラ環境はアプリケーションはECS on Fargate、データベースはRDS（エンジン:Aurora MySQL、以下MySQLと表記）です。

1.Dockerクライアントの認証

ECRにDockerイメージをpushする際に~/.aws/credentialsのユーザーでログインしますが、指定がなければdefaultユーザーになります。私のローカルdefaultユーザーは対象のAWS環境にログインできないユーザーだったため、新たなユーザーを作成してECR操作に必要なロールをアタッチしました。

デフォルト

[default]
aws_access_key_id=AKIAIOSFODNN7EXAMPLE
aws_secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

$aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin 694119307320.dkr.ecr.ap-northeast-1.amazonaws.com

以下のように追記・変更しました。

profile指定

[default]
aws_access_key_id=xxxxxxxxxxxxxxxxxxxxxxxx
aws_secret_access_key=xxxxxxxxxxxxxxxxxxxxxxxx

[new-user]
aws_access_key_id=xxxxxxxxxxxxxxxxxxxxxxxx
aws_secret_access_key=xxxxxxxxxxxxxxxxxxxxxxxx

$aws ecr get-login-password --region ap-northeast-1 --profile new-user | docker login --username AWS --password-stdin 694119307320.dkr.ecr.ap-northeast-1.amazonaws.com

参考：https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-configure-files.html

※new-userでアクセスできるようになりましたが、そもそもあまり使わないユーザーがdefaultのままだと事故リスクがある、と指摘をもらったのでdefaultユーザーは使わず、原則profileオプションを付けてアクセスする方針にした

参考：AWS CLI を設定する環境変数 - AWS Command Line Interface

2.health_checkエラー

イメージからサービスを作ったところ404エラーが発生しました。ローカルのイメージをそのままpushしていたのでエラーは想定内でしたが、health_checkパス /でレスポンスコード200が返ってこないため、1分ぐらいでサービスが自動停止してしまい、調査したいけどコンテナの中に入れない状態になってしまってました。対策としてnginx.confにhealth_check用のlocationディレクティブを設定してempty_gifを返すようにして、レスポンスコード200が返ってくるようにしました。

 location /health_check {
            empty_gif;
 }

参考：ELBなどでhealth checkをする際に使える便利なempty_gif（Nginx）

3.HTTPSとHTTPのmixContentsエラー

HTTPS通信していましたが、ALBを使っているのでプロキシから先はHTTPで通信しています。そのためasset関数はhttp://xxxxxになってしまい、通信はHTTPS、読み込む静的ファイルはHTTPで混在となり、mixContentsエラーが発生しました。

ロードバランサのIPアドレスを固定できない状態を許容するため$proxies プロパティにワイルドカードを設定して、プロキシー全信頼で対応しました。ただ、もっと良い対応方法などもありそうな気がするので暫定対応としています。

protected $proxies = '*'; //　protected $proxies;　を変更

参考：AWSのELB(ALB)を使ってLaravelのアプリをリリースしたとき「Mixed Content: The page at ‘‘ …」

4.DBの確認

ECS EXECでコンテナに入って、migrationを実行しました。 MySQLにアクセスして実際にテーブル作成を確認したく、踏み台サーバの構築やDBに一時的に穴をあけて直接つなげる、Cloud9から接続、などの方法がありますが、今回はCloud9を使ったことがなかったため、Cloud9で確認する方法を取りました。 EC2が立ち上がるのでコストがかかってしまいますが、ちょっと確認したいときに便利なサービスだと思いました。

image.png (210.7 kB)