【AWS備忘録】AWS Fargateで「WordPress」ってやつを動かしてみる③（トラブルシューティング等、まとめ）
おはようございますこぐまです。
「もうこの通りやれば、とりあえず「AWS Fargate」で「WordPress」動かせるよ！」
の記事その③です。
①②はこちら。
①②を通して実施すれば、何も問題なければあなただけのWordPressがFargate上で動いているはずです。
しかし、そんなに1発でうまくいかないことも多々あると思いますので、
ここではトラブルシューティング等をまとめていこうと思います。
とその前に、まずは今回いろいろ作成した時のログがどこに出るのか？
それをチェックしていきましょう。
Fargateのログの確認方法
以下の流れでログを確認できます。
1.クラスター画面の「タスク」タブから、ログを見たいタスクのIDをクリックする
2.「ログ」タブを選択する
3.プルダウンからログを見たい「コンテナ」を選択する。
また、「2.「ログ」タブを選択する」の画面の下のほうに、コンテナの情報が表示されます。その中の「ログドライバー: awslogs CloudWatch のログを表示」のリンクをクリックすることで、CloudWatchのログにダイレクトにリンクし表示されます。
ここまでの設定の仕方だと、ロググループ（ログをとりまとめるフォルダ）は「/ecs/test-task」となっているはずです。今まで（失敗も含めて）起動を試みたすべてのログは上記に保存されます。
ダイレクトリンクします。
ロググループ：CloudWatchのログの格納単位です。ログを入れるフォルダみたいなものです。
ログストリーム：個々のログのことです。
これは、「サービス名（ecs）/コンテナ名/タスクID」という名前でストリーム名が付けられます。
その一つ一つが起動したコンテナの記録である。
ログストリーム名は「ecs/wordpress-con/<タスクID>」のような形をとる。
ログの見方はここまでです。
では、トラブルシューティングいってみましょう！
トラブルシューティング
１．タスク定義の書き方をよくよくチェック！
自分の場合、エラーのほとんどはタスク定義の書き方が原因でした。
今回のNote記事のための環境は一発で行けるかなと思っていましたが、環境変数を書く場所でなぜかスペースが入っていて、コンテナが起動できませんでした。
「次のいずれか一つの変数を指定してください」というエラーが出てます。
反転させると、PASSWORDの後ろに空白が入っています。
（おそらくTAB押してしまったかと・・）
タスク定義は、「新しいリビジョンの作成」からどんどん作り直すことができます。なので、失敗を恐れずにガンガン試していくといいと思います。
２．「Error establishing a database connection」
コンテナを立ち上げて、ブラウザでアクセスした瞬間に出るメッセージ。
今回一番見たエラーですね。
これは一言でいうと、「wordpress-conからmysql-conへの接続ができないです～」というシステムの泣きのメッセージです。
これには原因がいくつかあります。
１．接続DBの情報が間違っている。
コンテナの環境変数に必要な項目を過不足なく設定していないといけません。具体的には、以下となります。
【wordpress-con側の環境変数】
①WORDPRESS_DB_HOST
②WORDPRESS_DB_NAME
③WORDPRESS_DB_PASSWORD
④WORDPRESS_DB_USER
【mysql-con側の環境変数】
⑤MYSQL_DATABASE
⑥MYSQL_PASSWORD
⑦MYSQL_ROOT_PASSWORD
⑧MYSQL_USER
また上記のうち、DBの名前（②と⑤）、DBのパスワード（③と⑥）、DBのユーザ（④と⑧）は同じ値でないと接続できません。
２．ヘルスチェックの記載方法が間違っている
これも苦戦した部分です。
ヘルスチェックの部分は一字一句間違えないように入力してください。
CMD-SHELL mysqladmin ping -u testuser -ptestpass -h 127.0.0.1 || exit 1上記をそのまま、ヘルスチェックの入力欄に記載してください。
AWSの説明だと、二重引用符で囲む旨読み取れるのですが、こちら付けないのが正解のようです。(ここもかなり悩みました）
３．環境変数「WORDPRESS_DB_HOST」の値として「localhost」「mysql-con」を指定している。
今回のNoteの記事通り進めれば遭遇はしませんが、私が悩んだ部分として挙げておきます。Fargateはネットワークモードとして「awsvpc」を使います。「awsvpc」とはどういうモードかというと、タスクごとにENIをアタッチできるモードです。つまり、タスクごとにIPおよびセキュリティグループをアタッチできるということです。また、タスク内（タスク間ではなく、タスク内）のコンテナ間の通信はlocalhostとして通信できます。
今回は、タスク内に2つのコンテナを作ったので、「wordpress-con」から「mysql-con」へのアクセスは「localhost」で通信できるのではと思い、
「WORDPRESS_DB_HOST value localhost」と設定しましたが、そうすると
「Error establishing a database connection」となってしまいました。これはmysqlの仕様のようで、localhostと入れるとTCP/IP通信ではなくなるようです。
また、コンテナの名前をホスト名として利用できないかな・・？と思い、
「WORDPRESS_DB_HOST value mysql-con」としましたが、こちらも「Error establishing a database connection」となってしまいました。これはdocker-compose.ymlの時にそのような書き方をするのでタスク定義でも行けるかな～と思ったのですが私が試行した限りでは無理みたいでした。
４．ヘルスチェックおよびコンテナ注文を設定していない
「wordpress-con」と「mysql-con」、どちらが先に立ち上がっていてほしいでしょうか？普通に考えると「mysql-con」ですね。つまりデータベースの準備が整い、アプリケーションからの接続を受け入れることができてから、アプリケーションを立ち上げる・・という順番です。
ヘルスチェックやコンテナ注文（コンテナの依存関係のことです）を入れていない場合、その時の状況により「mysql-con」「wordpress-con」のどちらが先に起動が完了するかわかりません。「mysql-con」が準備できていない状態で「wordpress-con」が接続を試みる場合があります。そうすると「Error establishing a database connection」となります。
ヘルスチェックを設定し、コンテナ注文として「mysql-con」が「HEALTHY」になっていること確認してから「wordpress-con」を立ち上げるように設定することで、この「どちらが先に立ち上がるかわからない」という状態を回避することができます。
主要なトラブルシューティングは以上です！
その他、まとめとか
さてFargateでWordpress（とDB）、起動できたでしょうか？
最後になりますが、3点ほど記載したいと思います。
１．これは検証用です！
この作り方は検証用です。このまま本番運用してはいけないです！
一番の理由は、「データが永続的に保存されないから」です。
「mysql-con」というコンテナが担う役目は、本来はRDSなど別のサービスで
行います。RDSはAWSのマネージドDBであり、永続的なデータの保存、冗長化、バックアップなどかなり使いやすいので、そちらをDBとして使うのがいいかと思います。
別途DBを用意せず、コンテナのままでかつ永続ボリュームが欲しい場合は、
fargateの場合だと、ホストのボリュームを直接マウントするバインドマウントかEFSを利用する方法があります。私も試したことはないので、機会があれば実施してみたいと思います。
いずれにせよ、今回作ったWordPressはコンテナが再作成されたら全部消えます。せっかく作ったブログが一瞬で全部おじゃんに・・という状態にならないよう、あくまで検証用として利用してください。
２．今後の拡張性について
データ永続性の課題を解決できたら、セキュリティグループを緩くして
一般公開することができます。併せてドメインを取得したり、HTTPS通信を実装したりできます。
また、検証のままでも以下のようなことができます。
タスク単体実行ではなく、「ECSサービス」として実行させ、タスクが落ちた時の挙動などを確認できる。
「WordPress＋Mysql」のタスクを複数起動し、ALBやNLBでIPベース、パスベースのルーティングしてみてその動きを確認する。
３．終わりに（なぜこの記事を書こうと思ったか・・）
最後に、なぜこの記事を書こうと思ったのかを書いてみようと思います。
事の始まりはある方から、「今利用しているシステムのURLのパスに追加することで、（別サーバで運用している）WordPressを表示できないか」という質問があったからです。
そのシステムはELB（ALB）を利用しているので、パスベースのルーティングができるということは何となくわかってはいましたが、実際検証してみようと思って、せっかくなら使ったことのないFargateを利用してみようと思いました。
ところが公開されているナレッジのほとんどが、Fargateで作るのは「wordpress-con」だけで「mysql-con」は別構築（RDSとか）になっていました。実運用を考えたら当然ですね。
でも、とりあえずサクッと検証用にFargateでAP（wordpress-con）、DB（mysql-con）どちらも用意できるような記事があってもいいかなと思って書きました。
そして、やってみてやっぱり思うのは、
「実際やってみると予想以上にムズいな～でもわかった時嬉しいな～」
ということです。そしてその体験から、このような記事も書けるし、次はサクッと一瞬で作れるという自信にもつながります。
一番最初に、用意するものは「AWSアカウント」と「好奇心」とだけ書きました。VPCやセキュリティグループなど覚えなきゃいけない部分は他にもたくさんあるのですが、なるべくそれらを簡潔にして書いたつもり・・です。
もしどなたかの好奇心の一助となれば幸いです！
本執筆にあたりたくさんの記事を参考にさせていただきました。
個別にコメント等返させていただきました。
本当にありがとうございました！
この記事が気に入ったらサポートをしてみませんか？