Day13：実務課題（中盤）
テーマ：React（フロント）＋API（バックエンド）＋MySQL（DB）を “本当に動く Compose 構成” として組み立てる
中盤では、前半で理解した
「3つのコンテナがどう連携するか」
という全体像を、実際の docker-compose.yml を書きながら 動く形に落とし込む ところまで進めます。
ここを理解すると、あなたは
「実務で使われる3層構成を Docker Compose で再現できるエンジニア」
になります。
Compose で統合する“本番レベルの構成”を作る
まずは全体の Compose を書いてみる
以下は、React（frontend）・API（backend）・MySQL（db）をまとめた 最小構成の Compose です。
version: "3.9"
services:
frontend:
build: ./frontend
ports:
- "3000:3000"
environment:
REACT_APP_API_URL: http://api:4000
depends_on:
- api
api:
build: ./api
ports:
- "4000:4000"
environment:
DB_HOST: db
DB_USER: user
DB_PASSWORD: password
DB_NAME: myapp
depends_on:
- db
db:
image: mysql:8
environment:
MYSQL_ROOT_PASSWORD: password
MYSQL_DATABASE: myapp
MYSQL_USER: user
MYSQL_PASSWORD: password
volumes:
- db-data:/var/lib/mysql
volumes:
db-data:
ここから、重要ポイントを1つずつ深掘りしていきます。
React → API の接続を service名で行う理由を深掘りする
React の API URL は localhost ではない
React はブラウザで動くため、http://localhost:4000 にアクセスすると ホストPC を見に行きます。
しかし、Docker Compose で動かす場合、
API は api コンテナ の中で動いています。
だから、React から API にアクセスするには：
http://api:4000
と書く必要があります。
なぜこれで届くのか
Compose は
同じ docker-compose.yml に書かれたサービス同士を同じネットワークに入れる
ため、service名が DNS として使えるからです。
frontend → api
api → db
この “名前解決” が Docker Compose の最大の強みです。
API → DB の接続も service名で行う
API の環境変数
environment:
DB_HOST: db
DB_USER: user
DB_PASSWORD: password
DB_NAME: myapp
API のコードでは：
const connection = mysql.createConnection({
host: process.env.DB_HOST, // "db"
user: process.env.DB_USER,
password: process.env.DB_PASSWORD,
database: process.env.DB_NAME,
});
このように、
コードは環境変数を見るだけ
という構造にするのが実務の基本です。
MySQL の永続化を深掘りする
なぜ永続化が必要なのか
コンテナは消えると中身も消えます。
しかし、DB のデータは消えてはいけません。
そこで、MySQL のデータディレクトリ /var/lib/mysql を
ボリュームに紐づけます。
volumes:
- db-data:/var/lib/mysql
これで何が起きるか
- コンテナを削除してもデータは残る
- MySQL のアップデートも安全に行える
- 本番環境と同じ「永続化された DB」を再現できる
これは実務で必須の考え方です。
depends_on の役割を深掘りする
起動順序を保証する
frontend:
depends_on:
- api
これは
「frontend は api より後に起動してね」
という意味です。
同様に：
api:
depends_on:
- db
API は DB より後に起動します。
ただし注意
depends_on は
「起動順序」だけを保証し、DB が完全に起動したかは保証しない
という点が重要です。
実務では healthcheck を使って
「DB が本当に起動したか」を確認することもあります。
中盤で理解すべき“Compose の本質”
ここまでの内容をまとめると、Compose の本質は次の3つです。
1. 複数コンテナを“1つのアプリケーション”として扱える
React・API・DB をまとめて起動・停止できる。
2. service名で接続できる
localhost を使わず、
frontend → api
api → db
という構造が自然に作れる。
3. 永続化と環境変数管理ができる
実務の必須要素を Compose だけで再現できる。
中盤まとめ
あなたがここまで理解できていれば、中盤はクリアです。
- Compose で React＋API＋MySQL を統合できる
- service名で接続する理由が説明できる
- 永続化（volume）の意味が理解できる
- 環境変数で設定を外出しする実務的構成が分かる
- depends_on の役割を理解している