addictionwhite’s diary

考え中のことを整理と忘備録のために綴ります。ここに書かれている考えは翌日には変わる可能性があります

ecsでLaravelのトップページ表示まで

AWS ECS

最近インプットしないといけないことが多くて細切れでも綴ったほうがよいと感じたため
（区切りまですすめると、保留になってどんどん記憶が古くなってしまう）

docker-composeでローカル環境でLaravel表示するところまでは前提（これは適当にwebで公開されているものを引っ張ってきた）

docekr-composeで定義されているイメージをECRにpushする

  • まずECRにリポジトリを生成する
  • リポジトリのURIをdocker-composeのimageにecrのリポジトリをセットする。 すでにimageをセットしている（公式のimage指定しているようなやつ）はそれもDockerfileにわけてimageとbuildをわけて記述した

before

image: nginx:1.15.6

after

  web:
      #image: nginx:1.15.6
    image: xxxxxxxxxxx(ecrリポジトリURL)
    build:
      context: ./
      dockerfile: ./docker/web/Dockerfile

Dockerfileには

FROM nginx:1.15.6

と指定してある

docker-compose build
docker-compose push

でecrのリポジトリにpushできる。 （最初docker-composeで構成されたイメージをひとつひとつ生成しないといけないと思っていたのでこれは楽で助かる）

pushしたあと気づいたけどmysqlのイメージは別にいらなかったと思う（RDS使う想定なので）

ECRのイメージからLaravelのトップページを表示する

かなり苦戦した。ECSでのデバッグの流れがわかっていないのと、ローカルとの差異をイメージしきれていなかったため。

最初に単純に生成したECRのイメージからページを叩くと「このページにはアクセスできません」的なエラーが出る
ここでいくつか原因を考える

  • VPCやロードバランサーまわりでアクセスできない
  • ECSのタスク定義をミスっている（割と適当に設定したので）

とりあえず問題の切り分けがしたかったのでECSインスタンスにHTTPのセキュリティグループがついているか確認する。
（一旦ロードバランサーとか経由させずにECSコンテナから直接画面を表示するように試みる）

ローカルでLaravelの画面はでていたので、タスク定義がなんとなくいけないのだろうなと思い少し適当にいじるがうまくいかない。
以前ECS触ったときに試行錯誤を延々と実施してどん詰まりになったので一旦どのようにデバッグすればいいかを考える。
（インフラ周り難しいのでとりあえずゴリ押しでトライアンドエラーで動かして動いたのを逆算して腹落ちさせる悪癖？があるのだけど、複雑なものになってくるとそれが通用せず延々と時間が溶ける）

ECSでデバッグする方法を考える

  • CloudWatchでログを見る（正統派っぽいけど、これ一見ログはかれていないように見える。ログ吐かせる準備ができてないのか見方間違えているのか）
  • ecs-cliでログを見る（あまり調べてないので見れるかわからない。見れそうと思っただけ
  • ECSコンテナに入ってローカルのときと同じようにデバッグする

邪道で泥臭い気もしたけどECSコンテナに入ってローカルと同じような形でデバッグする方法を取る (今回はEC2採用しているのでいいけど、FargetってSSHできなかった気がするけどどうデバッグするのだろう)。

ECSコンテナの鍵はクラスターの設定時に設定するので新しいクラスタを定義（鍵指定するの忘れていたため）。
ECSコンテナのセキュリティグループにSSHのポートを追加して入る。

ECSコンテナ（いって基本はEC2）でdocker ps叩くとphpとnginxのコンテナが動いている
（ecs agentも動いている。存在は知っていたのだけど実際にいると「へぇ」って気持ちになる）。
nginxのコンテナに入ってtailして再度URL叩いてみるがログは吐かれない。
docker logs -f でnginxのログ出るか試みるがやはりログは吐かれない。
そもそもnginまでたどり着いていないと認識する
（そもそもたどり着いていたら404とかfile not foundとか出るだろうから慣れている人はその画面みてもうすぐさま判断するのだるか）

よくよく調べてみるとローカルのdocker-composeの方でnginxのポートが80以外に指定されており、
AWSのセキュリティグループのHTTPは80に指定されていた。
AWSの方のポートの変え方がぱっとわからなかったのでローカルのポートを80にして再度イメージをpushして、再度タスク定義を作り直すとコンテナのURLを叩くと「file not found」の画面とnginxのログが出た

file not foundがでたということはnginxの設定かphp側のファイルの配置場所が悪いのだとあてをつけて、ECSコンテナの中でそれぞれnginxとphpのコンテナに入って調べる

  • nginxの設定ファイルが反映されていない
  • phpのコンテナにファイルが配置されていない

要はローカル環境のdocker-composeでvolumes(マウント）していたファイルをイメージに含めていなかったというのだけれど、
当たり前といったら当たり前だけどローカル環境でしか使っていなかったゆえの意識の漏れって感じがした。
単純にDockerfileでそれぞれ欲しい物(nginxの設定ファイル,Laravelのファイル）をCOPYで追加して再度イメージをプッシュしてタスク定義を作り直し、 再度クラスタからECSコンテナを立ち上げるとLaravelのトップページが表示された。

ただDBには接続されていないし、デプロイ周りの自動化もできていないし、諸々課題が山積みに感じる（一応メモだけ残している）
それでもひとまずトップページが出たことに一旦安堵している。

備考 docker-coposeのcontextの記述漏れで一部ハマった
（nginxにはcontext指定しているのに、phpには漏れていて、phpのDockerfileだとCOPYコマンドが失敗する現象がおきた

ERROR: Service 'php' failed to build: COPY failed: xxxxxxxxxxxxxxxxxxxx : no such file or directory

phpのコンテナに配置するのはディレクトリだったのでそこらへんが問題かと思って延々と調べていたが、原因はdocker-copmposeの指定の方だった。