English below the Japanese
背景
Amazon ECS on EC2を使用してVue、Laravel、MySQLを実行する3つのDockerコンテナを構築した際に直面した特定の問題について述べます。この問題は、タスクが不定期に約一日に一回自動的に終了し、再起動する現象です。
環境
- コンテナA：Vueを実行（専用のDockerボリュームあり）
- コンテナB：Laravelを実行（専用のDockerボリュームあり）
- コンテナC：MySQLを実行（専用のDockerボリュームあり、再起動によるデータ損失あり）
これらのコンテナは、それぞれ専用のDockerボリュームを持ち、EC2インスタンス上の一つのクラスターを介して一つのタスクとして定義され、各ボリュームがホストマシンにマウントされています。
問題の特定過程
タスクが不定期に再起動するため、AWSでは停止したタスクの情報は約1時間しか保持されません。そこで、以下のURLに従い、タスクの停止原因をCloudWatch Logsに記録することにしました。
参考URL
エラーメッセージ「Essential container in task exited」により、あるコンテナの停止が全体のタスク再起動を引き起こしていることが示唆されました。特に、MySQLコンテナCの再起動がデータ損失を引き起こしていたため、このコンテナが原因であると考えられました。
解決策
ホストマシン上のMySQLコンテナCのDockerボリュームのファイル権限を確認したところ、rootユーザーにのみ書き込み、読み取り、実行権限があることが分かりました。この制限がMySQLコンテナCがボリュームへの書き込みに失敗し、再起動される原因である可能性がありました。
そこで、MySQLコンテナCのボリュームのファイル権限を777に変更しました。この変更により、現在は問題なく稼働しており、新たな問題は発生していません。
Background
I faced a specific problem when setting up three Docker containers to run Vue, Laravel, and MySQL using Amazon ECS on EC2. The issue was that the tasks would automatically stop and restart about once a day at irregular intervals.
Environment
- Container A: Running Vue (with a dedicated Docker volume)
- Container B: Running Laravel (with a dedicated Docker volume)
- Container C: Running MySQL (with a dedicated Docker volume, experiencing data loss due to restarts)
These containers each had their dedicated Docker volumes and were defined as a single task through a cluster on an EC2 instance, with each volume mounted on the host machine.
Process of Identifying the Problem
Since the tasks were restarting irregularly, AWS only retains information about stopped tasks for about an hour. Therefore, following the instructions at the URL below, I set up to record the reasons for task stoppage in CloudWatch Logs.
Reference URL
The error message "Essential container in task exited" suggested that the stopping of a particular container was triggering the restart of the entire task. Especially, the restarts of the MySQL container C were causing data loss, leading to the conclusion that this container was the culprit.
Solution
Upon checking the file permissions of the Docker volume for the MySQL container C on the host machine, it was found that only the root user had write, read, and execute permissions. This restriction could have been causing the MySQL container C to fail writing to the volume, leading to its restart.
Consequently, I changed the file permissions of the volume for MySQL container C to 777. Since this change, the system has been operating smoothly without any new issues arising.